Cross-Origin Opener Policy, Cross-Origin Embedder Policy and extensions

[Yutaka Hirano]

Hi Chrome extension developers,

In Chrome 83 we shipped two security features: Cross-Origin Opener Policy (COOP) and Cross-Origin Embedder Policy (COEP). These security features take effect only when the site owners opt-in to the features, and when enabled they will affect content scripts as well: in short, some loadings will be blocked.

Here is a document describing the possible breakages, how to detect them and how to fix them.

I'm very sorry for the belated heads-up. As the sites using COOP and COEP are currently very few, you will not see many breakages in weeks, I think.

Thanks,

[nightpool]

Hi Yutaka, (and cc chromium-extensions@ which has much more subscribers)

First off, I'd like to thank you for your valuable work. But I can't see your document. Did you send a publicly visible link to it? If you attached it as a file, Google Groups might have discarded it.

What was the justification for adding another web security feature that affects content scripts? Content scripts run as part of the browser chrome, and have their own security model. In short, a content script that is explicitly trusted by the user through host permissions should be able to override the website developer's desired behavior in a secure manner.

We've already seen the consequences of implementing web security features in a way that negatively affect content scripts with Firefox's CSP implementation, which they're trying hard to walk back. We're starting to see similar problems in Chromium with the CORB and CORS hardening work, as people write design documents and specs that don't consider Chrome Extensions, or consider them only as an afterthought, and then implement those designs in a way that destroys valid and secure usecase.

Chrome's security hardening work is extremely valuable, and frankly COOP seems completely uncontroversial, but I don't see any reason why COEP should affect resources embedded by content scripts, and doing so is a major regression in the functionality of Chromiums's extension API. And without a design document that explicitly addresses the security model of the extension ecosystem, I can't see what security benefit this brings to the user.

Do you have such a design document?

--
You received this message because you are subscribed to the Google Groups "extensions-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to extensions-de...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/extensions-dev/CABihn6F1FL6pBNQu1rqs%3D7YJwwSXbsT5MVwhfEJfB4gtyDNAcw%40mail.gmail.com.

[Yutaka Hirano]

Sorry, it seems I forgot to attach it. Here is the document: https://docs.google.com/document/d/1t4eReUV-VM83lLFPQeU5XO6Qy4Er9ZnaDvKrMhrigrw/edit#

On Mon, Jun 15, 2020 at 10:37 PM nightpool <nigh...@cybre.space> wrote:

Hi Yutaka, (and cc chromium-extensions@ which has much more subscribers)

First off, I'd like to thank you for your valuable work. But I can't see your document. Did you send a publicly visible link to it? If you attached it as a file, Google Groups might have discarded it.

What was the justification for adding another web security feature that affects content scripts? Content scripts run as part of the browser chrome, and have their own security model. In short, a content script that is explicitly trusted by the user through host permissions should be able to override the website developer's desired behavior in a secure manner.

We've already seen the consequences of implementing web security features in a way that negatively affect content scripts with Firefox's CSP implementation, which they're trying hard to walk back. We're starting to see similar problems in Chromium with the CORB and CORS hardening work, as people write design documents and specs that don't consider Chrome Extensions, or consider them only as an afterthought, and then implement those designs in a way that destroys valid and secure usecase.

The most important reason is that content scripts run in the page process ("renderer process"), and COEP prevents resources that are not verified by CORS or CORP from entering into the renderer process.

This is similar to the CORB and CORS hardening work you mentioned, because these security features rely on the memory protection on OS processes.

https://www.chromium.org/Home/chromium-security/extension-content-script-fetches

 

Chrome's security hardening work is extremely valuable, and frankly COOP seems completely uncontroversial, but I don't see any reason why COEP should affect resources embedded by content scripts, and doing so is a major regression in the functionality of Chromiums's extension API. And without a design document that explicitly addresses the security model of the extension ecosystem, I can't see what security benefit this brings to the user.

We are planning to allow powerful APIs (SharedArrayBuffer, the memory measurement API, etc) for pages using COOP and COEP. Again, these security features rely on the memory protection on OS processes. If COEP is bypassed for content scripts, malicious web pages can use that content script to sniff resources, which is pretty bad for user's security and privacy.

[Yutaka Hirano]

Sorry, I was not a member of chromium-extensions@ so my reply (below) was rejected. Now it's fixed, hopefully.