CSP error notification -> Conflicting with uBlock Origin?

[ididntknowicoulddothatXD]

Switched from an Amazon page where I blocked almost nothing with uMatrix to a new tab and loaded a site that blocked everything except the frame and CSS. Suddenly I get a notification on Chrome telling me I've got an "extension error" or something, and when I reviewed my extensions, the following warning appeared:

Warning:
This extension failed to modify the response header "Content-Security-Policy" of a network request because the modification conflicted with another extension (uBlock Origin).

No idea if that is a bad thing, both uBlock Origin and uMatrix seem to continue to work as expected.

Settings

• OS/version: Debian 9
• Browser/version: Chromium 64.0.3282.119
• uBlock Origin version: 1.15.2
• uMatrix: 1.3.2

[gorhill]

Duplicate of gorhill/uBlock#1170.

I thought I was on uBO's issue tracker, I corrected the link above: only one extension can modify a HTTP header, it's a browser API by-design behavior. You will have to find what setting is causing uBO to modify the Content-Security-Policy header and change it such that the CSP header is left free to be modified by uMatrix (or vice-versa, as you want).

[gorhill]

I decided to test an idea, and it worked, so re-opening -- I will need to experiment more to be sure though in case there was a flaw in my test.

This seems fixable if I inject a new CSP header instead of modifying an existing one -- which both uMatrix and uBO do. Speculating: this is probably a solution because it's allowed for servers to send more than one CSP header.

[uBlock-user]

@gorhill Will this finally fix all such "extension errors" invoked via CSP header modification or only this one in particular ?

[gorhill]

Unfortunately, added response headers were not merged on Firefox 58 and less:
https://bugzilla.mozilla.org/show_bug.cgi?id=1377689, so this means the fix here is a regression for FF58 and less.

Test case:

URL: http://tobago-vm.apache.org/demo-4-snapshot/content/30-concept/80-security/content-security-policy.xhtml?dswid=-3095

Browser console with default uBO settings:

Content Security Policy: Ignoring ‘x-frame-options’ because of ‘frame-ancestors’ directive.
Content Security Policy: Ignoring “'unsafe-inline'” within script-src or style-src: nonce-source or hash-source specified
Content Security Policy: Directive ‘child-src’ has been deprecated. Please use directive ‘worker-src’ to control workers, or directive ‘frame-src’ to control frames respectively.
Content Security Policy: Ignoring unknown option 'none'
Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src http://tobago-vm.apache.org”). Source: call to eval() or related function blocked by CSP.
Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src http://tobago-vm.apache.org”). Source: &#x0a;      <![CDATA[&#x0a;      functio....
Content Security Policy: The page’s settings blocked the loading of a resource at self (“style-src 'unsafe-inline' 'nonce-u/AeAK/RSoKWoyl+rn/QBA==' http://tobago-vm.apache.org”). Source: display:none.
Content Security Policy: The page’s settings blocked the loading of a resource at self (“style-src 'unsafe-inline' 'nonce-u/AeAK/RSoKWoyl+rn/QBA==' http://tobago-vm.apache.org”).

Add filter: ||apache.org^$csp=font-src 'none'

Browser console with FF58:

Content Security Policy: The page’s settings blocked the loading of a resource at http://tobago-vm.apache.org/demo-4-snapshot/tobago/standard/font-awesome/4.7.0/fonts/fontawesome-webfont.woff2?v=4.7.0 (“font-src 'none'”).
Content Security Policy: The page’s settings blocked the loading of a resource at http://tobago-vm.apache.org/demo-4-snapshot/tobago/standard/font-awesome/4.7.0/fonts/fontawesome-webfont.woff?v=4.7.0 (“font-src 'none'”).
Content Security Policy: The page’s settings blocked the loading of a resource at http://tobago-vm.apache.org/demo-4-snapshot/tobago/standard/font-awesome/4.7.0/fonts/fontawesome-webfont.ttf?v=4.7.0 (“font-src 'none'”).

Browser console with FF61, as expected a combination of both output above:

Content Security Policy: Ignoring ‘x-frame-options’ because of ‘frame-ancestors’ directive.
Content Security Policy: Ignoring “'unsafe-inline'” within script-src or style-src: nonce-source or hash-source specified
Content Security Policy: Directive ‘child-src’ has been deprecated. Please use directive ‘worker-src’ to control workers, or directive ‘frame-src’ to control frames respectively.
Content Security Policy: Ignoring unknown option 'none'
Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src”). Source: call to eval() or related function blocked by CSP.
Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src”). Source: &#x0a;      <![CDATA[&#x0a;      functio....
Content Security Policy: The page’s settings blocked the loading of a resource at http://tobago-vm.apache.org/demo-4-snapshot/tobago/standard/font-awesome/4.7.0/fonts/fontawesome-webfont.woff2?v=4.7.0 (“font-src”).
Content Security Policy: The page’s settings blocked the loading of a resource at http://tobago-vm.apache.org/demo-4-snapshot/tobago/standard/font-awesome/4.7.0/fonts/fontawesome-webfont.woff?v=4.7.0 (“font-src”).
Content Security Policy: The page’s settings blocked the loading of a resource at http://tobago-vm.apache.org/demo-4-snapshot/tobago/standard/font-awesome/4.7.0/fonts/fontawesome-webfont.ttf?v=4.7.0 (“font-src”).
Content Security Policy: The page’s settings blocked the loading of a resource at self (“style-src”). Source: display:none.
Content Security Policy: The page’s settings blocked the loading of a resource at self (“style-src”).

[uBlock-user]

Will it work on Chromium ?

Works as expected on Chromium.

To experiment, add ||github.com^$csp=default-src 'self' 'unsafe-inline' 'unsafe-eval' *.git.luolix.top *.githubusercontent.com in uBO and on uMatrix(v1.3.3.x) add no-workers: github.com true and then visit github.com, a CSP notification error will appear in extreme right burger menu in Chrome, now repeat the steps with uBO version 1.15.11.14, it doesn't happen anymore.

[Okamoi]

This seems fixable if I inject a new CSP header instead of modifying an existing one -- which both uMatrix and uBO do. Speculating: this is probably a solution because it's allowed for servers to send more than one CSP header.

Unfortunately, added response headers were not merged on Firefox 58 and less:
https://bugzilla.mozilla.org/show_bug.cgi?id=1377689, so this means the fix here is a regression for FF58 and less.

@gorhill I'm not sure what to conclude out of this, could you confirm or correct the following ?

Firefox 59 merges headers with the same name, which includes CSP headers, when there is more than one add-on trying to modify them.

So now, can a website infer from the headers that I have both uMatrix and uBO installed ? I'd rather have them only able to infer I have uBO, as it has many users. uMatrix is more of an oddball unfortunately and I'd rather not stand out if possible.

More generally, what can the website figure out from headers if I have both uBO and uMatrix installed ?

Note that this is a different question, the first one assumes uBO can be figured out and wishes to know if having uMatrix on top can go unnoticed. The second seeks to know if uBO and/or uMatrix are even distinguishable from one another, from another content blocker or from, I don't know, Firefox's Tracking Protection or even a network failure or a site bug.

Thanks!