Skip to content
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

Closed
marcoscaceres opened this issue Sep 27, 2017 · 31 comments · Fixed by #450
Closed

Feature Policy #24

marcoscaceres opened this issue Sep 27, 2017 · 31 comments · Fixed by #450
Labels
position: positive proposal appears unstable venue: W3C CG Specifications in W3C Community Groups (e.g., WICG, Privacy CG)

Comments

@marcoscaceres
Copy link
Contributor

marcoscaceres commented Sep 27, 2017

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:

  • getUserMedia (Camera, Speakers and Microphone)
  • Fullscreen
  • Geolocation
  • MIDI
  • Payments
  • Synchronous XHR
  • Synchronous scripts
  • Vibrate

There is also a detailed explainer

Introduction to Feature Policy

@annevk
Copy link
Contributor

annevk commented Nov 16, 2017

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 <iframe>s.


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.)

@upsuper
Copy link

upsuper commented Nov 21, 2017

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.

@martinthomson
Copy link
Member

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 <iframe>s being created, so it seems like a script-only solution is perfectly feasible.

@dbaron
Copy link
Contributor

dbaron commented Nov 21, 2017

(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 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.

@annevk
Copy link
Contributor

annevk commented Nov 22, 2017

@martinthomson you need a header to constrain top-level documents.

@martinthomson
Copy link
Member

@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 (navigator.featurePolicy.activate(["allowed-feature", "other-allowed"]) for instance) would be a much cheaper alternative.

@annevk
Copy link
Contributor

annevk commented Nov 23, 2017

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 document.domain is disabled we could set up a global with much less overhead.

@martinthomson
Copy link
Member

Why create a system this complex when I-need-legacy-browser-features: false is what you really want?

@annevk
Copy link
Contributor

annevk commented Nov 28, 2017

Because whenever we tightly couple solutions they don't get adoption. Needs and legacy code bases of sites are simply too diverse.

@annevk
Copy link
Contributor

annevk commented Dec 20, 2017

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.

@johannhof
Copy link

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
https://docs.google.com/document/d/1x5QejvpyQ71LPWhMLsaM1lWCfSsBsSQ8Dap9kJ6uLv0/edit#

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.

@jonathanKingston
Copy link

Some questions I have (which probably have obvious answers):

  1. Why isn't there a default-feature like there is default-src in CSP?
  2. Isn't this a SOP violation in letting one resource control / have visibility on another? (perhaps we don't care enough than improving feature control)
  3. Why is this only iframes and not other active content loads like imports and scripts?
  4. Why isn't there a disallow, so third parties linking to other third parties can be responsible citizens?
  • For example example.com iframes to a.com which loads another frame to b.com how does b.com get granted or denied?
  1. Can we make non specified features in the response policy "none" if the header is present?

@johannhof
Copy link

Why isn't there a default-feature like there is default-src in CSP?

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.

Isn't this a SOP violation in letting one resource control / have visibility on another? (perhaps we don't care enough than improving feature control)

I don't understand this question, top-level pages can already sandbox their frames.

Why is this only iframes and not other active content loads like imports and scripts?

It sounds extremely hard to implement this for dynamic content.

Why isn't there a disallow, so third parties linking to other third parties can be responsible citizens?

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?

Can we make non specified features in the response policy "none" if the header is present?

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.

@annevk
Copy link
Contributor

annevk commented Jan 16, 2018

Correct, delegation is a per-iframe-element decision.

@jesup
Copy link
Member

jesup commented Feb 16, 2018

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.

dbaron added a commit to dbaron/standards-positions that referenced this issue Mar 5, 2018
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.)
dbaron added a commit that referenced this issue Mar 6, 2018
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.)
@jcjones
Copy link
Contributor

jcjones commented Mar 7, 2018

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.

@annevk
Copy link
Contributor

annevk commented Mar 7, 2018

I think we should mark this worth prototyping. There's still some kinks to be worked out to ensure it actually reuses the CSP syntax and what self means and such, but overall it seems we need something like this.

@dbaron
Copy link
Contributor

dbaron commented Mar 7, 2018

I think I agree, but I'd like to take another look at the current state of the spec first.

@dbaron
Copy link
Contributor

dbaron commented Mar 13, 2018

Yeah, I agree with the worth prototyping. I feel like the spec could use a bit more explanatory material explaining how it should be used by other specifications, but the various explanations I've heard in places other than the spec make me consider it a promising spec. I think it's probably most valuable to write something about how it might help the default policies for existing features to evolve over time, and how it can change the tradeoffs around the default policies for new features.

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.:

  • slight disagreements between the formal syntax for the attributes and the algorithms that process them (in particular, the allow attribute uses a grammar modified by prose saying the latter part can be omitted; the algorithm also allows omitting the whitespace prior to that latter part)
  • numerous failures to use the single quotes around the special origin keywords that require them, or
  • weirdness where it seems to accept both commas and semicolons as separators but disagrees based on which is used as to whether earlier or later items win (the comma thing might have been intended as internal to the algorithms, but seems to be exposed))

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?)

dbaron added a commit to dbaron/standards-positions that referenced this issue Mar 13, 2018
@dbaron
Copy link
Contributor

dbaron commented Mar 13, 2018

I created #69 to mark this as worth prototyping. The other interesting bit there is that I added a detail field for the position, saying:

This specification allows finer-grained control over certain features; some of these features require user consent, and some have privacy and/or security implications. Allowing this control could allow pages that use these features (in many cases, following user consent) to prevent cross-origin subframes (which are often ads, and which often do tracking) from getting the same permission as the toplevel page. Having the control also makes it easier for future specifications to be designed so that this behavior is the default, but can be overridden in the other direction to allow the subframe to use the feature. The control provided by this specification also allows sites to exercise CSP-like control over their own content's use of these features.

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?

@martinthomson
Copy link
Member

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.

@annevk
Copy link
Contributor

annevk commented Mar 13, 2018

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.

@birtles
Copy link
Member

birtles commented Nov 9, 2018

I have many concerns about the proposed layout-animations feature policy that I have expressed in various issues on the repo and on blink-dev.

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.

@annevk
Copy link
Contributor

annevk commented Nov 9, 2018

@bakulf if you review Feature Policy additions, let's require an intent to implement for them so we can flag additions that are undesirable as per @birtles's comment?

@bakulf
Copy link

bakulf commented Nov 9, 2018

I'll write separate intent-to-implement communications for each new feature policy. At the moment we just have:
autoplay - camera - encrypted-media - fullscreen - geolocation - microphone - midi - payment - vr

and each one of them has been reviewed by a peer of the corresponding modules.

See: https://searchfox.org/mozilla-central/rev/17f55aee76b7c4610a974cffd3453454e0c8de7b/dom/security/featurepolicy/FeaturePolicyUtils.cpp#20-36

@annevk
Copy link
Contributor

annevk commented Mar 26, 2019

Let's reopen this for a bit given https://bugzilla.mozilla.org/show_bug.cgi?id=1531012. The new issues we identified:

@annevk annevk reopened this Mar 26, 2019
@adamroach adamroach added the venue: W3C CG Specifications in W3C Community Groups (e.g., WICG, Privacy CG) label Nov 16, 2019
@dbaron
Copy link
Contributor

dbaron commented Nov 20, 2019

@annevk Do you think that changes our worth prototyping position? Does it require revising the detailed statement of the position? (If so, could you suggest such revisions?)

@martinthomson
Copy link
Member

I think that we should be closing this now based on Anne's updates in #226.

@annevk
Copy link
Contributor

annevk commented Apr 21, 2020

Yeah, I guess it's worth noting here that there are ongoing unresolved issues with the Feature Policy specification, but we have shipped the allow attribute and are generally happy with that. We're unsure about other aspects at this point though and hope to make progress on those through the issues we raised.

@annevk
Copy link
Contributor

annevk commented Oct 6, 2020

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.

@annevk annevk reopened this Oct 6, 2020
@johannhof
Copy link

I suggest we update our detailed position to also support the header.

That SGTM

martinthomson pushed a commit that referenced this issue Oct 13, 2020
* Update Permissions Policy position per recent developments

Closes #24.

* Update activities.json
@sefeng211 sefeng211 mentioned this issue May 1, 2023
@zcorpan zcorpan changed the title RFP: Feature Policy Feature Policy Sep 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
position: positive proposal appears unstable venue: W3C CG Specifications in W3C Community Groups (e.g., WICG, Privacy CG)
Projects
None yet
Development

Successfully merging a pull request may close this issue.