And there's no understanding among a lot of web standards people that popups for site permissions are widely used by malicious actors. Apple consulted the community and thought about security, and that's why this implementation is refreshingly better.
If the user doesn't know how to enable those permissions, then they also very likely don't know how to disable them either, which is a problem. If they don't know those permissions exist, they also probably don't know what the implications are of turning them on. Giving them a bunch of yes/no dialogs to click through doesn't change anything about the obligation to educate users about their device permissions, and if they are educated properly then they can set those permissions themselves.
Google (and browser manufactures in general) kind of taught people that the way we do permissions is that apps ask for them and the user says yes/no, and the app responds. It's not entirely only their fault, but it's the wrong way to think about it in my opinion. I'm not even sure I like the word "permissions". Most permissions should be better thought of as "capabilities" and they should be something granted by the user, not requested by the app, and the app shouldn't be able to tell the difference between a phone/platform that doesn't support those capabilities at all and a phone/platform where the user has denied those capabilities.
A lot of issues about how permissions aren't scalable or how they don't work stem from the way we think about permissions as if the default UX for them should be that they're handed to the user like a EULA to sign.
----
I'm still bitter over the fact that Chrome blocks webaudio behind a user action and literally breaks the website audio if you accidentally set it up when that permission isn't granted yet, and then disables all of those protections whenever you navigate pages within a domain. It's ridiculous; what should have happened is that by default, tabs in Chrome should just be muted globally, and audio code should just continue to work normally so that a massive number of web games don't just immediately break, and the user can untick the mute button and turn on sound for the very, very few websites where most users want sound.
I'm bitter that they made all these justifications about how blocking the audio was important because it would save mobile data, and actually what happens is all of these sites just mute the audio by default, stream the video on mobile data anyway, and then unmute the video as soon as the user clicks anywhere. It's a bunch of bad justifications for a UX that makes it easier for websites to abuse users. We could have had more user-friendly behavior and not broken the entire web, but Chrome wanted to try out some weird statistical model for blocking/allowing audio playback instead of adding a button.
The "spamming requests for things the user doesn't care about" problem is a lot easier to deal with if you invert "permissions" into something the user requests and not the site.
One of the things that excites me about Apple's approach here in particular is that it's very easy for people to understand: Users intuitively know they can install apps to do things on their device, and uninstalling the app will make those things go away/not happen. While still using web app technology, it embraces a much more classically understood concept. I hope the other browser companies follow suit.
The site permissions model feels more empowering and narrow-scoped to power users, but it's absolutely baffling to everyone else. Install and uninstalling is simple.
And similarly, it's great to tie that to the app list -- it means if you want to get rid of those permissions, you now have a really easily viewable list of every site that's sending you notifications (I'm assuming that iOS revokes push notifications if an app is unpinned from the homescreen).
There are ways in browser to get lists of every site that can send you notifications, but nobody outside of tech circles will ever find them. In contrast, this is reusing the same UI that you'd use for any other cleanup action. Everything that can send notifications is in the same place. That's something I can explain to a non-technical user.
I made a demo showing how easy this was to circumvent in 2018 and it works just as well today in both Chrome and Firefox as it did in 2018, nothing has improved since then: https://danshumway.com/blog/chrome-autoplay/demo/ (link has autoplaying audio).
Chrome introduced a solution where in practice, videos still all autoplay (the demo doesn't show this, but if you start a video muted you're still allowed to autoplay it), and then 15 seconds into browsing the page you still get hit with a blast of music. And in the process of doing that, they also broke a substantial number of web games.
And, also, the restrictions don't apply if you're browsing within a domain, so if you click on a CNET article and then click a link to another CNET article, now the second article has permission to play even without a user gesture. "In response to a user gesture" is such a weak protection. Highlighting text counts as a user gesture.
My preference would have been for Chrome to just auto-mute that tab as soon as audio started playing, and allow the user to unmute it themselves not as a gesture that "implies" consent, but by explicitly clicking the unmute button.
I don't think the current solution solves anything at all, I think it's worse then what we started with. Particularly on mobile, it's extremely easy to accidentally tap on a website. In my opinion, it's effective the same thing as just allowing autoplaying audio, I feel like they might as well have changed nothing.
Edit: I've got a longer article I wrote in 2018 that goes into more problems, but a lot of them are orthogonal to the current conversation and are mostly focused on the impact to web games and criticizing Google's communication with developers, so I tend to just directly link to the demo when talking about it nowadays (https://danshumway.com/blog/chrome-autoplay/)
> mute the audio by default, stream the video on mobile data anyway, and then unmute the video as soon as the user clicks anywhere
sounds like exactly like how Instagram app works.
To be more specific about why the Chromium model is so messed up, it's based on the idea that you should only be able to start audio playback in response to a user action.
But what counts as a user action is:
- highlighting any text on the page
- clicking anywhere on the page
- pressing any key on the keyboard
- basically anything you do on a web page.
And then the web page can play any audio it wants for the entire duration of the page visit. So in practice, blocking autoplay only makes things more inconvenient to devs and breaks a bunch of websites. It doesn't help the user at all.
Firefox's implementation is slightly better because it's more predictable (Firefox doesn't have Chrome's weird algorithms about playback), but it's still mostly broken. I wrote a giant article about this back in 2018, and 5 years later the demo that I made works just as well today as it worked back then: https://danshumway.com/blog/chrome-autoplay/demo/ (link has autoplaying music)
Nothing ever got fixed, and autoplaying audio is still a problem.
I would argue (and have argued before), if placed behind a well-understood consent concept like "installing" the PWA, it would be safer to implement these sorts of APIs.