Local scheme navigation policy container patch

[blu25]

When navigating to a URL with a local scheme (URLs like about:blank), iframes clone their policy container from the policy container of the navigation's initiating document. We don't want fenced frames to be able to do that, since that will tell the fenced frame information about a policy container that lives past a fenced frame boundary. This PR adds a patch to stop that inheritance from happening.

(Implementation detail) Note that with the Chromium's MPArch implementation of fenced frames, we get that behavior for free because the initiator frame token is not passed in to the policy container builder during the navigation request. However, we want to make sure that any other implementations also have this behavior, which is why this patch is needed.

The main algorithm that is patched is determine navigation params policy container. It now takes a new "fenced" parameter that prevents cloning the initiator policy container if set to true. There are 3 places where this function is called:

• Within the beginning navigation algorithm, which does not need a patch because the part of the algorithm where this is hit only applies to object and embed elements (it will never hit for fenced frames).
• Within “create navigation params from a srcdoc resource”, which does not need a patch because srcdoc is not supported in fenced frames.
• Within create navigation params by fetching, which does need a patch because this is the path that is taken when fetch is called to navigate a fenced frame.

---

Preview | Diff

[domfarolino]

Is there anything with PNA that needs to be addressed in the navigation case? Perhaps only for about:blank navigations but maybe more, I can't recall exactly (though I thought there was some work to be done in that area).

[blu25]

Is there anything with PNA that needs to be addressed in the navigation case? Perhaps only for about:blank navigations but maybe more, I can't recall exactly (though I thought there was some work to be done in that area).

From what I understand, we only need to make sure that fenced frames aren't inheriting the policy container's IP address space from its embedder. I don't think that happens during the fetching process.

Though, looking at this again, I'm also not entirely convinced that this where the gating should happen.

[domfarolino]

From what I understand, we only need to make sure that fenced frames aren't inheriting the policy container's IP address space from its embedder. I don't think that happens during the fetching process.

For navigations to local schemes I think it certainly can, right? https://html.spec.whatwg.org/C#populating-a-session-history-entry:determining-navigation-params-policy-container-2. So I think this is on the right track.

We also need to prevent the inheritance for initial Document creation, but that looks like it's being done mostly in https://wicg.github.io/fenced-frame/#creating-browsing-contexts-patch, which we should probably allude to in your PR, since that takes care of the creation case.

[blu25]

After talking with Titouan offline, I think we need to be patching more than just PNA. I don't think we want to inherit any part of the policy container from a parent for local navigations, so I've rewritten the spec to reflect that. Instead of just setting the IP address space, now it will only inherit the policy container from the initiator if the navigation is a local navigation not in a fenced frame. I think this is simpler and what we want the behavior to be in the end. WDYT?