Web Pushは送信者識別を標準化することでアプリストアのサイロを回避した

初期のWeb PushはChromeで動作したが、バックエンドの経路は依然としてFirebase Cloud Messagingを経由し、Google固有のプロジェクト認証情報を必要としていた。そのため、複数のブラウザに対応する開発者にとって、このオープンAPIはオープンとは言い難いものになっていた。

Chromeの2016年の相互運用性に関する注記は、その修正内容を説明していた。FCMが標準のWeb Push Protocolを受け入れるようになり、VAPIDがGCM送信者IDと独自のAuthorizationヘッダーの代わりに、公開鍵/秘密鍵のペアによる送信者認証を提供したのである。

実用的な結果として、コード経路は1つになった。Chrome自身のガイダンスによれば、VAPIDによって開発者はFirebaseプロジェクトを必要としなくなり、ChromeとFirefoxで同じ購読と送信のフローを使えるようになった。

AppleのWebKitも後に、macOS Ventura上のSafari 16でこの標準規格の道に加わった。WebKitは、Web PushがPush API、Notifications API、Service Workersの組み合わせによって有効になり、標準規格に準拠したサイトがApple Developer Programに参加することなくSafariのユーザーに到達できると述べた。

プッシュ送信者の識別をポータブルにする

ブラウザのプッシュを分散型に保った。各ブラウザが独自のサービスを運用できる一方で、アプリは1つのプロトコルを使えた。

ベンダー登録を、リクエストに含まれる暗号学的な識別に置き換えた。

ユーザーに表示される通知を必須とすることで、プッシュをWebの許可モデルに整合させた。

Web標準は、一般的な経路からベンダーへのサインアップ手順を取り除くことで勝利する。

VAPID以降、ChromeとFirefoxは同じ標準規格ベースの送信経路を共有し、Safariは2022年にWeb Pushのサポートを追加した。Webアプリは、プッシュのためだけにネイティブアプリを構築することなく、主要なエンジン間でユーザーに通知できるようになった。