We'd like to ship a subset of Feature Policy in order to simplify permission requests and make third-party embeddees less capable by default. Here's an enumeration of the things that need to be completed, please feel free to add blocking bugs as required:

1. allow attribute implementation with agreed upon processing model. See discussion at the end of https://github.com/w3c/webappsec-feature-policy/issues/230 for potentially drastically simplifying this.
2. Disable camera/microphone/geolocation by default in third-party embeddees (screensharing was not discussed, but mentioned in the bug Tom filed; similar for fullscreen; we should probably support those as well). And support for these permissions (and no others) in the allow attribute.
3. Integration with permissions API and WebRTC enumerateDevices() API for the supported features.
4. Simplification of the UX dialogs to only contain the top-level embedder origin.
5. Test coverage. In particular for all the web-exposed bits.
6. A blog post summarizing this change to give developers the opportunity to adapt their sites.

(If you're wondering about notifications, see bug 1560741.)

(In reply to Anne (:annevk) from comment #0)

1. Simplification of the UX dialogs to only contain the top-level embedder origin.
   I am on board with giving the top level granting rights for permissions - embed.com can't get a permission unless the top-level gives it the right to ask for the permission. But when it does ask, shouldn't we scope it to embed.com? Instead of granting to the permission to any third party in the entire page (and the first party)? Can you explain why granting, say camera access, for the whole page is beneficial? Thanks!

(In reply to Tanvi Vyas[:tanvi] from comment #1)

(In reply to Anne (:annevk) from comment #0)

1. Simplification of the UX dialogs to only contain the top-level embedder origin.
   I am on board with giving the top level granting rights for permissions - embed.com can't get a permission unless the top-level gives it the right to ask for the permission. But when it does ask, shouldn't we scope it to embed.com? Instead of granting to the permission to any third party in the entire page (and the first party)? Can you explain why granting, say camera access, for the whole page is beneficial? Thanks!

The point is that (going by our assumptions) the user makes this choice without considering the URL that's being displayed in the prompt, so effectively any third party or first party could show this prompt, and the user probably wouldn't use the domain name to make a trust decision (which makes sense, let's say you're on a site that wants your location access and the domain in the prompt is "maps-services.com", how do you know it's a malicious site vs. a legitimate service provider).

One-off granting really isn't the issue here, as that should still be scoped to the single entity that made the call to access the functionality (i.e. in my idea if the frame calls getUserMedia and gets it granted and if the top-level then call getUserMedia again there's another prompt, though we should probably clarify this). The big problem is what happens if the user clicks on "Remember this decision"?

I get your point that we could double-key the permission here. Back when we originally started this project double-keying permissions was actually technically blocked on some work that has now been resolved (and I don't think we expected it to become possible so quickly). So we could do that, on the other hand this then forces us to display very complicated UI to the user that needs a lot of explanation (we had troubles explaining iframes, now we need to explain double-keying as well). The goal of this project is to reduce the amount and complexity of the UI we have to display, so that makes me very hesitant to go down that route.

Again, I think your concern is valid but I would see it as an edge case to a large overall improvement.

I'm going to call this fixed. Let's track new bugs using bug 1531012.