(Updated) Feature Policy v1 explainer

[igrigorik]

We've been making steady progress on this end on Feature Policy and, as is usually the case, once you start implementing, you discover all kinds of opportunities to clarify and simplify things.

Latest explainer and a couple of highlights below:
https://docs.google.com/document/d/1k0Ua-ZWlM_PsFCFdLMa8kaVTo32PeNZ4G7FFHqpFx4E/edit

You'll notice that the explainer takes a slightly different (whitelist based) approach from the one we were exploring in earlier drafts of this proposal (note: the spec doc is out of date, ignore it for now and refer to the explainer instead). The end result is the same but—I think—much cleaner both conceptually and in terms of implementation.

Speaking of implementation, @clelland and @raymeskhoury have been busy building out a prototype in Chrome and are making great progress - we should have a working demo soon! For the first version we're targeting a small set of features that will be controlled via this mechanism: Vibrate API, getUserMedia, and maybe a few other related permissions based APIs. At a minimum, this would bring coherence into the growing mess of "allowX" iframe attribute proposals, which would already be a nice win for the platform! From there (v2+), we can then reuse the same mechanism to expose control over the long list of other features that folks have been asking for.

---

Would love to hear any thoughts and feedback!

Outstanding v1 issues: https://github.com/WICG/feature-policy/milestone/1

[igrigorik]

Copying (email) feedback from @smaug----...

I wonder if [Feature=foobar] should be able to also say the default enabling policy.
Something like [Feature=midi,default-disabled] or [Feature=midi,top-enabled] or hopefully some better syntax. That would make it a tad less error prone to implement this stuff, since the default would be controlled by the (generated) bindings layer, and would ease reading specs too.

Since this has some similarity to SecureContext too (exposing APIs conditionally), would there be some webidl syntax to capture them both better than 'SecureContext, Feature=payment'. Perhaps Exposed could be reused here? Expose=Window,<midi, top-enabled>,SecureContext. Hmm, dunno if that is easier for the reader, but at least it would explain in one place what all affects whether the API is exposed in some global.

---

Also, paging @domenic @annevk @toddreifsteck @rniwa @foolip: would love to hear your thoughts and comments on the new explainer!

[annevk]

It's a little too sketchy still for my taste. Should this be done together with permission delegation perhaps as they both have similar goals?

[igrigorik]

@annevk we've already merged permission delegation use cases (which @raymeskhoury and @noncombatant were driving) with FP - e.g. a feature (say, Vibrate) can have a default policy of "disabled" in nested contexts, and the embedder has to explicitly enable said feature via FP.

[alvestrand]

@igrigorik do you want issues raised in docs comments, in new github issues, or as comments on this issue?
I added a few comments to the document, but I lose track of such easily.

[annevk]

@igrigorik I'm not sure what that means. How would I enable an <iframe> to use my Notifications API permission?

[tobie]

Really excited by this as it helps solve a bunch of issues around sensor permissions in embedded iframes, but we need a clearer story for dealing with APIs requesting permissions. Does the trust chain extend to passing user-granted permissions across origins using that system? i.e. if I grant access to geolocation in a top-level browsing context which navigated to https://example.com and allow geolocation access to an embedded iframe pointing at https://ads.com, does that also grant geolocation permission to ads.com? If not, how can the user be prompted in a way that makes it clear who is requesting access?

[tobie]

I also very much like the idea of a shared registry of "features" (as you call them) between this spec and the permissions spec, along with dedicated WebIDL extended attributes to annotate APIs (similar to what was done with SecureContext). Happy to help get those integrated in WebIDL when the time comes.

[raymeskhoury]

@annevk @tobie @alvestrand All good questions regarding permissions - let me try to explain. In the explainer, we've focussed mainly on the Feature Policy mechanism itself and how it would work for non-permission features. This is just because that's already somewhat complicated and we wanted to try to convey it in an understandable way.

However we are actively working on how this integrates with permissions (that's actually my personal priority). I think there are 2 main questions here:

1. How does the list of features relate to the list of permissions in the permissions spec. We don't have a concrete plan for that yet, but I agree with @tobie that this should be a unified/shared list. I'm happy to draft up a proposal for how that could work.
2. How this is related to "permission delegation". Specifically, what happens when you specify a policy which allows a permission in an iframe. If that iframe requests permission, what would the request look like and how would the decision be stored. This is partly a UX question but we would still basically like to pursue the (now outdated) permission delegation proposal here https://noncombatant.github.io/permission-delegation-api/ but using feature policy as the mechanism to do the delegation. We're actively doing UX research in this area. Does that make sense? Happy to chat more :)

[alvestrand]

@raymeskhoury in an explainer, the important thing is to show that you're aware of the issue, that you think there are solutions, and that you intend for the spec to solve it.
Saying that you intend to solve for /permissions/ and that /permission-delegation-api/ can be ignored is exactly the info I think should be in an explainer; shouldn't take more than a paragraph.

For mediacapture, I think the desirable interaction is that when permission is given to an iframe, it has access to exactly the devices of the containing frame - if some of them are in "prompt", they should be prompted for with the context of the containing frame, and if stored, permission should be stored for the containing frame and be avalible to all iframes with the permission.

I'm sure a filered approach ("grant this device but no other to this iframe") is possible to specify, but I'm not sure it's possible to explain to either the users or the application writers.

[tobie]

1. How does the list of features relate to the list of permissions in the permissions spec. We don't have a concrete plan for that yet, but I agree with @tobie that this should be a unified/shared list. I'm happy to draft up a proposal for how that could work.

Awesome. Would love to see that. Do you have an ETA on this? It's a dependency for the Generic Sensor API, and depending on what timeframe you're looking at, I'll either wait or pursue a different (probably temporary) solution.

[igrigorik]

@annevk In addition to @raymeskhoury's reply, take a look at examples 1 and 9. Do those make sense?

---

As an aside, it looks like there was some confusion earlier between explainer and the (very) outdated spec doc. Apologies about that, we should have taken that doc down earlier. With that in mind, I've redirected the spec to the explainer; let's hash out the high order bits in the explainer, and we can translate to specese once the dust settles down.

[annevk]

Generally it seems fine, but I personally need something more concrete to be able to review.

[annevk]

Closing as this is no longer relevant.