request: separate extension permissions from site permissions

[Kilian]

This might be already on the table but I couldn't find it explicitly mentioned in the charter.

A large majority of extensions opt to rip out CSP headers completely[1]. They have to do this because extension scripts (like content scripts) are subject to CSP headers and so can be prevented from running by any website.

Browsers being user agents, I feel that extension permissions should not be influenced by website security headers. Conversely, I also do not think website security headers should have to be sacrificed for extension compatibility. I would like to see this community group come up with a model that preserves a websites security settings on one level, but allow extension content scripts to run as well.

[1] https://therecord.media/thousands-of-chrome-extensions-are-tampering-with-security-headers/

[nir-walkme]

I agree

[twschiller]

A related header is the X-Frame-Options header: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options which a server can use to prevent iframing.

Currently a browser extension author has to request the webRequest permission and modify the responses. This is also subject to the limitation that only one extension can modify the server response

References:

• https://stackoverflow.com/questions/15532791/getting-around-x-frame-options-deny-in-a-chrome-extension/15534822#15534822
• Consider supporting removal of X-Frame-Options header in iframe brick pixiebrix/pixiebrix-extension#436

[Jack-Works]

According to CSP specification https://www.w3.org/TR/CSP3/#extensions,

Policy enforced on a resource SHOULD NOT interfere with the operation of user-agent features like addons, extensions, or bookmarklets. These kinds of features generally advance the user’s priority over page authors, as espoused in [HTML-DESIGN].

Moreover, applying CSP to these kinds of features produces a substantial amount of noise in violation reports, significantly reducing their value to developers.

Chrome, for example, excludes the chrome-extension: scheme from CSP checks, and does some work to ensure that extension-driven injections are allowed, regardless of a page’s policy.

[dotproto]

While I agree that the browser extension platform should take steps to provide extension developers with alternatives that don't compromise the security features of the web platform, I'd like to caution against hyperbole. "A large majority of extensions" do not, in fact, "opt to rip out CSP headers completely."

Taking a closer look at the preprint paper the authors examined 186,434 extensions from the Chrome Web Store. Through runtime analysis of a subset of these items, the authors found that 2,485 "tamper with at least one security header considered for this study." While that was "approximately 76% of all the extensions … analyzed at this stage", it represents only approx. 1.33% of the total extension pool they analyzed.

I would like to see this community group come up with a model that preserves a websites security settings on one level, but allow extension content scripts to run as well.

For clarity, what do you mean by "allow extension content scripts to run as well"? I may be mistaken, but I believe all browsers participating in this group can inject content scripts in a page without relaxing CSP or other security headers. That said, I believe DOM-injected scripts (extension scripts running in the page's world) and web accessible resources (e.g. images) likely need other accommodations. Please correct me if I'm off base here.

According to CSP specification https://www.w3.org/TR/CSP3/#extensions,
…

Chrome, for example, excludes the chrome-extension: scheme from CSP checks, and does some work to ensure that extension-driven injections are allowed, regardless of a page’s policy.

The last quotation from the CSP spec is no longer accurate. Beginning in Chrome 85, content scripts are limited by the host page's CSP restrictions, but background contexts are not. This change was introduced for security reasons related to process boundaries. Additional details can be found in this chromium-extensions thread and in the chromium explainer.

[dotproto]

Closing this issue due to lack lack of interaction since my last comment. We have other, issues that better target specific aspects of extension permissions and script execution.