Exact behavior for navigating iframes

[simon-friedberger]

I've created a new WPT to discuss some details regarding iframes: https://wpt.fyi/results/fullscreen/api/navigate-iframe.sub.html?label=master&label=experimental&aligned

Specifically, Firefox does not allow a cross-origin iframe to navigate itself to be same-origin and obtain permissions that way. Other browsers do.

My interpretation of the spec is that Firefox is correct here because of the following:

According to the spec the default origin for an iframe is its declared origin

meaning, the src attribute...

https://w3c.github.io/webappsec-permissions-policy/#declared-origin

The default allowlist for 'fullscreen' is "'self'"

https://fullscreen.spec.whatwg.org/#permissions-policy-integration

'self':

The feature is allowed in documents in top-level traversables by default,
as well as those in child navigables whose document is same origin with
its parent’s document, when allowed in that Document. It is disallowed
by default in child navigables whose document is cross-origin with its
parent’s document.

https://w3c.github.io/webappsec-permissions-policy/#default-allowlists

Therefore a navigated iframe must not have fullscreen permissions unless the new origin matches the origin in the src attribute and is same-origin with the embedding page.

I'm not sure if I am missing something but it does seem like this might not have been the intended behavior and I would appreciate some clarification.

[clelland]

The default origin concept shouldn't be relevant here; that is a property of the JavaScript interface object, and used to compute what the policy should be for an iframe, from the perspective of the containing document.

What's important here is whether the origin of the document hosted in the iframe matches the allowlist declared in the iframe element's allow attribute. For features with a default allowlist of 'self', if there is no allow attribute, then it should behave as if the allow attribute was present and matched the containing document's origin. That means that a same-origin framed document can have fullscreen permission, and a cross-origin document cannot. The spec doesn't care whether the framed document was initially same-origin because of the src attribute, or whether it happened to navigate later to a same-origin document. That's the intended meaning of the phrasing:

as well as those in child navigables whose document is same origin with
its parent’s document, when allowed in that Document. It is disallowed
by default in child navigables whose document is cross-origin with its
parent’s document.

(And that describes the default behaviour -- if there is an explicit allow attribute, then that is what we compare the framed document's origin with)

[simon-friedberger]

The default origin concept shouldn't be relevant here; that is a property of the JavaScript interface object, and used to compute what the policy should be for an iframe, from the perspective of the containing document.

I'm not sure I follow. The policy of the iframe from the perspective of the containing document should not be the actual policy of the document in the iframe?

[clelland]

If the containing document and the framed document are cross-origin with each other, then we can't expose a lot of details about the framed document. In this case specifically, the containing document shouldn't be able to know the exact origin of the framed document. It can know the value of the src attribute, but the frame may have navigated in the meantime.

Giving it the complete composed policy could reveal that new origin, so for the <iframeElement>.permissionsPolicy object, we don't use it. Instead, we use the "default origin" from that src attribute to compute what the policy would be, assuming that the frame is still hosting a document from that origin.

(That's only relevant for that JS interface -- for computing the actual policy, the browser uses the real origin of the document. It just doesn't necessarily reveal that to the parent doc)

[simon-friedberger]

Right, I understand that some values must be hidden for cross-origin isolation.

I'm not sure I follow the rest of the logic though.

If the actual policy is based on being same-origin with the document, wouldn't it make more sense for JS to use the document origin as the computed value? Or why not just remove that information from the JS object?