Web Push entkam den App-Store-Silos, indem es die Absenderidentität standardisierte

Frühes Web Push funktionierte in Chrome, aber der Backend-Pfad lief weiterhin über Firebase Cloud Messaging und erforderte Google-spezifische Projekt-Anmeldedaten. Das ließ die offene API für Entwickler, die mehr als einen Browser bedienten, weniger offen wirken.

Chroms Interoperabilitätshinweis von 2016 beschrieb die Lösung: FCM begann, das standardisierte Web Push Protocol zu akzeptieren, und VAPID lieferte die Absenderauthentifizierung mit einem öffentlichen/privaten Schlüsselpaar statt einer GCM-Absender-ID und einem proprietären Authorization-Header.

Das praktische Ergebnis war ein einziger Codepfad. Chroms eigene Anleitung besagte, dass Entwickler mit VAPID kein Firebase-Projekt mehr benötigten und denselben Abonnement- und Sendevorgang in Chrome und Firefox verwenden konnten.

Apples WebKit schloss sich später dem Standardweg in Safari 16 unter macOS Ventura an. WebKit erklärte, Web Push werde durch Push API, Notifications API und Service Workers gemeinsam aktiviert, und standardkonforme Websites könnten Safari-Nutzer erreichen, ohne dem Apple Developer Program beizutreten.

Die Push-Absenderidentität portabel machen

Es hielt Browser-Push dezentral: Jeder Browser konnte seinen eigenen Dienst betreiben, während Apps ein einziges Protokoll verwendeten.

Es ersetzte die Anbieterregistrierung durch eine kryptografische Identität, die in der Anfrage mitgeführt wird.

Es brachte Push mit dem Berechtigungsmodell des Webs in Einklang, indem es für den Nutzer sichtbare Benachrichtigungen verlangte.

Ein Webstandard gewinnt, wenn er den Anmeldeschritt beim Anbieter aus dem üblichen Weg entfernt.

Nach VAPID teilten Chrome und Firefox denselben standardbasierten Sendeweg, und Safari fügte 2022 Web-Push-Unterstützung hinzu. Web-Apps konnten Nutzer über die wichtigsten Engines hinweg benachrichtigen, ohne eigens für Push eine native App zu bauen.