Is push support in Service Workers dependent on Internet and third-party Google/Apple services?

Question

Is push support in Service Workers dependant on Firebase (and Apple's equivalent)? All the tutorials I find have a step where you register a Firebase account, but for our webapp this is a no-go as it will be used at premises without internet access.

I would have assumed that it was possible to register a URL that conformed to some protocol that the OS would register with, but I cannot find any information of the sort.

If it is the case that one needs internet access for service worker push support I assume the only option for a web app to receive background notifications is to wrap it in a native web view and use that to call out to on-premise services.

Answer 1

Internet or third-party push services are not required if you provide a local push service on a local network server that can be accessed via HTTPS URL from clients' browsers. Your local push service needs to implement the W3C Push API specification, and you could also search the web or GitHub for an open-source push service in the language of your choice.

The browsers would would require an HTTPS URL that resolves to a server on your network via hostname or IP, so self-signed SSL certificates would most likely be used. The devices would need the certificates (or CAs) implicitly trusted or explicitly added as a trusted CA/cert.

Answer 2

tldr; it depends on your browser, as it needs to be configured on a per-browser level. As of May 2018, it seems as if Firefox is the only one that lets you configure the service url. For everyone else, you need internet for push messages to be delivered.

The December 2017 Push API specification (which is the official one as of May 2018), says this:

The term push service refers to a system that allows application servers to send push messages to a webapp. A push service serves the push endpoint or endpoints for the push subscriptions it serves.

There is only one push service per user agent and it cannot be changed from the default value. This limitation is 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.

In April 2018 they relaxed this requirement and the spec now allows for configuring a different provider.

---

I also recommend reading this the dumbed-down version of how webpush works, where the main points are as follows:

1. First the end user's web browser needs to establish a push channel with the browser manufacturer's push server. In the case of Firefox, this would be a Mozilla server, in Chrome's case, this would be a Google server. After this is done, a unique endpoint URL is sent to the browser, and the browser generates a public and private key pair which is stored internally in the browser. The browser then makes a public key and a user authentication secret used by your server to E2E encrypt messages to the user's browser.
2. The browser sends the public key, authentication secret and endpoint URL to your server, and the server stores this somehow (in a database, in memory, a file, whatever).
3. When the time comes that the server wishes to send a push message, it retrieves the stored information on the push message subscription and creates an encrypted message with the public key and user authentication. Then the server contacts the endpoint URL and tells it to push some content to the user agent.
4. Given everything looks OK, the push server pushes the message to the user's browser.