Extension violates Content-Security-Policy

[jribbens]

Description

When the extension blocks things such as Google Analytics, if the site in question has a Content-Security-Policy then the code that the extension inserts violates the policy, causing false reports of policy violations.

Steps to Reproduce

Using Chrome, go to the example page I have made at https://unequivocal.eu/duckduckgo-issue.html (or presumably any page which uses Google Analytics and has a Content-Security-Policy with a report-uri).

Expected behavior:

The analytics would be blocked without generating policy violations.

Actual behavior:

Observe in the network tab that Chrome generates a false report. From the console it can be seen that this is because the extension is trying to insert a script with src=data:.... Obviously as well as the false report, whatever it is that that script is supposed to be doing will not happen.

Versions

• Extension: 2019.3.6
• Browser: Chrome 73
• OS: Windows 10

[jdorweiler]

@jribbens, thanks. I'm going to make an internal task to look into it.

[acsant]

@jdorweiler This also popped up on my page. I decided to look a bit into where it was coming from. This is what I found out, let me know if this sounds correct... Here's my thought process behind this:

• Since the violation showed up, it has to be something in the background script - according to google CSP doesn't have power over content scripts on injection for chrome extensions
• Looking into background script, there's a list of surrogates that are loaded in base64 encoded to provide the least minimal functionality for all the blocked scripts
• Here's a list of those: https://duckduckgo.com/contentblocking.js?l=surrogates
• The example site linked in the issue loads google-analytics.com/ga.js, which is the first one in the surrogate's list.
• If you open the src for the blocked request from the networks tab on that example page, you will see that it is indeed that surrogate which is causing that CSP violation As a result, it's just that the surrogate isn't loaded but the actual blocking should work as expected. data: needs to be whitelisted in the page's CSP if the background scripts were to load it

[jdorweiler]

uBlock has an interesting solution to this. They're keeping the surrogates in web_accessible_resources and generating an access token when the extension starts up. https://github.com/gorhill/uBlock/issues/2823

[akanshgulati]

@acsant are you working on it?

[jonathanKingston]

This was resolved with a recent update of the extension so there are no longer CSP issues from this feature. We do still trigger some CSP issues in Firefox however this is to be resolved soon also.