Intent to Ship: The Web Push Protocol and subscription restrictions

[Peter Beverloo]

Contact emails

poz...@google.com, cos...@google.com (GCM);

hark...@chromium.org, pe...@chromium.org (Chrome)

Spec

https://w3c.github.io/push-api/#widl-PushSubscriptionOptionsInit-applicationServerKey

https://tools.ietf.org/html/draft-ietf-webpush-protocol

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

Summary

Allow websites to indicate their application server’s public key when creating a push subscription, superseding the existing “gcm_sender_id” manifest key. This drops the requirement to register with the Google Developer Console as well.

When a website uses this method of authentication, they will receive a Web Push Protocol-compatible endpoint. The endpoint, provided by Google Cloud Messaging (GCM), supports the Web Push Protocol with the exception of delivery receipts, which we intend to support later.

 

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/topic/blink-dev/ghf2Wq4qQ_w/discussion

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

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

Demo link

https://tests.peter.sh/push-generator/

Interoperability and Compatibility Risk

We will align with the W3C and IETF standards following this change, modulo delivery receipts which are still being debated by the working group. The suite of specifications are a collaboration between Mozilla, Microsoft, Google and many others.

Existing subscriptions will continue to work. In the mid-term we plan to migrate all subscriptions to receive a Web Push Protocol-compatible endpoint, but would like to group this with another potential change that may impact existing implementations (subscription expiration).

OWP launch tracking bug

https://crbug.com/583753

Entry on the feature dashboard

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

[Chris Harrelson]

LGTM1. This is great!

Side note: though it is a critical part of the implementation of the end-to-end feature, the Web Push Protocol is not actually a protocol in Blink, so it's an FYI w.r.t. the Intent process, not a blocker.

Chris

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Dimitri Glazkov]

LGTM2

:DG<

[Rick Byers]

LGTM3

Thanks for the note about the push protocol - I was digging in try to better understand the interop risk there, but I agree that's out of scope for this intent.

Still Peter, could you say a little more about your take on the interop risk in this whole space?  Eg. "we will align with the standards" - do you mean the standards are still changing but we expect we can safely change with them?  How stable do these standards seem to be?  What's the implementation status in other engines?

[PhistucK]

Gecko already implemented Web Push, as far as I know. Does Blink fully interoperate with Gecko?

☆PhistucK

[Peter Beverloo]

On Wed, May 4, 2016 at 8:28 PM, PhistucK <phis...@gmail.com> wrote:

Gecko already implemented Web Push, as far as I know. Does Blink fully interoperate with Gecko?

Yes, although (1) we still have the userVisibleOnly requirement whereas Firefox allows messages that don't show a notification as well, and (2) support for applicationServerKey been implemented in, but hasn't shipped in Firefox yet.

https://bugzilla.mozilla.org/show_bug.cgi?id=1247685

 

☆PhistucK

On Wed, May 4, 2016 at 9:20 PM, Rick Byers <rby...@chromium.org> wrote:

LGTM3

Thanks for the note about the push protocol - I was digging in try to better understand the interop risk there, but I agree that's out of scope for this intent.

Still Peter, could you say a little more about your take on the interop risk in this whole space?  Eg. "we will align with the standards" - do you mean the standards are still changing but we expect we can safely change with them?  How stable do these standards seem to be?  What's the implementation status in other engines?

There are a few on-going discussions, but specification is deemed mature enough to have moved to the Working Group Last Call phase:

    https://mailarchive.ietf.org/arch/msg/webpush/6s1lgkp0q9iu7bZ0M0UpY6X7RpU

The drafts themselves have been fairly stable have seen at least four implementations, two of which (Mozilla's and ours) are public. I don't expect any major changes anymore.

Thanks,

Peter

[Rick Byers]

On Wed, May 18, 2016 at 1:43 PM, Peter Beverloo <pe...@chromium.org> wrote:

On Wed, May 4, 2016 at 8:28 PM, PhistucK <phis...@gmail.com> wrote:

Gecko already implemented Web Push, as far as I know. Does Blink fully interoperate with Gecko?

Yes, although (1) we still have the userVisibleOnly requirement whereas Firefox allows messages that don't show a notification as well, and (2) support for applicationServerKey been implemented in, but hasn't shipped in Firefox yet.

https://bugzilla.mozilla.org/show_bug.cgi?id=1247685

 

☆PhistucK

On Wed, May 4, 2016 at 9:20 PM, Rick Byers <rby...@chromium.org> wrote:

LGTM3

Thanks for the note about the push protocol - I was digging in try to better understand the interop risk there, but I agree that's out of scope for this intent.

Still Peter, could you say a little more about your take on the interop risk in this whole space?  Eg. "we will align with the standards" - do you mean the standards are still changing but we expect we can safely change with them?  How stable do these standards seem to be?  What's the implementation status in other engines?

There are a few on-going discussions, but specification is deemed mature enough to have moved to the Working Group Last Call phase:

    https://mailarchive.ietf.org/arch/msg/webpush/6s1lgkp0q9iu7bZ0M0UpY6X7RpU

The drafts themselves have been fairly stable have seen at least four implementations, two of which (Mozilla's and ours) are public. I don't expect any major changes anymore.

Sounds perfect, thanks for the details!

[Costin Manolache]

I'm testing Firefox 46 - same code (slightly modified fork of GoogleChrome/push-encryption-go) can send to both Chrome and Firefox - it seems they just ignore the VAPID key, and are more strict on the base64 encoding, and we have a small server-side bug that will be fixed in next push.

As Peter mentioned, firefox no longer requires 'user visible'.

Costin