The NoScript dev -- not "devs" ;) -- here.

Thank you for your commentary, which is quite to the point except for two details which I'd like to set straight:

• The existence of this vulnerability, let alone its nature, has never been disclosed neither to me or the Tor Browser team. The very first hint I had about it has been this tweet by the ZDNet reporter, sent about one later than Zerodium's one, and noticed even later.
• Based exclusively on that Zerodium's tweet (not a proper bug report, just a innuendo without even a link to a live PoC), the "NoScript team" (just me, actually) scrambled to create a reproducible test-case, dig in NoScript 5 "Classic"'s code base which had not been touched for months*, find the bug, fix it, test the patch, package two new versions (one for the beta autoupdate channel, one for the stable one) and deploy them both in quite less than one hour, real-time while been interviewed by the journalist. In the old days, when I had my own garage bands, our typical rehearsals were much longer -- and pleasant ;)

* NoScript 10 "Quantum" has been the main branch and the only I focused on since December 2017: it's a complete rewrite and was born unaffected by this bug. NoScript 5 has been kept around so far for the Tor Browser and the others based on Firefox ESR 52, like Palemoon.

I'd like also to add that NoScript 10's code is much simpler, leaner and easier to understand / maintain, and has got a lot more "friendly" eyeballs reviewing it for possible flaws. Therefore I'm quite confident something like this wouldn't go unnoticed that easily. Anyway, I vow to keep fixing whatever security bug is found (either cooperatively or in a hostile and disturbing way, like in this case) as fast as humanly possible, and even a bit faster, like I always did :)

Great work by Mozilla and the Tor Project on the lighting fast (

And yes, NoScript did protect against this (the Tor Browser has it built-in, for users who know what they're doing).

Easiest, one-click way to remove vulnerable SSL3 support from Firefox, while still allowing Mozilla to automatically enforce even safer defaults in future updates:

the SSL Version Control add-on.

NoScript Options>Advanced>HTTPS> Forbid Active Content unless it comes from a secure (HTTPS) connection .

Painful, yes, but it should take care of this kind of attacks, as long as you can trust HTTPS (e.g. with Convergence).

Furthermore, NoScript 2.6.8.37rc2 introduce an experimental "Allow HTTPS scripts globally on HTTPS documents" mode (in Advanced>HTTPS>Permissions) if you value convenience over finer grained security.

Fresh from the summary of the upcoming BlackHat talk by Jeremiah Grossman, A Million Browser Botnet:

Besides some "minor" features first introduced by NoScript, which advanced the state of the art of browser security (such as the most effective in-browser XSS filter, the ClearClick anti-Clickjacking technology and the Application Boundaries Enforcer module), NoScript holds a modest advantage over all its Chrome-based "clones": basic script blocking which actually works ;)

The patch is not exactly a one-liner, because the implemented behavior is not as straight-forward as just "block 3rd party cookies".

It's "block cross-site cookies from origins which I've not visited yet as a 1st party websites and have already 1st party cookies from".

This means, for instance, that Facebook, Google and Twitter gets likely a free-pass to track almost anybody.

And that once you (accidentally or not) click any ad box, you give a free-pass to its advertising agency too.

Wrong, that's exactly what they do: Why do you base your stats on page views rather than unique visitors?

And yes, they're aware of the prerendering Chrome stats inflation problem, even though they believe it doesn't significantly skew their stats, for some reason they're unable to explain themselves (sounds like "faith" or "we're too lazy to adjust our data even though we could").

Does StatCounter take in account Chrome's page views inflation caused by its Instant Pages prerendering feature?

I'd be surprised, since even Google Analytics itself is affected...

Anyway, please be careful before announcing "Chrome usage surpassed this or that" :P