Tested on latest Chrome Stable #60.0.3112.78 on Ubuntu 14.04, Windows 7, Mac 10.12.6 and able to reproduce the issue. Issue is also reproduced on Canary #62.0.3169.0.

Please find the bisect info below:
Chrome Good Build - 49.0.2616.0
Chrome Bad Build - 49.0.2617.0

You are probably looking for a change made after 367789 (known good), but no later than 367794 (first known bad).

CHANGELOG URL:
The script might not always return single CL as suspect as some perf builds might get missing due to failure.
https://chromium.googlesource.com/chromium/src/+log/b7c3414768afff35204a6c6b86
9c47d90d3953e0..ba97fc223ed31c9f3a406ebcc45541064fdbdaaf

https://chromium.googlesource.com/chromium/src/+/738ab011f3ba03a698ba51e8a525b41a3605e33d

Review URL: https://codereview.chromium.org/1569433002

Unable to find the suspect from the above CL.

@Hablich -- Could you please look into the issue and assign it to owner concerned.

Thanks

The bisect results points to an update 1,5 years old. I think this is WAI but our CSP need to decide this.

@Hablich -- Could you please provide any update on this. Thanks!

I agree that the extension should be able to bypass the page's policy. Generally speaking, that's tough to do for things like this, as Blink doesn't know whether a given redirect is initiated by an extension or by web content. It's something we should do, but it's not going to change anytime soon given current priorities.

A workaround for the specific case discussed here would be to load a resource from the extension's package as the redirect target (e.g. `chrome-extension://.../whatever.js`), which will certainly bypass the page's policy. That won't enable dynamic injection, but it's better than nothing.

Do y'all welcome pull requests?

Also, I'd like to emphasize the severity of this. Redirecting to data URI's is core piece of how *many* web extensions with *many* users operate.

This bug, for example, allows websites to circumvent privacy protecting web extensions like privacy badger and uBlock Origin.

> Do y'all welcome pull requests?

Yup. :) https://www.chromium.org/developers/how-tos/get-the-code and https://www.chromium.org/developers/contributing-code are pretty helpful if someone's interested in poking at this. It will not be a trivial fix, but I'd be happy to review patches.

> Also, I'd like to emphasize the severity of this. Redirecting to data URI's is core piece of how *many* web extensions with *many* users operate.

Understood. As I noted above, shifting to a resource in the extension's package might be a reasonable workaround.

> This bug, for example, allows websites to circumvent privacy protecting web extensions like privacy badger and uBlock Origin.

Can you point me to more detail here? How does blocking the resource prevent ad blockers from blocking?

Sure, for example on airbnb, we'd like to inject a surrogate script for the tracking script bat.bing.com/bat.js. But since injecting the surrogate fails, and the normal script is blocked, the page breaks. So the user ends up disabling protections for the site. This is described here:
https://github.com/EFForg/privacybadger/issues/1411

This same thing happens for other sites with google analytics, as outlined here:
https://github.com/gorhill/uBlock/issues/2823

> As I noted above, shifting to a resource in the extension's package might be a reasonable workaround.

This adds further privacy concerns, as web sites can now use the resources exposed through `web_accessible_resources` to assert that a user is definitely using a specific extension.

> This adds further privacy concerns, as web sites can now use the resources exposed through `web_accessible_resources` to assert that a user is definitely using a specific extension. 

If you have a helper extension with randomized file names, then websites cannot detect it. 
The idea is the main extension connects to the helper extension and fetch the resources list, then redirect to the helper extension's resources if needed. Every 4 hours, a new helper extension is generated and pushed to Web Store (might need a private CI server for this), when the helper extension installs (updates), it will send a message to the main extension to tell it to update its resources list. Data URI can be used as a fallback. 
If the random file names have enough entropy, it is close to impossible for websites to detect it. 
Firefox has similar problem, actually, probably worse, as it blocks XHR redirects by default, which breaks `$xmlhttprequest,redirect=` rules of uBO, and ended up getting some French ads server white listed... 

Also a big problem with injecting a file is that it creates a race condition, while the data URI does not. Since you must return a value (not a promise) inside blocking webrequest, we can't wait for an asynchronous thing to happen inside of them. So you don't know if the script ran in time.

For example if we detect a malicious script loading, we cannot inject a file, and wait for it to be ready, before blocking the malicious script.

However this *should be* possible in Firefox because you can return promises in blocking webrequests. You can't in Chrome.

Currently we are only reliably able to either block a script, or not. So if a site decides to integrate some necessary functionality inside a malicious script, we are basically forced to allow it. As trackers realize this, they are going to take advantage of this, and the problem is going to get worse.

Cache the resources list in memory, and use whatever you know at the time of request to decide what to do. It's not perfect, but should work for most cases. It won't create race condition, but you can't check if the redirect worked out. 
For me I have all the rules I want hard coded into content script. That is going to be non-configurable though, but good enough for my case. 
Another way is to not block the tracking script, but block the tracking callbacks. 

I agree redirect from extensions should ignore CSP entirely, just some ideas until proper CSP is implemented. 

Issue 786032 has been merged into this issue.

It seems that Chrome is not following what is said about content scripts and XMLHttpRequests at https://developer.chrome.com/extensions/content_scripts

"... Content scripts can also make cross-site XMLHttpRequests to the same sites as their parent extensions..."

How come this bug still doesn't have an owner yet ? Is there a patch being developed about it or is the development stalled for good ?