On Thu, Apr 4, 2024 at 12:11 PM Charlie Reis <[email protected]> wrote:
> 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. > I seem to recall that Android Chrome is also limited here, but maybe that has changed and my knowledge is outdated. > > 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. > Ah that makes sense. There may still be some possibility with just spamming 3p iframes but that likely exists today anyway Thanks! Vlad > > 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/CADsXd2PnVpwc1sEAUCQEgHVgT95Qj-waPssUKvdH2LcB8H2tzA%40mail.gmail.com.
