Is a boolean attribute sufficient?
Opened this issue · 5 comments
It seems that if the attribute is not set, it's value means "inherit", not "false". Could there be a future where we want to express "false"?
I don't think there is a future like this, in the context of COEP (see below)
However, maybe we should switch back toward a string value, so that future web browser developer can potentially repurpose the "anonymous" attribute in a different way, potentially (?)
The goal was to avoid the problem with COEP: its requirement is recursive. When you want to embed a website, you need to ask the 3rd party to deploy COEP, and the 3rd party of your 3rd party to deploy COEP too. In most cases, it is not possible.
So the anonymous bit is inherited and can only become more restricted. This is similar to sandbox flags in some sense. This guarantee when using anonymous iframe that you aren't going to break the iframe. It is guaranteed to load.
If we allowed to express "false", this would break the chain and won't be able to provide this guarantee anymore.
Also, allowing multiple change along the ancestor chain would force us to update some algorithm and check the whole chain instead of depending only on the parent. Doable, but not ideal. There is also the question of popups.
I haven't fully thought this through, but a way to think of this feature might be as a COEP policy. It is then conceivable that a nested document could meet that COEP requirement in another way. Of course, given the way this is structured the embedder would have to know that in advance and undo the "forced COEP" somehow.
Have you tried to imagine this feature as a COEP policy rather than a new kind of policy? (Happy to open a new issue for this if you prefer.)
Have you tried to imagine this feature as a COEP policy rather than a new kind of policy?
This was the original idea. Then, we had 3 meeting during Feb/March 2021, which caused us to reconsider it, and put anonymous iframe out of COEP:credentialless. I realize the necessary justification isn't yet part of the "alternatives considered" section. Please let me some time to update this section. I will let you know when it's updated.
Anonymous iframe affects the credentials of the navigation request, so we can't really rely on the navigation's response later for a potential override/inherit decision at the child level.
So the parent is the only one who can make the decision, prior to sending the navigation request. However, it can still be part of its own COEP policy like you said. However, this would be a "global" state and developer wouldn't have a way to make the appropriate decision on each individual <iframe>.
It is important, because there are website containing a mix of <iframe> it controls where credentials play a role, and some <iframe> outside of their own control, like ads.
With COEP:credentialless you can make the decision at the individual request level, by switching the request.mode to CORS and request.credentials to "include".
We need something similar for the <iframe> element. This became <iframe credentials="xxx">. Then it became <iframe anonymous> (see why).
I was thinking of something where you'd still have <iframe x>, but the result is as if the newly navigated document ends up with Cross-Origin-Embedder-Policy: forced-credentialless or some such. But reflecting on it a bit more I suspect that's not great as this ends up impacting all requests, not just "no-cors" requests. And COEP thus far has been strictly about the latter.
(@smaug---- was wondering if this could be part of a larger whole somehow and that made me think along these lines, but I can't quite figure it out.)
I added an "alternative considered" about using some kind of COEP:credentialless top-level state:
https://wicg.github.io/anonymous-iframe/#alternatives-coep-credentialless
Cross-Origin-Embedder-Policy: forced-credentialless or some such. But reflecting on it a bit more I suspect that's not great as this ends up impacting all requests, not just "no-cors" requests. And COEP thus far has been strictly about the latter.
Yes, that's right.
One thing we wanted with anonymous iframe, is being able to ensure the iframe's document to load. Using an ephemeral storage area is different from forcing COEP:credentialless. The main differences are:
COEP: credentiallesscauses no-cors request to omit credentials, so the embedded website may be broken. With the anonymous iframe, it will behave as if it was the first visit ever. It can set some cookies using JS and issue some fetch with those cookies. It won't break the website.- COEP:credentialless only affect the network requests issued by the website, but we need to protect from any kind of credentials being leaked through Spectre. This is more than just cookies. This is about every kind of storage API.
I am wondering if @smaug---- would have some alternative to anonymous iframe.