Latest NoScript version (1.9.2) breaks Adblock Plus

[mh]

Just to give an idea of where I am coming from, this is speaking as one of the people that currently has NS uninstalled due to all this on my main computer, albeit with it installed on my laptop so that I can investigate the changes. I loved the addon before, it just feels like a betrayal of trust for such a security oriented addon to do what seems to be one of the very things it is used to prevent in order to try to drive up its own revenue. But, I'm not here just to complain about things - considerably more people than necessary have already done so What I am here about is to look at how things can be fixed and the community brought back to peace again.

Removing the filterset was a good first step, but some people feel betrayed enough by this whole thing that it isn't enough by itself to bring people back. As a second step, as a show of sincerity, perhaps you should add an option to the normal options menu of NS to disable NS's page displaying every time it updates? Many people now consider the fact that it displays so often to be purely an attempt to drive ad impressions after this whole ordeal - it was something that's annoyed people for a long time, with people wondering why it couldn't be disabled (or for those who knew about the config setting, why it was so buried and hidden). Adding this long-requested feature might do some good toward patching your and NS's reputation on account of this whole ordeal.

That, and I would really like to see a proper and thorough explanation for the 1.9.2 obfuscated code incident.

But first, sleep, you've corrected the immediate problem, and going further isn't worth a risk to your health.

[Ricksterto]

MH,

I have heard that you can do this yourself by doing an about:config, filter on noscript and change

noscript.firstrunredirection to false

[Giorgio Maone]

Personally I was OK with the ABP filterset as long as the reason for it was stated honestly. But I believe the main point of Wladimir's post, which I agree with, is that it was unacceptable to add obfuscated code to NoScript 1.9.2 to interfere with ABP with no mention in the changelog. Giorgio, you will have to answer for that if you want to regain my trust.

Matt, first of all let me agree that adding that code, obfuscated or not (more on this later) was unacceptable. I won't argue with that and I feel very sorry about it. I wouldn't ever do anything like that again for my life.
But please believe that it was made out of anger and hurry, rather than greed, since at that time literally everything was blocked by EasyList on my sites. This was a war between Ares and me, but my foolish moves made the collateral damages of users' trust prevail on anything else.
Blame also my hacker mentality, which led me to dig into the low-level implementation of ABP blocking internals first, rather than notice the API which allowed an external filterset to be added publicly. So I ended to build my own hand-made implementation of whitelisting, and only after trial and error I realized it could be done in a more acceptable way.
Notice also that this happened well before the ABP 1.1 beta addressing the redirect bug has been announced, so the suspect it was a "survive technique" for that is FUD as well (not to mention ABP suffers of several other flaws which could be still exploited by a motivated website, and Wladimir knows that).

Regarding obfuscation, the mrd.js code (as you, who seem to be a coder, could easily confirm) was not properly "obfuscated", despite what has been repeated over and over. Not at least in the common meaning, i.e. code scrambled algorithmically in a form not understandable by a coder, while retaining its semantics.
In facts, the code in question is even properly indented, and its identifiers (method and variable names) are quite descriptive, albeit concise (it's been written as it is).
The "obfuscation", if any, was in some string literals (data), it could be easily spotted and decoded by any mediocre programmer (just hex Unicode escaping) and was focused on the CSS counter-reacting the element hiding rules targeted to my sites. This alone should explain who was the intended recipient of that "obfuscation": too easy for a coder, regular user wouldn't bother about CSS: it was obviously a filterset mantainer, and we know who specifically. Again, not excusable, but it explains itself in context as it was not enough to circumvent code reviewers and not worth to address regular users who don't even know where the code is.

Please feel free to ask any question (being indulgent with my reaction times and my orthography, seen the head spinning I'm currently undergoing) and accept my personal apologies, which I'm currently trying to extend to every ABP user and, more in general, to the Mozilla community.

[IT'S FIXED: DON'T PUNISH YOURSELF BY REMOVING NOSCRIPT]

https://addons.mozilla.org/fr/firefox/r ... isplay/722

no comment

[Guest]

My last post for what I now see as an extension that just should not be used....period.

Firstly, I won't respond to your above comments; this is undoubtedly your business and source of income - it appears that you want to fix the issue and let's let your users decide.

Two last things:

FAQ's are not placed to put in important information such as when your coding bypasses the functionality of the programming. In addition, what exactly is the about:config line "noscript.xblHack with value http://hackademix.net/". I don't see that anywhere in your GUI lists.

and perhaps a bug?

I just ran a test on the latest release using Javascript Deobfuscator 1.5.3 - seems that permitted scripts are allowing calls to scripts that should have been blocked. Background, site has scripts on, adbrite is blocked however. The one that caught my attention was called from http://sitenamehidden/banners (runs a js for their banner - in that script, they call another script related to adbrite). Adbrite script runs perfectly and is not blocked.

var AdBrite_Iframe = window.top != window.self ? 2 : 1;
var AdBrite_Referrer = document.referrer == "" ? document.location : document.referrer;
AdBrite_Referrer = encodeURIComponent(AdBrite_Referrer);

Again, too bad about what was a good product.

Ugh, if true, this is an atrocious behavior. Giorgio, any explanation?

[Alan Baxter]

Now I just need to wait for it to update, for some reason, it's impossible to remove the filter anyway because noscript just re-adds it on every iteration of start-up/refresh of the site.

I'm able to reproduce this issue in Fx 2.0.0.20, i.e. the obsolete NoScript 1.9.2.4 reinstalls the whitelist filter when Firefox is restarted, if it was previously deleted. The workaround for this was to Disable the subscription without deleting it, using the ABP preferences window. I've verified that works in Fx 2.0.0.20.

But it would be better if you just update to NoScript 1.9.2.6. I was able to do that just now from AMO at https://addons.mozilla.org/en-US/firefox/addon/722. That update completely removed the whitelist subscription and it didn't return when I restarted Firefox. Did you say you're unable to update for some reason?

[Giorgio Maone]

FAQ's are not placed to put in important information such as when your coding bypasses the functionality of the programming. In addition, what exactly is the about:config line "noscript.xblHack with value http://hackademix.net/". I don't see that anywhere in your GUI lists.

This is a relic of the element unhiding code: since hackademix.net is not in the scripting whitelist, it was added from that preference to the element unhiding whitelist (which is separated: I wouldn't even override the scripting whitelist, being a serious security breach).
Thanks for reminding me about removing it, since it's useless now.

and perhaps a bug? [...]
Background, site has scripts on, adbrite is blocked however. [...]
Adbrite script runs perfectly and is not blocked.

The question is, are these "Adbrite scripts" loaded from adbrite.com (in which case they would be blocked) or inlined in the main page (which you said has "scripts on")?
If the latter applies, as I suspect, it's normal behaviour: those are not "Adbrite scripts", they're "main site scripts" which happen to contain indentifiers named AdBriteThis and AdBriteThat (the fact they've been probably provided to publisher for copy & paste by AdBrite corp. is irrelevant, from a domain-based security point of view).

[PeterSP]

It silently and without my authorization or knowledge sabotaged another piece of code running on my computer for the sole purpose of financial gain. I don't know what your definition of malware is but that's just about spot on. Calling this willful act of sabotage a "faux pas" is absurd. I certainly won't let NoScript or any other piece of InformAction software anywhere near my computer again. Trust, once lost, is rarely regained.

I don't believe it was for "the sole purpose of financial gain."

[capacityjunting]

I don't believe it was for "the sole purpose of financial gain."

It sabotaged other code in order to display advertisements. Unless these advertisements were bizarro non-profit advertisements I don't see how it can be explained any other way. Can you do so?

[Guest]

But please believe that it was made out of anger and hurry, rather than greed, since at that time literally everything was blocked by EasyList on my sites.

These filters were needed to block the ads on your site and because you kept changing them (and you still are changing them). Breaking a site of you was never intended but Ares needed to change the filters in this way only to block the ads.

[Giorgio Maone]

But please believe that it was made out of anger and hurry, rather than greed, since at that time literally everything was blocked by EasyList on my sites.

These filters were needed to block the ads on your site and because you kept changing them (and you still are changing them). Breaking a site of you was never intended but Ares needed to change the filters in this way only to block the ads.

I already admitted that what I've done (altering the expected browser behavior without an explicit warning) has been unacceptably bad behavior, so don't take the following as an apologetic attempt.
However if you use the logic "I was legitimate to break your install links because there was no way to block ads otherwise" I could argue (but, mind, I'm not arguing) that I was legitimate to break your list because there was no way to install NoScript (e.g. development builds not provided on AMO) otherwise.
But mind again, I'm not arguing that.

[mh]

I am aware, hence my mentioning being able to do it in Config in my post My argument here is that requiring going into about:config is pretty much the definition of bad usability at worst, and appears to at heart be a deliberate attempt to make it very hard to do, while still technically being able to say it can be done - I'm sure the vast majority of FF users have no idea how to change settings with about:config, let alone know what it is. It's something that seems to be born of the same attitude of hiding and obfuscation, hence why it would seem a step forward to me to remove the obfuscation and make it a plain, normal NS menu option.

MH,

I have heard that you can do this yourself by doing an about:config, filter on noscript and change

noscript.firstrunredirection to false

[mh]

Perhaps I should have previewed that first, didn't mean to top post my part of the comment >.<

Giorgio, get some sleep!

[Chronos]

Giorgio:

You made two mistakes. The first was attempting to alter AdBlock. This you admitted and I almost understand why. Please bear with me, I'm not going to have another dig at you - I just want to explain something.

The second was assuming all people who block Google (or ads in general) are simply freeloaders. I block Google's entire IP space, including IPv6 (two subnets), at the border gateway. Not for the reasons you mention, but that I disagree with Google's (and others) data gathering and mining operations on privacy grounds. Knowledge is power, and I believe they already have far too much of both. This extends to blacklisting the likes of google-analytics and filtering on the proxy for urchin.js by content as well as filename. Regardless of the state of NoScript or AdBlock, no such traffic enters or leaves this network. Others may not have such a complex system in place, nor the ability or desire to create one but the same results can be had from a combination of ABP and NoScript with careful attention to setup. Seriously, you guys are natural allies, so to see this war between the two of you when the extensions complement each other so well with such little overlap in functionality was painful.

I do agree that this was a badly thought-out move on your part. However, I was also shocked by the speed in which people who have been served well by NoScript for years turned on you. Initially, I was just as annoyed at the move against ABP but, in such situations, I have found it wise to lay off the keyboard for a while and gather thoughts. You have my sympathy, if it's not too patronising, regarding the way you have been publicly savaged and I have faith that this one incident won't affect, long term at least, one of the best Fx extensions to date. Just remember there are security risks everywhere and not all of us define them by the same criteria you do. Of course, NoScript is flexible enough to accommodate them all and long may it continue.

Your mutli-year efforts keeping Firefox users safer than they would have been otherwise are still appreciated, at least from here.

[GµårÐïåñ]

Not saying ABP is not useful, I use it myself but it can easily be replaced without lifting a single finger or writing a single filter by RequestPolicy which blocks anything and everything unless you allow it explicitly. Especially that element hiding in ABP doesn't really block anything, just hides it and if its being pushed by script and is blocked by NS then its already done and no need for ABP to do anything. I am so sick of this crap.