Web Pushの二つの境界：VAPIDによる送信元識別と本文の暗号化
VAPIDはプッシュサービスにアプリケーションサーバーを識別させ、購読先を制限します。本文はRFC 8291が別に保護しますが、どちらも通知の到達や表示を保証しません。
発行・訂正窓口：infostoa · 編集基準
この記事の個別の執筆者・専門査読者の情報は提供されていません。
Web Pushでは「誰が送ったか」と「本文を誰が読めるか」は別の問いです。VAPIDはアプリケーションサーバーをプッシュサービスに識別させ、RFC 8291はユーザーエージェントが復号できるようペイロードを保護します。通知表示の許可も別の条件です。
VAPIDが識別するのは要求元サーバー
Webアプリケーションサーバーは購読情報を使ってプッシュサービスへ送信を要求します。RFC 8292のVAPIDでは署名付きトークンと公開鍵を含め、要求元に対応するサーバー鍵を識別します。購読を特定の鍵に結び付ける場合、サービス側は対応する秘密鍵で署名されたトークンを要求できます。
これは通知に表示される名前を認証することとは異なります。署名が示すのは要求とサーバー鍵の関係であり、本文の真実性や運営者の法的身元ではありません。問い合わせ先をトークンに含めても、運営者が提供した情報です。鍵の紛失や交換が購読に影響し得るため、保管と更新の手順も必要です。
RFC 8291は本文を別に暗号化する
送信元を識別してもペイロードは自動的に暗号化されません。Web Pushの暗号化では購読に結び付いた鍵情報と、送信時に作る鍵素材を使います。RFC 8291はP-256曲線のECDH鍵共有と鍵導出を説明し、本文を暗号化する対称鍵とnonceを得る手順を定めます。
目的はプッシュサービスが本文を読んだり改変したりすることを難しくすることです。ただし配送に必要なendpointや時刻など、全てのメタデータを隠すわけではありません。暗号化はブラウザーに通知を表示させる命令でもありません。本文の秘匿性と配送情報を分けて説明します。
購読と表示許可は別の状態
利用者が通知を許可し、サイトがPush APIの購読を作ると、ブラウザーはプッシュサービスに結び付いたendpointと鍵情報を返します。サーバーは購読を保存して要求を用意し、サービスワーカーはpushイベントを処理して必要なら通知を表示します。
購読は配送先、権限はブラウザーが管理する利用者の同意です。権限が拒否されたり購読が失効したりすれば、認証と暗号化だけでは補えません。endpointと購読鍵へのアクセスを制限し、通常のログに出さず、不要になった購読を整理します。
規格は到達や表示を約束しない
Web Pushはサーバーが配送を依頼する仕組みです。端末がオフラインのときの到着時刻、ブラウザーのバックグラウンド動作、OSによる表示を保証しません。ネットワーク、期限、ブラウザーの方針、利用者設定、電源管理が結果に影響します。送信要求の成功だけでは、利用者が通知を見たとは言えません。
機密情報を含むときは、ロック画面や共有端末に表示される可能性を考えます。本文を最小限にし、詳しい情報は認証済み画面に案内すれば露出を抑えられる場合があります。これはRFCが指定する表示規則ではなく、運用上の判断です。
境界ごとに実装を点検する
レビューでは三つを分けて確認します。VAPIDはどのサーバー鍵を識別し、どの購読が受け入れるか。本文は規定どおり暗号化され、プッシュサービスにどの配送情報が残るか。権限の変更、購読の更新・削除、サービスワーカーの失敗、通知表示をどう扱うかです。
認証エラーはトークン・鍵・購読制限、復号エラーは購読鍵と暗号文、通知が出ない問題は権限・サービスワーカー・ブラウザーやOSの動作を調べます。各経路を分けて試すと一層の成功を別の成功と取り違えません。一つの端末での成功を全てのブラウザーでの配送保証にしないことが大切です。
ブラウザー実装では許可状態やバックグラウンド実行の条件が同じとは限りません。互換性を確認するときは、鍵とサーバー要求の試験だけでなく、許可の変更、再購読、サービスワーカーが受信後に通知を出す流れも分けて確かめます。
専門家の実装解説では、web.devがブラウザーの購読鍵とアプリケーションサーバー鍵を別の用途として説明しています。「Web Pushの鍵」を一つの資格情報として扱わず、生成・保管・更新の経路を分けて点検します。