Thanks for sharing this. I do think it's worth calling attention to this paragraph <https://github.com/explainers-by-googlers/document-isolation-policy?tab=readme-ov-file#browsing-context-group-switch-instead-of-agent-cluster-keying> of the explainer, for one thing to consider about the proposal:
The Document-Isolation-Policy proposal relies on agent cluster keying to > achieve isolation, instead of browsing context group switches. This means > that it introduces a situation where two same-origin documents might find > themselves in different agent clusters and be unable to have DOM access to > each other. This is unprecedented in the HTML spec. > In other words, two same-origin frames within the same page (or anywhere in the same browsing context group) can end up in different processes, unable to script each other. It could be that this is considered fine and might be outweighed by the benefits of the proposal, though it does have some implications for web developers and for the browser's implementation: - Web developers might be confused when some attempts to script a same-origin frame fail, since this has always been possible within a given browsing context group. Maybe this can be mitigated with a different type of error message in the DevTools console? - In Chromium's implementation, both the browser process and renderer process make assumptions that same-origin frames within the same browsing context group (also known as content::BrowsingInstance) must be in the same process so that they can script each other. Dividing that up based on Document-Isolation-Policy seems like it should be possible, though it would add some complexity and might require some auditing of process model <https://chromium.googlesource.com/chromium/src/+/main/docs/process_model_and_site_isolation.md> code. Maybe this is a manageable risk? Thanks, Charlie On Wed, Apr 3, 2024 at 5:41 AM Camille Lamy <cl...@chromium.org> wrote: > Contact emailscl...@google.com > > Explainer > https://github.com/explainers-by-googlers/document-isolation-policy > > SpecificationNone > > Summary > > Document-Isolation-Policy allows a document to enable crossOriginIsolation > for itself, without having to deploy COOP or COEP, and regardless of the > crossOriginIsolation status of the page. The policy is backed by process > isolation. Additionally, the document non-CORS cross-origin subresources > will either be loaded without credentials or will need to have a CORP > header. > > > Blink componentBlink>SecurityFeature > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature> > > Motivation > > Developers want to build applications that are fast using > SharedArrayBuffers (SAB), which can improve computation time by ~40%. But > SharedArrayBuffers allow to create high-precision timers that can be > exploited in a Spectre attack, allowing to leak cross-origin user data. To > mitigate the risk, SharedArrayBuffers are gated behind crossOriginIsolation > (COI). CrossOriginIsolation requires to deploy both > Cross-Origin-Opener-Policy (COOP) and Cross-Origin-Embedder-Policy (COEP). > Both have proven hard to deploy, COOP because it prevents communication > with cross-origin popups, and COEP because it imposes restrictions on > third-party embeds. Finally, the whole COOP + COEP model is focused on > providing access to SharedArrayBuffers to the top-level frame. Cross-origin > embeds can only use SABs if their embedder deploys crossOriginIsolation and > delegates the permission to use COI-gated APIs, making the availability of > SABs in third-party iframes very unreliable. Document-Isolation-Policy, is > proposing to solve these deployment concerns by relying on the browser > Out-of-Process-Iframe capability. It will provide a way to securely build > fast applications using SharedArrayBuffers while maintaining communication > with cross-origin popups and not requiring extra work to embed cross-origin > iframes. Finally, it will be available for embedded widgets. > > > Initial public proposalhttps://github.com/WICG/proposals/issues/145 > > TAG reviewNone > > TAG review statusPending > > Risks > > > Interoperability and Compatibility > > None > > > *Gecko*: No signal > > *WebKit*: No signal > > *Web developers*: No signals > > *Other signals*: > > WebView application risks > > Does this intent deprecate or change behavior of existing APIs, such that > it has potentially high risk for Android WebView-based applications? > > None > > > Debuggability > > None > > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ?No > > Flag name on chrome://flagsNone > > Finch feature nameNone > > Non-finch justificationNone > > Requires code in //chrome?False > > Estimated milestones > > No milestones specified > > > Link to entry on the Chrome Platform Status > https://chromestatus.com/feature/5141940204208128?gate=5097535879512064 > > This intent message was generated by Chrome Platform Status > <https://chromestatus.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+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMKsNvp7Xcgz%3DcMXJ7%2B%2BBgwhO2wOKEkaMiDk_wUY1nprvPG4HQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMKsNvp7Xcgz%3DcMXJ7%2B%2BBgwhO2wOKEkaMiDk_wUY1nprvPG4HQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH%2B8MBZfpRCRsQMqvjy8NPmo9_v8WQcdu%3Ds06%2BVWb6a17dQ-jw%40mail.gmail.com.
