search

WICG / anonymous-iframe

Give developers the ability to embed third party HTML documents inside a new and ephemeral context. In return, COEP embedding rules can be relaxed. Thanks to anonymous iframe, developers using COEP can now embed third party content that do not.
Other
25 stars 9 forks source link

Is a boolean attribute sufficient? #4

Open annevk opened 2 years ago

annevk commented 2 years ago

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"?

ArthurSonzogni commented 2 years ago

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.

annevk commented 2 years ago

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.)

ArthurSonzogni commented 2 years ago

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