Tracking: m.webtrends.com [n/a]

[Sim]

http://m.webtrends.com/dcs4j9w6r0000082 ... t&WT.js=No

Found at http://www.winsupersite.com/

[rick752]

Already blocked in ABP Tracking Filter.

[Sim]

Already blocked in ABP Tracking Filter.

Not that I could find.

Code: Select all

/webtrends$script .webtrendslive.

are in there but not this one.

[rick752]

Already blocked with:

Code: Select all

/wtid.js

[Sim]

Already blocked with:

Code: Select all

/wtid.js

Thanks. So how do I work out what is blocked and what isn't? - So I can stop pestering you!

I'm looking at the "blockable items" in Adblock Plus and I don't see this or the previous one (eloqua.com) being highlighted there. Wrong place to look?

[Adblock Plus Fan]

Already blocked with:

Code: Select all

/wtid.js

Rick the url he pointed out is not blocked by that filter. (http://m.webtrends.com/dcs4j9w6r0000082 ... t&WT.js=No)
He probably has Noscript running, this is the same issue as in the readingroom.com (pvt) thread.

[Adblock Plus Fan]

@Sim, you are using Noscript right?
Look here: http://noscript.net/changelog#1.1.6.11
Enabling that feature will kill off every instances of web bugs similar to the one you posted.

If you could go here http://forums.mozillazine.org/viewtopic.php?t=564542
And help me convince Giorgio to enable this feature by default, this would clear 99.99% of these problems, and ABP Tracking Filter would not need to deal with these things

[Adblock Plus Fan]

Anyway I do not think we need to worry about this issue, in the future I think Giorgio will enable that feature by default.

Judging from what he said in that thread:

On the other end, the related new noscript.blockNSWB about:config option deserves to be enabled (it's not by default yet just because it's experimental), since it prevents some kinds of scriptless tracking.

It will probably be enabled by default once it has been tested more thoroughly.

[rick752]

Btw, Fan.

Nice job getting that to Giorgio . It seems our finding was responsible for the newest update of NoScript. Cool

[Sim]

Yes I am running NoScript but that option noscript.blockNSWB isn't enabled in my about:config.

I enabled it and the Webtrends got blocked - cool!

So I guess my question is with this disabled (the default for NoScript at the moment) why am I not seeing this as a hit in Adblock Plus?

[Adblock Plus Fan]

Yes I am running NoScript but that option noscript.blockNSWB isn't enabled in my about:config.

It is not supposed to be enabled by default yet since it is still experimental.

So I guess my question is with this disabled (the default for NoScript at the moment) why am I not seeing this as a hit in Adblock Plus?

You mean this:

Code: Select all

http://m.webtrends.com/dcs4j9w6r0000082nlgmjxktd_1c1j/njs.gif?dcsuri=/nojavascript&WT.js=No

?

Perhaps because you have no filters to catch it. If you disable the noscript feature, the picture will pass onto ABP and if ABP does not block it then no hit.

[rick752]

This is how it is happening ........

NoScript DISABLES javascript. Because of that it activates the "noscript" tag contained after the js (when that tag is used). This is the proper way that html was designed to work. This tag is used in html for js-disabled browsers to give users a regular link, an alternate image, or some kind of text alternative if they are not using js (like using the 'alt' text in an image for image-disabled browsers). If there is no javascript-enabling present in the browser, it will serve the info in the html "noscript" tags instead. Some places are using that tag to exploit the NoScript program (or the disabling of js) to still serve a tracker/web bug ... sometimes the js and the 'noscript' tag info will contain different addresses. You can usually find this info by searching for:

Code: Select all

<noscript>

... tags in a page's source code.

So basicly, NoScript is responsible for releasing that tag because it tells the browser that there is no javascript enabled. ABP alone does NOT have this problem because it can not block the inline script within the html ... it WILL block the resulting request though. Because it does not attack the inline html js itself, ABP does NOT release the info contained in the "noscript" tags and those do not exist in the "Blockable items" list when only using ABP.. So you see, the programs work differently.

The NoScript program in your browser operates before ABP does, so the "noscript" tag info coming to ABP has already been 'changed' by NoScript from the original js info into the 'noscript' tag info. That would be why I see something you don't, and you see something I don't. This is a new problem for NoScript ... but it now has an 'experimental' option to block the release of the "noscript"tag info in its latest release.

Hope you both can follow that. I think that would be a proper assessment.