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.