Need to define behaviour of features in associated browsing contexts

[clelland]

As one of the last things to solidify in the spec, I'm trying to work out the correct mechanism for feature inheritance in associated browsing contexts -- essentially popup windows, and new tabs/windows opened from clicking links.

My instinct here is that associated browsing contexts which don't disown their opener are still "connected" enough to it that they should inherit the same restrictions/policies as their opener. This would mean that if, say, paymentRequest or geolocation is disabled in an iframe, it cannot open a popup which has access to those APIs. Sandboxed iframes work similarly to this. This would stop a page from opening a popup and then having that popup use postMessage to shuttle information back to the opener.

OTOH, associated browsing contexts are considered top-level browsing contexts by the spec, and so this may not be compatible with the existing web. Features like fullscreen or WebVR, which are defined to be allowed in top-level contexts, would not work in these popups -- or even in a new tab opened from a link like

<a href="https://example.com" target="_blank">

Proposal

My thinking is that if an associated browsing context is disowned, either by the opener using

window.open("https://example.com", "noopener")

or the user clicking a link like

<a href="https://example.com" target="_blank" rel="noopener">

then there's not much difference between that new window, and just navigating to a new page, in which case the new page would just get all of the features normally granted to top-level documents. (Or right-click, open-link-in-new-tab)

I would propose, then, that an associated browsing context which is not disowned inherits the parent's policy, in the same way as if it were an iframe embedded in its parent. A disowned context is treated like a new navigation, or a completely new tab, and is treated like any other top-level browsing context.

Does this seem like a reasonable way forward? Or am I misusing the 'owner' concept here?

See #170 for some actual spec text changes that I think would do this.

[annevk]

This is different from sandboxing. That requires an explicit allow-popups-to-escape-sandbox token.

[clelland]

It is different, that's correct. (Not sure if you're suggesting that diverging from it would be okay or not, or just pointing it out).

Sandboxing has a different set of constraints, since

• Sandboxed pages / frames are typically cross-origin to each other anyway, so you can't just open a new same-origin window with relaxed permissions
• Sandboxing isn't used to control features which are just available-at-top-level, blocked-cross-origin. Many of these features should be available in new top level contexts most of the time, I think.

Maybe we could spec a similar feature (and have it on by default, likely) to the sandboxed auxiliary navigation browsing context flag, and use that instead. We'd have to think carefully about how to do that without breaking compatibility, I expect.

[annevk]

Pointing it out; I think I agree with your analysis.

[clelland]

@annevk, does this seem like a reasonable proposal?

The other option that I can see is that we make a policy-controlled feature similar to allow-popups-to-escape-sandbox—maybe reset-policy-in-popups—which determines whether the policy in a new tab/window is inherited from the parent or treated as a new top-level browsing context. We can ensure that it is disabled in sandboxed frames (or couple it to the allow-popups-to-escape-sandbox flag) but have it enabled by default everywhere else (default allowlist of *, like syncxhr).

The biggest source of web-incompatibility I can see with that is any features which are disabled in cross-origin frames by default would now also be disabled in sandbox-triggered-popups (they're enabled today). This could be a good thing, though, because right now popups can use things like fullscreen, webusb, paymentrequest, even if they're still sandboxed; this would stop that from being possible.

[annevk]

That sounds rather good. It'd be good to get some input from @mikewest @andypaicu (and others?) as I likely forgot some nuances here.

[clelland]

Working this out with @domenic offline -- it feels like the best behavior for now (consistent, works with sandboxing, extendable in the future to the "reset-policy-in-popups" idea if we want to) would be this:

• From a non-sandboxed document, opening a popup works like originally proposed -- popups inherit the opener's feature policy, unless disowned.
• From a sandboxed document with the allow-popups-to-escape-sandbox flag set, it works the same way. You have the option of breaking out of the feature policy, but you have to disown your popups to do so.
• From any other sandboxed document, popups always inherit their opener's feature policy.

I've updated #170 with that logic; if it makes sense, I'll merge it.

[clelland]

Rebased and updated, but botched the merge. This is #259 now.

In order to use feature policy for existing sandbox features, this isn't quite going to be enough, as those currently do not require popups to disown their opener in order to escape the sandbox. We will either need to fix that in HTML (require noopener as well), or make a special class of features which don't require noopener, and use that for the sandbox features.

@annevk, @domenic, WDYT?

[annevk]

This can probably be closed, no?

[clelland]

Yes. #259 is closed, and is not going to be merged. Permissions Policy resets in popups, as the user is presented with a new top-level window, and can make informed security/privacy decisions regarding that window's (and origin's) actions.

Sandbox features are not currently being considered for Permissions Policy.

Closing this now.