Page 1 of 2

.google-analytics.com/

Posted: Thu Jun 25, 2009 3:28 pm
by se224141
I notice .google-analytics.com/ doesn't figure in Easylist.

http://www.google-analytics.com/urchin.js is not blocked at http://www.yogameditation.com/.

http://www.google-analytics.com/ga.js is not blocked at http://www.economist.com/.

Any specific reason.

Re: .google-analytics.com/

Posted: Thu Jun 25, 2009 4:47 pm
by reepicheep
se224141 wrote:I notice .google-analytics.com/ doesn't figure in Easylist. ...
I was about to reply that it is in Easylist ... until I checked what was actually blocked. Now I remember this was the very first thing I added to my personal filter list and sure enough the blocking list indicates that it's my rule being used. Does beg the quesiton why isn't it in EasyList.

Posted: Thu Jun 25, 2009 4:57 pm
by Ares2
1. EasyList doesn't block tracking like Google-Analytics, the separate subscription EasyPrivacy does

2. Blocking the GA script caused A LOT of sites not to work correctly, therefore this filter has been removed from EasyPrivacy yesterday. This only allows the script to run, the actual tracking is still blocked.

FYI: Those are only the sites that have problems we know of:

Code: Select all

.google-analytics.com/$domain=~asos.com|~beatport.com|~britannica.com|~catalog.belkin.com|
~crushorflush.com|~designer.userbars.com|~expotv.com|~forex.com|~gamepro.com|
~gmodules.com|~jonathancoulton.com|~krone.tv|~minyanville.com|~oasisactive.com|
~reiseplanung.de|~sirius.com|~smash247.com|~songza.com|~tangle.com|~typeracer.com|
~yestosafesex.com
but every site using GA can potentially have issues.

You can of course add the filter yourself if you feel uncomfortable with allowing that script, but you should expect sites not to work properly.

Posted: Fri Jun 26, 2009 9:32 am
by se224141
Thank you for your reply.

This makes me curious which filter list or sets are more effective and up to date.

www.google-analytics.com is on various other lists and it also figures on various other hosts files.

I guess Easylist + Easyprivacy is more dynamic and very frequently updated. Is this the best filter set?

Posted: Fri Jun 26, 2009 11:19 am
by reepicheep
Ares2 wrote:1. EasyList doesn't block tracking like Google-Analytics, the separate subscription EasyPrivacy does
Does it? Not for me it doesn't. Searching for analytics in my filter lists shows only the definition I added. EasyPrivacy has no listing of google-analytics at all. I see filters like

Code: Select all

.analytics.yahoo.com
in EasyPrivacy but no explicit filter for the Google variation. Unless you're thinking of the

Code: Select all

analytics.js

entry.

Maybe I'm just less trusting of Google at this point. I blat away the entire site.

Posted: Fri Jun 26, 2009 4:18 pm
by Wladimir Palant
reepicheep wrote:Searching for analytics in my filter lists shows only the definition I added.
As Ares said above, the specific rule to block Google Analytics script has been removed. However, the tracking image is still being blocked by a generic filter.

@Ares2: I'm not sure this is enough however. I would guess that the script request already gets the most important information (IP address, cookie etc) and the image is only there to gather additional information. Still, seeing the list of exceptions it is understandable that you had to remove this filter.

Posted: Sat Jun 27, 2009 12:42 am
by Ares2
Any way to remove the undefined function with Greasemonkey so that there is at least a usable alternative for people (like me) who are not happy with allowing this script to run?

And a way to fix this in EasyPrivacy would be blog/filtering-html-code-in-adblock-plus :wink:

Posted: Sat Jun 27, 2009 8:41 am
by Wladimir Palant
Yes, with GreaseMonkey you can simply define that function as an empty function:

Code: Select all

function foo(){}

Posted: Sat Jun 27, 2009 2:48 pm
by Ares2
Hmm, doesn't really seem to work. I blocked .google-analytics.com/ and tried

Code: Select all

// ==UserScript==
// @name           Google Analytics fix
// @namespace      http://aaa.aaa.aa/
// @include        *
// ==/UserScript==
function urchinTracker(){};
function pageTracker(){};
with

http://kexp.org/ (listen now links on the top left)
http://www.yestosafesex.com/

What am I doing wrong?

Posted: Sat Jun 27, 2009 8:26 pm
by Wladimir Palant
I think it should be:

Code: Select all

// ==UserScript==
// @name           Google Analytics fix
// @namespace      http://aaa.aaa.aa/
// @include        *
// ==/UserScript==
unsafeWindow.urchinTracker = function(){};
unsafeWindow.pageTracker = function(){};

Posted: Sat Jun 27, 2009 8:43 pm
by Ares2
Thanks, works now.

I recall this: http://adblockplus.org/forum/viewtopic. ... 7764#17764

So is using unsafeWindow OK now/in this case or are there any risks?

Posted: Sat Jun 27, 2009 9:01 pm
by Wladimir Palant
I probably misinterpreted the GreaseMonkey wiki page back then (or was edited to be more clear). The risk is that the web page can use tricks which will make sure that this doesn't do what it is intended to do. For example, it can watch the urchinTracker property of the window and run its own code when this property is set - this would be a great way to detect Adblock Plus if I ever did something similar there. But that isn't a big deal for a GreaseMonkey script that only few people will use.

Posted: Sat Jun 27, 2009 9:09 pm
by Ares2
So is there an alternative to unsafeWindow in this case? Just asking. :)

Posted: Sat Jun 27, 2009 9:16 pm
by Wladimir Palant
I guess this should do as well:

Code: Select all

// ==UserScript==
// @name           Google Analytics fix
// @namespace      http://aaa.aaa.aa/
// @include        *
// ==/UserScript==
window.setTimeout("window.urchinTracker = function(){};window.pageTracker = function(){};", 0);
This executes the code in the context of the unsafe window, with no more traces leading back to chrome. Not that it helps with the detection but at least it takes care of any potential browser vulnerabilities. Only problem might be that this code executes too late due to setTimeout().

Posted: Mon Jun 29, 2009 11:36 am
by mrbene
Branching a bit:
Wladimir Palant wrote:I would guess that the script request already gets the most important information (IP address, cookie etc) and the image is only there to gather additional information.
In most cases the script will be delivered from the browser cache, with no interaction with the server. If the browser cache is working perfectly, you'll only send 1 request to google-analytics.com servers every 7 days - and, since the cache headers specify that the resource is public, it's possible for an upstream provider (caching proxy at the ISP/school/country/etc level) to cache it on Google's behalf.