Anonymous iframes

[camillelamy]

Ya ya yawm TAG!

I'm requesting a TAG review of Anonymous iframes.

Anonymous iframes allows to load document that haven't enabled COEP in COEP environments. To make this safe, anonymous iframes restrict usage of shared storage and credentials, to avoid personalized resources being loaded in a high-risk crossOriginIsolated environment.

• Explainer¹ (minimally containing user needs and example code): https://github.com/camillelamy/explainers/blob/main/anonymous_iframes.md
• Security and Privacy self-review²: https://github.com/camillelamy/explainers/blob/main/anonymous_iframes.md (in the explainer)
• GitHub repo (if you prefer feedback filed there): https://github.com/camillelamy/explainers
• Primary contacts (and their relationship to the specification):
  • Camille Lamy (camillelamy), Google
• Organization/project driving the design: Chromium, Google
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status):
  • Chrome Status

Further details:

• [x] I have reviewed the TAG's Web Platform Design Principles

• The group where the incubation/design work on this is being done (or is intended to be done in the future): WHATWG

• The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG

• Existing major pieces of multi-stakeholder review or discussion of this design:

• Major unresolved issues with or opposition to this design:

• This work is being funded by: Google

You should also know that...

[please tell us anything you think is relevant to this review]

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

[hadleybeeman]

Hi @camillelamy! Thanks for this review request.

1. What end user needs are you trying to support? When would this feature be useful to a user, and why is it worth adding to the web? It would be great if you could add this to the explainer.

2. We are seeing a number of iframe related proposals, all of which would benefit from input from the rest of the W3C community. To help bring that together, we will be recommending the W3C create a task force on iFrames, and we would very much welcome your participation.

3. Could you elaborate on the answers in the Security and Privacy questionnaire? For example, where you've just said "No", can you give more detail?

[camillelamy]

Hi @hadleybeeman!

I have put together another doc explaining the wider problems we are facing with crossOriginIsolation. To sum it up: developers that currently use SharedArrayBuffers on Chrome need to migrate to crossOriginIsolation or risk losing access to SABs and their websites stop functioning. The migration to crossOriginIsolation is hard, in particular deploying COEP. COEP requires every single embedded frame to have deployed COEP to load or be blocked. This particularly complex when embedding legacy content. This proposal tackles this issue by adding an attribute on iframes that waves the COEP deployment requirement in exchange of additional restrictions on the frame. This way sites that are currently using SABs and have legacy/arbitrary 3rd party content can keep functioning. Real world examples are Google Earth or any site using both SABs and Google Ads for example.

We know that there other proposal around iframes going on, Fenced Frames for example. We have been looking at the interaction between Fenced Frames and our proposal, and we'd be happy to discuss our conclusions and look at the interaction with other iframe-related proposals.

I have also updated the Security and Privacy questionaire. However, I'd like to point out that many of the questions are yes/no questions, so there often isn't that many more details to give beyond "no the feature is not doing that".

[hober]

@atanassov and I looked at this today during our virtual F2F. One thing I'm not terribly enthused about is the name of the DOM attribute or attribute value, because it's not credentials that are being omitted, it's storage, and it's not so much that it's omitted, it's that you get a new, one-off partition. There's an open issue that captures this concern: camillelamy/explainers#20

[torgo]

Hi @camillelamy I have similar feedback as i did for #649 which is that the explainer jumps right in to talking about how "sites that wish to continue using SharedArrayBuffer must opt-into cross-origin isolation" without first talking about the end-user use cases (the user need). I see you've responded to Hadley's comment above with a link to the general doc describing the wider problem. But what user need is being served by the use of SharedArrayBuffer in this context that this set of mitigations is aimed at securing? You talk about password managers later on in the explainer doc - is that one of the primary use cases? Can you please amend the explainer to start with a few user needs to help us set the context?

[ArthurSonzogni]

But what user need is being served by the use of SharedArrayBuffer in this context that this set of mitigations is aimed at securing

SharedArrayBuffer availability in the context of an anonymous iframe is not really updated by this proposal. This is more about using SAB on the main document, which is never an anonymous one.

Let me explain why I believe anonymous iframe is useful to developers and end users:

1. End users needs performant websites.
2. Some developers get performant website, by using multithreading/SharedArrayBuffer on the main document.
3. To mitigate Spectre attacks, Web browsers (Chrome, Firefox, Safari (soon)) gate SharedArrayBuffer usage behind the crossOriginIsolated capability. This requires COOP and COEP.
4. COEP requirement is recursive: 3rd party iframes are required to deploy COEP in order to be embeddable inside a COEP parent.
5. Waiting for 3rd party to deploy COEP is painful for developers. Most of the time this is out of their control. Anonymous iframe removes the need to wait for 3rd party to update their website, at the cost of loading them using an ephemeral storage partition.

So anonymous iframe is helpful to developers, because they allow the top-level document to deploy crossOriginIsolation and keep embedding their 3rd party iframes.

Hoping to have answered the right question.

---

I made a quick online search. Here are some example of users who would see their problems addressed by this proposal:

• https://stackoverflow.com/questions/68654550/cross-origin-embedder-policy-how-to-allow-only-certain-domains
• https://twitter.com/DenisTRUFFAUT/status/1366506319990112259
• https://support.google.com/chrome/thread/117100049/cross-origin-isolation-for-part-of-the-document-and-not-the-whole-page?hl=en
• https://community.auth0.com/t/use-spa-sdk-with-cross-origin-embeder-policy/57285

[torgo]

Thanks @ArthurSonzogni that's very helpful. Can this info be brought into the explainer to make that document more clear (including the linked user needs)? This looks good to us on the basis of it being a stopgap. Can you please progress the open issues including the one Tess pointed to. Spec-wise where is this going? Is this headed to HTML?

[torgo]

@ArthurSonzogni noting the above updates to your explainer. Anything you'd in particular like to draw our attention to?

[ArthurSonzogni]

I was going to reply in a few days:

Can this info be brought into the explainer to make that document more clear (including the linked user needs)?

Will be done by PR: https://github.com/camillelamy/explainers/pull/25

Can you please progress the open issues including the one Tess pointed to

Tess pointed to https://github.com/camillelamy/explainers/issues/20, which is also addressed by PR https://github.com/camillelamy/explainers/pull/25.

Spec-wise where is this going? Is this headed to HTML?

I think HTML & fetch.

1. Adding the iframe's attribute and inheritance logic is going to happen in the HTML spec. Inheritance is similar to the sandbox attribute, modulo that this is only for iframe, it doesn't propagate to popups.

2. Some details: autofill, behavior of popup opened from anonymous iframe, etc are also going inside the HTML spec.

3. Getting an ephemeral storage partition is done by piggybacking on ongoing efforts. This is mostly about adding a nonce to the network partition key / cookie partition key / storage partition key, defined from: Partition Network State, Cookies Having Independent Partitioned State, Client-Side Storage Partitioning. This would touch HTML and fetch I believe.

[torgo]

Thanks @ArthurSonzogni based on this I think we are good to close this. Thanks for being responsive to our feedback!