There is a huge demand for protecting data that's shared with users Any help in strong binding data to origin and blocking sharing would a big win.
thx ..Tom (mobile) On Mon, Apr 8, 2024, 1:20 AM Yoav Weiss (@Shopify) <[email protected]> wrote: > This is very interesting! > > Do I understand correctly and the main reason this would be easier to > deploy is because embedded iframes and popups won't need to deploy COEP in > this model? > > On Fri, Apr 5, 2024 at 12:14 PM Camille Lamy <[email protected]> wrote: > >> Yes the user agent keying is deterministic, and we're adding reporting to >> warn developers if they end up having two same origin documents that could >> normally have DOM access but can't due to Document-Isolation-Policy. > > > I'm not sure same-origin isolation won't end up being a desired feature > on its own. I heard developers asking for stronger isolation primitives on > more than one occasion. I'll talk to folks and think about it some more. > > >> Our recommendation would be to adopt the header on all documents of an >> origin, which removes the concerns around script access. As a followup, we >> might resurrect the Origin-Policy work to help with this issue. > > > Origin-Policy would definitely help avoid mistakes here.. > > >> >> For COOP and COEP, you're correct to note that they are not available due >> to the platform limitations on Android WebView. Because of this, the >> crossOriginIsolated spec already has a notion of crossOriginIsolation being >> either logical (ie no API access) or effective (ie API access). We're >> building on this existing notion. >> >> In terms of platform support, our goal is to first release on desktop, in >> order to finally end the ungated SAB reverse Origin Trial. Then we'll >> extend to Android (but not Android WebView). For Android, the situation is >> a bit different from full Site Isolation, because here the isolation and >> resulting increase memory consumption is driven by the website as opposed >> to the platform. We might not implement full functionality on low-end >> Android, but then none of the developers interested in the API want to have >> it run on low-end Android. Basically, this gives access to >> SharedArrayBuffers, which are mostly useful to cut calculation time in >> heavy web apps, that wouldn't run on devices with limited hardware. >> >> Hope that helps! >> Camille >> >> On Thursday, April 4, 2024 at 9:45:04 PM UTC+2 Charlie Reis wrote: >> >>> 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/1db78c8e-0672-4f62-ac3e-22cb614ca2a6n%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1db78c8e-0672-4f62-ac3e-22cb614ca2a6n%40chromium.org?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/CAOmohS%2BzyOX6amnva6t_HBsXPXAFoZEri7A78ka7-OwA66B%3Dmw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2BzyOX6amnva6t_HBsXPXAFoZEri7A78ka7-OwA66B%3Dmw%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/CAK2Cwb6gct6%3DT5jsxSUjD1TvLjk0UJMqcmz5fSkM6X_%2BOkqnvg%40mail.gmail.com.
