I've got an initial exploration of "all" capabilities and their "guards" in Chrome, at https://docs.google.com/spreadsheets/d/1xWK4uf5O3v7xTo85U3X0gGVNfJLD8_W8Zt93BO37we4/edit#gid=0. The guards form a much bigger space than permissions.query() gives access to, but we should start thinking about how to expose the whole space systematically. I'm sure it won't fit into any one enum, and I'm not confident it'll fit into the PermissionStatus interface.

Did a telecon happen yesterday and was this discussed?

We did not have a teleconference yesterday.

For what it's worth, Chrome isn't interested to express autoplay as a permission. It sounds that we might be moving towards having an autoplay field in Feature Policy as Safari is also interested in this.

It isn't clear to me that feature policy and permissions are in opposition here; to the contrary, having something as a feature policy without any introspection ability from script seems bad (and I don't note any API surface for Feature Policy here)

(Discussed in today's teleconference.)

Also, to expand a little on @slightlyoff's https://github.com/w3ctag/design-reviews/issues/203#issuecomment-346164153 -- I could imagine feature-policy as a mechanism to allow delegating the permission to subframes -- but still modeling the permission for the toplevel frame as a permission that might related to user interactions -- and still (as Alex points out) having the permissions API being a way to detect the current state that results from the whole interaction.

To me, these sounds like two different things: blocking a feature (by default or not) for cross origin iframes and having this feature as a permission. Blink is looking into having "annoying" features blocked by default on cross origin iframes to prevent abuse and give better control to the top frame owner. However, we do not want to make theses permissions as requiring the user to decide whether a website should be allowed to vibrate your phone is wasted user attention.

At the moment, autoplay policies implemented by Safari and about to launch in Chrome could not easily fit into the permission model. These policies have multiple states that change depending on the user actions on the page. It would be easy to describe the state when autoplay is allowed as allow but all the other states would hardly transcribe properly as an "autoplay" permission.

And the other thing we discussed in last week's teleconference was possibly getting some domain experts from different browsers on a call to have further discussion.

The relevant person to pull in from Mozilla would probably be @kentuckyfriedtakahe, who (being in New Zealand) could make our teleconferences that are at 1pm or 10pm California time on Tuesdays (10am or 7pm New Zealand time Wednesdays) but not the one at 7am California time on Tuesday (4am New Zealand time Wednesday).

We discussed using the call on December 19/December 20, which would be the using same times as this week's call.

Thank you @dbaron. @kentuckyfriedtakahe and I had a discussion about autoplay a couple of weeks ago. I had a similar discussion with folks from Apple (inc. @jernoble and @hober). We had brief exchanges with Microsoft too. Given the scheduling challenges, it might be useful to double-check that it will not be duplicating the various discussions that already happened. What outcome do we expect out of the call?

We need to close this out in some way - put it in the agenda for thew next f2f.

TAG resolved at Tokyo F2F: “Media autoplay should be under user control, that could mean for example having a setting "yes, autoplay is OK across the board" or it could mean origin-specific permissions prompts. "yes, netflix can autoplay videos". ---> therefore modeling autoplay as a permission is desirable because the diversity of effective policies will require that sites be able to introspect the policy without attempting to play media.”

FYI: The discussion moved here https://github.com/whatwg/html/issues/3617

(Mounir does not believe a Permission is the right model for this for reasons listed here.