Cross-Origin-Embedder-Policy: credentialless

[ArthurSonzogni]

The problem

Sites that wish to continue using SharedArrayBuffer must opt-into cross-origin isolation. Among other things, cross-origin isolation will block the use of cross-origin resources and documents unless those resources opt-into inclusion via either CORS or CORP. This behavior ships today in Firefox, and Chrome aims to ship it as well in 2021.

The opt-in requirement is generally positive, as it ensures that developers have the opportunity to adequately evaluate the rewards of being included cross-site against the risks of potential data leakage via Spectre. It poses adoption challenges, however, as it does require developers to adjust their servers to send an explicit opt-in. This is challenging in cases where there’s not a single developer involved, but many. Google Earth, for example, includes user-generated content in sandboxed frames, and it seems somewhat unlikely that they’ll be able to ensure that all the resources typed in by all their users over the years will do the work to opt-into being loadable.

Cases like Earth are, likely, outliers. Still, it seems clear that adoption of any opt-in mechanism is going to be limited (metrics). From a deployment perspective (especially with an eye towards changing default behaviors), it would be ideal if we could find an approach that provided robust-enough protection against accidental cross-process leakage without requiring an explicit opt-in.

The proposal

The goal of the existing opt-in is to block interesting data that an attacker wouldn’t otherwise have access to from flowing into a process they control. It might be possible to obtain a similar result by minimizing the risk that outgoing requests will generate responses personalized to a specific user by extending COEP to support a new credentialless mode which strips credentials (cookies, client certs, etc) by default for no-cors subresource requests.

Read the complete Explainer & Proposed specification

See also:

• "credentialless" embedder policy. w3ctag/design-reviews#582
• Cross-Origin-Embedder-Policy: credentialless whatwg/html#6637
• CacheStorage & COEP:credentialless w3c/ServiceWorker#1592

Feedback

I welcome feedback in this thread, but encourage you to file bugs against:
HTML spec. topic: coep-credentialless

+CC @mikewest @camillelamy @annevk @whatwg/cross-origin-isolation

[ArthurSonzogni]

What are your opinions moving: https://github.com/mikewest/credentiallessness toward WICG?

Maybe @yoavweiss, @annevk, or others would have opinions?

[yoavweiss]

I'm happy to handle transferring it to the WICG org once there's broader industry support, so @annevk's opinion matters infinitely more than mine :)

[mikewest]

"Industry" includes developers of course, not just Anne! :) @ArthurSonzogni, perhaps you could poke some of the folks who have been experimenting with Chromium's nascent implementation to weigh in as well? I've also poked @othermaciej elsewhere.

[Caffeinix]

Speaking as a developer of Google Earth, I am unsurprisingly very much in favor of this proposal.

As Arthur points out, COEP opt-in only works if all content can be guaranteed to have opted in, which is sometimes just not feasible. In such situations, it's usually much easier to ensure that the content isn't personalized — and in fact that makes intuitive sense in ways that COEP opt-in might not: allowing personalized content in an iframe where you can't trust the embedding context is obviously a bad idea, so if developers are doing that and would therefore be inconvenienced by COEP:credentialless, we're probably doing them a favor. It feels like a solution well suited to the problem.

Moreover, although admittedly it's not possible to identify all potentially sensitive content this way, this proposal has the considerable benefit that it keeps web sites working. Without this, we would have had no choice but to present a degraded experience to users without any way to explain to them why, and without any more actual security (since in our case we know the embedding context is not evil). That counts for a great deal.

[nkirkes]

At Zoom, we make use of SharedArrayBuffer and have recently implemented against Chrome's Origin Trial based support for CORS / CORP. Our specific implementation will require credentialless support in both Chrome and Firefox.

[ArthurSonzogni]

I'm happy to handle transferring it to the WICG org once there's broader industry support, so @annevk's opinion matters infinitely more than mine :)

Hey @yoavweiss, I would like to move the repository to WICG. Do you think recent Google Earth and Zoom comments help?

[mikewest]

Yoav is OOO until next week. @travisleithead or @cwilso might be able to make that decision in the meantime.

[yoavweiss]

And I'm back to being in an office! Interest from Zoom is sufficient for WICG incubation. I'll ping you offline for details.

[yoavweiss]

The repo now lives in https://github.com/WICG/credentiallessness
Happy incubation!!

[ArthurSonzogni]

Thanks Yoav!
Since the repository transfert has been done. We can close this.