As an update, we plan add support for DocumentIsolationPolicy on Android in M146.
On Wednesday, April 23, 2025 at 2:14:27 PM UTC+2 Yoav Weiss (@Shopify) wrote: > LGTM3 > > On Wednesday, April 23, 2025 at 11:58:31 AM UTC+2 Camille Lamy wrote: > >> I have updated the explainer to reflect what we're shipping in terms of >> reporting. >> >> I have also updated the spec to have the DocumentIsolationPolicy inherit >> DIP from its owner through the PolicyContainer: >> https://wicg.github.io/document-isolation-policy/#dip-policy-containers. >> This should ensure that the subresource checks are appropriately done. When >> it comes to agent clustering, we have the following behavior in the spec >> already: >> >> - Dedicated Workers are put in the agent cluster of their creator: >> step 3 of >> >> https://html.spec.whatwg.org/multipage/webappapis.html#obtaining-a-worker/worklet-agent. >> >> Which means that if the creator has COI due to DIP, the DedicatedWorker >> would have it as well. This match what we will ship with >> DocumentIsolationPolicy. >> - SharedWorkers get an origin-keyed agent cluster which does not have >> COI: step 2 of >> >> https://html.spec.whatwg.org/multipage/webappapis.html#obtaining-a-worker/worklet-agent. >> >> This agent is obtained on step 4 of the run a worker algorithm >> https://html.spec.whatwg.org/multipage/workers.html#run-a-worker, >> which happens before the main fetch. Then on step 12.3.4 of the same >> algorithm, once we have gotten the script response we check its COEP, and >> if it has one we set the agent cluster to crossOriginIsolated. There's a >> big note that it should be done earlier when the agent cluster is created >> and that the spec should be rewritten. Which is true, because Chrome >> cannot >> actually implement this as the process we pick to host the SharedWorker >> is >> chosen before we get the response and is always set to a non >> crossOriginIsolated process. Which means that the SharedWorker never gets >> crossOriginIsolation, regardless of whether it returns a COEP or a >> DocumentIsolationPolicy (but we do apply the checks on subresources). >> With >> the spec as it is, DIP never gets you a COI shared worker (since step >> 12.3.4 checks for COEP specifically and will not return true), and this >> is >> what we have implemented. >> >> My reading is that what we have in the monkey patch spec + the existing >> HTML spec now accurately describes what we implemented for >> DocumentIsolationPolicy. However, the general situation for SharedWorkers >> and crossOriginIsolation is not satisfactory, regardless of whether COI >> comes from COEP and DIP. So going forward, we should rework how COI and >> SharedWorkers interact. In my opinion, we should either inherit >> COEP/DIP/COI status from the SharedWorker creator, or it needs to be passed >> to the SharedWorker at creation time as a parameter (as opposed to relying >> on the script response). I am not sure which makes more sense. That said, >> since it involves COEP as well, I would like to proceed with >> DocumentIsolationPolicy launch as it is right now, and do a follow up for >> SharedWorkers that will align both COEP and DIP. Does that sound ok? >> On Tuesday, April 22, 2025 at 5:26:12 PM UTC+2 Camille Lamy wrote: >> >>> Thanks! >>> >>> On Tue, Apr 22, 2025 at 11:19 AM Domenic Denicola <[email protected]> >>> wrote: >>> >>>> This generally looks really good, with an amazing detailed explainer >>>> and similarly-detailed spec. I am excited to approve it. >>>> >>>> However I have a couple of questions about mismatches between the >>>> explainer and spec I'd like to hear back on first: >>>> >>>> - >>>> >>>> https://github.com/WICG/document-isolation-policy/blob/main/README.md#reporting >>>> >>>> seems pretty different from the only reporting support I find in the >>>> spec, >>>> at >>>> >>>> https://wicg.github.io/document-isolation-policy/#queue-a-document-isolation-policy-corp-violation-report >>>> >>>> Yes following feedback from developers, we've only implemented the >>> reporting for subresources being blocked (similar to COEP) and as described >>> in the spec. If developers tell us that they also need the reporting on >>> same-origin frames in the browsing context group we'll implement that as >>> well, but the developers who tried the OT didn't think it was useful for >>> them, so we've held off implementing that. I will update the explainer and >>> move this part of the reporting as a potential follow up. >>> >>> >>>> >>>> - >>>> >>>> https://github.com/WICG/document-isolation-policy/blob/main/README.md#interactions-with-workers >>>> >>>> talks about worker inheritance, but I don't see any of that in the >>>> spec. >>>> (Maybe it's taken care of automatically by the policy container >>>> infrastructure or something similar?) >>>> >>>> Right, for this I think both the explainer and the spec should be >>> updated as this was modified during the OT. Following the OT, what we ended >>> up with was: >>> - ServiceWorkers can't have a DocumentIsolationPolicy by themselves. >>> However, if they handle a resource request from a document with DIP, they >>> will apply the subresource checks as expected. If SeviceWorkers themselves >>> want access to COI gated APIs, then they should just deploy COEP. >>> - DedicatedWorkers inherit their DocumentIsolationPolicy from their >>> embedders. This is different from COEP, which will block the worker script >>> from loading if its COEP doesn't match the COEP of its creator. We were >>> told by developers that having the script blocked from loading made rollout >>> harder, so we opted for a different solution for DocumentIsolationPolicy. >>> Provided that there are no compatibility issues, we'll also try to modify >>> the COEP behavior in the future so that it matches DIP. >>> - SharedWorkers are supposed to set their DIP by themselves, like for >>> COEP. I say supposed here because a SharedWorker created by a >>> crossOriginIsolated document can be not crossOriginIsolated, but our >>> implementation does not support the reverse. We'd have to change the moment >>> at which we allocate processes for the SharedWorker to make it work, which >>> is likely complicated. Alternatively, maybe SharedWorkers should also just >>> inherit COEP and DIP from their creators when they are same-origin, just as >>> is the case for DedicatedWorkers. This would make it possible for >>> SharedWorkers to have access to COI gated APIs when they were created in a >>> document with COI. That said, it's possible to change this after release, >>> since we would not have compatibility risks (i.e. currently SharedWorkers >>> can never get COI, with this change they might). >>> >>> I will update the explainer and the spec to reflect the current state of >>> the interactions with workers. >>> >>> >>> >>>> >>>> On Tuesday, April 22, 2025 at 3:47:08 AM UTC+9 [email protected] >>>> wrote: >>>> >>>>> LGTM2 >>>>> >>>>> On Wednesday, April 16, 2025 at 8:11:46 AM UTC-7 [email protected] >>>>> wrote: >>>>> >>>>>> LGTM1. We're excited to see this move forward. >>>>>> >>>>>> On Wednesday, April 16, 2025 at 6:22:26 AM UTC-7 Chromestatus wrote: >>>>>> >>>>> Contact emails [email protected] >>>>>>> >>>>>> >>>>>>> Explainer >>>>>>> https://github.com/WICG/document-isolation-policy/blob/main/README.md >>>>>>> >>>>>>> Specification https://wicg.github.io/document-isolation-policy >>>>>>> >>>>>>> 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 component Blink>SecurityFeature >>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ESecurityFeature%22> >>>>>>> >>>>>>> >>>>>>> TAG review https://github.com/w3ctag/design-reviews/issues/995 >>>>>>> >>>>>>> TAG review status Pending >>>>>>> >>>>>>> Origin Trial Name Document Isolation Policy >>>>>>> >>>>>>> Chromium Trial Name DocumentIsolationPolicy >>>>>>> >>>>>>> Origin Trial documentation link >>>>>>> https://github.com/WICG/document-isolation-policy >>>>>>> >>>>>>> WebFeature UseCounter name kDocumentIsolationPolicyRequireCorp >>>>>>> >>>>>>> Risks >>>>>>> >>>>>>> >>>>>>> Interoperability and Compatibility >>>>>>> >>>>>>> None >>>>>>> >>>>>>> >>>>>>> *Gecko*: No signal ( >>>>>>> https://github.com/mozilla/standards-positions/issues/1074) >>>>>>> >>>>>>> *WebKit*: Negative ( >>>>>>> https://github.com/WebKit/standards-positions/issues/399) Safari is >>>>>>> concerned about our first version of the API for Android, which would >>>>>>> have >>>>>>> us not provide access to crossOriginIsolation-gated API on very low end >>>>>>> devices. We have revised this plan, and plan to launch on low end >>>>>>> Android >>>>>>> as well. >>>>>>> >>>>>>> *Web developers*: Positive ( >>>>>>> https://github.com/WICG/proposals/issues/145) See the initial WICG >>>>>>> proposal. We've also been in touch with developers at Google and >>>>>>> Microsoft >>>>>>> who think the proposed API will allow them to use Shared-Array-Buffers. >>>>>>> Gmail, Google Meet and Zoom have experimented the feature during Origin >>>>>>> Trial. While they still have work to do to fully roll it out, they now >>>>>>> see >>>>>>> deploying crossOriginIsolation as possible. Deploying >>>>>>> crossOriginIsolation >>>>>>> using COOP and COEP was previously impossible for them. >>>>>>> >>>>>>> *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? >>>>>>> >>>>>>> We have no plans on launching the feature in Android WebView in the >>>>>>> foreseeable future due to lack of process isolation in Android WebView. >>>>>>> >>>>>>> >>>>>>> Debuggability >>>>>>> >>>>>>> None >>>>>>> >>>>>>> >>>>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>>>> Mac, Linux, ChromeOS, Android, and Android WebView)? No >>>>>>> >>>>>>> We are planning to launch in M137 on desktop only (ChromeOS, Linux, >>>>>>> Windows, MacOS). Android requires more development work due to the >>>>>>> different process allocation model. We will add support on Android as >>>>>>> soon >>>>>>> as possible. However, we'd like to launch for desktop as soon as >>>>>>> possible >>>>>>> to help developers currently in the ungated SAB reverse origin trial >>>>>>> get >>>>>>> off the deprecation OT. Support on Android WebView is not possible due >>>>>>> to >>>>>>> the lack of process isolation. >>>>>>> >>>>>>> >>>>>>> Is this feature fully tested by web-platform-tests >>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>> ? Yes >>>>>>> >>>>>>> >>>>>>> https://wpt.fyi/results/html/document-isolation-policy?label=experimental&label=master&aligned >>>>>>> >>>>>>> >>>>>>> Flag name on about://flags None >>>>>>> >>>>>>> Finch feature name DocumentIsolationPolicy >>>>>>> >>>>>>> Rollout plan Will ship enabled for all users >>>>>>> >>>>>>> Requires code in //chrome? False >>>>>>> >>>>>>> Tracking bug https://g-issues.chromium.org/issues/333029146 >>>>>>> >>>>>>> Availability expectation As of now, other browser vendors have not >>>>>>> given us signals that they plan to implement this. >>>>>>> >>>>>>> Adoption expectation Gmail, Google Meet and Zoom are interested in >>>>>>> rolling out the feature to gain access to SharedArrayBuffers. They will >>>>>>> need a bit more work, but we expect that they will be rolling it out in >>>>>>> the >>>>>>> next 12 months. >>>>>>> >>>>>>> Estimated milestones >>>>>>> Shipping on desktop 137 >>>>>>> Origin trial desktop first 132 >>>>>>> Origin trial desktop last 134 >>>>>>> Origin trial extension 1 end milestone 136 >>>>>>> >>>>>>> Anticipated spec changes >>>>>>> >>>>>>> Open questions about a feature may be a source of future web compat >>>>>>> or interop issues. Please list open issues (e.g. links to known github >>>>>>> issues in the project for the feature specification) whose resolution >>>>>>> may >>>>>>> introduce web compat/interop risk (e.g., changing to naming or >>>>>>> structure of >>>>>>> the API in a non-backward-compatible way). >>>>>>> None >>>>>>> >>>>>>> Link to entry on the Chrome Platform Status >>>>>>> https://chromestatus.com/feature/5141940204208128?gate=5070133686173696 >>>>>>> >>>>>>> Links to previous Intent discussions Intent to Prototype: >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2BzyOX6amnva6t_HBsXPXAFoZEri7A78ka7-OwA66B%3Dmw%40mail.gmail.com >>>>>>> >>>>>>> Intent to Experiment: >>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/p52-T7m3rOM?e=48417069 >>>>>>> >>>>>>> Intent to Extend Experiment 1: >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67a63f67.2b0a0220.2908d.02b2.GAE%40google.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3ffd6913-4869-439f-b8dd-013401179611n%40chromium.org.
