Cannot directly access forum on xda-developers.com from front page

[Nocturnalizer]

This is actually an issue when using AdGuard and Bluhell Firewall (on Firefox) too. If you browse to the front page of xda-developers.com and then click the 'Forum' button while uBlock is active absolutely nothing happens. You can open the link in a new tab without an issue but clicking on the 'Forum' button won't take you to the page at all. If you then disable uBlock (or any of the listed adblockers above) and refresh the page and click again, it goes through absolutely fine. Do you know what the issue might be and whether it can be solved?

Thanks in advance!

[gorhill]

Looks like blocking Google Analytics breaks the site. So the solution is to add this filter in the "Your filters" area:

@@||www.google-analytics.com/ga.js^$domain=xda-developers.com

Then press "Apply changes"

The blocking filter is in Peter Lowe's Ad Server list (and also in Fanboy Enhanced and some others).

[Nocturnalizer]

Thanks! That fixes it immediately. Really appreciate the quick help!

[gorhill]

I've created a list of filters specific to uBlock which will contains fixes to unbreak site as the one case above, so that all users can benefit from the workaround. So with 0.1.0.11 you can remove (or comment out) the filter from Your Filters area if you want.

[Nocturnalizer]

Thanks, I'll give that a try! Do we need to report any broken sites to you first before you add them to the list?

[0xallie]

This is an issue with the XDA-Developers site and you should tell the admins of the site to fix their broken code instead of silently allowing Google Analytics to track users without any notice.

[gorhill]

@nyuszika7h For your interest, EasyPrivacy does not break that site because it doesn't block Google Analytics as strictly as Peter Lowe's. The exception filters in uBlock's filters are to un-break what breaks with Peter Lowe's, which would not otherwise break with EasyPrivacy (because it doesn't protect as much).

People who use a blocker with out-of-the box settings do not expect sites to break. So what you suggest would cause many to un-install uBlock and install ABP because "it doesn't break the site" (a still common complaint with uBlock), which of course is because ABP + EasyPrivacy doesn't block Google Analytics in the first place as strictly as in uBlock. So I rather create an exception for one site to meet user's expectations of no breakage, and this way the user will keep using uBlock instead of ABP, and as a consequence is more protected overall against Google Analytics.

You have to look at the big picture. If you want to block completely Google Analytics, it is documented how to do so: just use a static filter like ||google-analytics.com^$important, or a dynamic filtering rules lie * google-analytics.com * block. Advanced users are by definition able to deal with breakage.

[my-password-is-password]

@nyuszika7h Theres a Google Analytics Opt-out t extension.
https://chrome.google.com/webstore/detail/google-analytics-opt-out/fllaojicojecljbmefodhfapmkghcbnh

To test I opened a Request log for https://github.com/gorhill/uBlock. You see uBlock blocks

||google-analytics.com/collect?     image   https://www.google-analytics.com/collect?v=....

and theres google-analytics.com in the popup.

Now install the extension and revisit https://github.com/gorhill/uBlock. There is no google-analytics.com in the popup and in the request log there is no

https://www.google-analytics.com/collect?v=

I think all it does is add this one line script into pages.

<script type="text/javascript">window["_gaUserPrefs"] = { ioo : function() { return true; } }</script>

[gorhill]

@my-password-is-password Did you check if it also opt-out the behind-the-scene connection to google-analytics.com? (occurs on github.com, caused by navigator.beacon)

[my-password-is-password]

No, i haven't. I just installed it just now. How would I test it behind-the-scene? Just keep a request log pin opened for behind-the-scene and see if I ever see a ".../collect?v="?

[gorhill]

How would I test it behind-the-scene?

Just navigating on github.com causes behind-the-scene connections to google-analytics.com.

[my-password-is-password]

Yeah, I see google-analytics.com in behind-the-scene. So the extension isn't good?

[gorhill]

So the extension isn't good?

The navigator.beacon may be fired by github.com's own code, I never really checked, in which case that would explain why the extension does not work for these behind-the-scene occurrences. At least uBlock's allows to block these as well (which I do myself).

[my-password-is-password]

On firefox you can disable navigator.beacon in about:config setting beacon.enabled to false

Gonna see if you can turn it off in chrome now.

[my-password-is-password]

@gorhill I think that extension does stop the behind-the-scene google-analytics.com request. I think I had another tab opened to github before installing the extension so it didn't inject the opt out script into that tab. I restarted chrome with the extension enabled and haven't see google-analytics.com while navigating github... yet. I'll keep using to see if it ever happens again.

[0xallie]

@gorhill I can completely understand your reason for adding an exception, I'm just saying it would have been nice to know about this sooner. I marked google-analytics.com as untrusted in NoScript (because I'm too lazy to use it properly so I'm using it in "allow scripts globally" mode just to get some XSS/clickjacking protection still), and the surrogate does its job fine.

@my-password-is-password Using the opt-out extension is a terrible idea. It doesn't prevent the script from running. It just sets a variable which tells it not to send data. That actually makes your browser more fingerprintable—it's trivial to detect from JavaScript that you have the opt-out extension.

https://hackademix.net/2010/05/26/google-analytics-opt-out-snake-oil/