Google Analytics Opt-Out Snake Oil
Posted by: Giorgio in Google, Mozilla, Security, NoScriptOn 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 ;)
May 27th, 2010 at 12:58 am
That cheap shot at Wladimir was unnecessary and childish, all it does is reflect very badly on you. I don't want to read something like this on Planet Mozilla
May 27th, 2010 at 6:03 am
I'm glad to see both Wladimir's and your takes on the Google Analytics Opt-Out add-on. In his update Wladimir went on to say:
I've been Allowing google-analytics.com in NoScript and using EasyPrivacy to block the tracking. Is there any downside to this approach?
May 27th, 2010 at 9:13 am
@#1 - I didn't read it as an attack, just as a point of pride. From the set-up of the article I was actually *expecting* it to be an attack, but I don't think it was.
May 27th, 2010 at 9:50 am
@Kadir:
Really I don't understand which part of this post sounds like an "attack" (your comment does, though).
@Alan Baxter:
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.
May 27th, 2010 at 1:55 pm
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.
May 27th, 2010 at 2:17 pm
@Wladimir Palant:
Thanks, I noticed it this morning and it's a regression of the new "GreaseMonkey like" no-script surrogates.
The _patchTimeouts() is necessary to collapse timeouts as synchronous calls, in order to allow some bookmarklets to run even on scriptless pages. What kind of warnings are you getting?
May 27th, 2010 at 6:18 pm
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.
May 27th, 2010 at 6:53 pm
This is a really easy fix.
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.
May 27th, 2010 at 7:50 pm
can you give a few examples of sites that break with google analytics disabled ?
June 1st, 2010 at 12:23 am
As said above, what can be easily done is replace all the functions provided by the ga.js and urchin.js scripts with dummy functions. What I've done can be found here:
http://blog.0x0lab.org/2010/03/how-to-stop-google-analytics/
June 1st, 2010 at 8:48 pm
The Google Analytics Opt-Out Browser Add-on installs the Google Updater which is far worse than the Google Analytics bug IMO.
The Ghostery Extension in Firefox blocks Google Analytics plus over 240 other tracking scripts at present and doesn't break any websites that I visit.
June 24th, 2010 at 6:52 am
CloudLiam, actually Ghostery tracks you as far as I know, you're better off with NoScript.
July 6th, 2010 at 12:21 am
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.
July 18th, 2010 at 1:27 am
The Dutch professor B. Jacobs always replies when someone states on the privacy
discussion 'I've got nothing to hide' with the question "When did you masturbate
and how did you do it?"
July 24th, 2010 at 3:18 am
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...
July 26th, 2010 at 9:13 am
@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.
August 21st, 2010 at 11:37 pm
Can you believe I have no idea what could be bad about GA? Can someone tell me?