Hacker News Reader

Comment by msoad | Hacker News Reader

An important detail that you might miss without reading the article is that these capabilities are not available to any website a user visits. The user must add the website to the their Home Screen before the website can ask for notifications permissions.

As an iOS user I actually like this restriction. Can't imagine what the browsing experience would've looked like if any website could take their chance on sending me notifications

View on HN

Good. Web push is such a mess. The amount of people with Android phones like my grandma that accepted push notifications on some spam site, either by accident or because users are so conditioned to just click "ok" to make popups go away, it's absurd.

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.

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.

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).

When I click that link it doesn't autoplay. I need to click something on that page for it to work!

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/)

What you describe around audio

> 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.

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.

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.

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.

FYI, you can disable the ability for Chromium-based browsers to even ask the user if they want to allow notifications - on my Android phone in Chrome, it's under Settings, Site settings. There you can set "Notifications" to "Blocked" (and if you're paranoid like me, turn most others off as well).

You can do this in Firefox as well.

However, nagging the shit out of users should not be the default behavior. They knew that this feature would get abused by every sleazy webmaster on the planet as soon as it was supported in popular browsers. The feature should have been properly designed in the first place. Now I'm content with letting it die.

I appreciate Apple's willingness to more or less ignore open standards that hurt the user experience more than they benefit it.

I doubt his grandma would find this option.

Absolutely fair, but that's why I set that on all browsers I configure for family, and recently had to walk my sister through on her phone when she accidentally allowed notifications from some website that started spamming her with various scam attempts.

I don’t know if they’ll accept this solution. The other camp just want: “It works automatically like magic”. I just want to point out that we have to be familiar with the tools we used.

I wonder, does setting this stop one from getting or subscribing to notifications on sites where they're wanted?

As I understand it (I never want notifications so don't have any experience with it), it's only blocking new sites from asking to send notifications. So if you find a site you want notifications from, you can change that back to "Ask" temporarily, allow for that site, and then change back to "Block" for all sites by default.

Note that that behavior might be different on mobile vs. desktop browsers, but again, I don't really know how to test, sorry.

Are all the notifications from native apps fine? Or just the web notifications that are bad?

Good question. I think the main difference is that it is so much easier to visit an annoying website then to download an annoying app. And your GP mentions how a good compromise is to grant this access only to websites you install to your home screen (which I think is a comparable action to downloading an app).

I regularly get spam notifications from major/famous iOS apps. It's always an instant uninstall for me.

IIRC this used to be against Apple App Store rules but I guess they got relaxed for spamming existing customers.

Fastest way to lose me as a customer, TBH, is to disrespect my fiercely-guarded attention span with prompts to spend money while I'm busy being focused on making it.

> IIRC this used to be against Apple App Store rules

It was.

> but I guess they got relaxed for spamming existing customers.

Apple themselves have sent notifications of that kind. The rule has since been dropped, I doubt it was ever enforced.

Last I checked, the push notifications that are masquerading as native popup asking user to install “antivirus” are all on web.

Can’t she revoke it from the notification screen when she sees a spammy one ?

Sure it’s still better to never subscribe to unwanted notifications, but removing them isn’t much of a hassle in the current system IMO

My parents are in the same boat. Revoking it assumes the user even has a mental model of what a notification is. That is: Something that you can opt out of or even necessarily that they gave permission in the first place. I suppose it's viewed a bit like receiving junk mail or advertisements on TV. That might seem absurd on the face of it like of course it's your device but not everyone is necessarily aware that they even have any agency (or are interested in learning yet more "computer nonsense")

I'm being a bit over the top here but I consider it much the same problem as how you might use a car without understanding any of how it works. In the same way, plenty of people own mobile phones without any understanding of cause and effect.

I'm pretty sure my parents don't even "see" permission prompts, they just sort of have this "thing" in the way of the "screen" and tap at it to go away rather than y'know, some sort of two way consent dialogue.

> My parents are in the same boat. Revoking it assumes the user even has a mental model of what a notification is. That is: Something that you can opt out of or even necessarily that they gave permission in the first place.

My feeling is that if a user doesn't know how to disable a permission, then they were not giving informed consent about enabling the permission. Being able to turn on a permission is an imperfect but ultimately better indicator that they likely know what the permission is (it's not completely bullet-proof, but it's better).

Clicking "yes" just means that they clicked "yes", it doesn't mean anything more than that.

I might be misremembering, but I think android (at least Pixels) have a prompt to ask if you want to get rid of an app's notification if it pops up too often, and/or show you the current settings for the notification for review.

I wonder if a similar approach could be used: just as users might half blindly push "OK" on a request for notification permission, it could be counter balanced by a check on new notifications in the kind of "Do you want to stop this app from sending you more of these messages ? you can always change your mind in the XXXXX screen <link to said screen>"

To be honest, I don't wish for more people to have to comb their notifications screens and have a deep understanding of what's happening. I'd prefer the OS to better surface to the user they just need to push a button to get rid of the crap.

Nobody who doesn't work in the industry knows how to do this. Browser site permissions are basically the absolutely most incomprehensible UI ever to ordinary users. It's why implementing these features without an app install is user hostile.

It's a good restriction although I wish Apple helped a bit with the installation of web apps to the home screen.

Not install prompt banners like in Android* but right now you have to use the Share screen. It almost feels like Apple is hiding that functionality so that users don't find it. Installing and sharing are two very different actions.

* I'm an android user and I agree these are bad.

For people who haven't used iOS, the Share screen is the ios junk draw where every option they couldn't find a better place to put something goes. Things like Find on page are located there too.

FYI you can just type in the address bar and a “find in page” option appears in the autocomplete list if that text is on the page, no need to use the share screen

The worst part of this is it’s the last item in the autocomplete list, and will often be under the keyboard, off screen until we scroll to it. It also hides the current page behind the list of course.

All in all, text selection and search is still such a second class experience on iOS.

This is even more hidden than the one in the share screen

More hidden maybe, but definitely more logical.

More logical to use a textbox typically reserved for navigating away from the current page, to instead search that page?

Thanks, was going to answer the same: nor the "address" text field nor the "share" button indicate actions to be performed inside the page; the logical idea is that first one is to go to another site, the second one is to transfer the current page to another app/person

I have to admit I don't see where to put the "search inside the page" feature, definitely some ux trick to be found

I disagree, the “share screen” is the logical place for actions that operate on the object you’re currently looking at. Adding a new banner or something for installing PWAs would just clutter up the UI and make it less consistent.

I don't think it's strictly bad to have a junk draw menu, but calling it a share menu doesn't really describe what it is.

Its official name is not the share menu, if that helps.

DRAWER, it's a drawer.

Somewhat off-topic but as someone who used to be a very heavy iPad user (the M1 Mac has kind of obsoleted it), I think of the share sheet as the equivalent of a Unix pipe. It takes your current view or output and makes it available to another process - and if you use Shortcuts, you can actually see the data and its transformations along a literal pipeline.

So, back on-topic, it does kind of make sense in that you’re taking the current URL and sending it to the Springboard.

A perfect menu already exists for this. If you click the “Aa <puzzle piece” button, a bunch of website-specific settings pop up. “Search on Page” or “Install on Homescreen” would fit in perfectly here. Maybe under “Translate Page”.

This is close, but it’s not ideal: the drawer is an OS-wide feature, that puzzle menu is a relic of when the drawer didn’t exist. And its symbol suggests that it’s about text options.

You’re not wrong, however they’ve actually been cutting down on that lately — moving the items which aren’t really “sharing” in any sense to a kebab / ellipsis.

The best example is Photos, where the Share Sheet would have a LOT of unrelated junk — Duplicate, Hide, Slideshow… But as of one or two major versions ago, there’s now an ellipsis menu to keep those options instead. Notes got the same treatment.

In current Safari, the “aA” menu is an equivalent of that. In my opinion, “Find on page” is really the only option on that Share Sheet which doesn’t really belong. All the others make sense, as they’re an “Export” of the page in some way or another.

It’s more like what would be the context menu in a traditional desktop GUI.

"Share sheet" is a bit historical in my opinion, and has been for some time. In practice it serves as more of an OS-level context menu that happens to put the "send to frequent contacts" and "open in another app" options first.

In theory Safari's tab context menu would be a better fit, but given it iconifies as a "change text size" tool, I don't know if that would really address your concern at all.

I’ve long been hoping for something like the Smart App Banners[0] that native app developers can use to link to their app in the App Store.

It’s relatively unobtrusive and easy for users to dismiss.

[0] https://developer.apple.com/documentation/webkit/promoting_a...

yes! Smart App Banners are really great and I just wished they would be available for PWAs

Now if only they'd create a separate folder for web apps in the App Library to put them in instead of requiring that they be on the Home Screen.

And reinstall it like native apps on factory reset or transfer like native apps to a new device.

You can get close: put them in a folder on your Home Screen.

Disadvantages:

- cannot hide that folder in the App Library

- limited number of shortcuts per folder

I don't think there is a limit to how many apps icons can be in an iOS folder, they're paginated. Right now, I have 27 in an "Apple" folder, spread over 3 pages. If I add another icon, it adds another page.

> Now if only they'd create a separate folder for web apps in the App Library to put them in instead of requiring that they be on the Home Screen.

Could be a feature of iOS 17, which will be available to developers at WWDC in June.

It could, but I won't hold my breath. I've fallen into the trap of being optimistic that some annoyance will be fixed or some obvious improvement will be implemented in iOS <next_version> multiple times and ending up disappointed. I'm even less hopeful of anything that would improve PWAs, whether in terms of API support or user experience, due to Apple's incentive to keep them second-class.

Yes, like it is every year. Shovelware blog tier speculation.

Oh thank god. I was worried it'd let sites ask without the user first taking some action to permit it. Sites being able to pop "allow notifications?" without the user first indicating they might want that, on desktop, is a menace.

My mother has an Android phone, and she’s not really tech savvy. Her notifications are absolutely bombarded with garbage from various websites, and her lock screen displays ads. I’m moving her to iOS, as I’m quite sick of constantly being the IT guy.

Oh I can relate to this. Bought my mum an android phone when my daughter was born so I could share photos and do video calls.

It was such a hassle doing support over the phone (She lives in NZ and I was in Singapore, and now Taiwan)

Bought her an iPhone 12. Apple support helped her set it up over the phone. 2 years and I haven’t played IT guy once!

Yeah absolutely this has to be a limitation.

I do not want to have to go chasing “where did this annoying notification come from” game… ever.

Desktop browsers don't have this limitation and I never have to play that game. It's just a stetting where you can choose to allow websites to ask for notification permission, or block it from every website.

Part of the problem for desktop browsers (except for power users) is that they've never opened the settings option, not once. They might have opened Mac's system preferences or Windows Settings app but other than that they have no idea they can toggle a plethora of options for their browser.

Exactly, which is why things like this used to happen: https://i.stack.imgur.com/82hWm.jpg

For you and me no problems.

Other people I think it is an issue.

Check in with the average user of desktop browsers. You may find a lot of them have accidentally accepted web pushes and have no idea how to make them go away.

I'd be shocked if the vast majority of "use" of the "feature" weren't exactly that kind of spammy, unwanted messaging.

It’s certainly the majority of times I’ve been prompted to enable it for a website.

I dislike the desktop implementation of push permission request in macOS Safari

It presents a modal popup asking for permission. A few times I have accidentally clicked "Allow" only to have to hunt through my notification settings for the offending website to remove it

Web sites should not be allowed to present modal, native UI that can interrupt the browser. They should be contained to their window

A better implementation would be to allow the browser to show a bell or other icon in the main UI indicating the website offers push notifications. Clicking on that would inform and allow the user to opt-in

My desktop browsers get denied permission to show notifications at the OS level and are set to block them for all sites without asking.

I can't think of a single valid use case for them. There are only a handful of desktop apps (literally 4 or 5 apps like MeetingBar) that I allow to use notifications on desktop. For essential messaging app, etc. that I need notifications on, I configure them to be only on my phone, which I can just turn over if I don't want to see them.

This new iOS functionality therefore fits perfectly with how I use notifications: if I install the website like a mobile app, it can maybe get notifications, otherwise websites can't bother me even with requests to show them.

it’s constantly abused by spam trying to masquerade as the browser because the prompt extends below the line of death

Ya. It's safe to assume if someone is opting to add a website to their homescreen they are interested in it; notifications may make sense. Random websites asking me to enable desktop notifications are annoying. This prevents that for mobile.

Very sensible limitation, otherwise we would just have another dialog to deny or accept on every website.

I agree. None of this stuff should even be requested before the user makes it clear they are actually interested.

I like that I didn't have to permanently disable push notifications in Safari to stop those awful popups asking if I wanted them. Apple knows that people will say "no" 99.9% of the time. It makes more sense to make the user jump through hoops the one time they actually want it than to incessantly nag them every single time they make the mistake of visiting a new web page.

I guess websites will start asking users to add them "to the home screen", so they can later start asking permissions for push notifications...

But this is a different kind of problem and no reason to slow down the Push API standard.

I'm very happy that they also finally implemented things like Screen Wake Lock API so developers will no longer be forced to do silly things like play a fake video loop in the background to keep the app in focus.

Looks like Apple is finally going to give PWAs some love and it's a good thing overall.

It's actually pretty difficult to do something like that since an install is done through the OS and the app can't set off the process. I think it's too clumsy for most sites to try it.

Chrome does let you do it though.

I'd have expected no less, since Chrome already protects the notification noise by default, too. You have to opt in to notifications. Sounds like a slightly different implementation for iOS, which is interesting in that they're assuming any app you add to Home Screen means your opting in to the notifications, or is there another opt-in? I see myself putting a few apps on my home screen that I want to click on often, but maybe not wanting the notifications to go with it?

A web app that has been added to the Home Screen can request permission to receive push notifications as long as that request is in response to direct user interaction -- such as tapping on a ‘subscribe’ button provided by the web app. iOS or iPadOS will prompt the user to give the web app permission to send notifications. The user can then manage those permissions per web app in Notifications Settings -- just like any other app on iPhone and iPad.

> Chrome already protects the notification noise by default

Does it though? I still get asked to opt-in for notifications on websites regularly, including those I've already said no to. A simple opt-in question still makes me answer the question routinely (with the default "Sites can ask to send notifications" setting).

This puts a much higher bar on the notification opt-in game.

I get asked, but once I say no, I haven't gotten prompted again.

And if you accidentally click yes, it even has a section in the 'safety check' section that will have a list of sites sending you too many notifications.

Also, there's another setting where you can toggle between: ask permission, block all; and some other silent blocking them....

I wonder if it remembers my settings better because I have a google account that my chrome is logged into for syncing these things?

I believe adding a site to your home screen isn't opting in to notifications, but opting in to allowing the site to request notifications, which would then require another opt-in.

Does this affect Firefox on iOS too? Just yesterday I tried to add a website to my home screen but couldn't find the button.

The web has a standard we push API.

This seems very unintuitive though. Why not just add a button somewhere that says "enable notifications"? Apple loves these super unintuitive approaches. Blows my mind that anyone actually believes the marketing that they're "easier to use" than any other platform.

I think that’s this is because the “add to Home Screen” workflow is how you install PWAs on iOS and they want to restrict these APIs to PWAs.

Reply on news.ycombinator.com