-
Notifications
You must be signed in to change notification settings - Fork 56
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
Modeling media auto-playing as a permission? #203
Comments
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 |
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 #203 (comment) -- 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 |
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 whatwg/html#3617 (Mounir does not believe a Permission is the right model for this for reasons listed here. |
Inspired by conversation in #199, we have noted that the heuristics being implemented by Chrome and Safari around auto-playing media with sound are creating a situation where sites may need to "earn" the ability to auto-play.
This sounds very much like the sort of asynchronous decision made by the Progressive Web App install prompt system in various browsers and interventions being considered for permissions which are being pervasively requested at load time (but without user interaction).
In these cases, it seems as though browsers will always intervene on behalf of users. Developers will struggle to understand the situation until the reflection APIs get better. One possible alternative would be to model auto-playing media within the Permissions API which already includes a notification mechanism to let developers know when browsers change the status of a permission.
It may be necessary to extend the
PermissionState
enum to handle this situation./cc @owencm @jyasskin
The text was updated successfully, but these errors were encountered: