Comment by joekrill

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