> > I seem to recall that Android Chrome is also limited here, but maybe that > has changed and my knowledge is outdated. >
Correct, we don't usually create out-of-process iframes on Android Chrome if the device has less than 2G of RAM. Otherwise we allow it (e.g., for partial Site Isolation <https://chromium.googlesource.com/chromium/src/+/main/docs/process_model_and_site_isolation.md#Partial-Site-Isolation>). I'm not sure if COOP+COEP has any restrictions on low-end Android devices, since that mode requires multiple processes but not out-of-process iframes. For Document-Isolation-Policy, I believe there's some notes about low-end Android devices in the explainer, maybe suggesting that it's less needed on such devices? I'll let Camille clarify. Charlie On Thu, Apr 4, 2024 at 12:27 PM Vladimir Levin <[email protected]> wrote: > > > 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/CAH%2B8MBa-5NhLj7oGZzadR9ZoY5GhtVeBR8qCjY%3D497Rhckfe%3Dw%40mail.gmail.com.
