Intent to Prototype: Origin isolation

[Domenic Denicola]

Contact emails dom...@chromium.org,wjma...@chromium.org Explainer https://github.com/domenic/origin-isolation/blob/master/README.md Design docs/spec https://github.com/domenic/origin-isolation/blob/master/README.md#specification-plan TAG review https://github.com/w3ctag/design-reviews/issues/464 Summary Origin isolation allows web developers to opt in to giving up certain cross-origin same-site access capabilities (namely synchronous scripting via document.domain, and postMessage()ing of SharedArrayBuffers). This allows browsers to potentially segregate the origin into its own process. The developer can also provide hints to the browser as to why they are doing so, in the hopes of guiding the browser's process allocation. Motivation Site isolation, i.e. process-per-site, is the current state of the art in protecting websites from each other. Certain legacy features prevent us from aligning this protection boundary with the origin boundary. Origin isolation allows developers to voluntarily give up these legacy features, in exchange for better isolation. Reasons why a site may want better isolation include: performance isolation, allocations of large amounts of memory, side-channel protection (e.g. against Spectre), and improved memory measurement. Risks

Interoperability and Compatibility This feature is early-stage and is still being shared around with other browsers. Although generally browsers seem supportive of origin isolation as a concept, this specific proposal still needs more discussion. Even then, the interop risk is borne mostly by Chromium, since 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 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. Firefox: No public signals (standards positions repo issue filed) Edge: No public signals Safari: No public signals Web developers: Positive. GSuite has expressed interest, specifically with an eye toward performance isolation and better memory measurement. There is also previously-expressed partner interest in the memory measurement API, which can become more accurate when origin isolation is enabled. Ergonomics Origin isolation will be delivered via Origin Policy. It will impact the behavior of the document.domain setter (to be a no-op) and postMessage()ing SharedArrayBuffers cross-origin (which will fail). Origin isolation is specifically designed to be a series of hints, which 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, in a way that is not directly observable by the web page. Activation Since this feature is delivered via Origin Policy, there is an inherent activation barrier in needing access to origin-wide server configuration to use it. This is intentional, as it affects all pages on the origin. 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.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes. 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? We intend to add tests as part of prototyping this feature. Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5683766104162304

This intent message was generated by Chrome Platform Status.

[Philip Jägenstedt]

I appreciate the Interoperability and Compatibility section, and the judgement there looks right to me. Given enough time of lacking interop almost anything can turn into a compat problem of course, but this is definitely towards the low end of the risk spectrum.

--
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/CAM0wra9xarRgpcYrc_4OjYpXuSzweVDiiVFSJZU8mUcF9UQmbQ%40mail.gmail.com.