Iframe credentialless (was: Anonymous iframe)

[ArthurSonzogni]

Request for position on an emerging web specification

This was previously filled as: https://lists.webkit.org/pipermail/webkit-dev/2022-April/032205.html
but didn't get any replies. Since WebKit is now using this new Github Medium, I am asking again. We would appreciate your feedback. In particular, there is a recent discussion with Mozilla who suggested activating it via a sandbox flag instead.

• WebKittens who can provide input: @annevk @cdumez

Information about the spec

• Spec Title: Iframe credentialless
• Spec URL: https://wicg.github.io/anonymous-iframe/#specification
• GitHub repository: https://github.com/WICG/anonymous-iframe
• Issue Tracker (if not the repository's issue tracker): https://github.com/WICG/anonymous-iframe/issues/
• Explainer (if not README.md in the repository): https://wicg.github.io/anonymous-iframe/#explainer

Design reviews and vendor positions

• TAG Design Review: Anonymous iframes w3ctag/design-reviews#639
• Mozilla standards-positions issue: iframe credentialless (was: Anonymous iframe) mozilla/standards-positions#628

Bugs tracking this feature

• WebKit Bugzilla:
• Radar:

Anything else we need to know

Anonymous iframes give developers a way to load documents in third party iframes using new and ephemeral contexts.

Anonymous iframes are a generalization of COEP credentialless to support 3rd party iframes that may not deploy COEP. Like with COEP credentialless, we replace the opt-in of cross-origin subresources by avoiding to load non-public resources. This will remove the constraint that 3rd party iframes must support COEP in order to be embedded in a COEP page and will unblock developers looking to adopt cross-origin-isolation.

This way, developers using COEP can now embed third party iframes that do not.

[annevk]

I think WebKit's storage policies are already pretty close to the desires of this feature:

• Cross-site storage is already ephemeral (though it does outlast a document at the moment).
• Cross-site cookies are disabled.
• requestStorageAccess() is a mismatch presumably. (Filed Define interaction with requestStorageAccess() WICG/anonymous-iframe#16 on that.)
• That cross-site documents of the same origin that are descendants of a singular top-level origin can communicate is a mismatch presumably. (Filed How could a credentialless iframe use BroadcastChannel? WICG/anonymous-iframe#15 on that.)

I guess that Chromium doesn't mean for cross-site storage to become ephemeral?

[ArthurSonzogni]

Thanks @annevk !

I think WebKit's storage policies are already pretty close to the desires of this feature:

Yes, it has some similar properties indeed, which are nice!

However, at the end, the goal of iframe credentialless is to allow embedding safely non-COEP document inside a COEP one. In particular it must be safe with regards to Spectre attacks, because the parent can be crossOriginIsolated. That's the only "real" feature of iframe credentialess. Everything else are only means to this end.

From the current Safari state, if we wanted to supersede iframe credentialless and allow the embedding without it, I think we would have to:

• Find a way to protect against attacks using a vulnerable cross-origin website. Every property you listed is Cross-Site, but Cross-Origin is needed instead. For instance, we don't want a vulnerability from blog.example.com to be used to leak data from accounts.example.com. The amount of security efforts developers are using is usually proportional to the value of the things they protect.
• Prevent autofill and similar non-web features from leaking data into the process.
• Prevent popups from leaking data into the process. This should be fine already assuming a crossOriginIsolated top-level ancestor requires COOP:same-origin.

---

I guess that Chromium doesn't mean for cross-site storage to become ephemeral?

I don't know myself if there are plans for this, beyond the current plan to bring in partitioning.

[annevk]

It has come to my attention that <iframe credentialless> is sometimes used for payment flows, despite autofill not being supported. Have you heard about this? That makes me very hesitant about this feature as it puts end users at risk, essentially training them to be phished.

[ArthurSonzogni]

+CC @camillelamy & @mikewest, as I haven't worked on <iframe credentialless> for years.
Payment data is not specific to the iframed's document, so there is no need to disable autofill here. Only username/password are needed. I guess clarifying this section would help, even if this is about vendor specific recommandations?

In Chrome's implementation, I remember it was explicitely decided not to. [internal design doc about autofill].

extract

Question: What components of autofill need to be disabled?

There are several components in autofill: payment, username/password and addresses. From the design of anonymous iframe, the only component we want to disable is username and password autofill.
We are interested in data both specific to the user and specific to the victim website. If the data isn’t specific to the website, then the attacker can get the same information from its own page anyway.

[annevk]

I think that very much depends. If you checkout through PayPal you might well have to login. But it also strikes me as very risky that some autofill functionality works and some doesn't. I don't think web developers will be able to make the right tradeoffs here as it creates a very subtle model. And web developers will just want to enable COOP+COEP and choose the most expedient route to get there.

(Also, autofill of other data might well be domain-bound in some way.)

[adamziel]

Lack of credentialless support is an issue for WebKit users browsing specific WordPress sites. You can't do these two at the same time:

• Use iframes to embed content from other sites
• Use SharedArrayBuffer

These two require conflicting CORP headers, but can work together with <iframe credentialless>. See swissspidy/media-experiments#294 for more details.

[annevk]

Thank you, rest assured that we know how the feature works and what it enables. The problem I tried to outline above is that we don't think we can support this in a way that safeguards end users.