Strange redirect related to Google Analytics

[c0m4r]

Today the orange icon show up on Google Chrome's settings, indicating some problem with uBlock.

What i saw was this:

Warning: This extension failed to redirect a network request to (base64 string) because another extension (Disconnect) redirected it to about:blank

First I thought that this is some kind of conflict between uBlock and previously used Ghostery so I've switched to Disconnect, but since the problem is still present I have decoded this base64 string and it turned out to be a Google Analytics invocation:

(function() {
    // https://developers.google.com/analytics/devguides/collection/analyticsjs/
    var noopfn = function() {
        ;
    };
    var noopnullfn = function() {
        return null;
    };
    //
    var Tracker = function() {
        ;
    };
    var p = Tracker.prototype;
    p.get = noopfn;
    p.set = noopfn;
    p.send = noopfn;
    //
    var gaName = window.GoogleAnalyticsObject || 'ga';
    var ga = function() {
        var len = arguments.length;
        if ( len === 0 ) {
            return;
        }
        var f = arguments[len-1];
        if ( typeof f === 'object' && typeof f.hitCallback === 'function' ) {
            f.hitCallback();
        }
    };
    ga.create = function() {
        return new Tracker();
    };
    ga.getByName = noopnullfn;
    ga.getAll = function() {
        return [];
    };
    ga.remove = noopfn;
    window[gaName] = ga;
})();

One of the users also posted same report on reddit: https://www.reddit.com/r/techsupport/comments/3zi5jq/what_does_this_javascript_code_do_and_why_was/

[Redshift91]

Yep,I have the same problem,but I use Ghostery with Ublock origin

[engineerwolf]

as far as I understand, both ghostery and uBlock are trying to block request to google analytics by redirecting them to base64 encoded javascript. Implementation of the javascript is different for ublock, Ghostery, Disconnect etc. The request can be redirected to only one of the two codes. hence the conflict.

solution is to disable google analytics blocking in one of the two extensions. either let uBlock handle it or Ghostery. I guess its easier to disable it in Ghostery.

[c0m4r]

as far as I understand, both ghostery and uBlock are trying to block request to google analytics by redirecting them to base64 encoded javascript

Well, that's what it supposed to do. But as you can see, uBlock puts its own Google Analytics script instead. The purpose of GA filter is to stop all the GA connections, not to replace one GA script with another, as far as I'm concerned.

One more note: I was using uBlock alongside with Ghostery for a long time and I didn't do anything with it recently. I just woke up today's morning and I saw this warning.

[harshanvn]

The purpose of GA filter is to stop all the GA connections, not to replace one GA script with another

Yes, the purpose of the GA filter is stop connecting to GA. However in doing so, some websites fails to work if GA related scripts are absent. In those situations, one has to create an exception to the filter and allow an GA connection.
But by replacing with a dummy script, you are able to successfully avoid connecting to GA and the sites still continue to work.
However, per your issue looks like replacing a script by more than one extenstion is causing the issue.

Can you try the steps mentioned by @engineerwolf and report back your findings..?

I just woke up today's morning and I saw this warning.

This feature (uBlock redirection) is recently introduced.

[c0m4r]

Ok, everything's clear now.

[gorhill]

uBO blocks Google Analytics ("GA") -- but since last night, it also redirects the blocked network request for the GA script to a neutered version of the blocked GA script (which is the code you are seeing), so as to minimize web page breakages, some web pages will not work properly when you block Google Analytics.

The neutered version does nothing, its purpose is to just declare the API (only empty function calls as you can see) that some web pages expect to be there without ever testing first -- causing the pages to break.

An example, reported yesterday: http://www.biirdiegolf.com/ breaks when blocking GA (the links won't work), but still works fine when using uBO's neutered version of GA (another example). This motivated me to bring the GA filter out of experimental status.

I didn't know Ghostery did the same, I don't use Ghostery. The issue here is not really one, it's more a warning from the browser API: only one extension is allowed to redirect a network request. I can't remember off the top of my head, but I think the "winner" is the last extension installed. So if ever you reverse the order of installation between uBO and Ghostery, a warning will be reported for Ghostery instead. Aside the warning itself, there is no functional issue.

In summary, the network requests to Google Analytics are blocked, but only one of the extension will be able to redirect to its neutered script as replacement (I am assuming Ghostery's replacement script is also a neutered version, I did not look into it). Result of using a neutered script as replacement: less page breakage while still blocking GA.

The resources used by uBO for redirection purpose are found in this file. Support for redirection was introduced in version 1.4.0.

[jamiebegin]

@gorhill This conflict is causing random crashes in the latest x64 build of Chrome Canary on Windows 10. Since this may eventually make it to the release version of Chrome, it's a bug that might want to be addressed.

[0xBRM]

@jamiebegin Extensions are not supposed to be able to crash the browser. Submit the issue to the chromium team.

[gorhill]

@jamiebegin How did you confirm this specific issue is causing the browser to crash? Also, as said by @CrisBRM, extensions are HTML/CSS/javascript, they are not supposed to crash a browser. If this happens, an issue needs to be opened for the browser, and you need to provide them the exact steps which lead to the crash.

[reedloden]

This also causes big problems with Content Security Policy. :(

[gorhill]

big problems with Content Security Policy. :(

Why would that be "big problems"? Care to explain? uBO's neutered script for GA is nothing, it's all empty functions essentially.

[reedloden]

Sorry for the lack of explanation. Was just annoyed to see my browser sending CSP violation reports due to this change.

@gorhill, because some sites (such as the one I work on) have a script-src directive that doesn't allow loading data: URLs or inline scripts (to protect against XSS and other malicious things), causing a CSP violation error when uBO replaces the GA script with the "neutered" version. Are you using https://developer.mozilla.org/en-US/Add-ons/SDK/Guides/Content_Scripts for doing this? Perhaps Firefox just needs to whitelist that somehow for CSP purposes... or you need to add the call via something like <script src="resource://foo/content/ga.js"></script> (I have no idea if that would work) to possible make the page treat it as self: (again, I'm just pulling things out of my butt here...). I just found https://bugzilla.mozilla.org/show_bug.cgi?id=866522, so maybe WebExtensions is the answer.

Not sure how Chrome handles it. Do they throw a CSP violation error as well? I thought they whitelist stuff from chrome-extension://, so probably not.

[gorhill]

@reedloden Yes, I am not fond of these spurious CSP reports -- I wish there was a setting in the browser to disable this. Chromium-based browsers have the same issue, this is not FF-specific. Unfortunately, these CSP reports are network requests fired in the behind-the-scene scope, and they do not have a specific request type. From uBO's point of view, the features of these requests are:

• POST method
• Content-Type is...
  • Chromium: application/csp-report (nice, could be blocked from just this info)
  • Firefox: application/json (not nice, need to further look into POST payload)

So it would be somewhat simple to block in Chromium with minimal overhead, however in FF this would require examining the payload of the request when the headers are available -- but then all this work occurs only for POST requests, which are rare. I suppose this could be another setting under uBO's Privacy section.

Test case: https://www.cloudflare.com/a/login.

[reedloden]

@gorhill, don't think it's really appropriate to have uBO try to block the CSP reports directly (and likely would get Chrome and Firefox security teams upset with you), but would be good to work with the browsers to find a way to modify the page contents without causing a CSP violation.

[gorhill]

likely would get Chrome and Firefox security teams upset with you

Why is this? CSP reports are not sent to "Chrome and Firefox security teams", they are sent to whatever remote servers is listed in the report-uri directive. These network requests are not beneficial to the users in that this is done without the user knowledge, in the behind-the-scene scope, and this leaks bits of information -- so having the ability to block these would fit well with blocking hyperlink auditing etc. The warning about CSP violations should be reported to the user first, then one can decide whether to dismiss or to report to whatever remote server is listed in report-uri.

[reedloden]

Seems like you're crossing a line by interfering with a browser security feature. I would read the Mozilla and Chrome add-on/extension policies very well to make sure you're not overstepping by disabling CSP reports going to sites. Just wanting to point that out about your proposal...

I personally would be very unhappy if an add-on blocked my site from receiving CSP reports, preventing me from seeing the very problems CSP reporting was designed to report. I understand your concerns, but the data sent in those reports is extremely minimal (purposely so) to protect user privacy while helping the site stay secure. Also, hyperlink auditing () is not a security feature. CSP (and its associated violation reports) is. This just seems like another attempt to prevent (a certain class of) fingerprinting, which just isn't reasonable in today's web at all. There will always be ways to fingerprint a user (however you want to take that).

[dveditz]

If you added a file to your package containing the stub, and then injected chrome-extension:// urls then chrome's CSP implementation wouldn't block your content and wouldn't annoy Reed with reports about it. Not sure if Firefox does the same thing with chrome:// urls. I think so, but you'd have to test. You'd also have to mark your package as contentaccessible which has fingerprinting side-effects, but I think sites can already figure out that an ad blocker is blocking things when they try hard enough.

[gorhill]

@reedloden

Seems like you're crossing a line by interfering with a browser security feature. I would read the Mozilla and Chrome add-on/extension policies very well to make sure you're not overstepping by disabling CSP reports going to sites. Just wanting to point that out about your proposal...

I personally would be very unhappy if an add-on blocked my site from receiving CSP reports

That doesn't sound like a pro-user stance.

See: 47cf638?diff=unified#diff-e89c0f548b51d6b02baea1e832b9d8baR471.

The only line I will not cross is to let web sites dictate was can or cannot be blocked. The report-uri is set by web sites, not the browser, and no security feature is disabled, only the reporting to a remote server. I don't have to agree with whatever network requests a web site is asking my browser to fire.

[CollinChaffin]

@gorhill,

For those who want to continue using Ublock as opposed to throwing away all our other extensions, can you please indicate what setting we can change in Ublock to make these errors go away that you reference you introduced way back on Jan 4th and revert the behavior to that of the version on Jan 3rd?

Thanks.

Collin

[ghost]

AFAIK you can continue using all your extensions as normal. The error is basically meaningless to the user. It doesn't even show up in Firefox like it does in Chrome. In case it still annoys you you could uncheck the filter lists which contain the redirection filters (only uBlock filters – Experimental‎ and uBlock filters – Privacy I believe). Though not worth it in my opinion since those filter lists contain other useful filters. Whitelisting the scripts from google-analytics.com (and potentially other scripts that are also being redirected by a second extension) should make the error disappear too but again not worth the trouble IMO.

[Hrxn]

Why even using uBO together with other extensions, like e.g. Ghostery in the first place?
I don't get it. Doesn't make sense.

[gorhill]

For those who want to continue using Ublock as opposed to throwing away all our other extensions

I repeat:

The issue here is not really one, it's more a warning from the browser API