Repository navigation
Document-Isolation-Policy #399
Description
WebKittens
Title of the proposal
Document-Isolation-Policy
URL to the spec
https://wicg.github.io/document-isolation-policy/
URL to the spec's repository
https://github.com/WICG/document-isolation-policy
Issue Tracker URL
No response
Explainer URL
No response
TAG Design Review URL
Mozilla standards-positions issue URL
mozilla/standards-positions#1074
WebKit Bugzilla URL
No response
Radar URL
No response
Description
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 (needed for OAuth and payment flows) and not requiring extra work to embed cross-origin iframes. Finally, it will be available for embedded widgets as well as top-level frames, allowing to build efficient compute heavy widgets that are embedded across a variety of websites (e.g. photo library, video conference iframe, etc…).
Activity
camillelamy commentedon Apr 3, 2025
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
annevk commentedon Apr 3, 2025
I asked a question a year ago over at explainers-by-googlers/document-isolation-policy#3 that I'm still curious about. From a quick skim it seems like this new document hasn't improved upon that.
camillelamy commentedon Apr 3, 2025
Sorry I had missed this. I have answered your question. Note that the launch in Chrome is currently desktop/laptop only, and we will follow up with mobile support later this year.
annevk commentedon Apr 4, 2025
Thank you. I worry that this will harm the device independent nature of the web.
camillelamy commentedon Apr 10, 2025
Ok, that is a fair point. We have taken into account your concerns and have revised our launch plan and will instead launch on all Android devices, even if there is a small fraction of devices where we cannot back the API with actual process isolation. Our rational is that in the long run we do want APIs like SharedArrayBuffers to be easily available to websites in a safe manner. To get there, an Out-Of-Process-Iframe backed policy is the best option. In Chrome, we can deploy this except on a small fraction of devices (Android devices with less than 2GB of RAM). Considering that these devices generally don't have processors with speculative execution flaw, their number is small in proportion, and that number is diminishing, we believe that they are less at risk than the general web. Based on this, we believe we should still launch on them, which will preserve the device independent nature of the web and move it towards a better direction when it comes to SharedArrayBuffers and WASM threads availability. Should any issue arise, we will invest in performance work to enable Out-Of-Process-Iframes specifically on the documents with DocumentIsolationPolicy for low end Android devices.
fideltian commentedon Apr 17, 2025
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.
[-]https://wicg.github.io/document-isolation-policy/[/-][+]Document-Isolation-Policy[/+]adamziel commentedon Mar 17, 2026
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:
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.
tommygaessler commentedon Apr 1, 2026
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,
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.
adamsilverstein commentedon Aug 13, 2026
We recently landed client-side media handling in WordPress 7.1, which leapfrogs server limitations by leveraging wasm-vips to do all of our media processing in the editor's browser. This feature requires SharedBuffer Array, and we use document-isolation policy by default. WebKit users get a subpar experience, they need to install a plugin and the CORP/COEP headers required break other on-page embeds and 3p resources.
Following up here to see if WebKit can consider this proposal now, I'd like to propose if for the upcoming Interop 2027.
Mozilla recently resolved their position on DIP as positive on August 10: mozilla/standards-positions#1074
The reasoning there was that the device independence concern raised on this thread looks largely settled, given Chrome revised its launch plan to cover all Android devices including those under 2GB of RAM rather than shipping desktop-only: #399 (comment)
That leaves the
concerns: portabilitylabel as the part with no public discussion attached to it, so it is hard to tell from outside whether it is a separate objection or the same one under a different name.The reason for asking now: the Interop 2027 proposal window opens September 3, and DIP is a strong candidate on developer demand. Three of the cases are already written up on this thread, from WordPress Playground, WordPress client-side media and from Zoom. A recorded WebKit position, in either direction, would tell everyone whether that is worth pursuing for 2027 or whether there is spec work to do first.
Is the device independence concern settled, and is there a portability issue still worth filing against the spec?
gregbenz commentedon Aug 25, 2026
Support for this would be high value for WordPress users uploading HDR images (including native captures with iPhone). With WP 7.1's client-side transcoding, HDR JPG gain maps are properly transcoded (JPG now, and the underlying library should be able to transcode HEIF/AVIF later this year).
The workaround would be to switch to a Chromium browser, which supports this new client-side transcoding. However, given Apple's large installed base of XDR and other great HDR displays, it would be especially helpful if the native Safari browser could be used to upload the images to WordPress.
adamsilverstein commentedon Sep 1, 2026
@annevk any updates here on WebKit's position on Document Isolation Policy? ❤️
adamsilverstein commentedon Sep 5, 2026
I have proposed Document Isolation Policy for Interop 2027: web-platform-tests/interop#1332
annevk commentedon Sep 26, 2026
Colleagues and I discussed this and are satisfied with how the portability concerns have been addressed. It remains to be seen how it will all pan out, but if browsers do their best and computing platforms continue to become more powerful there should not be much of an issue.
The remaining concern here is venue. This work should really be upstreamed to Fetch and HTML as already laid out in the document.
adamsilverstein commentedon Sep 28, 2026
Excellent, thanks for clarifying @annevk - I will see what I can do to help push the effort forward.