3 ms·
Since the software can be updated at almost any time, I don't think either of those are true.
by geocar 10y ago
Since the software can be updated at almost any time, I don't think either of those are true.
- FabHK 10y agoIf the client gets compromised, you're screwed anyway. e2e encryption's goal is that the communication between A and B is secure even if the server gets compromised. Here, by design choice, the server could be compromised such that messages that (A thinks) B hasn't received yet can be triggered (by the server) to be re-keyed and re-sent from A.
- geocar 10y agoI don't think this is what most people think of when they think of "e2e encryption". If "A" is FaceBook software (client) and the communication to FaceBook's servers is encrypted, that should be standard, but it's not "e2e encryption". That's what TLS/SSL does. Why do we need another protocol when we already have TLS/SSL? Those are hugely deployed protocols whose implementations still have bugs. I think "A" is me. I think that's what most people think, that we're talking about keeping the communication private between them and their partner. "A" is not the software that FaceBook controls: If FaceBook cannot decrypt my messages, then nobody can hack FaceBook to decrypt my messages, and FaceBook cannot be compelled to provide my messages to someone else. That's something that is actually valuable, and befitting a special label of "e2e encryption". FaceBook can update that software (so can Google, Apple, or potentially Amazon or any other "app store" in the ideal scenario, hackers in the less ideal, and an oppressive government in the dire) at any time, so you simply do not know what it does, did, or will do, but at least you can keep it honest if you can supply and verify the keys yourself.