EP: Restoring Google Analytics

Discussion of EasyList subscription policy

Moderator: EasyList authors

Post Reply
User avatar
Erunno
Emeritus Contributor
Emeritus Contributor
Posts: 1866
Joined: Fri Dec 05, 2008 5:21 pm
Reputation: 0

EP: Restoring Google Analytics

Post by Erunno » Wed Mar 23, 2011 10:33 am

I wanted to initiate a discussion about whether to restore Google Analytics.

Pro:
1. There's empiric evidence that it is the most used tracker on the Internet, especially on sites which are covered by EasyList Privacy. My custom filter had tens of thousands of hits before I purged my old profile for Firefox 4 (though this might depend on my personal browsing habits).

2. We have now a better feedback system in case of site breakages (though I really haven't followed how well it is working currently).

3. A lot of time has passed since GA was taken out of EP. Reinstating the filter for a limited time might give us hints whether websites have become more resilient against blocking GA.

4. Independent of my own desire to give the GA filter another go I recently (yesterday) discovered that fanboy is also using it again. We might use his exception list to bootstrap our own filter.

Con:
All the reasons we had for removing it in the first place.

Discuss!
Zombie Contributor

Khrin
EasyList Author
EasyList Author
Posts: 3412
Joined: Fri Mar 26, 2010 8:50 pm
Reputation: 13

Post by Khrin » Wed Mar 23, 2011 6:18 pm

His exception list is quite long... And include at least one adult website (which is not under our control).

Google Analytics is not blocked by EasyPrivacy and, until few months ago, also by Fanboy's Lists... About your second point, considers that also almost every other "adblock list" available try to block google-analytics.com, and so I think that is preferable to don't block it for many websites and in my opinion an exception list would become unmanageable.

Michael
Contributor
Contributor
Posts: 4126
Joined: Sun Aug 23, 2009 8:08 pm
Reputation: 0

Post by Michael » Sun Mar 27, 2011 4:43 pm

I really don't think that many websites have updated the problematic code (what incentive is there do so?) and would therefore also prefer not to reinstate the Google Analytics filter to avoid the numerous false positives that we would be likely to encounter.

Ares2
Emeritus Contributor
Emeritus Contributor
Posts: 4572
Joined: Thu Sep 27, 2007 12:49 pm
Reputation: 0

Post by Ares2 » Mon Mar 28, 2011 12:25 am

I'm generally not opposed to the idea. Let's face the fact: If you want to explain somebody not really into that kind of things what "web tracking" actually is and why it is worth to know about it, the prime example to use is google-analytics. In my experience it's actually the only example people know (we've recently talked about the topic in my system security course which confirmed that :-) ). Now it feels a little bit strange to say "Well, there are filterlists for Adblock Plus that blocks such things" [except that they actually don't block google analytics, only the other ones^^].

Yet on the other hand I still cling to the (foolish?) hope that Google doesn't analyze the data they gain from loading the script (secret internal stats) but that they only use the "actual" data submitted through the pixels (global stats derived from all individual client stats). I the good case our current approach is clearly the better one as it causes less problems, in the bad case one could ask whether EasyPrivacy shouldn't be expected to block the single most well known and used tracker there is - even if it's just on 95% of all sites because some have been excepted to make them work.

One thing is for sure: The number domain exceptions would eventually become huge, I expect 50-100 if we only fix the "severe" cases, hundreds if we fix every minor problem. Technically not really a problem, but it will always "feel" like this is a stupid approach.

Michael
Contributor
Contributor
Posts: 4126
Joined: Sun Aug 23, 2009 8:08 pm
Reputation: 0

Post by Michael » Mon Mar 28, 2011 6:58 am

What about all the other known trackers that are not currently blocked, such as s_code.js and the many variants thereof? They are all excellent examples of tracking systems, but problematic when absent.

I would propose moving this topic to the development forum for further discussion.

User avatar
Erunno
Emeritus Contributor
Emeritus Contributor
Posts: 1866
Joined: Fri Dec 05, 2008 5:21 pm
Reputation: 0

Post by Erunno » Mon Mar 28, 2011 7:25 am

Michael wrote:I really don't think that many websites have updated the problematic code (what incentive is there do so?)
I'm simply betting on the fact that the most problematic websites get rewritten/updated often enough that there's an off-chance that they were made more resilient in the process due to developers writing better code in general or just by pure accident. There's a huge body of sites out there which do use GA and do nothing more than displaying information with little interactive content. In my experience it's the sites which do fancy JS-driven stuff which are more fragile and there's bound to be few(er) of them due to cost and complexity to set them up so my hope is that the exception list stays manageable (i.e. less than 100 exceptions).
Michael wrote:What about all the other known trackers that are not currently blocked, such as s_code.js and the many variants thereof?
They are hardly as ubiquitous as GA in my experience so it's easier to bear that these trackers are missing in EP.

One can also cut down the size of the cookie storage by half at least by blocking GA. With Firefox 4 the I/O penalty for reading and writing cookies has allegedly been lessened considerably but at least the cookies don't get send all the time.
Zombie Contributor

Ares2
Emeritus Contributor
Emeritus Contributor
Posts: 4572
Joined: Thu Sep 27, 2007 12:49 pm
Reputation: 0

Post by Ares2 » Mon Mar 28, 2011 2:48 pm

Michael wrote:What about all the other known trackers that are not currently blocked, such as s_code.js and the many variants thereof?
Are you really comparing first-party scripts (the resulting third-party requests are blocked) to GA?

Michael
Contributor
Contributor
Posts: 4126
Joined: Sun Aug 23, 2009 8:08 pm
Reputation: 0

Post by Michael » Mon Mar 28, 2011 3:11 pm

I wasn't attempting to compare s_code.js to Google Analytics, merely suggesting that the notion of restoring problematic filters in general could be raised and that discussion of where the line should be drawn could take place concurrently.

I have moved the topic to the development forum.

Post Reply