Thanks! On Tue, Apr 22, 2025 at 11:19 AM Domenic Denicola <dome...@chromium.org> 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 dan...@microsoft.com wrote: > >> LGTM2 >> >> On Wednesday, April 16, 2025 at 8:11:46 AM UTC-7 sligh...@chromium.org >> 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 cl...@google.com >>>> >>> >>>> 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 blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMKsNvrydRZh%3DnJKtoEYxDGFwKLeWFguUGmj3mTXoijDAQSg2A%40mail.gmail.com.
