-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Strange redirect related to Google Analytics #1170
Comments
Yep,I have the same problem,but I use Ghostery with Ublock origin |
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. |
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. |
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. Can you try the steps mentioned by @engineerwolf and report back your findings..?
This feature (uBlock redirection) is recently introduced. |
Ok, everything's clear now. |
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. |
@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. |
@jamiebegin Extensions are not supposed to be able to crash the browser. Submit the issue to the chromium team. |
@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. |
This also causes 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. |
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 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. |
@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:
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 Test case: https://www.cloudflare.com/a/login. |
@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. |
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 |
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). |
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. |
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 |
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 |
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 |
Why even using uBO together with other extensions, like e.g. Ghostery in the first place? |
I repeat:
|
Today the orange icon show up on Google Chrome's settings, indicating some problem with uBlock.
What i saw was this:
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:
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/
The text was updated successfully, but these errors were encountered: