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



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

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

17 Responses to “Google Analytics Opt-Out Snake Oil”

  1. #1 Kadir says:

    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

  2. #2 Alan Baxter says:

    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:

    [EasyPrivacy] only blocks the subsequent request to Google, effectively the same as Google’s add-on (minus the part where websites can influence that behavior).

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

  3. #3 Morgan says:

    @#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.

  4. #4 Giorgio says:

    Really I don’t understand which part of this post sounds like an “attack” (your comment does, though).

    @Alan Baxter:

    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.

  5. #5 Wladimir Palant says:

    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.

  6. #6 Giorgio says:

    @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?

  7. #7 Saurabh says:

    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.

  8. #8 Acidus says:

    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.

  9. #9 anonymous says:

    can you give a few examples of sites that break with google analytics disabled ?

  10. #10 cirrus says:

    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:

  11. #11 CloudLiam says:

    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.

  12. #12 Anonymous says:

    CloudLiam, actually Ghostery tracks you as far as I know, you’re better off with NoScript.

  13. #13 avalanch says:

    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.

  14. #14 Me says:

    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?"

  15. #15 mh2 says:

    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…

  16. #16 Giorgio says:

    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.

  17. #17 cypressdude says:

    Can you believe I have no idea what could be bad about GA? Can someone tell me?

Bad Behavior has blocked 21712 access attempts in the last 7 days.