3 ms·
This should have mandatory crypto built in from the beginning so that third party push providers can be used without causing privacy/security concerns. The bro
by mike-cardwell 12y ago
This should have mandatory crypto built in from the beginning so that third party push providers can be used without causing privacy/security concerns.
The browser and the web server should negotiate an encryption key, or set of encryption keys during setup, and any push messages signed and encrypted. That way, any third party push provider can't inpect the messages.
Also, pigs should learn to fly.
- andrewstuart2 12y agoI think the whole point of the spec is third-party push servers, a la GCM. Encryption is still totally doable, as the client can negotiate directly with the service provider and then hand off to the single-socket push provider who would only see encrypted messages. You'd need metadata readable by the push server, however, so it can deliver messages to the right client. Push messages already exist via Server-Sent Events [1]. This would simply standardize a less resource intensive single-connection model that third parties can interact with. [1] http://www.w3.org/TR/eventsource/ http://www.w3.org/TR/eventsource/
- mike-cardwell 12y agoYes, you can already add your own encryption on top of the push system. What I was proposing is that it is standardised and doesn't require any extra code from the application developer. So when I want to push a message out to one of my users, the push software I am using will handle encrypting it, and the push software on the users device will handle decrypting it. They will both be aware of the encryption keys involved because they will have negotiated them during the initial direct connection and will have them stored.