Intent to Implement: Payloads for Push messages
102 views
Skip to first unread message
Peter Beverloo
Jul 9, 2015, 11:02:08 AM7/9/15
to blink-dev
Contact email
Spec
The already implemented PushMessageData interface:
Summary
Addition of the "curve25519dh" attribute on the PushSubscription interface, and the PushMessageData interface exposed off PushEvent providing access to the (decrypted) payload.
Motivation
The Push API implementation can currently be used to deliver "tickles" - notifications that something has happened, without indicating what happened. This requires developers to check with their application servers over the network to find out what the update is.
With the PushMessageData interface, developers can include some amount of data with their message. While the exact limit is implementation-defined, the Web Push protocol requires this limit to be at least 4 KB. Our push service, Google Cloud Messages, matches this.
Payloads must be encrypted because Web Push is, inherently, an intermediated protocol. The identify of these intermediaries is not always known, nor are they necessarily trusted.
Compatibility Risk
Medium. The current IETF draft and Martin Thomson's pull request propose using P-256 as the ECDH curve, whereas we prefer using Curve25519 instead. This is being discussed at the IETF:
(note that not all replies seem to be showing up.)
Ongoing technical constraints
Client-side JavaScript code has to share the public key (curve25519dh) and the other subscription information with their server upon subscribing for Push. The PushEvent will only receive decrypted payloads.
When sending messages on the server-side, the encryption part of draft-thomson-webpush-encryption-01 has to be implemented. This is hard. We anticipate libraries to provide all functionality, and are looking into expediting the overall availability.
OWP launch tracking bug
Link to entry on the feature dashboard
Requesting approval to ship?
No
abral...@gmail.com
Oct 1, 2015, 7:00:11 PM10/1/15
to blink-dev
Il giorno giovedì 9 luglio 2015 17:02:08 UTC+2, Peter Beverloo ha scritto:
When sending messages on the server-side, the encryption part of draft-thomson-webpush-encryption-01 has to be implemented. This is hard. We anticipate libraries to provide all functionality, and are looking into expediting the overall availability.
I'm working on such a library (https://github.com/marco-c/web-push), I was wondering what's the latest news here.
I've noticed you've started working on P-256 (https://code.google.com/p/chromium/issues/detail?id=486040#c20), do you have any idea when that work is going to be finished?
I'd also like to avoid GCM-specific code in the library, do you have any sense of when Chromium is going to use standard a standard push service?
Peter Beverloo
Oct 2, 2015, 5:44:57 AM10/2/15
to abral...@gmail.com, blink-dev
On Fri, Oct 2, 2015 at 12:00 AM, <abral...@gmail.com> wrote:
Il giorno giovedì 9 luglio 2015 17:02:08 UTC+2, Peter Beverloo ha scritto:When sending messages on the server-side, the encryption part of draft-thomson-webpush-encryption-01 has to be implemented. This is hard. We anticipate libraries to provide all functionality, and are looking into expediting the overall availability.
I'm working on such a library (https://github.com/marco-c/web-push), I was wondering what's the latest news here.
We're two patches away from supporting end-to-end encryption in Chrome, based on Curve25519, and are intending to have it working behind a flag in Chrome 47. I'll post an update to the bug when that's known.
I've noticed you've started working on P-256 (https://code.google.com/p/chromium/issues/detail?id=486040#c20), do you have any idea when that work is going to be finished?
Yes, there is a consensus to use P-256 with the Web Push protocol. Changing Chrome to use that instead is in scope for Chrome 48.
I'd also like to avoid GCM-specific code in the library, do you have any sense of when Chromium is going to use standard a standard push service?
We actually announced the availability of a preview of this service as part of GCM:
Right now, we don't have a plan yet for switching Chrome over completely, but this certainly is on our roadmap after the encryption story has been figured out :).
Thanks,
Peter
abral...@gmail.com
Oct 3, 2015, 7:17:54 AM10/3/15
to blink-dev, abral...@gmail.com
Thank you, great news!
Reply all
Reply to author
Forward
0 new messages