-
Notifications
You must be signed in to change notification settings - Fork 155
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Need to define behaviour of features in associated browsing contexts #173
Comments
This is different from sandboxing. That requires an explicit |
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
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. |
Pointing it out; I think I agree with your analysis. |
@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 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. |
That sounds rather good. It'd be good to get some input from @mikewest @andypaicu (and others?) as I likely forgot some nuances here. |
Working this out with @domenic offline -- it feels like the best behavior for now (consistent, works with sandboxing, extendable in the future to the "
I've updated #170 with that logic; if it makes sense, I'll merge it. |
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. |
This can probably be closed, no? |
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. |
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
Proposal
My thinking is that if an associated browsing context is disowned, either by the opener using
or the user clicking a link like
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.
The text was updated successfully, but these errors were encountered: