Define address space inheritance rules

[letitz]

In the spec, we should explicitly answer the question: when an iframe is embedded in a document in the local address space, what should the iframe's address space be?

This needs to consider a variety of sources for the iframe's content:

• srcdoc
• data: URLs (see issue Should we explicitly define cors-rfc1918 behavior for opaque origins? #17 for a discussion)
• blob: URLs (see also issue Address space inheritance for blob URLs #18)
• javascript: URLs
• about:blank

And possibly more I have not thought of yet.

[letitz]

See also #26 for sandboxed iframes. In the scope of this issue, however, we should not bother with sandboxing.

[letitz]

Alright, so... What matters in each case is the provenance of the data loaded into the iframe. Putting aside data: and blob: which have their own issues, I think the remaining 3 cases should be treated the same:

• srcdoc
• javascript:
• about:blank

In all 3 cases, the iframe should inherit the address space of the parent frame.

[anforowicz]

For about:blank and javascript: the address space should be inherited from the initiator frame (rather than from the parent frame - just as the origin of about:blank frames is supposed to be inherited from the initiator, rather than from the parent - see the algorithms in https://html.spec.whatwg.org/multipage/browsers.html#creating-browsing-contexts).

I think that inheriting from the creator/initiator might also make sense for data: and blob: URLs.

Finally, want to note that in addition to frames, service worker can also create and navigate windows (e.g. via Clients.openWindow() API), so the inheritance wouldn't necessarily be from a frame.

[letitz]

Thanks Lukasz, that's really helpful! I'll take a closer look at that - in particular it seems https://html.spec.whatwg.org/multipage/browsers.html#determining-the-origin is very relevant.

[anforowicz]

FWIW, the policy container idea raised in whatwg/html#4926 seems at least somewhat relevant. (It also raises the question of how blob URLs should inherit various policies, which probably should also include their address space)

[letitz]

Indeed, in fact we are looking to implement correct inheritance for address space in Chromium within the policy container :)

[letitz]

Alright, having read a bit about the inheritance rules for other policies and such, I believe this would align:

• srcdoc: inherit from the parent document, if any
• about:blank and javascript: inherit from the initiator (in the case of a new iframe, this is the same as the creator?)

It bothers me somewhat that the determining the origin algorithm in the HTML spec has different logic for javascript: and about:blank.

[letitz]

@hiroshige-g has done some research into inheritance rules across policies: https://docs.google.com/document/d/1CAegq63QY0HMW-66zG4wgawIaWGi33MHtmU3azQQNz8/edit#heading=h.cbj3hy89egsx

[letitz]

See also w3ctag/design-principles#111, which discusses general inheritance principles.

[letitz]

Ok, upon doing some more reading of the various related issues, I think this suggestion from the policy container issue makes the most sense: whatwg/html#4926 (comment). Adapting it lightly for our purposes, this yields the following algorithm:

• If URL is "about:srcdoc" and parent window exists:
  • Inherit policy from parent window
• If scheme is "about" or "data" or "javascript":
  • Inherit policy from Navigation Initiator
• If scheme is "blob" (or "filesystem"):
  • Inherit policy from URL creator

I'll draft a PR.

[letitz]

Mike has some suggestions for how to patch the specs to define inheritance in the case of about:srcdoc, data: and javascript: here: #37 (comment)

[letitz]

This issue is fixed by integration with HTML's new policy container, added in 4627c13.