Re: [w3ctag/design-reviews] Same-Origin iframe document-access limiting attribute (#397)

@dtapuska and I have discussed the relationship between origin isolation and disallowdocumentaccess at length. Although it is subtle, we conclude that they are best separated. Let me try to lay out the arguments. (We fully recognize that it would be helpful to have these in one or both of the explainers, and are planning to work on that in the near future.)

---

First, it's worth acknowledging what they have in common. They both achieve similar outcomes when applied: they isolate "something" in the same way. The specific definition of isolation here is the agent cluster boundary; roughly speaking, two things isolated into separate agent clusters in this way can no longer synchronously script each other (either via normal access, or via using `document.domain` to loosen the same-origin policy), and they can no longer share memory with each other (by `postMessage()`ing `SharedArrayBuffer`s). Note that there are [other types of isolation](https://github.com/WICG/origin-isolation#potential-future-work-on-further-isolation), but both proposals are intentionally restricting themselves to this particular type for now.

This agent cluster isolation has a number of potential benefits, in that it allows user agents---if they choose---to separate the isolated windows into different processes, or threads, or event loops, or similar, because there is no longer any shared memory or synchronous access possible. In essence, by invoking either of these mechanisms, the web developer is giving up some rarely-used capabilities, in exchange for potentially better performance and security.

---

Now let's talk about how they differ.

The fundamental differences are _the point at which they are applied_, and, very relatedly, _where they can be applied_. Origin isolation is something an origin applies, to every page on that origin, to ensure that origin gets isolated from other same-site-but-cross-origin pages, which would normally be in the agent cluster. Whereas disallowdocumentaccess is applied _as part of the embedding relationship_, i.e. in the `<iframe>` element.

These fundamental differences lead to a number of different consequences that make origin isolation more suitable for some cases:

- Origin isolation is more useful as a security boundary. It provides a single set-and-forget isolation mechanism that protects your origin in all cases, no matter whether you are the embedder, or the embedee.
- In particular, disallowdocumentaccess cannot protect your origin from being embedded, and put in the same agent cluster, by a same-site-cross-origin page. The embedder would simply choose not to put the `disallowdocumentaccess` attribute on the iframe when embedding you, and there's nothing you can do. (Except use origin isolation.)
- Similarly, disallowdocumentaccess provides no mechanism for isolating two top-level tabs with no embedder/embedee relationship. For example `https://mail.example.com/` might open `https://docs.example.com/` using `window.open()` or clicking on a `<a href>`, and there's no way to use disallowdocumentaccess to separate these into separate agent clusters.
- More esoterically, the user could open two top-level tabs to these URLs independently; although in those cases the tabs will not be in the same agent cluster (and thus cannot share memory/synchronously access each other anyway), they might be put in the same process in implementations. Origin isolation can be used to hint to the implementation that this is undesirable.

But in turn, the fundamental differences also lead to a number of cases where disallowdocumentaccess is more suitable:

- Disallowdocumentaccess can be applied selectively, on a per-embedding basis. You may want to isolate some cross-origin same-site iframes from your page (e.g. those from `https://third-party-widget-marketplace.example.com/`), but not others (e.g. those from `https://first-party-calendar-widget.example.com/`).
- Disallowdocumentaccess can be applied to isolate you even from _same-origin_ iframes. This is very useful because it essentially allows you to create "DOM workers", that run in a separate event loop (and potentially a separate thread/process), but still operate on your origin (and thus have access to, e.g., your origin's storage). This use case makes no sense for origin isolation, because the origin policy is about the origin, not about relationships between individual iframes and embedding pages within the origin.

----

Another way of looking at this is what problems each technology is fixing.

- Origin isolation allows an origin to fix some of the more egregious holes in the same-origin policy, that allow same-site-but-cross-origin pages to slip through into the process space, both in spec terms (where processes correspond to agent clusters), and in implementations.
- disallowdocumentaccess is fixing the fact that iframes are allowed to synchronously communicate by default. Modern techniques for creating separate realms, such as workers or portals, require asynchronous communication across the realm boundary; this enforces better programming discipline (e.g. avoiding leaking `Window` objects, which is a huge problem in the wild) and gives implementations more flexibility and optimizability. Iframes unfortunately got the default wrong, but disallowdocumentaccess allows an opt-in fix for this on a per-iframe level.

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