iframe credentialless (was: Anonymous iframe)

[ArthurSonzogni]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: iframe credentialless
• Specification or proposal URL: https://github.com/ArthurSonzogni/anonymous-iframe
• Caniuse.com URL (optional): N/A
• Bugzilla URL (optional): None. I will have to create one at some point.
• Mozillians who can provide input (optional): @annevk @smaug----

Other information

WICG proposal. The Feedback section mentions who are the developers interested in anonymous-iframe.

+CC @mikewest @camillelamy

[annevk]

We have started looking at this, but need more time. Part of this proposal I think supports the argument in whatwg/storage#142 that we ought to refactor origin, storage key, and network partition key, into a new authority field (or equivalent) we take care of propagating correctly. That ultimately means that changes like this need to happen in fewer places and we can be more sure they end up impacting all the necessary places.

[ArthurSonzogni]

Gentle ping ;-)
We would like experiment behind an origin trial in M106 (canary: Aug 18).
There are not a lot of days left and I would like to make sure AnonymousIframe's shape is something Mozilla's developers would be happy to ship.

Thanks for the 3 issues filled so far (#1, #2, #3). I did moving the anonymous bit into PolicyContainer. There are two filled issues left: the name and type of the attribute. I replied/explained and I am looking for your comments. Maybe @sefeng211 or @smaug---- have some opinions about this feature overall?

About @annevk last comment: Yes I think I agree with that.

[bgrins]

Will defer to @smaug---- but my understanding is that the concern at WICG/anonymous-iframe#5 (comment) hasn't changed:

(In general I'm rather worried about adding yet another allow/disallow/tweak-features type of attribute to iframe and not reuse existing ones)

If it were possible to solve the usecase without introducing a new attribute that seems ideal. I do see the consideration against i.e. using a new sandbox flag at https://wicg.github.io/anonymous-iframe/#alternatives-sandbox - thanks for documenting that. This may be an uninformed question, but can you say more about why this wouldn't be achievable with something like sandbox="allow-same-origin disallow-credentials"?

[ArthurSonzogni]

Thanks @bgrins!
Happy to switch to a different name if someone has some alternative proposition. I replied on the thread. We need to express something with the meaning of a "public iframe" / "~credentialless iframe" / "anonymous iframe".
I still have ~14 days before branch cut and starting experimenting. So the sooner, the better for me.

This may be an uninformed question, but can you say more about why this wouldn't be achievable with something like sandbox="allow-same-origin disallow-credentials"?

This doesn't fit sandbox attribute, because with sandbox, the iframe starts from the full "sandboxed" state and we can then allow again some of them with them with "allow-xxx". We can't express "disallow-xxx" with the syntax.
The goal of anonymous iframe was to load public document and minimizing breakage. With the sandbox syntax, users would get all the sandbox restrictions if they don't specify the full "allow-xxx" list. There are also some sandbox features that can't be toggled back.

[smaug----]

Yes you can express disallow-. Just use disallow-.

My worry with adding yet another attribute is that there isn't any coherent way to affect how iframes behave. We add more and more such attributes and the overall behavior becomes hard to define and understand.

[ArthurSonzogni]

Yes you can express disallow-. Just use disallow-.

This would introduce the first "disallow-xxx" in the API.
How do you avoid the side effect of declaring iframe.sandbox? Ask developers to add all the allow-xxx flags? What about the features without a corresponding allow-xxx flag?

My worry with adding yet another attribute is that there isn't any coherent way to affect how iframes behave. We add more and more such attributes and the overall behavior becomes hard to define and understand.

Trying to avoid new attributes to spread is a nice goal. If we can, that's good. Sandbox doesn't look like a good one to me, but maybe there are some alternatives?

[camillelamy]

I would second Arthur's comment that using sandbox flags means that we would introduce the first disallow flag, and a whole new mechanism for how sandbox flags behave.

In this particular case, there is also an additional challenge in that this particular sandbox flag could not be settable through a CSP header. This is because the request for the iframe document must be done without credentials, but by the time we get a response with a CSP header asking for this flag, credentials have already been used to make the request.

Overall, it seems to us that the precise mechanism we need to implement is sufficiently different from sandbox flags that we should have a different attribute instead of having this as a part of sandbox flags.

[bgrins]

In this particular case, there is also an additional challenge in that this particular sandbox flag could not be settable through a CSP header. This is because the request for the iframe document must be done without credentials, but by the time we get a response with a CSP header asking for this flag, credentials have already been used to make the request.

@camillelamy that's a good point and one I hadn't considered. If those headers are expected to reflect the sandbox attribute on frames then it would be surprising to add one that doesn't work the same. Might be worth capturing that in https://wicg.github.io/anonymous-iframe/#alternatives-sandbox.

[smaug----]

Sandbox is already special when it comes to CSP. CSP with <meta> can't handle sandbox at all.

[ArthurSonzogni]

Sandbox is already special when it comes to CSP. CSP with can't handle sandbox at all.

Yes, I agree the interaction with CSP and response headers is not a hard blocker for using sandbox, we could just ignore them, because it is too late.
What is blocking IMO is still that sandbox is different from anonymous iframe and iframe.sandbox can only express a set of allow-xxx. You can't define a disallow-xxx with the current sandbox syntax/behavior. By setting iframe.sandbox="allow-same-origin disallow-credentials", you would get all the unwanted sandbox restrictions and potentially a broken iframe. Sandbox flags syntax would have worked best if anonymous iframe was the default and you could allow credentials with allow-credentials. WDYT @smaug---- of my previous questions? #628 (comment)

[smaug----]

You can define disallow-xxx with sandbox. You just do it. One would need to define something new, but adding a totally new attribute is a new thing too.
But I'm not stuck with sandbox itself, just trying to figure out some way to not add yet another sandbox/allow/allowfullscreen/etc

Though, I wouldn't be surprised if credentialless iframes will be usually also sandboxed. One probably doesn't want to let ads and such to do top level navigations for example.

Do you have some concrete examples which would be broken with sandbox + disallow ? Such examples may reveal issues in the sandbox itself, like missing allow-*.

[ArthurSonzogni]

@mikewest also noted sandbox flags are inherited toward popups. This conflicts with the design where we decided the anonymous attribute do not propagate to popups (here)

We would have to define some exceptions to the current logic if we go this way.

---

Though, I wouldn't be surprised if credentialless iframes will be usually also sandboxed. One probably doesn't want to let ads and such to do top level navigations for example.

Yes, that's very likely true.

---

Do you have some concrete examples which would be broken with sandbox + disallow ? Such examples may reveal issues in the sandbox itself, like missing allow-*.

I was mostly annoyed that the closest equivalent to:

<iframe anonymous>

becomes:

<iframe sandbox="disallow-credentials allow-downloads allow-forms allow-modals
allow-orientation-lock allow-pointer-lock allow-popups
allow-popups-to-escape-sandbox allow-presentation allow-same-origin
allow-scripts allow-top-navigation">

Yes, users may already be using sandbox, in this case, this is not really annoying for them.

About the flags we can't allow-xxx back. I see:

• kNavigate. It seems to be about allowing focus without user activation.
• kPlugin. That's about loading PDF documents.
• kDocumentDomain. This is about mutating document.domain.

I also initially suspected kAutomaticFeature, but it is essentially an alias for kScript.

I will check what others are thinking about using sandbox.

---

But I'm not stuck with sandbox itself, just trying to figure out some way to not add yet another sandbox/allow/allowfullscreen/etc

Among all the existing attributes. It remains allow, I don't know enough yet to have an opinion.

<iframe allow="credentials='none'">

Not sure how it works with regards to inheritance and how to deal with the possible <allowlist>

[ArthurSonzogni]

Hello @smaug----
I discussed, mostly with @mikewest and @antosart

Developer experience is the annoying thing about the disallow- framing. Needing to specify every allow- flag to get mostly back to normal behavior isn't nice. But maybe we can define it as:

<iframe sandbox="allow-all disallow-credentials">

to switch the sandboxing parser into something of a blocklist as opposed to an allowlist?

---

About

window.anonymouslyFramed

it has to be renamed. Maybe:

window.credentialless

?

---

It is promising if the objection is only about how things are named/activated and not about how things work. @smaug---- what do you think would be Mozilla position if this is moved to a sandbox flag?

I didn't get any feedback from Webkit yet:
https://lists.webkit.org/pipermail/webkit-dev/2022-April/032205.html
Since they are now using Github too, I will ask again on this medium and let them know about @smaug---- sandbox flags proposition. This might get some attention this time.