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

_gaUserPrefs

variable.

Worse, the

_gaUserPrefs

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

if (!!_gaUserPrefs) alert("You hate Google Analytics, don't you?")

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 ;)

This entry was posted on Wednesday, May 26th, 2010 at 11:09 pm and is filed under Google, Mozilla, Security, NoScript. You can follow any responses to this entry through the RSS 2.0 feed.
Both comments and pings are currently closed.

I’ve been Allowing google-analytics.com in NoScript and using EasyPrivacy to block the tracking. Is there any downside to this approach?

Yes, there is: EasyPrivacy don't prevent Google Analytics scripts from running, hence you're potentially open to abuse from Google or (on an hostile network) from whomever manages to impersonate it.
You should keep GA blocked in NoScript, and let Script Surrogates take care of preventing the breakage for you.

Giorgio, it is funny that your script surrogates seem to be broken in the current NoScript version. Reason being that MainContentPolicy.shouldLoad omits the noScript parameter when calling ScriptSurrogate.apply() - but with undefined != false no surrogates are matched, consequently none are applied. Other than that I would be very careful doing this kind of manipulations from a content policy, allowing content scripts to run during content policies call will allow them to crash Firefox and probably even inject their own code. Particularly your Gecko 1.9.0 code is a clear security hole - it inserts a script element which triggers DOMNodeInserted event synchronously and that one can trigger content scripts, all while you are processing a content policy call. Fortunately, the code for Gecko 1.9.1 and newer seems less problematic - window.location.href changes aren't processed synchronously. I just hope that there is no way for the webpage to detect these changes directly (watch() doesn't work thanks to XPCNativeWrappers).

Oh, and a side-note: I noticed _patchTimeouts method because it produced warnings in my error console. Is this supposed to do any good? "delete window.setTimeout" is enough to restore the original setTimeout function.

I think Google Analytics Opt-out Browser Add-on should have been released a long time ago. Good that it has come now and I am sure a lot of internet users are going to use it. Visit my blog - Techchai.com to read some more interesting facts.

The problem is that the website might call function that GA has which results in runtime errors. Instead the plugin should just block requests to ga.js and create their own empty GA functions and variables in the window scope. No runtime errors because the functions exist, but you don't get tracked because they do nothing, and because ga.js is never touch in any way, nothing clobbers the stub functions or variables.

Why should we NOT want the google analytics code to execute? Seriously... what is all the fuss about? Is this a legitimate gripe about it allowing malicious code through or what? Personally I don't care if it runs or not and the way I see it, analytics is one of the best seo tools out there.

I'm intrigued with how this could be used on sights that "require" googleapis.com
I followed some links and found examples that imply that I could create:
# noscript.surrogate.gapi.sources: *.googleapis.com
# noscript.surrogate.gapi.replacement: var _0=function(){};with(window)urchinTracker=_0,_gat={_getTracker:function(){return {__noSuchMethod__:_0}}}

Would that work?
The website that I noticed this on is www.wowhead.com for World of Warcraft help. It has worked fine with googleapis blocked until recent months... Twould be nice to block them again...

@mh2:
Unfortunately if a site requires a script from googleapis.com, replacing it is not that simple because it likely provides real functionality, e.g. a shared copy of the jQuery JavaScript library. Of course you can grab the script, examine/modify it and save an acceptable copy on your hard disk, than use a file:// URL pointing at it as a surrogate replacement. However(unless you've got almost paranoid tracking issues) this is not probably worth the effort, because as I said googleapis.com is mostly used by websites to download common-place libraries from a central place and save themselves and you some bandwidth thanks to caching.