Origin isolation allows developers to opt in to giving up certain cross-origin same-site access capabilities — namely synchronous scripting via document.domain, and postMessage()ing WebAssembly.Module instances. This gives the browser more flexibility in implementation technologies. In particular, in Chrome, we will use this as a hint to put the origin in its own process, subject to resource or platform limitations.
TAG review status
Interoperability and Compatibility
This feature has positive or neutral receptions from other browsers. The feature is unlikely to pose interop problems even during the period of uneven implementation: any browser that doesn't implement the spec will end up with *more* capabilities on sites that request origin isolation, compared to Chromium which would restrict the capabilities.
This feature has one impact on desktop Chromium which it will not have in other browsers, which is preventing the postMessage()ing of SharedArrayBuffer. In other browsers, and in the specification, SharedArrayBuffer is not enabled in situations where origin isolation applies. We expect to eventually align with them by disabling SharedArrayBuffer in the same contexts.
Gecko: Positive (https://mozilla.github.io/standards-positions/#domenic-origin-isolation)
WebKit: Neutral (https://lists.webkit.org/pipermail/webkit-dev/2020-August/031355.html)
Web developers: Positive. Several GSuite products are interested in using this feature for better performance isolation, and to increase the accuracy of memory measurements. Previous and ongoing experiments have shown positive results with other forms of origin isolation that are not web-developer-controllable (e.g. enterprise policy or Finch). GSuite is excited about this mechanism, for allowing them to control origin isolation directly.
Origin isolation will impact the behavior of the document.domain setter (to be a no-op) and postMessage()ing WebAssembly.Module/SharedArrayBuffers cross-origin (which will fail).
Origin isolation is specifically designed to allow Chromium to make the best decision for trading off the web developer's desires against performance and memory constraints. So although a naive implementation could cause performance issues (e.g. if we give every iframe that requests origin isolation a dedicated process), this can be tweaked over time and per platform.
Taking advantage of this feature requires server configuration. This minor barrier is reasonable for something with origin-wide impact. This feature would not significantly benefit from polyfills, since it removes capabilities when used.
This feature provides an opportunity for the browser to increase security via process isolation. However, unlike cross-origin isolation (COOP+COEP), it does not give any guarantees in that regard. As such, it is not used to gate powerful features.
Goals for experimentation
The goal for this trial is to allow partners to determine whether origin isolation provides the hoped-for performance benefits, and to see the impact of different configurations. For example, partners can provide us with real world data as to how much origin-isolating increases parallelism/improves latency, using e.g. the long tasks API.
Original trial started in M84 and was scheduled to end a week before M87 launch. The extension is proposed to end a week before M88 launch.
Reason this experiment is being extended
We want to extend this experiment by another milestone, as one of the major experimentation partners is just starting to roll out the feature, and so we want to gather more data before the experiment ends and we can evaluate ship-readiness.
Ongoing technical constraints
Servers which are misconfigured and do not send the header uniformly, or send invalid header values, will generate console warnings.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Link to entry on the Chrome Platform Status
Links to previous Intent discussions