Open ArthurSonzogni opened 2 years ago
I think WebKit's storage policies are already pretty close to the desires of this feature:
requestStorageAccess()
is a mismatch presumably. (Filed https://github.com/WICG/anonymous-iframe/issues/16 on that.)I guess that Chromium doesn't mean for cross-site storage to become ephemeral?
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:
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.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.
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.
+CC @CamilleLamy & @MikeWest, as I haven't worked on 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].
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.)
Lack of credentialless
support is an issue for WebKit users browsing specific WordPress sites. You can't do these two at the same time:
SharedArrayBuffer
These two require conflicting CORP headers, but can work together with <iframe credentialless>
. See https://github.com/swissspidy/media-experiments/issues/294 for more details.
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.
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.
Information about the spec
Design reviews and vendor positions
Bugs tracking this feature
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.