Adblock Plus and (a little) more
The wrong way to deal with privacy concerns · 2010-05-26 14:30 by Wladimir Palant
Generally, I am not the guy to pick on Google. I think that they usually bring out very solid (often brilliant) solutions and do a good job on the privacy front (meaning: far from perfect but significantly better than the competition). All the more surprising was their release of the Google Analytics Opt-out Browser Add-on which doesn’t quite live up to the expected quality. I had a look at the Firefox version and here is what I saw:
- It doesn’t do anything whatsoever to prevent the Google Analytics script from being downloaded. Even with it installed, this script is still downloaded from Google’s servers which means that Google gets some data on you. And it could theoretically still set cookies (which it currently doesn’t, Analytics generally works with first-party cookies only).
- The extension sets a global variable and it is up to the script to check for its existence and obey (not send additional data to Google). While it currently does that and it is unlikely that this will change — this still requires users to trust Google thus defeating the entire purpose of such an add-on.
- What weights more for me personally is the fact that a website can easily override the global variable. So if a webmaster is really insistent on having each single user counted, he can still do it even if some users have this add-on installed.
I expect the versions for other browsers to work in a similar way, complete with placebo functionality. I can sort of understand why they had to implement it this way — if properly blocking the Analytics script were a requirement they wouldn’t be able to implement a version for Chrome any longer. And then there is the issue of websites that rely heavily on Analytics and break if that script is blocked — can only be solved by “redirecting” the request to a minimal local copy of the script without any functionality, again something that can only be done properly in Firefox. 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. It only blocks the subsequent request to Google, effectively the same as Google’s add-on (minus the part where websites can influence that behavior). If you want to have it blocked entirely you should add ||google-analytics.com^ to your filter list manually.
Comment [14]
Commenting is closed for this article.
eupator · 2010-05-26 16:16 · #
> 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.
It actually isn’t, since EasyPrivacy doesn’t block Google Analytics, either.
Reply from Wladimir Palant:
You are right, I wasn’t entirely up to date on things. I updated my post.
Tobu · 2010-05-26 18:36 · #
> ||google-analytics.com^
I have that rule, it’s the custom rule that gets the most hits (about 25k; clustrmaps is at 167k somehow, googlesyndication.com at 7k). I never noticed any adverse effects.
Reply from Wladimir Palant:
As Giorgio notes below, you are lucky because this problem is rather common – and EasyPrivacy maintainers had lots of trouble dealing with it before they decided to give up on this filter. On the other hand, they have to react to feedback of thousands of users, so you might never hit this problem on the sites you visit.
Giorgio Maone · 2010-05-26 18:48 · #
@Tobu:
I never noticed any adverse effects.
You’ve been rather lucky so far: many sites integrate GA calls inside their event handlers for click and buttons, or even in their initialization routines, hence they break more or less dramatically if you block the script.
This was so widespread that prompted EasyPrivacy to drop the filter, and NoScript to implement its Surrogate Scripts feature.
Ian · 2010-05-26 19:40 · #
The BetterPrivacy addon is also pretty significant for privacy – I use it in conjunction with AdBlock (with easylist/easyprivacy/fanboy’s adult blocklist).
Oh, I also use RegControl and set it to disable the HTTP Referer between two different sites by default, and disable 3rd party cookies. That gets most things I think :)
Reply from Wladimir Palant:
Yes, I am using a solution that is similar to BetterPrivacy: https://adblockplus.org/blog/getting-rid-of-flash-cookies.
Disabling Referer header is possible via network.http.sendRefererHeader preference (a few sites don’t like this but that’s rare). And disabling third-party cookies is also a built-in feature, accessible under Privacy in Firefox preferences.
charlo · 2010-05-27 00:18 · #
In reply to your reply, considering referer headers ; I disagree when you say only a few sites do not like it being blocked. I used to disable it and had several issues. Sadly, one of many.. as soon as you disable something to safe-keep your privacy (ie: sites which do not like cookies disabled, sites which do not like javascript disabled, sites which do not like Flash™ not installed, sites which do not like Adblock Plus enabled… gasp). In that concern, messing with about:config was not a solution and I use RefControl extension (https://addons.mozilla.org/fr/firefox/addon/953/) allowing to send “fake” referers + white-listing some web sites. In mine: myspace, sourceforge and my bank. Could not do without it.
And it makes me sad, because many people, even the one concerned by privacy issues in general, lose courage in front of the technicality involved.
Josh · 2010-05-27 13:28 · #
Mr Palant,
““redirecting” the request to a minimal local copy of the script”
Please tell me how I can do this without running a local webserver. The best I can come up with involves increasing the cache time. Is there an existing addon? If not, you should release one.
Reply from Wladimir Palant:
As Giorgio mentioned above, NoScript implements this functionality, so-called “surrogate scripts”. While the NoScript implementation is suboptimal, I see at least two ways that should work properly – replace the script location by a data: URL from a content policy or manipulate the HTTP request in http-on-modify-request observer (emit a fake response and cancel the channel then). These recent events prompted me to think again about adding this functionality to Adblock Plus, the problem is allowing filters that are flexible enough to solve the problem yet cannot compromise user’s safety.
icemaze · 2010-05-27 13:49 · #
IMHO your second point isn’t very strong: you’re already trusting Google by downloading an extension written by them. If they really wanted to screw you, they could push a new, defective version through automatic updates.
Users of that extension are already putting a lot of trust in Google.
More paranoid users probably have NoScript installed already.
Reply from Wladimir Palant:
The extension is simple enough that one can check out its functionality – or trust somebody who did. The really paranoid type won’t install automated updates either without having those checked first. Scripts on Google’s servers are a different thing however, checking them every time is impossible.
Ian · 2010-05-27 20:23 · #
Thanks for the reply Wladimir. For disabling referers on a custom basis I use an addon called RefControl.
I set it to disable cross-site referer headers by default. Most sites still work fine.
Only problematic sites are sites with “First Click Free” whereby it’s free to see if you come from a Google search – I’ve got about 3 on my list, but that’s it.
Szero · 2010-05-29 00:56 · #
Or you could let the Proxomitron do the job correctly, just like it protects you from many others, iFrames, injections, etc…
Josh · 2010-05-29 15:39 · #
Dear Wladimir,
“replace the script location by a data: URL from a content policy or manipulate the HTTP request in http-on-modify-request observer (emit a fake response and cancel the channel then)”
All I can work out how to change on http-on-modify-request is headers with nsIHttpChannel::setRequestHeader
nsIContentPolicy says:
“implementors of this method MUST NOT do any of the following
1) Modify the DOM in any way”
Please would you give me a few more details on how I might implement this myself?
Thanks
Reply from Wladimir Palant:
No, modifying the DOM is certainly not the way to go. However, one (unsupported) way to “redirect” a request is changing contentLocation.spec from nsIContentPolicy.shouldLoad() call. Not sure this still works in the current Firefox version, Mozilla started marking URI objects as immutable before passing them to content policies.
http-on-modify-request looks more promising. It should be possible to make all the necessary calls to nsIChannel.notificationCallbacks and cancel the request after that. But I would need to try it out.
christian louboutin · 2010-07-09 06:34 · #
People who are curious, please come with me, I will bring you different feeling!
http://www.gavots.com
christian louboutin · 2010-07-10 06:23 · #
Very refinement design, hope I can give you the same feeling!
armani sunglasses · 2010-07-16 06:57 · #
Very refinement design, hope I can give you the same feeling!
JTjr · 2010-09-15 17:19 · #
OK so it doesn’t block everything, but i can’t imagine using the internet without it!
all those shouting adverts and bad links. on another note before i used it norton would find about 30-50 tracking cookies now it finds a whole zero every time.