Consider to rename "anonymous" to "credentialless" or some such

[smaug----]

Seems like the spec doesn't try to create really anonymous iframes (anonymous feels rather strong word) but rather just credentialless.
The iframes aren't blocked from accessing each others or anything like that and they can access iframes which aren't anonymous.

(this was discussed during a Mozilla meeting on what we think of the proposal)

[ArthurSonzogni]

Thanks so much for taking the time to look into AnonymousIframe proposal!

This question makes sense. Initially, it used to be credentials=XXX. Then in a similar message than yours, but in the opposite direction, it was proposed to switch toward anonymous. Here is the rational:
camillelamy/explainers#20

What would be your prefered direction, without falling into the previous drawbacks?

[ArthurSonzogni]

@smaug---- , @sefeng211
Given camillelamy/explainers#20, do you think "anonymous" is good enough? Or do you believe something else would be a better fit?

[smaug----]

credentialless wouldn't have the drawbacks

[smaug----]

Though, #4 may require something more complicated.

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

[ArthurSonzogni]

@smaug---- I would be happy to switch to a different attribute. Do you have some proposition?

[smaug----]

credentialless. camillelamy/explainers#20 even suggested something similar 'clean-credentials'

But I'm not yet convinced we want yet another attribute to control how the iframe behaves. One might want to use sandbox attribute.

[ArthurSonzogni]

Yes

<iframe credentialless>

is nice too. We can switch again if you think this is better. What others are thinking? (@mikewest, @camillelamy, @annevk)

If we got this way, the windows.anonymouslyFramed would also need a rename. Not sure how.

But I'm not yet convinced we want yet another attribute to control how the iframe behaves. One might want to use sandbox attribute.

Okay, I will continue on: mozilla/standards-positions#628 (comment)

[RByers]

Any update? Seems like some resolution to this issue should block shipping, right?

[camillelamy]

I am happy with <iframe credentialless>. windows.anonymouslyFramed could become window.credentialless maybe?

[annevk]

The one nit I have with credentialless is that in the context of COEP it only applies to "no-cors" whereas here it would cast a wider net. We'd want to explicitly document that difference.

[ArthurSonzogni]

Similar to #1 (window.anonymous usage in the wild)
I checked window.credentialless usage in the http archive:

#standardSQL
SELECT page, url
FROM `httparchive.response_bodies.2022_10_01_mobile`
WHERE STRPOS(body, 'window.credentialless') > 0

It returned no occurrence. It seems this won't be an issue using this name.

[ArthurSonzogni]

Also pleased with the rename. I will update the explainer/spec/chrome.

The one nit I have with credentialless is that in the context of COEP it only applies to "no-cors" whereas here it would cast a wider net. We'd want to explicitly document that difference.

Thanks for mentioning it! I will make sure to add paragraph while updating it.

[ArthurSonzogni]

Okay. So this is mostly done:

1. @annevk comment 5 addressed here
2. WPT tests rename: patch
3. Spec rename: Rename anonymous iframe into iframe credentialless #13

What is left:

• Rename the repository
• Rename the WPT test directory
• Same as in (3), but in the HTML/FETCH/STORAGE/... PRs.

---

@mikewest also asked what about using window.credentiallesslyFramed instead window.credentialless.

I wonder if there's the potential for confusion between this and COEP: credentialless... Should we call this something like credentiallesslyFramed?

I don't really have a strong opinion.

[ArthurSonzogni]

I am done updating the PRs. Only the HTML required an update.
I think we can mark it as closed. Renaming the repository and the WPT directory is on its way