> > My understanding is that at least this behavior is deterministic, right? > That is, either the same-origin frames will be able to script each other or > they won't and this will happen consistently (based on the agent cluster > key). >
Yes, I think it would be deterministic based on the headers, so hopefully education via error messages would help. An observation I had is that it seems that the Document-Isolation-Policy is > still at the mercy of the platform having the resources to process-isolate > frames. > Camille can probably confirm the details, but I believe that's right. COOP+COEP depends on the platform being able to open a new window in a different process, which I think all platforms but Android WebView can support at this point (?). Document-Isolation-Policy would depend on out-of-process iframes, which wouldn't work on Android WebView or iOS, at least for the time being. On platforms that do support out-of-process iframes, it would make crossOriginIsolated modes much easier to adopt, though. Also I'm not sure if it would be possible for 3p iframes to starve platform > of such resources so that the top level frame would no longer be able to > create 1p frames that have access to COI-gated APIs > IIUC, I think each origin is limited in the number of processes it could create in a given page (basically one with SAB access and one without), which helps. Charlie On Thu, Apr 4, 2024 at 8:05 AM Vladimir Levin <[email protected]> wrote: > This does sound a bit unfortunate. My understanding is that at least this > behavior is deterministic, right? That is, either the same-origin frames > will be able to script each other or they won't and this will happen > consistently (based on the agent cluster key). > > An observation I had is that it seems that the Document-Isolation-Policy > is still at the mercy of the platform having the resources to > process-isolate frames. It wasn't clear to me from the explainer whether > this is already a limitation with the COOP and COEP approaches, however > unwieldy those may be. This basically means that one of the listed use-case > of authors maintaining two copies of their widgets -- one with > SharedArrayBuffers, one without -- doesn't seem to be addressed. Also I'm > not sure if it would be possible for 3p iframes to starve platform of such > resources so that the top level frame would no longer be able to create 1p > frames that have access to COI-gated APIs > > (I also don't know what is the right forum in which to raise these issues) > > Thanks, > Vlad > > On Wed, Apr 3, 2024 at 1:54 PM Charlie Reis <[email protected]> wrote: > >> 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 <[email protected]> wrote: >> >>> Contact [email protected] >>> >>> 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 [email protected]. >>> 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 [email protected]. >> 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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH%2B8MBZfpRCRsQMqvjy8NPmo9_v8WQcdu%3Ds06%2BVWb6a17dQ-jw%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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH%2B8MBaLke%2BgOpCJR%2B2O9%3De%2Bew8Xdh-pXP%2BLx4uaooDSvyw-pg%40mail.gmail.com.
