dom...@chromium.org, wjma...@chromium.org
https://github.com/WICG/origin-isolation/blob/master/README.md
https://html.spec.whatwg.org/multipage/origin.html#origin-isolation
Yes
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.
Internals>Sandbox>SiteIsolation
https://github.com/w3ctag/design-reviews/issues/464
Issues addressed
https://docs.google.com/document/d/1CI76APchF0g4RdngBwNWcEm4UAFviMu1sBc0hD6EZCI/edit?usp=sharing
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.
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.
Servers which are misconfigured and do not send the header uniformly, or send invalid header values, will generate console warnings.
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.
Yes
https://bugs.chromium.org/p/chromium/issues/detail?id=1042415
https://chromestatus.com/metrics/feature/timeline/popularity/3286
https://origin-isolation-test.com/
https://chromestatus.com/feature/5683766104162304
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.
--
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.
--
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.
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.
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.
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.
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.