Can you change the push service used by the browser? Is it possible to build and use a custom push service for delivering the web push notifications to the browser?
If you are getting started with web push notifications you may want to understand what is a browser push service, how can you pick one and if you can build your own push service.
A browser push service is a service running in the cloud that receives some messages from an application (e.g. from the backend of your website) and delivers them to the user browser. The user browser is constantly connected to its own push service and thus can instantly receive the messages. When the browser receives a message, it activates the push event in the service worker, which can finally display a notification to the user.
Each browser has a push service defined in its settings and you cannot change it. Whether you are a web developer or an end user, the choice has been already made by the browser manufacturer.
Basically the answer is that, unless you create your own browser, you cannot change the push service. Each browser manufacturer uses its own service: for example Google uses FCM for Chrome, Mozilla uses Autopush for Firefox, Microsoft uses WNS for Edge, Safari uses APNs for Safari, etc.
There are mainly two reasons for this choice:
- keeping only one push service per browser keeps the number of connections low and thus you can save energy
- running a reliable push service is complex and requires performance considerations.
Here's what the editors of the W3C standard stated initially:
The user agent is responsible for choosing the push service used for creating push subscriptions. There usually is a pre-existing relationship between the user agent and the push service due to a variety of performance-related concerns, including the complexity of running reliable push services and the impact on battery lifetime if there were an unbounded set of push services to which a device could connect.
Which was rephrased after some time in this way:
User agents MAY limit the choice of push services available. Reasons for doing so include performance-related concerns such as service availability (including whether services are blocked by firewalls in specific countries, or networks at workplaces and the like), reliability, impact on battery lifetime, and agreements to steer metadata to, or away from, specific push services.
In any case you should not worry about this limitation, because all the messages that go through a push service are encrypted end-to-end and cannot be read by the push service.
You can also read more about privacy and web push.
However it's worth mentioning that this design choice introduces some limitations, including:
- the notifications may not work in some countries, because the browser push service can be easily banned (censorship)
- the notifications may not work in work environments with strict firewall rules, since the browser needs to connect to an external service to fetch the notifications.
There is finally a question that you may have: if each browser has its own push service and you cannot change it, why there are so many push services?
The answer is that the web push services that you can find searching on Google, like Pushpad for example, are services built on top of the browser push services. They don't replace them.
They add an additional layer of abstraction (e.g. web UI, libraries, etc.) over the browser push services in order to simplify the work of developers and marketing teams.
Pushpad and similar services use the Push API standard in order to interact with the push service of the browser.