| ▲ | figassis 4 days ago | |||||||||||||||||||||||||||||||
The author is basically saying if you participate in any part of the encryption process, you're deceiving users in saying things are e2e encrypted. Isn't this conflating encryption with trust? Of course whoever claims to encrypt your data needs to be trustworthy, and whether they actually are is another matter, but If my app allows you to generate a client side key, export it and use it to encrypt data client side and we only get the encrypted data, that is verifiably valid encryption. I could be malicious and also send a copy of your actual plaintext to the server as well, but that is trivial to check (unless I'm being targeted and I am the only user that gets the malicious code, still, I can check). It's a risky proposition for an organization with vested interest in being seen as pro privacy. But I get it, different conversation if the government coerces you, and the outcome depends on your bank account and ability to handle pressure. | ||||||||||||||||||||||||||||||||
| ▲ | p-e-w 4 days ago | parent [-] | |||||||||||||||||||||||||||||||
> Isn't this conflating encryption with trust? Absolutely, and the claim is somewhere between nonsense and pedantry bordering on nonsense. The exact same thing is true for, say, Signal. The provider delivers the client, and they aggressively block non-official clients from participating. So the “ends” in end-to-end are ultimately controlled by Signal. But as long as you trust the Signal company not to insert a backdoor into your client, it’s still true that the company can’t read your texts. | ||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||