wicg / anonymous-iframe Goto Github PK

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)

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 quite understand this part of the explainer.

If the top-level page does a same-document navigation, e.g. from https://example.com/ to https://example.com/#foo, then probably you do not want to change the nonce??

And if the top-level page does a cross-document navigation, e.g. from https://example.com/ to https://example.com/bar, then all iframes will be blown away as part of creating an entirely new document.

Maybe you are talking about what happens if the iframe does a cross-document navigation, and then using bfcache we return back to the original document? I guess you would reset the nonce then?

Or is the intent instead, just, generate a new nonce for every top-level document, which all anonymous iframe descendants of that document will use?

Wouldn't that only allow talking to itself? Or it would construct an instance in its parent or something like that?

The w3c.json file in this repo does not follow the expected data model. The following errors were detected:

• unknown group name: "XXX"

_{This issue was detected and reported semi-automatically by validate-repos.}

Presumably it immediately rejects?

The state of the anonymous flag is exposed to the Window through a read-only constant attribute:

window.anonymous

It is true for Window loaded immediately inside an anonymous iframe, or deeper below it.

This should presumably be window.isAnonymouslyFramed.

While crawling Iframe credentialless, the following links to other specifications were detected as pointing to non-existing anchors:

• https://html.spec.whatwg.org/multipage/#sharedworer
• https://html.spec.whatwg.org/multipage/#service-worker-obj
• https://html.spec.whatwg.org/multipage/#HTMLIframeElement
• https://html.spec.whatwg.org/multipage/#still-on-its-initial-about:blank-document
• https://html.spec.whatwg.org/multipage/#navigation-params-hh
• https://html.spec.whatwg.org/multipage/#script-:settings-for-workers

_{This issue was detected and reported semi-automatically by Strudy based on data collected in webref.}

Should the anonymous bit be stored on a policy container? It seems like it is meant to inherit into all the relevant places.

Have y'all done any analysis of how common window.anonymous is on the web, maybe via HTTP Archive?

A quick search finds https://github.com/firebase/firebase-js-sdk/search?q=window.anonymous&type=code, which might create some confusing test errors down the road. Not sure that's a deal-breaker, but just flagging for awareness.

Looking at this again for WebKit/standards-positions#45 it occurred to us with everyone aligning on cross-site cookies, repurposing the sandbox attribute in some manner might be within grasp?

I realize this was discussed to some extent before in mozilla/standards-positions#628 (comment) but it would be nice to have this flushed out a bit more. And also discussed in a place that's a bit more appropriate.

The DOM Standard got this build error:

LINK ERROR: Multiple possible 'Window' idl refs.
Arbitrarily chose https://html.spec.whatwg.org/multipage/nav-history-apis.html#window
To auto-select one of the following refs, insert one of these lines into a <pre class=link-defaults> block:
spec:html; type:interface; text:Window
spec:anonymous-iframe; type:interface; text:Window
{{Window}}

Could you please resolve that?

Not sure if this is the right place to post this but I ran into the following issue trying to use the credentialless attribute with Twitter tweet embeds:

The iframes in this case are created by an external script (https://platform.twitter.com/widgets.js) which of course doesn't add the credentialless attribute. There is an event mechanism to run code when a tweet is rendered but it only triggers after the tweet is added to the DOM which appears to be too late.

I guess one kinda ugly workaround would be to do the tweet embedding inside a credentialless iframe but that's not really a great solution.

Ideally, there would be some way to say "please make all iframes credentialless", presumably via an HTTP header. This also would solve the issue of having to add the attribute to all iframes.

See https://w3ctag.github.io/design-principles/#naming-booleans and other precedents like crossOriginIsolated or originAgentCluster which do not have the is prefix.

I could not find any information about this online hence this post.

Is there any way one can postMessage a SharedArrayBuffer from a cross-origin iframe to it's parent window? Every combination of headers or even setting the credentialless attribute on the iframe does not work it seems.

The real-life use case here is a WASM application/plugin inside a cross-origin iframe, who's memory needs to be read by the parent window. The memory can not be copied because of performance reasons (>100mb of data up to 100 times per second).

I would've expected the credentialless attribute on the iframe to allow this as it ensures no sensitive data is inside the iframe, but instead the current behaviour is a postmessage error event when trying to send the shared array buffer from the iframe to the parent.

putting the cross-origin iframe behind a reverse proxy so it has the same-origin is also not an option, because then the (untrusted) iframe has access to all parent state. While the parent just needs to have access to the iframe shared array buffer.