Hi @camillelamy, thanks for bringing this to us. We're still struggling a little bit with the explainer here, but there are a few things you might add to help us a little.

1. What is the user need that this addresses? There is some mention of performance benefits in your writeup here (~40%! [citation-needed]), but that isn't really substantiated. Can you give us some examples of real-world scenarios in which this would be used and provide material end-user benefit. In particular, why do these applications need to jointly use popups and this sort of arrangement? In "use cases" you list "App with cross-origin popup" and state "The user would like some of their compute heavy web apps to be faster" - but there is no discussion of why these applications must exist cross-origin.

2. What are the trade-offs taken for this? Or, what are the risks that we'd be taking on by allowing this loosening of cross-origin isolation? The explainer focuses exclusively on arguing for the proposal, but if we're going to make a reasoned decision, we need to understand the cost of the change. Are there any safeguards that might be needed to mitigate these risks?

3. Are there cases where applications might want to use SharedArrayBuffer, but are unable to employ a fallback method, such that enabling easier access to the capability would dramatically simplify the deployment/development of those applications?

As a web developer, I'm very interested in the "Prevent XS-leaks and Specter without having to force all my 3rd-party iFrames to use COEP" part of this proposal.

Hi @martinthomson,

1. A real world example I can give you is a compute heavy application like a spreadsheet, a video conference app or a video game that is looking to improve its performance by taking advantage of the concurrency offered by SharedArrayBuffers and WASM threads (concurrency does offer significant speed ups to compute heavy applications). At the same time those applications might use SSO authentication or payment flows that are popup based and they can't easily change that. Or they might embed third-party iframes (for example ads for monetization, or some enterprise set ups allow companies to customize web app and add their own frames to the spreadsheet app). What we've found is that it's really hard to deploy crossOriginIsolation whenever a page interacts with thrid-party content, since the interaction might not work anymore or it might require a lot of work from third-party developers. And just dropping requirements on SharedArrayBuffers has security issues. So we want compute heavy applications to be able to use concurrency through SharedArrayBuffers to improve their performance, without having to rely on 3rd party content they interact with having to do any work.

2. The trade-offs are around the process model allocation the browser vendors will use to back this. Basically, to make it work you need to process isolate the documents that have requested Document-Isolation-Policy, which requires the use of Out-Of-Process Iframes. Whereas the original COOP+COEP model was designed to work with only page level isolation. In some cases, it might lead to increased memory consumption. That said, process isolation is not actually mandated by the spec, because we do not wish to specify the implementation of process model for browser vendors. It is simply the suggestion of the authors that this is a safe way to implement the API. Not implementing it in that way would increase the risk of XS-Leaks attacks.

3. Yes, as part of the OriginTrial on Chrome, we have been working with several developers who find it much easier to gain access to SharedArrayBuffers using DocumentIsolationPolicy. This has been the case for Zoom, Gmail, Google Meet and Google Earth. Basically, large applications have a lot of cross-origin iframes, and it has been hard for the applications to get the iframes to deploy COEP. The interaction with SSO logging flows through popups was also a blocker for a number of those websites.

Hi @camillelamy,

Thanks for the above information. We took another look at this in today's TAG breakout. We need to re-review (it has been a while) and we want to be sure we can give it the attention it deserves as we're still concerned that this might just re-enable the SPECTRE-type vulnerabilities. If you have further detail, especially an analysis that shows that this doesn't re-open those vulnerabilities, or any information that could help demonstrate the feasibility of this approach, that would be helpful.

Feedback from other implementers would helpful. We see that Anne has feedback but Mozilla hasn't provided anything substantive yet.

Hi @martinthomson,

I am not sure what you mean by an analysis, but maybe I can try to explain it in a different way and see if it is clearer. Please do keep in mind that Spectre risks are strictly limited to resources inside the process of the attacker, since this is the key point on which the security model hinges.

Basically, Document-Isolation-Policy divides the documents of a particular origin into two groups, the ones that have asked for isolation and the ones that haven't. And then, it prevents documents in two different groups to have synchronous script access to each other. This allows a browser to put them in different processes (provided the browser supports Out-Of-Process-Iframes), because the communication between those documents is entirely asynchronous and so they can live in different processes. With OOPIF backing, this means that we can have a process that contains only documents of a particular origin that requested isolation. So there is no risk of a Spectre attack from those documents on other cross-origin documents.

Now we still have the question of cross-origin subresources. To make it safe, DocumentIsolationPolicy also imposes constraints on subresource loads. Since all documents in the process are same-origin, and isolated, subresources fall into one of theses buckets:

• same-origin subresources, which are fine to load in the context.
• cross-origin subresources loaded through CORS. It's fine to load them because CORS either allowlist the document origin to read their content (so no extra information gained through Spectre) or they are requested without credentials (an attacker could already request the uncredentialled resource by itself).
• cross-origin subresources loaded without CORS. these are the subresources at risk. To protect them, we do exactly as with COEP. We have two modes: require-corp and credentialless. In require-corp mode, cross-origin resources are blocked from loading unless they have a CORP header (which is an opt-in to emebedding). In credentialless mode, all non-CORS cross-origin requests are made without credentials, which makes them uninteresting to an attacker.

Now, there is always an argument that resources could be personalized due to the user's network position, but that is an existing risk of the crossOriginIsolationModel. To address it, Chrome has been looking at restrictions on private network access.

So overall, as long as the browser uses Out-Of-Process iframes to isolate the documents with DocumentIsolationPolicy, there should be no spectre risks.

A small bit of feedback if I may. That response was very good. So good, that I think you should delete the entire explainer and replace it. The explainer is very long and convoluted, but this is both clear and concise. I understand that there are some important details in the explainer that you haven't repeated, so you'd need a bit more, but I'd risk losing detail if it provided the clarity you achieved here.

With that understanding (which I'm sure I had an approximation of six months ago, but lost), I think that my concerns might now be reduced to questions about spelling. For instance, why invent new labels for things when require-corp and credentialless are labels in COEP that apply directly in this design? That's relatively minor. (Anne's comments are still relevant, of course.)

Thanks for the feedback! I have added the explanation to the beginning of the explainer.. 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. 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.