Document-Isolation-Policy #1074

Activity

1. github-project-automation

   moved this to Unscreened in standards-positions reviewon Sep 18, 2024
2. github-project-automation

   added this to standards-positions reviewon Sep 18, 2024
3. zcorpan

   self-assigned this

   on Oct 14, 2024
4. zcorpan

   moved this from Unscreened to Needs proposed position in standards-positions reviewon Oct 14, 2024
5. camillelamy commented on Apr 3, 2025

   

   camillelamy

   on Apr 3, 2025

   Author

   More actions

   Hi, as a heads-up, this feature has been in an Origin Trial in Chrome until M136. Based on positive feedback from developers who've tried it, we're planning to release the feature in Chrome in M137 (which will branch on April 28th). We would appreciate any feedback you have!

   Thanks,
   Camille
6. fideltian commented on Apr 17, 2025

   

   fideltian

   on Apr 17, 2025

   More actions

   Up for it. One of our headache is how to make SAB be available easier. Especially in SDKs. 3rd party integrates our SDKs into their web site and our SDK depends on Wasm/SAB. It is hard for 3rd parties to enable the SAB without affecting their origin sites (their origin site might have other resources from other sites, that is conflict with COEP/COOP).

   The spec via IFRMAE could improve the issue and make things easier. We are looking forward for the support on mobile, weview, and all browsers.

   👍React with 👍1Reacted by Tommy Gaessler
7. adamziel commented on Mar 17, 2026

   

   adamziel

   on Mar 17, 2026

   More actions

   DIP, or a similar feature, would really help WordPress and WordPress Playground.

   For WordPress, the upcoming 7.0 release uses SAB. More specifically, it uses wasm-vips to convert large HEIC images (and other formats) to smaller PNG images before their uploaded. This expands the supported image formats beyond what most PHP hosts offer and saves upload traffic whenever someone tries to upload a 20MB photo (which happens surprisingly often).

   There are three challenges there:

   1. The post editor uses iframes internally
   2. Some WordPress hosts display the admin panel inside an iframe
   3. WordPress Playground displays an ephemeral WordPress site in an iframe

   That feature was initially implemented using the CORP/COEP headers, ran into problems, and then it moved to using DIP. With the CORP/COEP headers, the entire chain of iframes/parent windows needs to provide a compatible set of CORP/COEP headers. Refreshing the page to get a different set of headers throughout a chain is a destructive operation in the Playground context (which is why Playground implemented rewriting CORP/COEP to DIP). Also, mixing isolated and non-isolated content (e.g. YouTube embeds in the WordPress post editor) is challenging.

   DIP solves those problems. Unfortunately, it only solves them in Chromium. Having a cross-browser way of embedding a single isolated context within a larger parent context without imposing restrictions on that parent context would be a huge enabler for WordPress.

   👍React with 👍3Reacted by Tommy Gaessler, Johan Lindell and mrleemon
8. tommygaessler commented on Apr 1, 2026

   

   tommygaessler

   on Apr 1, 2026

   Last edited by tommygaessler

   More actions

   Tagging on, CORP/COEP enables powerful features, but breaks third-party embeds. DIP solves this problem, and we are already seeing positive results from users using Chrome and Edge.

   Here is some perspective from Zoom and our 3rd party developers using the Zoom Web SDKs:

   Zoom:

   Zoom Meetings on web uses CORP/COEP headers so we can leverage SharedArrayBuffer for complex audio/video tasks. While Zoom fully supports WebRTC for audio and video now, we still want to bring features we've built natively to web via WebAssembly, which leverages SAB.

   Zoom's other products on web currently do not use CORP/COEP headers because this prevents the usage of 3rd party embeds, like embedding a YouTube video in Zoom Docs or using a kanban integration like Asana in Zoom Whiteboard.

   This also becomes a problem when we want to offer Zoom Meetings inside our collaboration suite, like Zoom Docs, Whiteboard, etc.

   Zoom Web SDKs:

   You can think of this as the opposite use case; instead of embedding 3rd parties inside of Zoom, developers are embedding Zoom inside their own web experiences or building custom experiences with Zoom's real-time media stack, often among other 3rd party iFrames or SDKs.

   For example,

   • An education use case for remote learning that also uses 3rd party iFrames for videos, whiteboards, etc.
   • A healthcare use case that facilities doctor <> patient visits that also uses 3rd party embeds of charts, or EHRs.
   • A finance use case that connects financial advisors to clients, where both can view embedded portfolio charts.

   We want to give users the best experience regardless of their browser choice — DIP support on Safari and Firefox would go a long way toward that goal. We'd welcome the chance to work together on this.

   👍React with 👍5Reacted by Adam Zieliński, Fidel Tian, Michael Hagar, Johan Lindell and mrleemon
9. zcorpan commented on Aug 3, 2026

   

   zcorpan

   on Aug 3, 2026

   Member

   More actions

   From WebKit/standards-positions#399 (comment) it seems the concern about device independence is largely addressed. I don't recall any other concerns.

   Suggest positive.

   👍React with 👍2Reacted by Tommy Gaessler and Johan Lindell
10. zcorpan

    moved this from Needs proposed position to Position is proposed in standards-positions reviewon Aug 3, 2026
11. zcorpan

    added

    venue: W3C CGSpecifications in W3C Community Groups (e.g., WICG, Privacy CG)Specifications in W3C Community Groups (e.g., WICG, Privacy CG)

    position: positive

    on Aug 5, 2026
12. zcorpan

    closed this as completedon Aug 10, 2026