웹 푸시는 발신자 신원을 표준화하여 앱스토어 사일로를 벗어났다

초기 웹 푸시는 Chrome에서 작동했지만, 백엔드 경로는 여전히 Firebase Cloud Messaging을 거쳤고 Google 전용 프로젝트 자격 증명이 필요했다. 이 때문에 개방형 API가 둘 이상의 브라우저를 지원하는 개발자에게는 덜 개방적으로 느껴졌다.

Chrome의 2016년 상호운용성 관련 글은 해결책을 이렇게 설명했다. FCM이 표준 웹 푸시 프로토콜을 받아들이기 시작했고, VAPID는 GCM 발신자 ID와 독점 Authorization 헤더 대신 공개/비공개 키 쌍으로 발신자 인증을 제공했다.

실질적인 결과는 하나의 코드 경로였다. Chrome의 자체 안내에 따르면 VAPID 덕분에 개발자는 더 이상 Firebase 프로젝트가 필요 없었고 Chrome과 Firefox에서 동일한 구독 및 전송 흐름을 사용할 수 있었다.

Apple의 WebKit은 이후 macOS Ventura의 Safari 16에서 이 표준 경로에 합류했다. WebKit은 웹 푸시가 Push API, Notifications API, Service Worker가 함께 작동해야 활성화되며, 표준을 준수하는 사이트는 Apple Developer Program에 가입하지 않고도 Safari 사용자에게 도달할 수 있다고 밝혔다.

푸시 발신자 신원을 이식 가능하게 만들었다

브라우저 푸시를 분산된 구조로 유지했다. 각 브라우저는 자체 서비스를 운영할 수 있었고 앱은 하나의 프로토콜을 사용했다.

벤더 등록을 요청에 담긴 암호화 신원으로 대체했다.

사용자에게 표시되는 알림을 요구함으로써 푸시를 웹의 권한 모델과 정렬했다.

웹 표준은 일반적인 경로에서 벤더 가입 단계를 제거할 때 승리한다.

VAPID 이후 Chrome과 Firefox는 동일한 표준 기반 전송 경로를 공유했고, Safari는 2022년에 웹 푸시 지원을 추가했다. 웹 앱은 푸시만을 위해 네이티브 앱을 만들지 않고도 주요 엔진 전반의 사용자에게 알림을 보낼 수 있게 되었다.