Origin isolation

[domenic]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Origin isolation
• Specification or proposal URL: https://github.com/domenic/origin-isolation (this will eventually be merged into the origin policy spec (Origin Policy #160) and the HTML Standard)
• Mozillians who can provide input: @annevk has been quite helpful so far.

Other information

This proposal is a bit subtle. The normative impacts are relatively small: a site can opt out same-site cross-origin DOM object access via document.domain, and same-site cross-origin postMessage()ing of SharedArrayBuffers. But the intent is that, while doing so, the site can provide hints on why it's giving away these capabilities, the browser can use those hints to guide its process allocation strategies.

As for each of those hints: Chrome has partners interested in prefer_isolated_event_loop and for_memory_measurement. I think we all recognize that side-channel protection is good, so there's also for_side_channel_protection.

I also included prefer_isolated_memory, since I thought Mozilla might appreciate a standardized version of their Large-Allocation header; thoughts welcome there. I imagine it doesn't line up exactly, but it seems to cover similar use cases...

We also have partners that will not be able to deploy COOP + COEP + CORB-across-all-their-dependencies, but are still interested in isolated event loops. So we think this is additive to the idea of automatic origin isolation via COOP + COEP.

Although we're reasonably happy with where the explainer/spec draft has ended up right now, it's hard to say for sure what will survive real-world testing on partner sites (which we hope to do around the end of Q1). As such, any early design feedback would be much appreciated.

[annevk]

FWIW, I think this is something that's worth prototyping as isolating websites using the site boundary https://html.spec.whatwg.org/multipage/origin.html#same-site is the best we can do because of the features mentioned in OP, but not what we'd ideally do. Letting websites adopt a better boundary seems worthwhile.

(Note that there are some thorny issues still, such as WICG/origin-agent-cluster#8.)

[annevk]

Some more thoughts:

• Even with this primitive there would still be things that are not origin-scoped (cookies, WebAuthn): Cookies / WebAuthn WICG/origin-agent-cluster#12. That doesn't necessarily have to be tackled through the same mechanism, though the amount of policies that are essentially fixing design mistakes are getting rather unwieldy.
• COOP+COEP also provides this (and more), but also requires more. It does mean that the postMessage() thing in OP only applies to WebAssembly.Module (which has an agent cluster restriction, but not a cross-origin isolated requirement).
• It might be hard to respond to a request for origin isolation on constrained systems, but having the option still seems like a net-positive.

Overall this still seems like the most principled way to give up on document.domain and reduce the potential size of your agent cluster so I stand by my prior recommendation of worth prototyping and will create a PR for that. Happy to take more feedback though.