hackademix.net

On his blog, Wladimir Palant complains about Google providing browser users with a not effective enough way to opt-out from Google Analytics.

Specifically, he doesn’t like how the Google Analytics Opt-out Browser Add-on actually allows Google Analytics scripts to load and run, just setting a global variable (

) in the hosting page which tells the code not to send back data.

This approach is inherently flawed, because the hosting page can easily force Google Analytics to run by simply overwriting the aforementioned

variable.

Worse, the

variable is automatically added to every single page you load. Hence, the fact itself you’re using this “opt-out” add-on can be easily detected if you keep JavaScript enabled, adding some extra points to your unanonymity score. Something like

can make a nice test to update the Panopticlick suite with, singling out privacy concerned persons.

However, the original sin is that the Google Analytics’ script still being downloaded and executed, and if you find this questionable from a security/privacy perspective, then the Google’s Analytics Opt-Out Browser Add-on serves no purpose.

Wladimir’s post initially advertised his own extension as a better solution, but later he had to retract:

Still, until Google can come up with something better I recommend people to use Adblock Plus with EasyPrivacy filter subscription, that’s the easy and reliable solution (check the update below).

Update: Sorry, that last part wasn’t entirely correct — EasyPrivacy doesn’t block Google Analytics script either, due to many websites being broken without it as mentioned above.

True, if you block Google Analytics’ script by using a proxy, a firewall, a host file or Adblock Plus with an ad-hoc filter, many sites are going to break because they depend on JavaScript objects provided by Google Analytics. They integrate GA calls within essential functionality, such as link and button event handlers or even initialization routines, and they fail more or less dramatically when the script is missing. Sad, silly but true.

This is no news (and no problem) at all for NoScript users, though: in fact, almost one year and half ago, this very issue prompted the development of NoScript’s Script Surrogates feature, which prevents the breakage by “emulating” the blocked script with dummy replacements. This means that NoScript users have Google Analytics blocked by default, with no site-breaking side effects.

So, until Google can come up with something better I recommend people to use the reliable and easy solution ;)

I’m receiving several reports by Ubuntu and Debian users having their desktops crashed as soon as they click the NoScript icon. Yes, your whole session gone, back to your logon page in one move!

Actually this may be triggered by different actions, not necessarily with NoScript installed, or reportedly just by having a long/complex enough interaction with Firefox.

It turns out to be a bug in the xorg-server package, which Ubuntu’s maintainers deemed not worth to get fixed before releasing Lucid Lynx.

My understanding is that a fix will be included in next automatic update, but in the meanwhile you can apply the available patch from Bryce Harrington’s PPA by issuing the following commands in a terminal:

Update

I was sure I had this crash reported by Debian users as well, but when some of them commented here that they couldn’t reproduce it, I double checked and could find Lucid Lynx reporters only. Better so.

As you probably know, the details about the paradoxical behavior of the Internet Explorer XSS Filter, introducing XSS vulnerabilities of its own on otherwise immune web sites, which we hinted at some months ago, have been revealed by Edoardo “Sirdarckcat” Vela and David “thornmaker” Lindsay recently at the Black Hat Europe conference, in Barcelona (on a side note, looks like Sirdarckcat enjoyed his stay there so much that he decided to remotely hack a certain volcano…)

I’ve been quite disappointed by the preamble of their paper, which calls IE8’s XSS filter a new type of defense and a somewhat novel approach (before bashing it), when we all know that NoScript came first. Sirdarckcat personally apologized, blaming Lindsay for this and other “pro-big-players” bias, such as the decision of omitting, from the comparative table in their slides, Sirdarckcat’s opinion about NoScript’s being the safest among the in-browser filters and the hardest to bypass.

Notwithstanding, the technical core of this research is very worth reading, if you’re interested in XSS attack and defense techniques.

After the Black Hat debacle got echoes in the press, David Ross, the main XSS Filter engineer at Microsoft, published a Guidance on Internet Explorer XSS Filter document on the Microsoft Security Response Center website, announcing a not better specified “patch” coming in June (mmm, two whole months? need some help?) and making two interesting statements:

In the case of the Internet Explorer XSS Filter, researchers found scenarios that are generally applicable across XSS filtering technologies in all currently shipping browsers with this technology built-in.

This essentially means just two, IE8 and Chrome… but wait, Chrome doesn’t ship with its XSS Auditor enabled anymore because it was dog slow!
Hence the final recommendation by Ross…

Overall we maintain that it’s important to use a browser with an XSS Filter

… can really mean one thing only: Microsoft maintains that it’s important to use Firefox with NoScript :)

Congratulations to David Baron and the others involved for this well thought out fix :)

Time to revisit putting SSL in perspectives, since you can’t even trust CAs themselves.

I took a cursory look at Perspectives add-on’s code, and it cries for a compatibility & performance rewrite (oh, if I could just find the time!), but it’s still the best patch we can currently throw at this problem.