- From: Manu Sporny <notifications@github.com>
- Date: Tue, 21 Mar 2017 10:42:23 -0700
- To: w3c/push-api <push-api@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Tuesday, 21 March 2017 17:42:57 UTC
@beverloo @martinthomson While I can understand some of the technical reasons, note that going through a single set of servers, even if the data is encrypted, enables data mining and creates privacy issues. For example, one of our use cases is retailers pushing digital offers (coupons, sales, etc.) to their loyalty customers. When, where, and to whom this data is pushed from and to, even if it is encrypted, has economic value to competitors in the marketplace. So, the answer can't be as simple as "just encrypt the payload", because the delivery information cannot be encrypted. I'm at IETF 98 in Chicago this week and I'll check in with a couple of folks, including one of the editors of the WebRTC spec, wrt. numbers on battery/radio usage for the Web Push Protocol (as well as other protocols). Even selection among a set of bounded push servers would be better than not having the ability to select at all. -- 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-288160275
Received on Tuesday, 21 March 2017 17:42:57 UTC