3 ms·

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 understan

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.

account42 4y ago
If it was just Chrome that made these user-hostile decisions then I wouln't care that much, but for some reason Mozilla decides to copy most of them.
- ocdtrekkie 4y ago
  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.
danShumway 4y ago
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.
- ocdtrekkie 4y ago
  Indeed, I agree with everything you said here. 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.
  - danShumway 4y ago
    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.
- WirelessGigabit 4y ago
  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.
  - danShumway 4y ago
    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/ https://danshumway.com/blog/chrome-autoplay/demo/ (link has autoplaying audio).

account42 4y ago

If it was just Chrome that made these user-hostile decisions then I wouln't care that much, but for some reason Mozilla decides to copy most of them.

ocdtrekkie 4y ago
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.

danShumway 4y ago

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.

ocdtrekkie 4y ago
Indeed, I agree with everything you said here. 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.
- danShumway 4y ago
  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.
WirelessGigabit 4y ago
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.
- danShumway 4y ago
  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/ https://danshumway.com/blog/chrome-autoplay/demo/ (link has autoplaying audio).