Re: [w3ctag/design-reviews] Document-Isolation-Policy (Issue #995)

camillelamy left a comment (w3ctag/design-reviews#995)

Thanks for the feedback! I have added the explanation to the beginning of the [explainer.](https://github.com/WICG/document-isolation-policy?tab=readme-ov-file#document-isolation-policy-in-a-nutshell). Then if folks want more details, they can still read the rest of the explainer.

Regarding the naming, we wanted to convey the fact that the policy does more than COEP because it also puts your documents in a different agent cluster from the documents that don't have it. Hence the different name. We also thought that the mechanism of separating same-origin documents in different agent cluster is interesting (and something that some developers have requested in the past). So we thought that maybe we'll eventually extend Document-Isolation-Policy to do that with no impact on subresources and process allocation. And we would probably name such a mode isolate-something so maybe it would make sense to have all policies start with isolate.

Regarding Anne's comments, we addressed them in the [request for position](https://github.com/WebKit/standards-positions/issues/399). As explained above, the security model works because of Out-Of-Process Iframes. In Chrome, we have them everywhere except on very low end Android devices (devices with less than 2GB of RAM). So we have two options, either not give access to COI APIs on those, which is safe. This was our initial thinking, but Anne was concerned that this would break the device agnostic nature of the web. So we went back and evaluated the risk of shipping DocumentIsolationPolicy without Out-Of-Process Iframes on low-end Android devices. Based on the fact that most of those devices do not have processes with speculative execution, that it is a small fraction of devices, and that the number of those devices is going down (because even super cheap new phones have more than 2Gb of RAM nowadays), we think we should still go ahead with launching DocumentIsolationPolicy on low end Android, even if we can't have OOPIF.

The way we see it, having an OOPIF-based policy for SharedArrayBuffers is a reasonable long term model for the web. It is safe, and also deployable without too many constraints for websites. So we think this is where we should end up. And in Chrome, we're nearly there except for that small portion of Android devices. So we could either completely block on that, or go ahead with the launch even if we can't make it fully secure for those low-end devices. Considering that the reality of SharedArrayBuffer usage is that most developers use the ungated SharedArrayBuffer reverse Origin Trial on Chrome desktop, and get access to SABs without crossOriginIsolation, we think the tradeoff to get them something they can use and finally end this ungated access is worth it.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/995#issuecomment-2830726841
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/995/2830726841@github.com>