Intent to Ship: Origin Isolation

[Domenic Denicola]

Contact emails

dom...@chromium.org, wjma...@chromium.org

Explainer

https://github.com/WICG/origin-isolation/blob/master/README.md

Specification

https://html.spec.whatwg.org/multipage/origin.html#origin-isolation

API spec

Yes

Summary

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.

Blink component

Internals>Sandbox>SiteIsolation

TAG review

https://github.com/w3ctag/design-reviews/issues/464

TAG review status

Issues addressed

Link to origin trial feedback summary

https://docs.google.com/document/d/1CI76APchF0g4RdngBwNWcEm4UAFviMu1sBc0hD6EZCI/edit?usp=sharing 

Risks

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.

This feature poses minimal compatibility risk. Its JavaScript-observable effects are to remove capabilities, so if we unshipped it, sites would not see any change. They might become slightly less secure or performant, but it is hard to rely on those benefits in a compatibility-impacting way.

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 Google Workspace 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). Google Workspace is excited about this mechanism, for allowing them to control origin isolation directly, and has been testing it during the origin trial period with preliminary positive results.

Ergonomics

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.

Activation

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.

Security

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.

Debuggability

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)?

Yes-ish.

The initial version is disabled on platforms without site isolation (namely low-memory Android devices, and Android WebView), for reasons of technical complexity.

Within the next release, we plan to update our implementation so that it has the same web-observable effects of disabling document.domain and postMessage()ing of WebAssembly.Module instances on those platforms, independent of the process allocation strategies.

Is this feature fully tested by web-platform-tests?

Yes

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1042415

Measurement

https://chromestatus.com/metrics/feature/timeline/popularity/3286

Sample links

https://origin-isolation-test.com/

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5683766104162304

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/0vuiPTvBGvQ

Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/G0h3PFPeclA/m/Lqt872UCAAAJ

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

On Wed, Nov 11, 2020 at 8:36 PM Domenic Denicola <dom...@chromium.org> wrote:

Contact emails

dom...@chromium.org, wjma...@chromium.org

Explainer

https://github.com/WICG/origin-isolation/blob/master/README.md

That's a great explainer, thanks for writing that!

One thing I'm missing (or at least not explicitly stated) is: what would be the motivation for web developers to opt-in to this mode?

They add those restrictions on themselves, what are we promising them in return?

From the explainer and the OT report, I'm guessing that the answer is "improved performance, as documents from that origin are more likely to find themselves in different processes & event loops than other same-site cross-origin documents, reducing the chances of interference from those documents".

Am I guessing correctly?

 

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

[Domenic Denicola]

From: blin...@chromium.org <blin...@chromium.org> On Behalf Of Yoav Weiss

> That's a great explainer, thanks for writing that!
> One thing I'm missing (or at least not explicitly stated) is: what would be the motivation for web developers to opt-in to this mode?
> They add those restrictions on themselves, what are we promising them in return?
>
> From the explainer and the OT report, I'm guessing that the answer is "improved performance, as documents from that origin are more likely to find themselves in different processes & event loops than other same-site cross-origin documents, reducing the chances of interference from those documents".
> Am I guessing correctly?

Yes, that's right! Sorry that the explainer wasn't super-clear on this. It tries to encapsulate this in

> 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.

and later

> Allow user agents to use various implementation strategies to isolate origins when circumstances allow, and the developer has opted in to origin isolation, thus potentially achieving benefits for performance, security, and memory metrics.

[Yoav Weiss]

LGTM1

This seems like a positive change that would potentially help us reduce the use of document.domain, or at the very least, minimize the pain and suffering that its support brings to sites that don't use it.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MN2PR13MB3613ED61A95D2CF9F0AA879BDFE70%40MN2PR13MB3613.namprd13.prod.outlook.com.

[Chris Harrelson]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjTA%3DyqTKQ7_FpT4%3D9A%3DH1fEUvDM84pyMi26j1aca1M6g%40mail.gmail.com.

[Jochen Eisinger]

lgtm3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_DN9nDukBjcc6RsWtp_PG3GkMcoZqfRvZwVijEi%2BDMpw%40mail.gmail.com.

[Domenic Denicola]

Hi API Owners,

Late-breaking feedback from Chrome Security has made us believe we should rename this feature (including the Origin-Isolation header and the window.originIsolated getter), to better indicate that it is not a security primitive like site isolation or cross-origin isolation. You can see the full reasoning on this whatwg/html thread.

In collaboration with Mozilla, we've decided on the new name (Origin-Agent-Cluster and window.originAgentCluster), and have an approved HTML Standard pull request ready to merge. I also have a CL drafted to perform the rename, which contains minimal code changes (2 lines + comment blocks explaining the situation), plus a bunch of test changes. We are hoping, pending the release managers' blessing, to merge this back to M88.

I've also pinged the TAG review thread; Mozilla is updating their standards positions thread; and I've pinged the webkit-dev thread.

Please let us know if you have any concerns with this plan, or think it merits another Intent to Ship or round of LGTMs.

[Chris Harrelson]

The change is fine by me, especially since M88 is only now just going to first beta release.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a4d55129-0400-431e-9a52-8f7f1a6f007cn%40chromium.org.

[Daniel Bratell]

Yes, sounds good. As late as this is, I'm mostly happy it wasn't even later when it would have been more painful to correct.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_ZZpfgUk%3DQDh5uRLy%2BQbSg9ncw%3DS%3DfZneQOF14GeekAA%40mail.gmail.com.