> There's really no comparison between the two scenarios. Hacking the MIT server or distros to replace the GPG code is an incredibly noisy attack.. What percen

> There's really no comparison between the two scenarios. Hacking the MIT server or distros to replace the GPG code is an incredibly noisy attack.. What percentage of the packages you use in a production deployment are GPG signed? I think the minority. > On the other hand, forcing an email provider to colaborate is standard legal practice (Lavabit), you have a perfect selector (the email address of the target), there is no tripwire, and getting the key will permit you to decrypt al past and future communication. Once the user closes the browser, the evidence is gone. Easy as pie. This is totally irrelevant to the current conversation. As it was discussed protonmail uses client-side crypto with PGP signed messages -- meaning the only thing they store is your encrypted keys. Yes, if Protonmail could be forced to serve passphrase stealing javascript then your encrypted keys would be vulnerable - but so would you if Debian was forced to serve a keylogger as a kernel module. btw I do agree that SSL is a much higher-risk factor than a linux-system with a local mail-server using PGP - but I don't see a better alternative than something like protonmail for the majority of consumers.