Intent to Extend Origin Trial: 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

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

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

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.

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.

Experimental timeline

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

None

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

No. Although Android (and especially Android WebView) uses different process allocation heuristics than desktop platforms, and so origin isolation may influence those heuristics differently, the JavaScript-observable effects of isolation will be the same on all platforms.

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

Yes

Tracking bug

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

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  

[Mike West]

On Tue, Sep 22, 2020 at 9:41 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

Specification

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

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

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)

It's nice that Mozilla named their position's anchor after you. :)

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.

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.

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.

Experimental timeline

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.

Is one additional milestone going to be enough to ensure you get good feedback from partners? 89 should be shipping sometime in late February, and I can certainly see an argument than January/February will give you better data than December, given the holidays. Is that how you're looking at it?

-mike

Ongoing technical constraints

None

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

No. Although Android (and especially Android WebView) uses different process allocation heuristics than desktop platforms, and so origin isolation may influence those heuristics differently, the JavaScript-observable effects of isolation will be the same on all platforms.

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

Yes

Tracking bug

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

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  

--
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/CAM0wra8a_w4XeNtAn4KEmC9X%3DfpUu16QTpMvyJGRxYSoFpHOEg%40mail.gmail.com.

[Domenic Denicola]

On Wed, Sep 23, 2020 at 3:12 AM Mike West <mk...@chromium.org> wrote:

Experimental timeline

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.

Is one additional milestone going to be enough to ensure you get good feedback from partners? 89 should be shipping sometime in late February, and I can certainly see an argument than January/February will give you better data than December, given the holidays. Is that how you're looking at it?

Yes, based on how things are going now, we believe that one additional milestone will be enough. Since rollout is starting now, another six weeks until the M88 branch point should give enough data to evaluate ship-readiness.

 

[Mike West]

Ok. LGTM to extend the OT through M88.

-mike 

--

-mike