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

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

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.

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

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