From 28b20f86ea2bf861e972cfbac074281ca2012d0e Mon Sep 17 00:00:00 2001 From: anomalist Date: Thu, 24 Aug 2023 05:14:17 -0400 Subject: [PATCH] Add 'web-push.md' Document Describing Web Push Workflow --- web-push.md | 70 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 web-push.md diff --git a/web-push.md b/web-push.md new file mode 100644 index 0000000..1a68c19 --- /dev/null +++ b/web-push.md @@ -0,0 +1,70 @@ +Web Push notifications is a web browser messaging protocol defined by the W3C. + +Discussions of this interesting technology are clouded because of a terminological +morass. + +To understand how Web Push operates, we need to observe that are three (and +potentially four) parties involved. These are: + +1) The user's web browser. Let's call that BROWSER +2) The Web Push Service Provider which is operated by the organization controlling the +web browser's source code. Here named PROVIDER. An example of a PROVIDER is +FCM (Firebase Cloud Messaging) which is owned by Google. +3) The Web Application that a user is visiting from their web browser. Let's call this the +SERVICE (short for Web Push application service) +[4) A Custom Web Push Intermediary Service, either third party or self-hosted. Called +INTERMEDIARY here.] + +The workflow works like this: + +BROWSER visits a website which has a SERVICE. + +The SERVICE asks BROWSER for its permission to subscribe to messages coming +from the SERVICE. + +The BROWSER receives a data structure from SERVICE called a VAPID (Voluntary +Application Server Identification). + +The VAPID is a specification used to identify the application server (i.e. the SERVICE +server) that is sending push messages to a push service. It's an authentication +mechanism that allows the server to demonstrate its identity to the push service, by use +of a public and private key pair. These keys are used by the SERVICE in encrypting +messages being sent to the BROWSER, as well as being used by the BROWSER in +decrypting the messages coming from the SERVICE. + +If the BROWSER accepts and grants permission to subscribe to receiving from the +SERVICE Web Push messages, then the BROWSER makes a subscription request to +PROVIDER which creates and stores a special URL for that BROWSER. The +PROVIDER sends this URL back to the BROWSER. The BROWSER will then use that +URL to check for incoming messages by way of a special software named a "service +worker". The BROWSER also sends this URL back to SERVICE which will use that +URL to send messages to the BROWSER via the PROVIDER. + +Ultimately, the actual process of receiving messages varies from BROWSER to +BROWSER. Approaches vary from long-polling HTTP connections to WebSockets. A +lot of handwaving and voodoo magic. The bottom line is that the BROWSER itself +manages the connection to the PROVIDER whilst the SERVICE must send messages +via the PROVIDER so that they reach the BROWSER. + +Now to address the issue of receiving notification messages on mobile devices. +It should be noted that Web Push messages are only received when BROWSER is +open, except in the cases of Chrome and Firefox mobile BROWSERS. In iOS the +mobile application (in our case a PWA) must be added to the Home Screen and +permissions must be explicitly granted that allow the application to receive push +notifications. Further, with an iOS device the user must enable wake on notification to +have their device light-up when it receives a notification (https://support.apple.com/enus/HT208081). +So what about #4? - The INTERMEDIARY. Well, It is possible under very special +circumstances to create your own Web Push PROVIDER. The only case I've found so +far relates to making an Android Custom ROM. (An Android Custom ROM is a +customized version of the Android Operating System.) There are open source +IMTERMEDIARY products such as UnifiedPush (https://unifiedpush.org/) which can +fulfill this role. If you are using iOS you are not permitted to make or use your own +custom Web Push PROVIDER. Apple will never allow anyone to do that. Apple has +none of its own. + +It is, however, possible to have a sort of proxy working between your SERVICE and +FCM (or iOS). Services that mash up various Push notification services (like +OneSignal) can perform in the role of such proxies. + +#4 -The INTERMEDIARY- doesn't appear to be anything we should be spending our +time on.