[Proposal] Origin isolation, take 2

Origin isolation refers to segregating cross-origin documents into separate agent clusters. Translated into developer-observable effects, this means:

• preventing the document.domain setter from relaxing the same-origin policy; and
• preventing SharedArrayBuffer s from being shared with cross-origin (but same-site) documents.

If a developer chooses to give up these capabilities, then the browser has more flexibility in how it allocates resources like processes, threads, and event loops.

This proposal allows web applications to give up these capabilities for their origin, and also hint at why they are doing so, to better guide the browser in its resource allocation decisions. This is done via an origin policy.

See the full explainer for more details.

Note: Upon posting this topic, I learned that there was a previous proposal of the same name back in 2016 posted to WICG Discourse. It seems that my modern proposal represents an refinement of the 2016 proposal to focus on specific cases related to isolating same-site, cross-origin documents from synchronously accessing each other.

This proposal is being prototyped behind a flag in Chrome, and has a designation of “worth prototyping” from Mozilla, so I am hopeful it can migrate to WICG forthwith.

This looks related to a Chrome issue I filed a while ago about isolating the main thread of a popup window (crbug.com/738046). Would this kind of execution isolation be another developer-observable effect?

Since filing that issue, we’ve essentially solved the problem a different way by moving all our logic in to a Web Worker, largely thanks to OffscreenCanvas. This is actually better for us since we’re guaranteed a separate thread, as opposed to hinting that we want one, which the browser may ignore due to resource constraints.

I think it’s interesting to compare running everything in a web worker with the proposal. It does execution isolation/separate event loop already. Do Web Workers provide secure memory isolation, side-channel protection, and measurement isolation from the main thread and other workers? Could they? If so, it might be a more lightweight option relative to “maybe give my origin a whole new process”. It might also be another reason to consider better API coverage in workers to make it easier to take this route too.

Yeah. In this case, if you provided one of the isolation hints, that would be a stronger signal to the browser that perhaps you should get your own process, or at least your own thread. There’s no guarantee about these implementation details, but this does provide a dedicated mechanism for such hints.

Another related technology you probably would want to investigate is Cross-Origin-Opener-Policy.

I don’t think the comparison really applies, except perhaps in highly specific cases. Origin isolation allows you to isolate different origins from each other; usually those origins are not controlled by the same person.

Given the “worth prototyping” from Mozilla, this has been moved into the WICG: https://github.com/WICG/origin-isolation.