RFP: Feature Policy about standards-positions HOT 31 CLOSED

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

from standards-positions.

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.

from standards-positions.

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

from standards-positions.

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

from standards-positions.

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

That SGTM

from standards-positions.

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

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.

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

from standards-positions.

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

from standards-positions.

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

from standards-positions.

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.

from standards-positions.

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

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.

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?

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

from standards-positions.

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.

from standards-positions.

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

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.

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

from standards-positions.

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

from standards-positions.

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?

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.

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

from standards-positions.

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

• We'd rather not put all feature strings in a single namespace and have lots of hidden booleans control the processing model of those strings. In particular, it makes sense to separate permissions and sandboxing as detailed in https://github.com/w3c/webappsec-feature-policy/issues/282#issuecomment-467015708.
• Sandboxing features need to be opt-in to ensure an attacker cannot alter the control flow of a victim. This might get addressed as part of w3c/webappsec-permissions-policy#288.

from standards-positions.

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

from standards-positions.

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.

from standards-positions.

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.

from standards-positions.