Blocklist Additions

[sidki3003]

Regarding that cpmstar ad at animesuki.com, server.cpmstar.com is an ad server, mainly for game sites, i've added it to the AdHosts list.

[43unite]

A few more from Log_Rare

[sidki3003]

Thanks. That "camouflaged script" entry is a false positive. I'll attach the fixed filter.

[43unite]

Thank you.

[sh8an]

hi all. I have several questions.
1. Does sAdkey work from IncludeExclude-U List? If no, is it possible to make it so in order to retain user specific additions during upgrades. For info my IncludeExclude-U file is located outside original sidki directory structure.

2. slightly related question. i had the following two lines in IncludeExclude-U
(*.|)photofile.ru/ $SET(keyword=$GET(keyword)f_cookie.a_target.)$SET(sCookieP=2)$SET(sCookieF=accept=1)
(*.|)photofile.ru/ $SET(sAdKey=.c_right.rightWhite.bok.medialand_adland.)
exactly in that order. when the page is opened the first line gets ignored. can anybody enlighten me why?

thanks in advance.

[sidki3003]

(May. 19, 2009 03:24 PM)sh8an Wrote:  1. Does sAdkey work from IncludeExclude-U List? If no, is it possible to make it so in order to retain user specific additions during upgrades.

No. Good idea!

The default entries will continue to be in a separate list, AdKeys-S, because that way they only need to be scanned for HTML documents.

However, for user entries it's probably just fine (as long as you don't add hundreds).

To do this, replace the URL Match in "Manage: Specific Containers on sel. Sites" with:

Code:

$TYPE(htm)($LST(AdKeys-S)|$TST(sAdKey=*))

Quote:2. slightly related question. i had the following two lines in IncludeExclude-U

It's explained in the top comment of both IncludeExclude lists.
That explanation is confusing though, and it doesn't cover enough.

Here is the updated one:

Code:

#  URL expression syntax:
#       Exactly one page:                     www.mysite.com/mydir/mypage.html
#       One hostname:                         www.mysite.com/
#       The whole domain:                     ([^/]++.|)mysite.com/
#       All subdomains:                       [^/]++.mysite.com/
#       All primary subdomains:               [^.]+.mysite.com/
#       All primary subdomains except "www":  [^.]+.mysite.com/&(^www.)
#
#  Each URL expression must match only once!
#       Incorrect:
#       [^.]+.yahoo.com/                                $SET(0=a_rdlink.)
#       login.yahoo.com/config/                         $SET(0=a_redir.)
#
#       Correct:
#       [^.]+.yahoo.com/&(^login.yahoo.com/config/)     $SET(0=a_rdlink.)
#       login.yahoo.com/config/                         $SET(0=a_redir.)
#
#  You can apply multiple exception keywords to the same entry by
#  concatenating them, each keyword followed by a dot:
#       www.dummysoftware.com/                          $SET(0=a_js.a_ads.)

Quote:(*.|)photofile.ru/ $SET(keyword=$GET(keyword)f_cookie.a_target.)$SET(sCookieP=2)$SET(sCookieF=accept=1)
(*.|)photofile.ru/ $SET(sAdKey=.c_right.rightWhite.bok.medialand_adland.)

The "sCookieP" global variable, if present, must only have a value of 0 or 1. Any other value prevents the faked cookie from being applied.


So, for your entry that translates to (keep indent!):

Code:

([^/]++.|)photofile.ru/ $SET(0=f_cookie.a_target.)$SET(sCookieF=accept=1)
  $SET(sAdKey=.c_right.rightWhite.bok.medialand_adland.)

[sh8an]

the reason for sCookieP=2 is that on some specific sites faked cookie content has to be appended to existing values so i had to change the match&replace on "Cookie: 2 Fake Cookies on sel. Sites 7.07.24 [sd] (d.0 l.3) (Out)" to

Code:

Match = "\0&($TST(sCookieP=0(^$TST(\0=*))|1$SET(1=; \0)|2$SET(2=\0; ))$SET(sCookieP=)|(^$TST(sCookieP=*)))"
Replace = "\2$GET(sCookieF)\1$SET(sCookieF=)"

[sh8an]

hi all. I have a question again
is there a way of filtering content surrounded with comment pairs without thinkering with developer lists? something similar to making additions to $LST(IncludeExclude-U)
Obviously i can make an additional filter but would like to ensure consistent approach to filtering plus avoid spawning unnecessary filters especially when similar logic already exists.
for example there is a page 2baksa.net with something like this

Code:

<!-- Reklama Popander1-->
<link rel="stylesheet" href="http://traf.biz/pop_mp11.css" type="text/css">
<SCRIPT TYPE="text/javascript" LANGUAGE="JavaScript" SRC="http://traf.biz/pop_mp11.js"></SCRIPT>
<!-- /Reklama Popander1-->

<!-- RedTram Start -->
<script language="javascript" type="text/javascript"src="http://js.ru.redtram.com/n4p/2/b/2baksa.net.uneb_5f.js"></script>
<!-- RedTram End -->

<!-- 24new.Ru inform -->
<script src='http://24new.ru/inform/inform5_t.php?inf=773&id=1439&num=5&code=cp1251'></script>
<!-- 24new.Ru inform -->

<!-- MarketNews Start -->
<script type="text/javascript" src="http://mg.dt00.net/js/2/b/2baksa.net.i2.js" encoding="windows-1251"></script>
<!-- MarketNews End -->

<!-- MarketNews Start -->
<script type="text/javascript" src="http://mg.dt00.net/js/2/b/2baksa.net.i3.js" charset="windows-1251"></script>
<!-- MarketNews End -->

i don't think that it is an unique case so filtering similar to sAdKey would be an easy way of removing unwanted blocks.

[whenever]

(May. 31, 2009 11:11 AM)sh8an Wrote:  is there a way of filtering content surrounded with comment pairs without thinkering with developer lists?

AdComments.ptxt might be interesting to you.

[sidki3003]

I think sh8an has a site-specific, IncludeExclude controlled version of "<!> Remove: Comment-Block Ads I" in mind.
And yep, it's a good idea. Although, no other country is using ad comment blocks as much as Russia (which happens to be the origin of your example).

Actually, i'm thinking about adding such a filter for a couple of years now (after having been annoyed by comment blocks like "Omniture and Tacoda tag BEGIN/END" at suburbanchicagonews.com ).

So, i've added it to my to-do list now. Hard to say when i'll get to it though. (Turned out that i have to maintain the patched release config as well...)

[whenever]

Before sidki work out the site-specific version, one way I usually do for site-specific is inserting a $URL() command in the entry. For example:

Code:

XAD_STARTX-->*<!--XAD_ENDX-->$URL(http://www.somehost.com/)

It might be better in this example to put $URL() in the beginning for efficiency. You can use this technique in other blocklists as well if you want some entry to work on specific url.

[sidki3003]

Here is that site-specific filter. I have placed it above "Remove: Specific Functions on sel. Sites". In Advanced Mode the filter hits are listed in the "comments" flyover. In Debug Mode they are shown inline.

The IncludeExclude list notation is:

Code:

your.site.com    $SET(sComment=§<c1 begin§>c1 end§<start c2§>stop c2§<c3§>c3§)

... that is, all strings surrounded by section signs, plus a leading "<" for an opening comment, or a ">" for a closing comment.

There's no fuzzy search, except for the initial whitespace, so, to match:

Code:

<!---** c start **--->code<!---** c end **--->

... you have to use: $SET(sComment=§<-** c start§>-** c end§)


For your example page the IncludeExclude-U entry would look like (keep indents):

Code:

(www.|)2baksa.net/$SET(sComment=§<Reklama§>/Reklama§<RedTram Start§>
  RedTram End§<24new.Ru§>24new.Ru§<MarketNews Start§>MarketNews End§)

Unfortunately, the filter can't remove the comment block which i had in mind originally:
"Omniture and Tacoda tag" at http://www.suburbanchicagonews.com/
... because that block has grown to 47 KB, whereas the maximum byte limit for (unpatched) Proxomitron is 32K. Turning on multi-match and slicing the blocks seems too dangerous to me, because we wouldn't know if the closing comment is still there.


Let me know if you have ideas for improving it.

edit: WIP1 -> WIP2
edit: WIP3

[sidki3003]

Well, no, with $SET(sComment=§<c1 begin§>c1 end§<start c2§>stop c2§<c3§>c3§) WIP1 would also match:

Code:

<!-- start c2 -->
code
<!-- c1 end -->

I've replaced it with WIP2, which only looks for adjacent open/close pairs.
The very last trailing "§" isn't needed anymore in WIP2 (but doesn't hurt either).
So: $SET(sComment=§<open 1§>close 1§<open 2§>close 2)

Be careful when removing comment blocks in the <head> element. You might also remove the Proxomitron insertions.

Any suggestions to further simplify the notation?

[whenever]

(Jun. 07, 2009 10:00 PM)sidki3003 Wrote:  ... because that block has grown to 47 KB, whereas the maximum byte limit for (unpatched) Proxomitron is 32K.

How about a Plan A/Plan B route like what you do in Manage: Specific Containers on sel. Sites filter?

For block over Prox's byte limit, we can just remove the first --> so the browser would think the whole comment pairs as one comment statement.

For example:

Code:

<!-- c1 start -->
code
<!-- c1 end -->

changed to:

Code:

<!-- c1 start
code
<!-- c1 end -->

[sidki3003]

I like Plan B's, but this one would be risky. That's because huge block-worthy comment blocks usually contain further comments within. You couldn't control at which point our forced comment ends. Even ending up with an unmatched closing tag would make the filter unusable for XHTML/XML.

Consider mentioned Omniture/Tacoda block:

Code:

<!-- Omniture and Tacoda tag BEGIN -->
<!-- SiteCatalyst code version: H.1. [...] -->
<script language="JavaScript"><!--
[...]
// -->
</script>
<script language="JavaScript">
// <!--
[...]
// --></script>
<!-- End SiteCatalyst code version: H.1. -->
<!-- Tacoda tag BEGIN -->
[...]
<!-- Tacoda tag END -->
<!-- Omniture and Tacoda tag END -->