Intent to Implement: Push subscription restrictions and the Web Push protocol

[Peter Beverloo]

Contact emails

pe...@chromium.org, hark...@chromium.org

Spec

https://github.com/w3c/push-api/pull/182

https://tools.ietf.org/html/draft-thomson-webpush-vapid

Summary

Allow websites to indicate a public key of their application server when creating a push subscription, rather than using the existing “gcm_sender_id” manifest key. Advertise an Web Push protocol endpoint for sites using this.

Motivation

Our Push API implementation is backed by Google Cloud Messaging, and consequently has two proprietary aspects to it:

    (1) Relying on a “gcm_sender_id” property in the manifest, which the developer has to obtain in the Google Developer Console.

    (2) Advertising an endpoint that the developer must use with GCM’s proprietary protocol.

We recently specified a mechanism (draft-thomson-webpush-vapid) that adds server authentication capabilities to the Web Push protocol using P-256 ESDSA and a JWT token. It also introduces the concept of restricting subscriptions to a given application server, re-using the P-256 public points used for authenticating the server.

Together, we expect that they can satisfy our requirements, and enable us to move to a Web Push protocol-compatible endpoint.

The Web exposed changes in Chrome are limited to accepting an ArrayBuffer when creating a push subscription (we will only pass this data through to the server), and returning a different endpoint when the developer uses this. The server-side implementation will take place simultaneously.

Interoperability and Compatibility Risk

We will completely align with the W3C and IETF standards following this change. Firefox already ships the Web Push protocol.

Ongoing technical constraints

At some point we’ll want to deprecate the GCM endpoint that is currently returned by Chrome for new push subscriptions, but this will have to be a longer-term plan.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

This impacts all platforms where the Push API is currently supported (all but WebView).

OWP launch tracking bug

https://crbug.com/583753

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5748876422152192

Requesting approval to ship?

No

[PhistucK]

On Wed, Feb 3, 2016 at 9:19 PM, Peter Beverloo <pe...@chromium.org> wrote:

At some point we’ll want to deprecate the GCM endpoint that is currently returned by Chrome for new push subscriptions, but this will have to be a longer-term plan.

​Since the Push API has only been supported for a few releases and the adoption has not been so wide yet (https://www.chromestatus.com/metrics/feature/timeline/popularity/990​ shows 1% for service workers or something, so a fraction of that), I think a concrete plan for deprecation should be devised very soon... These things tend to stick.

Overall, this is great!

☆PhistucK