Same-Origin iframe document-access limiting attribute

[dtapuska]

こんにちはTAG!

I'm requesting a TAG review of:

• Name: document-access iframe attribute
• Specification URL: HTML Spec PR: Add disallowdocumentaccess iframe attribute to force a creation of a new agent cluster map whatwg/html#4606
• Explainer (containing user needs and example code)¹: https://github.com/dtapuska/documentaccess
• GitHub issues (if you prefer feedback filed there): https://github.com/dtapuska/documentaccess/issues
• Tests: pending
• Primary contacts (and their relationship to the specification): @dtapuska

Further details:

• Relevant time constraints or deadlines: None
• I have read and filled out the Self-Review Questionnare on Security and Privacy. The assessment is here.
• I have reviewed the TAG's API Design Principles
• The group where the work on this specification is: WHATWG HTML

There is some debate in the one PR about the feasiblity of using feature policy for this definition and I believe it is fine. There is some desire to specify feature policies in meta tags but for this definition it is required to be in a header because it changes the agent cluster (which needs to be determined before the document is created).

We'd prefer the TAG provide feedback as (please select one):

• open issues in our GitHub repo for each point of feedback
• open a single issue in our GitHub repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]

[bzbarsky]

It's worth considering the question and discussion in dtapuska/documentaccess#2

[dtapuska]

Does TAG have any feedback on the propsoal? I'd like to proceed with an I2S for Chromium on this feature.

[kenchris]

There seems to be other proposals in this same area like Document Isolation from @domenic and maybe the Document Feature policy idea.

Document Feature Policies #408
Origin Isolation #464

We think it would be better with a more broad solution, so please see if it is possible to collaborate with one of these other efforts

[domenic]

@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 SharedArrayBuffers). Note that there are other types of 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.

[dtapuska]

This issue is set to pending-external-feedback. I'm not sure that is the correct state given Domenic's response above.

I'm wondering what TAG's feedback on this proposal is. What I've seen from Mozilla is that they believe it is a major architectural change and could add additional attack vectors. I do believe that this proposal provides value and unlocks opportunities for improving performance on the web.

[kenchris]

@hober and I looked at this in a breakout and sympathize with the concerns raised in issues dtapuska/documentaccess#2, dtapuska/documentaccess#4, and dtapuska/documentaccess#6.

Developers are going to think that this is a security/privacy feature and not understand that it is mostly about performance benefits due to underlying architecture (running in same thread or not, etc) that they might not even understand.

It is also quite concerning that this adds yet another set of knobs for how to configure the whole feature/document/permissions policies and this doesn't seem to be a simplification, which @bzbarsky pointed out in this comment:

dtapuska/documentaccess#2 (comment)

[dtapuska]

@kenchris I know that I've talked with some folks in the Chromium project that suggested an alternate name for the attribute might help. I didn't want to propose this until we heard back from you. Do you feel something like that might help lead developers in the right path indicating that this is around performance rather than security.

Yes this is an unfortunate situation in that iframes should have been this model from the beginning but since we need the web to continue working it needs to be some opt-in way.

[kenchris]

@dtapuska that might indeed help. Something like disallowdirectscriptaccess, or similar - what were the suggestions that you have?

We are still worried that there are too many knobs on how to configure all of these various things already on the web, so consistency/alignment with other specs help (I remember Anne pointing that out).

[dtapuska]

@kenchris We couldn't come to a consensus on a name, we had things like separateeventloop, isolateeventloop, domworker focusing more on the event loop being different. (which then prevents direct script access) Yes the permutations of options is definitely a concern but we've thought about this a lot and we can't come up with an alternate design that meets the needs.

[kenchris]

I actually think that disallowdocumentaccess is a better name than these suggestions

[hober]

Hi,

We took another look at this during a TAG breakout today. Overall we agree this is a problem that needs solving and your approach is reasonable.

We're still concerned about the overall complexity of the web platform in this area:

It is also quite concerning that this adds yet another set of knobs for how to configure the whole feature/document/permissions policies and this doesn't seem to be a simplification[…]

But there's nothing you specifically need to change in this proposal to help with that; we're going to do a wholistic review in this area (tracked in #525) to try to identify possible simplifications or consolidations that could help.

Thanks for bringing this to us. Let us know if your design significantly changes and we'll take another look.