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?)