Comment by joekrill
1 day ago
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.
1 reply →