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