Unfortunately, you still need a level of trust with Proton. Even aside from trusting that they will not bend to pressure to terminate your service, you’re also trusting them with your network of contacts, because metadata (including the sender, recipient, and subject line) are not end-to-end encrypted in Proton.
Comment on Proton Mail Suspended Journalist Accounts at Request of Cybersecurity Agency
teawrecks@sopuli.xyz 17 hours agoFor the record, if your security is based on “trust”, you’re going to have a bad time. The whole point of a cryptographically secure line of communication is that you don’t need to trust anyone except the recipient. Protonmail users choose it specifically because they don’t trust anyone, including Protonmail.
GenderNeutralBro@lemmy.sdf.org 10 hours ago
teawrecks@sopuli.xyz 10 hours ago
That’s fair, though that’s more of a flaw with the email protocol. There’s no way around leaking that to the receiver’s email provider as well.
DragonTypeWyvern@midwest.social 14 hours ago
LMAO
teawrecks@sopuli.xyz 13 hours ago
Good point, I hadn’t considered that.
DragonTypeWyvern@midwest.social 10 hours ago
It is quite clear you haven’t put a lot of thought into it, but that’s okay
teawrecks@sopuli.xyz 10 hours ago
I sincerely apologize for taking you seriously. You tried to warn me with your alternating caps, so it’s my fault. Cheers.
DasSkelett@discuss.tchncs.de 8 hours ago
Except you’re still trusting a lot of people and systems there. Those that programmed, compiled and/or packaged your software in use (be it e.g. the cryptographic libraries themselves, the OS, random user space applications you are running that might be able to access your mail some way or another…), the hardware you use, the software, hardware and OpSec of the recipient…
The amount of people who have actually the resources, time and knowledge to eliminate all these points (i.e. reviewing the entire source code of all the software you use, and all the diffs of every new release you use, somehow check all the firmware blobs for your hardware or manage to get a fully de-blobbed system running and connected to the internet, and otherwise making sure your keyboard doesn’t sent a copy of every keystroke to “the enemy”, …) is very low. And the amount of people who actually do it might be zero? Not even a person in the NSA will have done all of this themself. They’re trusting some coworkers for some of these parts…
teawrecks@sopuli.xyz 6 hours ago
All of that can be publicly audited. When we talk about “trust” we’re referring to what happens server side, which we have to assume can never be publicly audited. The importance of e2e encryption is that what ever happens server side doesn’t matter. There’s a massive gulch between trusting a binary you’re able to inspect and trusting one you can’t.
What you said is valid though, if you want/need privacy, you need to put in effort, but you also have to assume there’s someone smarter than you who will be able to outsmart your own audit. The absolute best you can hope for is that at least the binary is publicly reviewable and that they’re not smarter than every pair of eyes who reviews it. That’s basically the backbone of open source security.