Is NS blocking this blocker blocker?

[luntrus]

Hi users of NoScript,

Some developers and trackers do not like users that have installed ABP or another form of adblocking and have come up with specific scripts that block ad blocking users and redirect them to another page. One such is:
http://www.blue.lu/other/blocker/
Is NS protecting users of ABP and ad-blovking against the blocking blocker?

Test there gives me a page with this message

This is the page that normal users are going to see.
Users using Ad blocking software are redirected to the url specified in check.js

If you first had your ad blocking software turned off while visiting this page, you have to wait 60 seconds before visiting this page again to get redirected. (Because the cookie set for a non ad blocking user is set to last for 60 seconds)

luntrus

[Tom T.]

So, you passed the test.

So did I, running AdBlock Original, which has been undetectable to many "ad-block detectors".

I would guess that the reason NS protects us -- Giorgio could confirm or correct this -- is:

One of the scripts (which is called ad.js) sets a cookie and a variable, and the other script checks if the cookie or the variable is set.

If you don't allow scripting from that site -- which of course you won't -- then neither script can run, so the second script can't check what it's supposed to.

I just confirmed this by going back to the test site, TA its scripting, allowing its cookies, and running the test. I was indeed redirected to blue.lu. Then I revoked the temporary permissions. I passed the test again.

Ha! I enabled their scripting, but refused their cookie, and passed! This "detector" is pretty worthless, so far.

If somesite.com includes that script in their own page, and not as third-party script, then you might have a problem if you allowed scripting from that page.

My belief is that this is why AdBlock Original, which doesn't use js at all AFAIK, but just silently blocks all blockable images and other elements, but *not* cookies, is less detectable, or non-detectable, but I don't know this with certainty. If you can find a site that incorporates the above code as part of its native scripting, I'd be happy to test it.

Thanks
Tom

[GµårÐïåñ]

Well its a script, so of course it will be blocked by NS unless it is on a site that is already trusted. In that case, it can be crippled using ABP or ABO which will prevent it from loading which means it will never assert. You can use ABE for this too. The only scenario where it would run and nothing that can be done is when the site is trusted and the code is integrated. Although even then you can use GM to hack the codeblock out if you have a pattern to check for.

[Giorgio Maone]

Although even then you can use GM to hack the codeblock out if you have a pattern to check for.

GM (GreaseMonkey, I guess), or even better SS (Script Surrogates), which have the noteworthy bonus to run before the page starts loading, circumventing inline scripts.

[Tom T.]

Although even then you can use GM to hack the codeblock out if you have a pattern to check for.

GM (GreaseMonkey, I guess),

No, I think Guardian meant that you can use Giorgio Maone to hack the codeblock out!

(not really a joke, since the suggestion of script surrogates pretty much amounts to using GM-aone's tool to hack out their code and replace it. )

[GµårÐïåñ]

Yes wiseguys, I meant GM = GreaseMonkey not GM = Great Master = Giorgio Maone. I actually refrained from the acronym in another post because I was posting right after Giorgio and didn't want this mistake, I guess I should have done it here too.

Now back to the post, Giorgio, you are absolutely right on what I meant and those would be noteworthy options definitely. But in those cases you either have to have the know how to write the surrogate (could be implemented on NS I guess by you) or you need to discover the patter that you need to bleep when the page is loading, which admittedly using GM is not pretty, although functional.

[Tom T.]

But in those cases you either have to have the know how to write the surrogate (could be implemented on NS I guess by you)

I believe that at one time, Giorgio planned a UI to create script surrogates as needed, although I could be mistaken.

But is it possible to add an FAQ that would be pretty much copy/paste - fill in the site script here? Or is it necessary to know all the stuff about urchintracker etc. to write it?

A UI where the menu shows script trying to load from datamining.com, and you could click "Create and use surrogate script for this site" would be awesome. Is it possible?

[GµårÐïåñ]

Well you would have to have a basic understanding of what the script is doing and how it is validating to be able to create a surrogate that would mimic that function but not actually communicate with the sever. This is not always generic and not always that easy to accomplish without understanding how the script actually functions. Too general or too broad and you could break other legitimate scripts, modularity and granularity needs to be maintained. Providing the function that is tied into it without breaking and at the same time not giving them what they want, which is the stats or tracking. Automating this task would be difficult without Giorgio spending time and building template scripts for each that the user would then call us as they want it, or the user would have to know what they are doing to accomplish the coding themselves. Basically to oversimplify, you take the original code, gut out the payload and substitute your own or null return and viola, the circuit is maintained but the bomb never goes off