Re: [w3c/push-api] Non-Browser Vendor Supplied Push Server Support (#243)

Hi Manu, exciting to hear that you'll soon be rolling out support for Web Push!

Mobile devices were the primary motivation for the Push API. They come with a series of unique constraints, notably that they're battery powered. They also usually come with built-in push services that are available to every application installed on the device. By enabling multiple applications to share a connection instead of each establishing their own, a very substantial amount of power can be saved. (Networking, specifically the radio on a mobile device, tends to be the largest contributor to battery usage after the screen.)

The Push API exists to enable web applications to benefit from this connection.

We've decided against supporting a bring-your-own-push-service model because establishing multiple connections goes against the goals of the Push API. It has a significant negative impact on the user (by draining their battery faster), and is, in fact, very hard to impossible to support on various mobile platforms.

As you note, this comes with important privacy and security considerations. For that reason the Push API goes hand-in-hand with the Web Push Protocol (RFC8030) standardized at the IETF. It specifically designates the intermediaries —the push services— as untrusted. In effect, we require end-to-end encryption for messages, and give you some other tools such as [message padding](https://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding-08#section-2) to even hide things like the length of your payload.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/push-api/issues/243#issuecomment-286782918

Received on Wednesday, 15 March 2017 15:43:21 UTC