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.