The request mechanism is so broken. There shouldn't be a pop-up at all. The website should declare a notification source and you should be able to subscribe to it if you feel like it. Somewhere in the overflow menu. The website shouldn't even get the option to natively bother you about it.
I mean then they’d just have pop ups that told you how to turn on notifications and make it seem like you have to to continue… wouldn’t be as successful but it would still suck.
It would at least be harder. It's a lot easier to sell "click ok to make the pop-up go away" than "go into the overflow menu, then click 'subscribe to notifications'".
Since users tend to choose the path with the lowest friction, they'll probably prefer to find a way to close a pop-up. The instructions also make it very clear what the user would sign up for.
Bonus: Don't even let the web app know whether the user has subscribed to make it impossible to force.
That's the right way to do it, but then the Chromium team that implemented it doesn't get good numbers to use for their promo packets.
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.
It's not just Web Push, most permissions should be user-prompted, not site-prompted.
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.
I kind of dislike the app/website distinction that people make sometimes, but even I feel like this is a pretty decent line between the two: "a thing I 'install' means that I want it to have more capabilities than something that I want to be transient." I agree, it's good UX.
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.
And yet they allow auto play. I wish they hid that behind a permission. It's god-aweful. Looking at you Ars Technica. Go burn someone else's mobile data.
It's wild to me that we all recognized autoplay was a problem, Google broke a bunch of websites, there was a big stink around it, and so 5 years later... we still haven't solved autoplay. Nothing has changed, we just stopped talking about it.
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).
Right, that's the point. How often do you browse a web page and never click on anything or highlight any text? If you're interacting with a SPA like Twitter or Facebook, it's impossible for you not to have a user action by the time you run into a video. It's fairly common for web articles to put everything except the first two paragraphs behind a "click to expand" button. What that does is force you to invisibly give them permission to autoplay 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/)
It's become really common on websites, and it's one of the primary reasons why I block JS by default on my phone. I assume a lot of mobile apps work the same way, but I haven't checked. I don't think you could pay me to install Instagram on my phone.
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.
Eh, in most cases it is just Chrome. WebUSB, Web Serial, a dozen others, Chrome has implemented despite both Mozilla and Apple saying they won't because the risk of malicious use is too high.
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.
