-
Notifications
You must be signed in to change notification settings - Fork 72
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
Feature Policy #24
Comments
It would be good to figure this out, as proposals are made to integrate this into the various standards it affects. E.g., whatwg/fullscreen#106. I also believe that @kentuckyfriedtakahe and @BlakeWu likely want this for "autoplay" control of Personally I think this approach seems reasonable. Offer control on a per-feature basis and leave grouping of features up to libraries and the future. (It's a little unfortunate the permission proposal for not prompting on behalf of parties other than the one in the address bar got lost. Hopefully that makes a comeback some day.) |
I read the draft briefly (without digging into every details), and it seems to me that it is a reasonable mechanism to control availability of features in documents. It may need some investigation on how this would integrate / interact with other standards, what it means for future features, and whether its API is understandable and explorable for web developers. |
The general idea here is fine. The implementation seems a little over-engineered. For example, I don't see why this needs new HTTP header fields or a convoluted grammar. I might be wrong, but I believe that script from a top-level browsing context always has a chance to run prior to things like |
I think this allows at least doing that for new permissions -- if they have a feature-policy from the start, then they could default to not delegating to subframes, but allow that delegation via explicit feature-policy, and then associate the permission grant with the origin of the toplevel document. And maybe it would be possible to move some existing things to that model as well. |
@martinthomson you need a header to constrain top-level documents. |
@annevk, "need" is a little strong for me. The assessment I am making is taking the complexity (in implementation and other things) relative to the value. Adding another bucket-load of bytes to every response is not a great solution. If you believe CSP to be an unmitigated success, then cloning it makes sense. I don't believe that CSP is successful enough to justify that. A simple API ( |
Is it? It seems that knowing ahead of time what features are enabled/disabled would allow for some optimizations not possible through a dynamic API. E.g., if we know |
Why create a system this complex when |
Because whenever we tightly couple solutions they don't get adoption. Needs and legacy code bases of sites are simply too diverse. |
We discussed some of the parser complexity concerns at the All Hands in the DOM team meeting. It turns out that Feature Policy is supposed to reuse the exact syntax of CSP. However, currently the specification is not layered in such a fashion. I've filed an issue on that and also filed another dozen on other things I noticed: https://github.com/WICG/feature-policy/issues/created_by/annevk. I'm now personally involved I suppose, though I did also keep @bzbarsky somewhat informed of my findings. @kentuckyfriedtakahe et al are also looking at implementing parts of Feature Policy for "autoplay", so I think at this point we're somewhat on board, with lots of reservations on various details. |
Chrome has put forward an intent to implement a new permission model that forces top-level origins to delegate their permission access to embedded frames using feature policy (for all permissions and not just new permissions as mentioned in #24 (comment)). https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/irAY53rSXIE/p0oZ5j4mAgAJ The proposal makes a lot of sense to me and IMO it makes an excellent use case for feature policy. Working on permissions UX we've wanted something like this for a long time. |
Some questions I have (which probably have obvious answers):
|
The list of features they're thinking about including is probably a bit too diverse to just brush it all over with a default value.
I don't understand this question, top-level pages can already sandbox their frames.
It sounds extremely hard to implement this for dynamic content.
Huh, I was expecting that iframes themselves had to delegate their features to their own iframes explicitly, but the spec isn't 100% clear on that to me. Maybe @annevk can clarify?
See first answer, it seems like people intend to stuff all sorts of things in there, including disabling features for performance sake, so this doesn't seem viable if you want people to adopt it. Even if it were only for permission-limited features, you'd have troubles introducing a new item to the list and then having it denied by default for all users of feature policy. |
Correct, delegation is a per- |
As johannh pointed out, we could use this for bug 1389198, and Chrome has already started blocking getusermedia in cross-origin iframes leveraging feature-policy. Separately, I've been discussing with dbaron and others the possibility of using feature-policy to impose limits on iframes (specifically ads, but that's up to the site) to help limit runaway leaks and CPU use in 3rd-party sources. (This also could help block cryptocurrency mining some, perhaps.) Still in the thinking-about-options phase, but feature-policy would be a good place to hook it in. |
These issues seem worth trying to resolve first, and as part of being more public about that discussion, I'm going to explicitly list them as "under consideration" and reference their issues. This will thus link to mozilla#58, mozilla#27, mozilla#24, and mozilla#19. It also happens to include the first links to caniuse (the "ciuName" field being non-null). Note that activities.py normalized some whitespace in a prior entry added in mozilla#53. (I should figure out why it's always adding a space at the end of the line, but that's a separate issue. Until then, I'd rather keep the file matching the way activities.py regenerates it rather than having to hand-edit every time to avoid changing those lines.)
These issues seem worth trying to resolve first, and as part of being more public about that discussion, I'm going to explicitly list them as "under consideration" and reference their issues. This will thus link to #58, #27, #24, and #19. It also happens to include the first links to caniuse (the "ciuName" field being non-null), and first links to bugzilla. Note that activities.py normalized some whitespace in a prior entry added in #53. (I should figure out why it's always adding a space at the end of the line, but that's a separate issue. Until then, I'd rather keep the file matching the way activities.py regenerates it rather than having to hand-edit every time to avoid changing those lines.)
Feature-Policy is currently the leading mechanism in discussions of how to allow Web Authentication to be used from cross-origin iframes; we call it out in a Note after point 2 of WebAuthn's algorithms. WebAuthn doesn't currently define any dependencies on Feature-Policy. It's something the WG has put off addressing. That said, I've already received several queries about how payment industry can use WebAuthn from within the iframes they already deploy for all of their embedded checkout mechanisms, so the questions will only increase. Since WebAuthn is rapidly approaching a Candidate Recommendation, and pressures will continue regarding using WebAuthn for iframes, this is a discussion worth accelerating, whether it's a consensus on implementing, or a recommendation to WebAuthn to approach this a different way. |
I think we should mark this |
I think I agree, but I'd like to take another look at the current state of the spec first. |
Yeah, I agree with the I think the spec is isn't all the way to being a formal spec yet, though. It's not clear to me if the things that are wrong are worth filing bugs about given the current level of stability of the spec, e.g.:
though I suspect they are and I should find some time to file them. It also feels like maybe it's getting enough support that it should be moving from WICG into a working group at some point soon. (Is WebAppSec appropriate?) |
I created #69 to mark this as
I'd like to know if others here think this is a reasonable statement -- and also whether it says anything that you think we shouldn't say? |
This is a fine statement. I agree that it is worth investigating further. For the record, the big problem I have with this is the CSP-like imposition on http header fields. I would be much happier if every single page load weren't encumbered by more CSP-style goop. There are better solutions, but not a lot of enthusiasm for fixing them. The idea that http/2 will magically fix infelicitous use of HTTP is a nasty meme. |
Something like https://wicg.github.io/origin-policy/ (but without the current issues) would go a long way towards addressing those, but given the legacy of existing sites I suspect they want a per-document migration story as well. |
I have many concerns about the proposed I hope our 'worth prototyping' status on Feature Policy in general is not applied to the layout-animations part as well, but given that layout animations is currently a separate doc, perhaps we're ok for now. |
I'll write separate intent-to-implement communications for each new feature policy. At the moment we just have: and each one of them has been reviewed by a peer of the corresponding modules. |
Let's reopen this for a bit given https://bugzilla.mozilla.org/show_bug.cgi?id=1531012. The new issues we identified:
|
@annevk Do you think that changes our |
I think that we should be closing this now based on Anne's updates in #226. |
Yeah, I guess it's worth noting here that there are ongoing unresolved issues with the Feature Policy specification, but we have shipped the |
Reopening this now that the header has been renamed and revised to use structured fields. I believe it's now also authoritative, potentially allowing for more sandboxing and such. I suggest we update our detailed position to also support the header. |
That SGTM |
* Update Permissions Policy position per recent developments Closes #24. * Update activities.json
Request for Mozilla Position on an Emerging Web Specification
Other information
This is WICG proposal.
A web platform API which gives a website the ability to allow and deny the use of browser features in its own frame, and in iframes that it embeds. Examples of features that could be controlled by feature policy include:
There is also a detailed explainer
Introduction to Feature Policy
The text was updated successfully, but these errors were encountered: