I have not found a good use case for browser notifications, to the point that I have turned them off completely due to endless prompts for permission from every website to push them.
Apple's approach of only allowing sites that you've pulled out onto your home screen to request them is actually not bad for balancing this. It means I'm not being constantly nagged while browsing normally, but when I decide I want to treat something "like an app" it gets access to richer features.
(I very rarely do this. I think the only thing I have pulled out like that currently is Puzzmo, which doesn't even do notifications.)
It's a decent way to handle permission but it's never "like an app" with iOS. Web push is missing basic features on iOS, such as notification sound/vibration. Many will say that's a good thing but there is no restriction for actual apps. I would love to rewrite a React Native app I work on as a PWA but silent notifications are totally useless for it.
My company has a product that allows you to chat with tech support. The end user (our customer's customer), is just someone who went to one of our customers' help portals and requested help via chat.
These chats are going to last < 1 hour typically. There are times when the custom support agent needs to confer with someone else, and then will respond back. The end user, in that case, does not want to sit there with their phone open for 15 minutes, waiting for a response.
While we have an app those end users could download and get notifications on, no one wants to do that for a one off session (not even an App Clip).
Trying to get iOS users to add it to their home screen, is basically a no-go too.
So, it would be really nice if we had a way to send push notifications, even if it was time limited (allow notifications for the next 1 hour).
Don't get me wrong, Push Notification can and are abused. But there are valid use cases.
There are some legitimate use cases for them, but generally I think web push permissions are best defaulted to “no” so sites can’t harass users with fake, “we need to maintain the ability to harass the users again” in app prompts.
Every request for notification permission is best defaulted to No. It shocks me how eager people are to opt-into getting spam and other junk alerting on their phone.
Among less technologically literate acquaintances, getting a gazillion browser notifications on startup seems to be the modern equivalent of accidentally installing tons of useless toolbars.
This is interesting for two reasons, firstly because the reason Chrome on Android has such terrible push notification latency is claimed to be the need to run the service worker in the context of the Chrome application, which being huge would use a load of battery so they avoid running it if at all possible.
Secondly, unfortunately the problem with iOS Safari notifications is once you get them working they cannot do things like group properly or replace each other. It just becomes a horrifying flood until you clear them all. If they have made iOS respect the tag and action fields, which are conspicuous by absence from their examples, then it will be game on.
I hope this is a sign that this is finally going to be working one day.
> Secondly, unfortunately the problem with iOS Safari notifications is once you get them working they cannot do things like group properly or replace each other
Can you elaborate? I runa PWA on my iPhone and once the PWA is installed ("added to home screen") you can manage the notification display (grouping, lockscreen, temporary/persistent) just as with any other app installed via the iPhone Settings -> Notifications.
Replacing previous notifications is not possible in the web-push standard at all, so it is not apple to blame.
"The idea of notification tags is that more than one notification can share the same tag, linking them together. One notification can then be programmatically replaced with another to avoid the users' screen being filled up with a huge number of similar notifications."
Apple are the only ones not supporting this, and much of the time with web stuff they have a point, but this one just seems obtuse.
You are right, wasn't aware of it. Looks like Chrome didn't implement this either. I'm not an android user, but to be fair, there is no way Notifications can be grouped like this on iOS with native apps.
"Declarative Web Push" is a web browser javascript API to subscribe to events from an HTTP server. It is similar to the "Web Push" API but changed to be better for mobile devices in a few ways.
Both the old Web Push and this new Declarative Web Push APIs use "the same Apple Push Notification service that powers native push on all Apple devices". I don't know if that means an Apple server actually listens for the notification from the HTTP server or if the device itself maintains the connection to the server.
It seems that for iOS this API only works on websites that are pinned to the home screen (i.e. not a notification from a site open in safari as a browser). These pinned websites work more like apps.
Is there something similar like this on Android? Either for pinned apps or from the browser? In other words, is there a reliable and efficient way to get notifications to an android phone without having to sign up for any service?
> I don't know if that means an Apple server actually listens for the notification from the HTTP server or if the device itself maintains the connection to the server.
In the case of Apple's ecosystem, the device maintains a connection to the Apple Push Notification service (APNs). The website POSTs notifications to APNs, which forwards them on to the user's device. The user's device then wakes up a local Service Worker for that website in order to process the incoming payload and display a notification.
Declarative Web Push makes the very last step unnecessary.
> Is there something similar like this on Android?
It works out of the box on Android (without adding to the homescreen or installing as PWA). For iOS, you need to tap the "share" button in safari, scroll down, and "Add to homescreen".
If you want to test this out (on either platform), you can try my PWA where I implemented this (https://lockmeout.online). In the users settings, you can even add several devices (browser, phones etc.) and send a test notifications to either a single or all devices. Installation instructions for iOS and Android are there (since it is a PWA, you just need to press the right buttons in the browser, there is not actual installation). PWAs can also be installed on Desktop (Chrome and Safari).
Btw. the PushNotification API is not device/vendor specific. I use the same code to send out notifications for mobile (iOS, Chrome Android) and Desktop (safari, firefox, chrome etc.). I also do not use any third party for sending, but do it from my server. And hell yeah, not having to create these clumsy serviceworkers will simplify my code a lot.
From an engineering and architecture perspective, I'm seriously disappointed at web notifications. They get abused by malicious or spammy threat actors a lot. The abuse potential was obvious from the start. Why are such technologies still possible, even after we've learned lessons from email and other legacy tech over the past several decades?
For example, why can sites spam users with repeated push notification requests? why is there no active trust assessment and allow/block list maintained by browsers and OS vendors (yeah, they're a plague on win10/11 too)? It even makes sense to require an EV TLS cert for any push notification service. There are many ways to tackle this, but the naive way of just letting anyone set up a random site and start spamming people is so 90's/2010's. At least as a default, it should be very hard to be able to ask users to permit your push notification service.
I think part of the problem is that push notifications became a thing on mobile platforms, where apps are vetted by app stores. But random website don't undergo any vetting before they can start pushing notifications to browsers. Another issue is that people who are part of these design decisions are too far removed from regular people who don't even know what a push notification is, they just accept random prompts and get increasingly miserable over all the popups over time. It is also very easy to allow a push notification, but the UI/UX is difficult to audit/disable these. Perhaps having some button or option in the notification box to disable similar notifications would go a long way?
In a way, the web industry re-introduced the annoying pop-up windows of the early internet.
>Why are such technologies still possible, even after we've learned lessons from email and other legacy tech over the past several decades?
The alternative seems far more disappointing from an engineering and architecture perspective to me - not bothering to implement any features because of fears that they may be abused.
I'm doubly disappointed because of your comment because that is not the alternative. You implement the technology with user experience as #1 priority and build layers upon layers of defenses against abuse and with trust establishment as its foundation.
> Web Push on Apple’s platforms uses the same Apple Push Notification service that powers native push on all Apple devices. You do not need to be a member of the Apple Developer Program to use it.
This has... interesting implications for natives apps, at least at first glance.
Also, it's not clear to me how you send to a website using this. Has Apple wildly overhauled APNS server-side since I implemented a sender-client for it years and years ago? That design was excellent, but you did need a push key tied to an app to even connect to the socket IIRC. Do they issue those for websites, now? Does it work totally differently? How does validation work?
The way web sites register for push is very different to the way Apple requires for APNS. They're using the same service to send the pushes but the client-side interface is totally different.
> This has... interesting implications for natives apps, at least at first glance.
Note: The fact that Web Push for Apple's browsers uses APNS and doesn't require any sort of developer account is not new to Declarative Web Push.
It's how it's always been since Web Push first shipped in Safari 13 on macOS - https://developer.apple.com/documentation/usernotifications/...
I don't get it, they pretend they made this new proposal because of security and battery life. And then we have dozens of native apps installed that push tons of useless notifications for upselling shit and clutter the screen... I had to disable all of them. So i don't understand why they fear web push so much
I always disable push notifications for the very first push notification I receive that is an advertisement regardless of service. And what's crazy is, basically everyone does it now. Amazon does it, even, and I don't think there's an obvious way to just disable ads. Fine, fuck you, I'll just use e-mail, then.
iOS and macOS native app notifications already work the way Declarative Web Push does, not like classic Web Push. This is giving web apps the same ability to be battery friendly and more reliable that native apps already have.
again battery friendly how? because you install them first? please... as I said native apps still abuse notification system(and battery) pushing ads. Apple just hate the web platform, and them trying to push alternative solutions is just PR for how little they care about PWAs and their progression
Battery friendly because notifications can be coalesced by the OS and processed without having to fire up a full browser engine process and JS VM just to unpack the notification and post a visible notification.
Even in the case where the app needs local processing to show the best notification, having this as fallback removes the risk that the app misses the deadline to display a visible notification and therefore loses its push subscription (which is a behavior Chrome and Firefox have too).
We're also not removing classic Web Push, so web apps can deny themselves the benefits of Declarative Web Push if they don't like it.
The blog post documents a relatively long engagement process with the web standards process. Starting with publishing an explainer (pretty common for the browser engines), directly talking with the other browser engines and web developers at the W3C TPAC conference, making concrete proposals to the relevant web standards githubs, taking feedback, etc.
Can you elaborate on the carelessness here? What should've been more careful?
It's standards track and we've had positive signals from Mozilla and Google. Apple is just the first to ship in this case. Are you also mad when Apple is _not_ the first to ship a feature? Is there any way to win?
Declarative Web Push seems like a beneficial addition, simplifying push notification integration. The declarative approach aligns well with modern web development. However, I'm curious about the performance implications compared to the existing API and how much flexibility developers might lose with this higher-level abstraction.
It reduces notification display latency because they can be displayed directly by the system services managing push, without having to wait for an opportune time to fire up a service worker process. It does still allow customizing the notification with code, but even in that case, having the declarative notification as a fallback improves reliability.
I've commented this before, but does this grant an exemption from the automatic purging that ITP does? the wording makes it seem like it does but that just makes their justification for ITP all the more baffling
Since there is no service worker required, if ITP removes the service worker, declarative web push continues to work.
I believe this is explicitly called out.
iOS Safari only allows push notifications for web apps added to the Home Screen, (as PWAs sometimes do), and that hasn't changed with the new Declarative Web Push. Most developers aren't familiar with this, and neither are users, and so it's very, very hard to educate users on how to allow you to push notifications.
Here's how it works.
First, users have to figure out how to add your web app to the home screen. There's no "Install" button that you can put in your web UI; users just have to know how. You can, of course, explain how, in your web page, but it's quite tricky. I'll explain it below; it takes like eight or nine steps.
First, the user has to click the Share button, the box with an arrow on it under the URL bar. On iPad, it's in the URL bar. It doesn't have the word "Share" on it, so if you use the word "Share" to describe it, users will get confused.
Also, the Share button may not be visible on the screen if the user has scrolled at all, because Safari collapses Safari's bar by default, but you can bring it back by scrolling back up to the top of the screen, or asking users to set up push notifications on a special page of your site that's too short to scroll.
Once they've clicked that, they need to find the "Add to Home Screen" button. On iPhone, "Add to Home Screen" is not visible by default either. The Share sheet is only half the height of the screen, and you have to scroll it to reveal more sharing options. One of the sharing options is "Add to Home Screen."
Once they've clicked that, they have the option to rename your app to whatever they want. You can control the default, but you can't prevent them from giving it a cute nickname, which they may forget later. Then, they can click the Add button.
When they click it, the sheet disappears. As far as the user can see, nothing useful has happened. But something has happened. There's a new app icon on their home screen. Not their first home screen, of course… it's probably their last home screen or something. There's no way for users to know which screen it's on. Or, they can search their iPhone for your app, if they can remember what it's called.
Anyway, once your web app has been added to the home screen, you have to tell your users to re-launch your app from that home-screen app launcher. It boots up slowly, slower than Safari, because it's running a whole separate process from Safari. (Also, JS in general just runs slower in home-screen web apps; only Safari is allowed to do JIT just-in-time compilation of JS.)
Finally, once they launch your app from your home screen, you can request permission to push. They have to click a button in your web UI (any click is fine), and then you can pop-up an iOS push permission request. If the user says no, you've missed your only chance; users have to go find your app in iOS Settings to turn on push.
Once users agree to push notifications in your home-screen web app, finally, finally, you can now send push notifications.
Last time I checked, push messages did not work when the web app was not running, has that changed? Because I think that is the most interesting feature for users: To notify about important things while not using the app. It has also always been abused by app creators with useless stuff to drive engagement etc.
I think I never allowed a single webpage to send me notifications - if for example I want to know about the latest news about plant pottery, I will probably just visit that website again...no need to notify me.
Push notifications work anytime, even when your phone is locked and in your pocket. On iOS you need to add the website "to your home screen", which then it becomes like an App (it is a progressive web app, PWA). For Chrome and Safari on Desktop it is the same (you even get notifications when your laptop is locked on macOS, provided you configured that in your settings of macOS).
Source: I run a PWA that enables web push (without any 3rd party push services) and have tested it many times on many platforms, and my users use them too.
I just want to say I appreciate your rant. Maybe this declarative web push API signals they are spending some developer time improving the "Add to Home Screen" experience overall.
I hope the whole industry pushes to prefer websites-as-apps. So many services have both native apps and websites and one or the other is broken or limited for no good reason other than it's hard to develop two things instead of one.
I even worked at Apple back in the day but it took me until seeing this post to realize WebKit also follows the same framework naming scheme that Apple always follows with AppKit, WatchKit, UIKit, HealthKit, GameKit, ARKit.
For some reason I didn't put WebKit into the same bucket.
Apple only allows it when you add the website to your home screen (a.k.a Install progressive web app). A user only does this when they are actually interested in the site. Once added to the home screen, it is like any other app, and you can manage the notifications from that app via iOS Settings.
Wait, this may be a huge game changer. But only if websites no longer have to ask the user to install the app on the home screen (arcane) and then launch it, and enable notifications.
I know that’s a popular sentiment here, but I honestly don’t think they give a shit.
This is 100% understandable to me as something to prevent random unknown websites from sending push notifications users don’t expect or know how to control from a site they accidentally visited weeks ago.
Accidentally visiting a website doesn’t give it permission to send notifications.
Seriously, it is not that difficult to let users choose whether to receive notifications, how often, and manage them later. Apple just had negative incentive to do that on the Web!
Guess what, people do that all the time. They get tricked into it. They just press a button really fast to get it to go away. They don’t remember doing it but then later that day or a week from then or whenever they might start getting notifications.
And of course they’re incentivized to get you to go back to their website with any notification they want to show. That way they can get more views, or try to run a scam on you if it was a scam website.
We already have ways of doing notifications from arbitrary third parties. It’s called email. Or you can make an app. Or you can get someone to add your site to their home screen. All are extremely clear measures of consent.
At work I’m not allowed to run an ad blocker. I get stupid little pop-ups asking me if I want to enable notifications on websites all the time. As far as I’m concerned it’s all spam.
I LIKE Apple’s stance. I LIKE they’re preventing me from having to see a stupid little permissions dialogue on every new website I go to asking me if I want to enable notifications.
I'm sure declarative web push is great. But most of this post sounds to me like they are trying to justify artificially restricting web push notification functionality on the web and offer an inferior solution instead. It's pretty clear they (and Google, to a lesser extent) don't want web apps to be on the same level as native apps. Cynically, I believe this is so they can continue to maintain full control of the app market.
There's a lot of statements that are presented as facts, when in fact they are not.
For example:
> Therefore we require push subscriptions to set the userVisibleOnly flag to true. While this can be frustrating, the original Web Push design made this necessary to protect user privacy and battery life.
Surely this wasn't the only option to "protect user privacy and battery life". Native apps can handle push subscriptions without this sort of flag. It's frustrating because it's _meant_ to be frustrating so that users prefer native apps over web apps.
> Allowing websites to remotely wake up a device for silent background work is a privacy violation and expends energy.
This _may_ be true in some cases, but it isn't inherently true. I'm sure there are many use cases for this that are NOT a privacy violation. And running _any_ amount of code "expends energy", so it seems silly to even imply that is a problem.
And again: this is perfectly OK for a native app to do. How is it really any different to allow web apps to do it? Because Apple doesn't get to review every app to their ever-changing standards?
At the end of the day this just further divides the native app from the web app, such that it's impossible for the latter to compete with the former.
> It's pretty clear they (and Google, to a lesser extent) don't want web apps to be on the same level as native apps.
Ironically the reality here is backwards: for a very long time iOS apps could _only_ send declarative push alerts. Only since iOS 10 were you able to use a UNNotificationServiceExtension to customize the content on-device. That extension has very strict resource and CPU limits and is terminated if it violates them. Even when you do have this extension you still need to send a declarative payload in case the on-client code fails, exactly the same as Declarative Web Push requires.
> And running _any_ amount of code "expends energy", so it seems silly to even imply that is a problem.
There's a big difference between running some native code and spinning up an entire JS virtual machine and worker environment to (effectively) modify some JSON. In fact, worker boot up speed is a recognized problem to the extent that there's an entire API to handle situations where a network response would load quicker than a Service Worker might:
Years ago I actually tried spinning up a JSContext in a notification extension out of curiosity and the extension was immediately killed for exceeding resource limits. May well not be the case today but the logic still makes sense to me.
Apple is no saint and has done plenty of negative things for web apps. But in this specific instance they're making the right call, IMO: requiring backup notification content for when client-side code fails is sensible.
Maybe you quoted the wrong the thing? but there's no irony here, and it's definitely not backwards in reality: Apple and Google have both severely limited what PWAs can do such that they are vastly inferior to native apps. It would very difficult to argue otherwise.
> There's a big difference between running some native code and spinning up an entire JS virtual machine and worker environment to (effectively) modify some JSON
Presumably React Native apps do something to that extent? Or, if they don't, whatever optimization they use could certainly be applied "under-the-hood" to PWAs.
> Presumably React Native apps do something to that extent?
Not in the background they don't, no.
> Or, if they don't, whatever optimization they use
They don't have one. There is no optimization they can do to run JS in the background. Push notifications in a React Native app either use native code or rely on declarative payloads sent from the server.
The big difference, as always with web apps, is intent and consent.
Installing an app is a strong signal that the user actually wants/needs it. The level of consent is much higher right out of the gate. With web apps on the other hand, the user can be swept away by a redirect, accidental tap, maliciously captured tap (think a transparent element covering the whole page), etc. There’s a much higher chance that users never intended to end up where they’re at and don’t actually want anything from the app.
Following this train of thought, it stands to reason to have a looser policy with apps. If there’s a way to install web apps with the same level of consent (PWA listings in an App Store for example), standards could be loosened when users come through that route, but for navigating to any random web address things should be more tight.
The user already has to explicitly "install" a PWA on iOS. See
dfabulich's comment in this same thread for how overly complicated and convoluted that process is currently. So there's a pretty good argument that installing a PWA actually require much, much MORE intent than a native app from the app store.
Similarly, the user needs to consent to notifications (among other things) just as they do for native apps.
Mozilla seems to be in favor as well: https://github.com/mozilla/standards-positions/pull/1190 (and funnily enough, a comment on this PR agrees with you in that background work might not be a significant factor in terms of energy consumption, but they still think this is a better design than the original Web Push spec).
Also, interestingly, in the original Web Push spec, they did think that energy consumption was enough of a concern that they implemented a quota system:
> Activating a service worker to deliver a push message can result in increased resource usage, particularly of the battery. Different browsers have different schemes for handling this, there is currently no standard mechanism. Firefox allows a limited number (quota) of push messages to be sent to an application, although Push messages that generate notifications are exempt from this limit. The limit is refreshed each time the site is visited. In Chrome there are no limits.
Anyway, let's put a defensive hat on for a moment, and assume we're dealing with malicious actors (and OF COURSE we're going to be dealing with malicious actors, this is the internet, come on).
> Surely this wasn't the only option to "protect user privacy and battery life".
First off, I notice you are confident that this wasn't the only option (there's never only one option, so the statement as it stands can't be falsified), but you don't actually _provide_ any alternative ideas.
> Native apps can handle push subscriptions without this sort of flag.
Native apps require a push token to send notifications, which can be revoked. If/when a native app abuses the user trust, it's easy to also ban the entire app, or ban the entire developer account in the worst case scenario. Even that often doesn't stop bad actors, but it does give some tools to the defenders to work with.
If I am running an abusive web app, I can spin up two dozen clones before breakfast when a particular domain gets blacklisted, and there is no way to ban me (that I know of).
>> Allowing websites to remotely wake up a device for silent background work is a privacy violation and expends energy.
> This _may_ be true in some cases, but it isn't inherently true. I'm sure there are many use cases for this that are NOT a privacy violation. And running _any_ amount of code "expends energy", so it seems silly to even imply that is a problem.
I'd love to see a heuristic that can be automatically applied to an incoming push notification to determine whether or not it's going to cause a privacy violation or excessive energy use.
In fact, maybe we can use the same heuristic with my geolocation API - after all, while some requests to the API _may_ be malicious, most of them aren't - surely there is no need to add safety guardrails that make malicious requests impossible or at least more difficult - we could just tell the computer to recognize and ignore evil requests, and only allow the good requests, right?
But, maybe you're right, and none of these are concerns to worry about - the main reason is to just make developer's life harder (though in that case, wouldn't the easiest solution be not to bother implementing any of this API at all?)
> Also, interestingly, in the original Web Push spec, they did think that energy consumption was enough of a concern that they implemented a quota system:
I never suggested energy consumption wasn't a concern. I said any code that runs expends energy. So to pretend it's a concern only for PWAs is silly. It's a concern for both web and native apps alike. But (as I understand from other comments) native apps get some sort of quota on iOS, while web apps don't even get that option.
> First off, I notice you are confident that this wasn't the only option (there's never only one option, so the statement as it stands can't be falsified), but you don't actually _provide_ any alternative ideas.
I didn't suggest an alternative because: 1) the post says it was "necessary" implying there was no other option: "the original Web Push design made this necessary to protect user privacy and battery life." But more importantly: 2) they don't go into what those privacy options _are_, exactly. So it's not really possible to address this broadly-defined privacy issue. Maybe it's buried in a Github discussion somewhere, but it's certainly not addressed in this blog post - they just say there's a privacy issue, and that's that.
> Native apps require a push token to send notifications, which can be revoked. If/when a native app abuses the user trust, it's easy to also ban the entire app, or ban the entire developer account in the worst case scenario. Even that often doesn't stop bad actors, but it does give some tools to the defenders to work
This isn't any different for web. Web app push notifications also require a token that can be revoked. The article even says "if an event handler doesn’t show the user visible notification for any reason we revoke its push subscription". So they do this already.
> If I am running an abusive web app, I can spin up two dozen clones before breakfast when a particular domain gets blacklisted, and there is no way to ban me (that I know of).
So associate push notifications with a specific account in some way, similarly to how native apps work.
> I'd love to see a heuristic that can be automatically applied to an incoming push notification to determine whether or not it's going to cause a privacy violation or excessive energy use.
I can't speak to the vague idea of what a "privacy violation" is without understanding what the specific concern is. Is it geolocation? IP address? Fingerprinting? Regardless, iOS already uses a heuristic for native apps, so why can't a similar heuristic be used for web apps?
> In fact, maybe we can use the same heuristic with my geolocation API - after all, while some requests to the API _may_ be malicious, most of them aren't - surely there is no need to add safety guardrails that make malicious requests impossible or at least more difficult - we could just tell the computer to recognize and ignore evil requests, and only allow the good requests, right?
That's quite the straw man, considering Service Workers can't even access the geolocation API. But also, the geolocation API requires explicit user consent. But I'll ask again (and this is really my main beef with all this): why is this totally fine for native apps but not for web apps?
> But, maybe you're right, and none of these are concerns to worry about - the main reason is to just make developer's life harder (though in that case, wouldn't the easiest solution be not to bother implementing any of this API at all?)
I don't think it's "just make developer's life harder". My personal opinion - as I mentioned previous - is that it's because Apple (and Google, to a lesser extent) want to maintain as much control over the mobile app market as possible. All payments go through them. They can shut down any app (ahem, competition) they please for any number of vague reasons. If web apps can be built with the same capabilities as native apps they won't be able to maintain that monopoly.
Thanks for engaging in good faith and for the detailed response (I didn't downvote any of your posts fwiw).
> I never suggested energy consumption wasn't a concern. I said any code that runs expends energy.
I don't think anyone would argue otherwise.
> So to pretend it's a concern only for PWAs is silly. It's a concern for both web and native apps alike.
I think you're ignoring the fact that running it for PWA's requires spinning up the entire browser engine in the background to run the ServiceWorker. That's considerably heavier than the minimal amount of native code required for a native app's notification extension. It's not the same cost/benefit calculation.
> So it's not really possible to address this broadly-defined privacy issue. Maybe it's buried in a Github discussion somewhere, but it's certainly not addressed in this blog post - they just say there's a privacy issue, and that's that.
Ok, but you're handwaving any potential privacy/energy issues away out of hand, and suggesting they are simply a smoke screen, and any and all discussion that I am sure went on over the course of arguments over the W3C spec as a nefarious cover. Again... from that point of view, I don't understand why you think anybody would even bother defining and implementing _any_ of this, if that was the goal?
> I can't speak to the vague idea of what a "privacy violation" is without understanding what the specific concern is. Is it geolocation? IP address? Fingerprinting? Regardless, iOS already uses a heuristic for native apps, so why can't a similar heuristic be used for web apps?
Right, you can't speak to it because it's too vaguely defined - so how can a computer universally and accurately judge the same thing without a precise definition?
And, unless I am mistaken, there IS no automatic heuristic for native apps either. I personally don't think it's even possible to define one, because there's no way to universally judge from the shape and content of a message whether it's benign or not, just like you can't judge from simply seeing an SQL statement like "DELETE x FROM y WHERE z" whether it's a valid request that should be processed, or a malicious one that should be denied - it all depends on a ton of context - and you DON'T have the same context between a web notification and a native notification.
> That's quite the straw man, considering Service Workers can't even access the geolocation API.
Sure, I am exaggerating for illustration. My point is there is no way to just handwave the complexity away with "there should be a magic heuristic that can distinguish good requests from bad requests"
> But also, the geolocation API requires explicit user consent.
Push notifications also prompt for user consent. Watch me pop up a request "Accept my push notifications from spacexlottery.com for a chance to win 1000 DOGE from Elon Musk!" and see how many acceptances I get. And that's the most trivial idea that comes to mind - a real gray or black hat would come up with a dozen more plausible options in 30 seconds, and a dozen ways to exploit access.
> But I'll ask again (and this is really my main beef with all this): why is this totally fine for native apps but not for web apps?
Because if I pull this with a native app, I'll get my app (and maybe my developer account) banned, probably sooner than later (and even so there's still a ton of scam/clone apps on app stores, because the reward is much greater than cost, and real black hats don't care about getting their accounts banned all that much).
If I pull this with a web app, there's nothing to ban... maybe a domain name, but those are infinitely available.
> So associate push notifications with a specific account in some way, similarly to how native apps work.
Sure, and...
1. What account do web developers use for sending notifications to Chrome, Mozilla, Opera, Konqueror, Ladybird users if they want to implement the notifications spec?
2. Is this a free developer account? Then there's no more friction than having no account.
3. Is this a paid developer account? I can just imagine the uproar :)
> My personal opinion - as I mentioned previous - is that it's because Apple (and Google, to a lesser extent) want to maintain as much control over the mobile app market as possible.
Fair enough opinion to hold, for sure. But, you know, companies are made of people, and people who work on things like browsers or new specs like this tend to be idealistic, I would suspect.
It's easy to see the world as a place full of evil bastards (and often enough it is). Even so, I'd say tech / open source / open standards is something that is a great achievement of humanity, which wouldn't exist without people wanting to help each other and fight for a better future. And often times, the people building these things do need to also consider the fact that yes, the internet _is_ also full of evil bastards who will gladly abuse the things they build against every single user.
> Thanks for engaging in good faith and for the detailed response (I didn't downvote any of your posts fwiw).
And you as well!
> I think you're ignoring the fact that running it for PWA's requires spinning up the entire browser engine in the background to run the ServiceWorker. That's considerably heavier than the minimal amount of native code required for a native app's notification extension. It's not the same cost/benefit calculation.
Is it "considerably heavier", though? And to what extent? I keep seeing this argument thrown around, but without any real numbers or data to back it up.
And I'm not sure what is meant exactly by "entire browser engine" (definitions vary), but you certainly don't need to spin up all the resources associated with a full-fledged browser. And much of the resources involved can be shared across many service workers and web apps.
> Ok, but you're handwaving any potential privacy/energy issues away out of hand, and suggesting they are simply a smoke screen, and any and all discussion that I am sure went on over the course of arguments over the W3C spec as a nefarious cover. Again... from that point of view, I don't understand why you think anybody would even bother defining and implementing _any_ of this, if that was the goal?
I don't mean to hand-wave them away at all. Of course these issues exist. But they also exist in native apps. For some reason they can be addressed and mitigated there, but they can't be for web apps?
> Right, you can't speak to it because it's too vaguely defined - so how can a computer universally and accurately judge the same thing without a precise definition?
I'm not saying it _isn't_ defined (or definable) _at all_. Just that this blog post doesn't define it or mention anything about the specific privacy issues.
> And, unless I am mistaken, there IS no automatic heuristic for native apps either.
I was referring to "energy consumption" heuristics, not privacy heuristics. Another commenter (afavour) mentioned that the UNNotificationServiceExtension has "very strict resource and CPU limits" that will kill a background process that exceeds them. That's entirely possible for a web app.
> My point is there is no way to just handwave the complexity away with "there should be a magic heuristic that can distinguish good requests from bad requests"
Again, I'm saying heuristics exists for native apps (as I mentioned above) and they can be applied to web apps as well.
And there's already heuristics in place for some "bad actions", as mentioned in the blog post: "if an event handler doesn’t show the user visible notification for any reason we revoke its push subscription".
They're certainly not all-encompassing, but they can certainly address "energy" concerns and some subset of bad actors.
> Push notifications also prompt for user consent. Watch me pop up a request "Accept my push notifications from spacexlottery.com for a chance to win 1000 DOGE from Elon Musk!"[...]
So you're suggesting that you can "trick" the user into giving permission? Native apps can (and do!) do this as well. So I'm not sure how this is any different for web apps.
> If I pull this with a web app, there's nothing to ban... maybe a domain name, but those are infinitely available.
But changing the domain name that would require the user to continually "reinstall" the web app over and over with each new domain, and re-approve push notifications for those domains each time. So I think banning domain names would actually be quite effective.
> But, you know, companies are made of people, and people who work on things like browsers or new specs like this tend to be idealistic, I would suspect.
Yes, but the things they work on are often limited in scope by management, which sometimes want to maintain monopolies over certain aspects of their products. This isn't some conspiracy theory - we actively see Apple and Google doing this all over the place. Forcing all payments through their platform is a perfect example. I'm sure many of the folks that work on these things would love to open up payments and allow people to install apps not gated by Apple. But that doesn't mean they can go ahead and unilaterally do that.
> It's easy to see the world as a place full of evil bastards (and often enough it is). Even so [...]
Well this I 100% agree with. But that's never stopped us from making progress before.
I have not found a good use case for browser notifications, to the point that I have turned them off completely due to endless prompts for permission from every website to push them.
Apple's approach of only allowing sites that you've pulled out onto your home screen to request them is actually not bad for balancing this. It means I'm not being constantly nagged while browsing normally, but when I decide I want to treat something "like an app" it gets access to richer features.
(I very rarely do this. I think the only thing I have pulled out like that currently is Puzzmo, which doesn't even do notifications.)
It's a decent way to handle permission but it's never "like an app" with iOS. Web push is missing basic features on iOS, such as notification sound/vibration. Many will say that's a good thing but there is no restriction for actual apps. I would love to rewrite a React Native app I work on as a PWA but silent notifications are totally useless for it.
Web Push does have the sound option now.
My company has a product that allows you to chat with tech support. The end user (our customer's customer), is just someone who went to one of our customers' help portals and requested help via chat.
These chats are going to last < 1 hour typically. There are times when the custom support agent needs to confer with someone else, and then will respond back. The end user, in that case, does not want to sit there with their phone open for 15 minutes, waiting for a response.
While we have an app those end users could download and get notifications on, no one wants to do that for a one off session (not even an App Clip).
Trying to get iOS users to add it to their home screen, is basically a no-go too.
So, it would be really nice if we had a way to send push notifications, even if it was time limited (allow notifications for the next 1 hour).
Don't get me wrong, Push Notification can and are abused. But there are valid use cases.
There are some legitimate use cases for them, but generally I think web push permissions are best defaulted to “no” so sites can’t harass users with fake, “we need to maintain the ability to harass the users again” in app prompts.
Every request for notification permission is best defaulted to No. It shocks me how eager people are to opt-into getting spam and other junk alerting on their phone.
Many people don't even read pop ups and just click the button that stands out to them. It's pretty wild to see.
Among less technologically literate acquaintances, getting a gazillion browser notifications on startup seems to be the modern equivalent of accidentally installing tons of useless toolbars.
Another thing that drives me nuts is the choice “yes / yes always / ask again next time”. I want “no never”!
How will they ever get you to accidentally click "yes" if it doesn't pop up again?
A rational person would avoid websites that flood with you things you don't want.
This is interesting for two reasons, firstly because the reason Chrome on Android has such terrible push notification latency is claimed to be the need to run the service worker in the context of the Chrome application, which being huge would use a load of battery so they avoid running it if at all possible.
Secondly, unfortunately the problem with iOS Safari notifications is once you get them working they cannot do things like group properly or replace each other. It just becomes a horrifying flood until you clear them all. If they have made iOS respect the tag and action fields, which are conspicuous by absence from their examples, then it will be game on.
I hope this is a sign that this is finally going to be working one day.
In Safari 18.4 (currently in beta) tags are supported and notifications can replace each other.
> Secondly, unfortunately the problem with iOS Safari notifications is once you get them working they cannot do things like group properly or replace each other
Can you elaborate? I runa PWA on my iPhone and once the PWA is installed ("added to home screen") you can manage the notification display (grouping, lockscreen, temporary/persistent) just as with any other app installed via the iPhone Settings -> Notifications.
Replacing previous notifications is not possible in the web-push standard at all, so it is not apple to blame.
It totally is: https://developer.mozilla.org/en-US/docs/Web/API/Notificatio...
"The idea of notification tags is that more than one notification can share the same tag, linking them together. One notification can then be programmatically replaced with another to avoid the users' screen being filled up with a huge number of similar notifications."
Apple are the only ones not supporting this, and much of the time with web stuff they have a point, but this one just seems obtuse.
You are right, wasn't aware of it. Looks like Chrome didn't implement this either. I'm not an android user, but to be fair, there is no way Notifications can be grouped like this on iOS with native apps.
Apple groups notifications using on their on-device AI.
So even if it was supported the OS would just ignore it.
Let's see if I can figure this out...
"Declarative Web Push" is a web browser javascript API to subscribe to events from an HTTP server. It is similar to the "Web Push" API but changed to be better for mobile devices in a few ways.
Both the old Web Push and this new Declarative Web Push APIs use "the same Apple Push Notification service that powers native push on all Apple devices". I don't know if that means an Apple server actually listens for the notification from the HTTP server or if the device itself maintains the connection to the server.
It seems that for iOS this API only works on websites that are pinned to the home screen (i.e. not a notification from a site open in safari as a browser). These pinned websites work more like apps.
Is there something similar like this on Android? Either for pinned apps or from the browser? In other words, is there a reliable and efficient way to get notifications to an android phone without having to sign up for any service?
> I don't know if that means an Apple server actually listens for the notification from the HTTP server or if the device itself maintains the connection to the server.
In the case of Apple's ecosystem, the device maintains a connection to the Apple Push Notification service (APNs). The website POSTs notifications to APNs, which forwards them on to the user's device. The user's device then wakes up a local Service Worker for that website in order to process the incoming payload and display a notification.
Declarative Web Push makes the very last step unnecessary.
(It's the same on Android but using Firebase Cloud Messaging instead of APNs. Mozilla also runs a push service and its source is at https://github.com/mozilla-services/autopush-rs/)
> Is there something similar like this on Android?
It works out of the box on Android (without adding to the homescreen or installing as PWA). For iOS, you need to tap the "share" button in safari, scroll down, and "Add to homescreen".
If you want to test this out (on either platform), you can try my PWA where I implemented this (https://lockmeout.online). In the users settings, you can even add several devices (browser, phones etc.) and send a test notifications to either a single or all devices. Installation instructions for iOS and Android are there (since it is a PWA, you just need to press the right buttons in the browser, there is not actual installation). PWAs can also be installed on Desktop (Chrome and Safari).
Btw. the PushNotification API is not device/vendor specific. I use the same code to send out notifications for mobile (iOS, Chrome Android) and Desktop (safari, firefox, chrome etc.). I also do not use any third party for sending, but do it from my server. And hell yeah, not having to create these clumsy serviceworkers will simplify my code a lot.
Still waiting for Alarms API to be implemented in web browsers to finally build my "Reminders" web app.
From an engineering and architecture perspective, I'm seriously disappointed at web notifications. They get abused by malicious or spammy threat actors a lot. The abuse potential was obvious from the start. Why are such technologies still possible, even after we've learned lessons from email and other legacy tech over the past several decades?
For example, why can sites spam users with repeated push notification requests? why is there no active trust assessment and allow/block list maintained by browsers and OS vendors (yeah, they're a plague on win10/11 too)? It even makes sense to require an EV TLS cert for any push notification service. There are many ways to tackle this, but the naive way of just letting anyone set up a random site and start spamming people is so 90's/2010's. At least as a default, it should be very hard to be able to ask users to permit your push notification service.
I think part of the problem is that push notifications became a thing on mobile platforms, where apps are vetted by app stores. But random website don't undergo any vetting before they can start pushing notifications to browsers. Another issue is that people who are part of these design decisions are too far removed from regular people who don't even know what a push notification is, they just accept random prompts and get increasingly miserable over all the popups over time. It is also very easy to allow a push notification, but the UI/UX is difficult to audit/disable these. Perhaps having some button or option in the notification box to disable similar notifications would go a long way?
In a way, the web industry re-introduced the annoying pop-up windows of the early internet.
>Why are such technologies still possible, even after we've learned lessons from email and other legacy tech over the past several decades?
The alternative seems far more disappointing from an engineering and architecture perspective to me - not bothering to implement any features because of fears that they may be abused.
I'm doubly disappointed because of your comment because that is not the alternative. You implement the technology with user experience as #1 priority and build layers upon layers of defenses against abuse and with trust establishment as its foundation.
> Web Push on Apple’s platforms uses the same Apple Push Notification service that powers native push on all Apple devices. You do not need to be a member of the Apple Developer Program to use it.
This has... interesting implications for natives apps, at least at first glance.
Also, it's not clear to me how you send to a website using this. Has Apple wildly overhauled APNS server-side since I implemented a sender-client for it years and years ago? That design was excellent, but you did need a push key tied to an app to even connect to the socket IIRC. Do they issue those for websites, now? Does it work totally differently? How does validation work?
The way web sites register for push is very different to the way Apple requires for APNS. They're using the same service to send the pushes but the client-side interface is totally different.
> This has... interesting implications for natives apps, at least at first glance.
Note: The fact that Web Push for Apple's browsers uses APNS and doesn't require any sort of developer account is not new to Declarative Web Push. It's how it's always been since Web Push first shipped in Safari 13 on macOS - https://developer.apple.com/documentation/usernotifications/...
I don't get it, they pretend they made this new proposal because of security and battery life. And then we have dozens of native apps installed that push tons of useless notifications for upselling shit and clutter the screen... I had to disable all of them. So i don't understand why they fear web push so much
I always disable push notifications for the very first push notification I receive that is an advertisement regardless of service. And what's crazy is, basically everyone does it now. Amazon does it, even, and I don't think there's an obvious way to just disable ads. Fine, fuck you, I'll just use e-mail, then.
iOS and macOS native app notifications already work the way Declarative Web Push does, not like classic Web Push. This is giving web apps the same ability to be battery friendly and more reliable that native apps already have.
again battery friendly how? because you install them first? please... as I said native apps still abuse notification system(and battery) pushing ads. Apple just hate the web platform, and them trying to push alternative solutions is just PR for how little they care about PWAs and their progression
Battery friendly because notifications can be coalesced by the OS and processed without having to fire up a full browser engine process and JS VM just to unpack the notification and post a visible notification.
Even in the case where the app needs local processing to show the best notification, having this as fallback removes the risk that the app misses the deadline to display a visible notification and therefore loses its push subscription (which is a behavior Chrome and Firefox have too).
We're also not removing classic Web Push, so web apps can deny themselves the benefits of Declarative Web Push if they don't like it.
This is a PWA-only feature; why would they spend the time to implement this if they didn’t care about PWAs?
also a webkit only feature far from the web standard, hence their carelessness
The blog post documents a relatively long engagement process with the web standards process. Starting with publishing an explainer (pretty common for the browser engines), directly talking with the other browser engines and web developers at the W3C TPAC conference, making concrete proposals to the relevant web standards githubs, taking feedback, etc.
Can you elaborate on the carelessness here? What should've been more careful?
I expect you will apply this to the other browsers who are 100x worse than Apple at adding proprietary features.
And if you read the article Apple reached out to the other browser vendors to push it as a standard.
It's standards track and we've had positive signals from Mozilla and Google. Apple is just the first to ship in this case. Are you also mad when Apple is _not_ the first to ship a feature? Is there any way to win?
Declarative Web Push seems like a beneficial addition, simplifying push notification integration. The declarative approach aligns well with modern web development. However, I'm curious about the performance implications compared to the existing API and how much flexibility developers might lose with this higher-level abstraction.
It reduces notification display latency because they can be displayed directly by the system services managing push, without having to wait for an opportune time to fire up a service worker process. It does still allow customizing the notification with code, but even in that case, having the declarative notification as a fallback improves reliability.
I've commented this before, but does this grant an exemption from the automatic purging that ITP does? the wording makes it seem like it does but that just makes their justification for ITP all the more baffling
Since there is no service worker required, if ITP removes the service worker, declarative web push continues to work. I believe this is explicitly called out.
iOS Safari only allows push notifications for web apps added to the Home Screen, (as PWAs sometimes do), and that hasn't changed with the new Declarative Web Push. Most developers aren't familiar with this, and neither are users, and so it's very, very hard to educate users on how to allow you to push notifications.
Here's how it works.
First, users have to figure out how to add your web app to the home screen. There's no "Install" button that you can put in your web UI; users just have to know how. You can, of course, explain how, in your web page, but it's quite tricky. I'll explain it below; it takes like eight or nine steps.
First, the user has to click the Share button, the box with an arrow on it under the URL bar. On iPad, it's in the URL bar. It doesn't have the word "Share" on it, so if you use the word "Share" to describe it, users will get confused.
Also, the Share button may not be visible on the screen if the user has scrolled at all, because Safari collapses Safari's bar by default, but you can bring it back by scrolling back up to the top of the screen, or asking users to set up push notifications on a special page of your site that's too short to scroll.
Once they've clicked that, they need to find the "Add to Home Screen" button. On iPhone, "Add to Home Screen" is not visible by default either. The Share sheet is only half the height of the screen, and you have to scroll it to reveal more sharing options. One of the sharing options is "Add to Home Screen."
Once they've clicked that, they have the option to rename your app to whatever they want. You can control the default, but you can't prevent them from giving it a cute nickname, which they may forget later. Then, they can click the Add button.
When they click it, the sheet disappears. As far as the user can see, nothing useful has happened. But something has happened. There's a new app icon on their home screen. Not their first home screen, of course… it's probably their last home screen or something. There's no way for users to know which screen it's on. Or, they can search their iPhone for your app, if they can remember what it's called.
Anyway, once your web app has been added to the home screen, you have to tell your users to re-launch your app from that home-screen app launcher. It boots up slowly, slower than Safari, because it's running a whole separate process from Safari. (Also, JS in general just runs slower in home-screen web apps; only Safari is allowed to do JIT just-in-time compilation of JS.)
Finally, once they launch your app from your home screen, you can request permission to push. They have to click a button in your web UI (any click is fine), and then you can pop-up an iOS push permission request. If the user says no, you've missed your only chance; users have to go find your app in iOS Settings to turn on push.
Once users agree to push notifications in your home-screen web app, finally, finally, you can now send push notifications.
Good.
I hate it when random websites on desktop ask to send notifications. I'm so glad randomly browsing on the web doesn't trigger this on mobile.
Just a workaround, but someone made a helping pop-up: https://github.com/ryxxn/pwa-install-prompt
Last time I checked, push messages did not work when the web app was not running, has that changed? Because I think that is the most interesting feature for users: To notify about important things while not using the app. It has also always been abused by app creators with useless stuff to drive engagement etc. I think I never allowed a single webpage to send me notifications - if for example I want to know about the latest news about plant pottery, I will probably just visit that website again...no need to notify me.
Push notifications work anytime, even when your phone is locked and in your pocket. On iOS you need to add the website "to your home screen", which then it becomes like an App (it is a progressive web app, PWA). For Chrome and Safari on Desktop it is the same (you even get notifications when your laptop is locked on macOS, provided you configured that in your settings of macOS).
Source: I run a PWA that enables web push (without any 3rd party push services) and have tested it many times on many platforms, and my users use them too.
I just want to say I appreciate your rant. Maybe this declarative web push API signals they are spending some developer time improving the "Add to Home Screen" experience overall.
I hope the whole industry pushes to prefer websites-as-apps. So many services have both native apps and websites and one or the other is broken or limited for no good reason other than it's hard to develop two things instead of one.
I even worked at Apple back in the day but it took me until seeing this post to realize WebKit also follows the same framework naming scheme that Apple always follows with AppKit, WatchKit, UIKit, HealthKit, GameKit, ARKit.
For some reason I didn't put WebKit into the same bucket.
The "Kit" nomenclature dates back to the NeXTSTEP days.
Notifications have been hi-jacked by corporations allowing them to effectively push ads to your lock screen.
It’s ghetto that Apple allows it, because publishers put these ads side-by-side with actual informational notifications.
Apple only allows it when you add the website to your home screen (a.k.a Install progressive web app). A user only does this when they are actually interested in the site. Once added to the home screen, it is like any other app, and you can manage the notifications from that app via iOS Settings.
Wait, this may be a huge game changer. But only if websites no longer have to ask the user to install the app on the home screen (arcane) and then launch it, and enable notifications.
It says they still do. And I’m glad about that.
I'm definitely not glad about it.
They are doing it to make sure their apps still have an edge over websites.
I know that’s a popular sentiment here, but I honestly don’t think they give a shit.
This is 100% understandable to me as something to prevent random unknown websites from sending push notifications users don’t expect or know how to control from a site they accidentally visited weeks ago.
Accidentally visiting a website doesn’t give it permission to send notifications.
Seriously, it is not that difficult to let users choose whether to receive notifications, how often, and manage them later. Apple just had negative incentive to do that on the Web!
They have to agree to a pop-up.
Guess what, people do that all the time. They get tricked into it. They just press a button really fast to get it to go away. They don’t remember doing it but then later that day or a week from then or whenever they might start getting notifications.
And of course they’re incentivized to get you to go back to their website with any notification they want to show. That way they can get more views, or try to run a scam on you if it was a scam website.
We already have ways of doing notifications from arbitrary third parties. It’s called email. Or you can make an app. Or you can get someone to add your site to their home screen. All are extremely clear measures of consent.
At work I’m not allowed to run an ad blocker. I get stupid little pop-ups asking me if I want to enable notifications on websites all the time. As far as I’m concerned it’s all spam.
I LIKE Apple’s stance. I LIKE they’re preventing me from having to see a stupid little permissions dialogue on every new website I go to asking me if I want to enable notifications.
I'm sure declarative web push is great. But most of this post sounds to me like they are trying to justify artificially restricting web push notification functionality on the web and offer an inferior solution instead. It's pretty clear they (and Google, to a lesser extent) don't want web apps to be on the same level as native apps. Cynically, I believe this is so they can continue to maintain full control of the app market.
There's a lot of statements that are presented as facts, when in fact they are not.
For example:
> Therefore we require push subscriptions to set the userVisibleOnly flag to true. While this can be frustrating, the original Web Push design made this necessary to protect user privacy and battery life.
Surely this wasn't the only option to "protect user privacy and battery life". Native apps can handle push subscriptions without this sort of flag. It's frustrating because it's _meant_ to be frustrating so that users prefer native apps over web apps.
> Allowing websites to remotely wake up a device for silent background work is a privacy violation and expends energy.
This _may_ be true in some cases, but it isn't inherently true. I'm sure there are many use cases for this that are NOT a privacy violation. And running _any_ amount of code "expends energy", so it seems silly to even imply that is a problem.
And again: this is perfectly OK for a native app to do. How is it really any different to allow web apps to do it? Because Apple doesn't get to review every app to their ever-changing standards?
At the end of the day this just further divides the native app from the web app, such that it's impossible for the latter to compete with the former.
> It's pretty clear they (and Google, to a lesser extent) don't want web apps to be on the same level as native apps.
Ironically the reality here is backwards: for a very long time iOS apps could _only_ send declarative push alerts. Only since iOS 10 were you able to use a UNNotificationServiceExtension to customize the content on-device. That extension has very strict resource and CPU limits and is terminated if it violates them. Even when you do have this extension you still need to send a declarative payload in case the on-client code fails, exactly the same as Declarative Web Push requires.
> And running _any_ amount of code "expends energy", so it seems silly to even imply that is a problem.
There's a big difference between running some native code and spinning up an entire JS virtual machine and worker environment to (effectively) modify some JSON. In fact, worker boot up speed is a recognized problem to the extent that there's an entire API to handle situations where a network response would load quicker than a Service Worker might:
https://developer.mozilla.org/en-US/docs/Web/API/NavigationP...
Years ago I actually tried spinning up a JSContext in a notification extension out of curiosity and the extension was immediately killed for exceeding resource limits. May well not be the case today but the logic still makes sense to me.
Apple is no saint and has done plenty of negative things for web apps. But in this specific instance they're making the right call, IMO: requiring backup notification content for when client-side code fails is sensible.
> Ironically the reality here is backwards:
Maybe you quoted the wrong the thing? but there's no irony here, and it's definitely not backwards in reality: Apple and Google have both severely limited what PWAs can do such that they are vastly inferior to native apps. It would very difficult to argue otherwise.
> There's a big difference between running some native code and spinning up an entire JS virtual machine and worker environment to (effectively) modify some JSON
Presumably React Native apps do something to that extent? Or, if they don't, whatever optimization they use could certainly be applied "under-the-hood" to PWAs.
> Presumably React Native apps do something to that extent?
Not in the background they don't, no.
> Or, if they don't, whatever optimization they use
They don't have one. There is no optimization they can do to run JS in the background. Push notifications in a React Native app either use native code or rely on declarative payloads sent from the server.
The big difference, as always with web apps, is intent and consent.
Installing an app is a strong signal that the user actually wants/needs it. The level of consent is much higher right out of the gate. With web apps on the other hand, the user can be swept away by a redirect, accidental tap, maliciously captured tap (think a transparent element covering the whole page), etc. There’s a much higher chance that users never intended to end up where they’re at and don’t actually want anything from the app.
Following this train of thought, it stands to reason to have a looser policy with apps. If there’s a way to install web apps with the same level of consent (PWA listings in an App Store for example), standards could be loosened when users come through that route, but for navigating to any random web address things should be more tight.
The user already has to explicitly "install" a PWA on iOS. See dfabulich's comment in this same thread for how overly complicated and convoluted that process is currently. So there's a pretty good argument that installing a PWA actually require much, much MORE intent than a native app from the app store.
Similarly, the user needs to consent to notifications (among other things) just as they do for native apps.
> So there's a pretty good argument that installing a PWA actually require much, much MORE intent than a native app from the app store
As it should because native apps go through an approval process to vet them.
Mozilla seems to be in favor as well: https://github.com/mozilla/standards-positions/pull/1190 (and funnily enough, a comment on this PR agrees with you in that background work might not be a significant factor in terms of energy consumption, but they still think this is a better design than the original Web Push spec).
Also, interestingly, in the original Web Push spec, they did think that energy consumption was enough of a concern that they implemented a quota system:
> Activating a service worker to deliver a push message can result in increased resource usage, particularly of the battery. Different browsers have different schemes for handling this, there is currently no standard mechanism. Firefox allows a limited number (quota) of push messages to be sent to an application, although Push messages that generate notifications are exempt from this limit. The limit is refreshed each time the site is visited. In Chrome there are no limits.
[0] https://developer.mozilla.org/en-US/docs/Web/API/Push_API
Anyway, let's put a defensive hat on for a moment, and assume we're dealing with malicious actors (and OF COURSE we're going to be dealing with malicious actors, this is the internet, come on).
> Surely this wasn't the only option to "protect user privacy and battery life".
First off, I notice you are confident that this wasn't the only option (there's never only one option, so the statement as it stands can't be falsified), but you don't actually _provide_ any alternative ideas.
> Native apps can handle push subscriptions without this sort of flag.
Native apps require a push token to send notifications, which can be revoked. If/when a native app abuses the user trust, it's easy to also ban the entire app, or ban the entire developer account in the worst case scenario. Even that often doesn't stop bad actors, but it does give some tools to the defenders to work with.
If I am running an abusive web app, I can spin up two dozen clones before breakfast when a particular domain gets blacklisted, and there is no way to ban me (that I know of).
>> Allowing websites to remotely wake up a device for silent background work is a privacy violation and expends energy.
> This _may_ be true in some cases, but it isn't inherently true. I'm sure there are many use cases for this that are NOT a privacy violation. And running _any_ amount of code "expends energy", so it seems silly to even imply that is a problem.
I'd love to see a heuristic that can be automatically applied to an incoming push notification to determine whether or not it's going to cause a privacy violation or excessive energy use.
In fact, maybe we can use the same heuristic with my geolocation API - after all, while some requests to the API _may_ be malicious, most of them aren't - surely there is no need to add safety guardrails that make malicious requests impossible or at least more difficult - we could just tell the computer to recognize and ignore evil requests, and only allow the good requests, right?
But, maybe you're right, and none of these are concerns to worry about - the main reason is to just make developer's life harder (though in that case, wouldn't the easiest solution be not to bother implementing any of this API at all?)
> Also, interestingly, in the original Web Push spec, they did think that energy consumption was enough of a concern that they implemented a quota system:
I never suggested energy consumption wasn't a concern. I said any code that runs expends energy. So to pretend it's a concern only for PWAs is silly. It's a concern for both web and native apps alike. But (as I understand from other comments) native apps get some sort of quota on iOS, while web apps don't even get that option.
> First off, I notice you are confident that this wasn't the only option (there's never only one option, so the statement as it stands can't be falsified), but you don't actually _provide_ any alternative ideas.
I didn't suggest an alternative because: 1) the post says it was "necessary" implying there was no other option: "the original Web Push design made this necessary to protect user privacy and battery life." But more importantly: 2) they don't go into what those privacy options _are_, exactly. So it's not really possible to address this broadly-defined privacy issue. Maybe it's buried in a Github discussion somewhere, but it's certainly not addressed in this blog post - they just say there's a privacy issue, and that's that.
> Native apps require a push token to send notifications, which can be revoked. If/when a native app abuses the user trust, it's easy to also ban the entire app, or ban the entire developer account in the worst case scenario. Even that often doesn't stop bad actors, but it does give some tools to the defenders to work
This isn't any different for web. Web app push notifications also require a token that can be revoked. The article even says "if an event handler doesn’t show the user visible notification for any reason we revoke its push subscription". So they do this already.
> If I am running an abusive web app, I can spin up two dozen clones before breakfast when a particular domain gets blacklisted, and there is no way to ban me (that I know of).
So associate push notifications with a specific account in some way, similarly to how native apps work.
> I'd love to see a heuristic that can be automatically applied to an incoming push notification to determine whether or not it's going to cause a privacy violation or excessive energy use.
I can't speak to the vague idea of what a "privacy violation" is without understanding what the specific concern is. Is it geolocation? IP address? Fingerprinting? Regardless, iOS already uses a heuristic for native apps, so why can't a similar heuristic be used for web apps?
> In fact, maybe we can use the same heuristic with my geolocation API - after all, while some requests to the API _may_ be malicious, most of them aren't - surely there is no need to add safety guardrails that make malicious requests impossible or at least more difficult - we could just tell the computer to recognize and ignore evil requests, and only allow the good requests, right?
That's quite the straw man, considering Service Workers can't even access the geolocation API. But also, the geolocation API requires explicit user consent. But I'll ask again (and this is really my main beef with all this): why is this totally fine for native apps but not for web apps?
> But, maybe you're right, and none of these are concerns to worry about - the main reason is to just make developer's life harder (though in that case, wouldn't the easiest solution be not to bother implementing any of this API at all?)
I don't think it's "just make developer's life harder". My personal opinion - as I mentioned previous - is that it's because Apple (and Google, to a lesser extent) want to maintain as much control over the mobile app market as possible. All payments go through them. They can shut down any app (ahem, competition) they please for any number of vague reasons. If web apps can be built with the same capabilities as native apps they won't be able to maintain that monopoly.
Thanks for engaging in good faith and for the detailed response (I didn't downvote any of your posts fwiw).
> I never suggested energy consumption wasn't a concern. I said any code that runs expends energy.
I don't think anyone would argue otherwise.
> So to pretend it's a concern only for PWAs is silly. It's a concern for both web and native apps alike.
I think you're ignoring the fact that running it for PWA's requires spinning up the entire browser engine in the background to run the ServiceWorker. That's considerably heavier than the minimal amount of native code required for a native app's notification extension. It's not the same cost/benefit calculation.
> So it's not really possible to address this broadly-defined privacy issue. Maybe it's buried in a Github discussion somewhere, but it's certainly not addressed in this blog post - they just say there's a privacy issue, and that's that.
Ok, but you're handwaving any potential privacy/energy issues away out of hand, and suggesting they are simply a smoke screen, and any and all discussion that I am sure went on over the course of arguments over the W3C spec as a nefarious cover. Again... from that point of view, I don't understand why you think anybody would even bother defining and implementing _any_ of this, if that was the goal?
> I can't speak to the vague idea of what a "privacy violation" is without understanding what the specific concern is. Is it geolocation? IP address? Fingerprinting? Regardless, iOS already uses a heuristic for native apps, so why can't a similar heuristic be used for web apps?
Right, you can't speak to it because it's too vaguely defined - so how can a computer universally and accurately judge the same thing without a precise definition?
And, unless I am mistaken, there IS no automatic heuristic for native apps either. I personally don't think it's even possible to define one, because there's no way to universally judge from the shape and content of a message whether it's benign or not, just like you can't judge from simply seeing an SQL statement like "DELETE x FROM y WHERE z" whether it's a valid request that should be processed, or a malicious one that should be denied - it all depends on a ton of context - and you DON'T have the same context between a web notification and a native notification.
> That's quite the straw man, considering Service Workers can't even access the geolocation API.
Sure, I am exaggerating for illustration. My point is there is no way to just handwave the complexity away with "there should be a magic heuristic that can distinguish good requests from bad requests"
> But also, the geolocation API requires explicit user consent.
Push notifications also prompt for user consent. Watch me pop up a request "Accept my push notifications from spacexlottery.com for a chance to win 1000 DOGE from Elon Musk!" and see how many acceptances I get. And that's the most trivial idea that comes to mind - a real gray or black hat would come up with a dozen more plausible options in 30 seconds, and a dozen ways to exploit access.
> But I'll ask again (and this is really my main beef with all this): why is this totally fine for native apps but not for web apps?
Because if I pull this with a native app, I'll get my app (and maybe my developer account) banned, probably sooner than later (and even so there's still a ton of scam/clone apps on app stores, because the reward is much greater than cost, and real black hats don't care about getting their accounts banned all that much).
If I pull this with a web app, there's nothing to ban... maybe a domain name, but those are infinitely available.
> So associate push notifications with a specific account in some way, similarly to how native apps work.
Sure, and...
1. What account do web developers use for sending notifications to Chrome, Mozilla, Opera, Konqueror, Ladybird users if they want to implement the notifications spec?
2. Is this a free developer account? Then there's no more friction than having no account.
3. Is this a paid developer account? I can just imagine the uproar :)
> My personal opinion - as I mentioned previous - is that it's because Apple (and Google, to a lesser extent) want to maintain as much control over the mobile app market as possible.
Fair enough opinion to hold, for sure. But, you know, companies are made of people, and people who work on things like browsers or new specs like this tend to be idealistic, I would suspect.
It's easy to see the world as a place full of evil bastards (and often enough it is). Even so, I'd say tech / open source / open standards is something that is a great achievement of humanity, which wouldn't exist without people wanting to help each other and fight for a better future. And often times, the people building these things do need to also consider the fact that yes, the internet _is_ also full of evil bastards who will gladly abuse the things they build against every single user.
> Thanks for engaging in good faith and for the detailed response (I didn't downvote any of your posts fwiw).
And you as well!
> I think you're ignoring the fact that running it for PWA's requires spinning up the entire browser engine in the background to run the ServiceWorker. That's considerably heavier than the minimal amount of native code required for a native app's notification extension. It's not the same cost/benefit calculation.
Is it "considerably heavier", though? And to what extent? I keep seeing this argument thrown around, but without any real numbers or data to back it up.
And I'm not sure what is meant exactly by "entire browser engine" (definitions vary), but you certainly don't need to spin up all the resources associated with a full-fledged browser. And much of the resources involved can be shared across many service workers and web apps.
> Ok, but you're handwaving any potential privacy/energy issues away out of hand, and suggesting they are simply a smoke screen, and any and all discussion that I am sure went on over the course of arguments over the W3C spec as a nefarious cover. Again... from that point of view, I don't understand why you think anybody would even bother defining and implementing _any_ of this, if that was the goal?
I don't mean to hand-wave them away at all. Of course these issues exist. But they also exist in native apps. For some reason they can be addressed and mitigated there, but they can't be for web apps?
> Right, you can't speak to it because it's too vaguely defined - so how can a computer universally and accurately judge the same thing without a precise definition?
I'm not saying it _isn't_ defined (or definable) _at all_. Just that this blog post doesn't define it or mention anything about the specific privacy issues.
> And, unless I am mistaken, there IS no automatic heuristic for native apps either.
I was referring to "energy consumption" heuristics, not privacy heuristics. Another commenter (afavour) mentioned that the UNNotificationServiceExtension has "very strict resource and CPU limits" that will kill a background process that exceeds them. That's entirely possible for a web app.
> My point is there is no way to just handwave the complexity away with "there should be a magic heuristic that can distinguish good requests from bad requests"
Again, I'm saying heuristics exists for native apps (as I mentioned above) and they can be applied to web apps as well.
And there's already heuristics in place for some "bad actions", as mentioned in the blog post: "if an event handler doesn’t show the user visible notification for any reason we revoke its push subscription".
They're certainly not all-encompassing, but they can certainly address "energy" concerns and some subset of bad actors.
> Push notifications also prompt for user consent. Watch me pop up a request "Accept my push notifications from spacexlottery.com for a chance to win 1000 DOGE from Elon Musk!"[...]
So you're suggesting that you can "trick" the user into giving permission? Native apps can (and do!) do this as well. So I'm not sure how this is any different for web apps.
> If I pull this with a web app, there's nothing to ban... maybe a domain name, but those are infinitely available.
But changing the domain name that would require the user to continually "reinstall" the web app over and over with each new domain, and re-approve push notifications for those domains each time. So I think banning domain names would actually be quite effective.
> But, you know, companies are made of people, and people who work on things like browsers or new specs like this tend to be idealistic, I would suspect.
Yes, but the things they work on are often limited in scope by management, which sometimes want to maintain monopolies over certain aspects of their products. This isn't some conspiracy theory - we actively see Apple and Google doing this all over the place. Forcing all payments through their platform is a perfect example. I'm sure many of the folks that work on these things would love to open up payments and allow people to install apps not gated by Apple. But that doesn't mean they can go ahead and unilaterally do that.
> It's easy to see the world as a place full of evil bastards (and often enough it is). Even so [...]
Well this I 100% agree with. But that's never stopped us from making progress before.