Calling Proton Mail “E2EE” is pretty questionable.
Yeah. The original article addressed the issue but buried the lede. Will update:
Old: Proton Mail stores your emails e2ee. … (Later warning) Most of your email can still be read in transit by the authorities. If two Proton Mail emails communicate, they automatically use e2ee. However, if e.g. a @gmail.com address sends you something, the content will be plainly visible to the authorities.
New: Proton Mail stores your emails E2EE. If two Proton Mail email addresses communicate, they automatically use E2EE in communicating with each other. However, if e.g. a @gmail.com address sends you something, the content will be plainly visible to the authorities while in the sender’s account (if they seize the data) and during transmission. Once received, Proton encrypts it in your mailbox, but the government could have already intercepted it in transit.
.
Not only do they handle the plaintext of most of your mail
IMO—Not Proton’s fault, just how email works sadly. I also warn that most emails will be read by authorities via other access points.
they also provide the code you use to handle the plaintext of all your mail.
Yes, but the code is open source and independently audited. I don’t see why I should call this out as a trust deficiency in particular.
I think there are probably occasions when even relatively normal people should be using Tor or I2P, rather than a trustful VPN like Proton or Mullvad. [And, on edit, there is some risk of any of those being treated as suspicious in itself].
Yeah, I agree. I’m adding a section on Tor.
I’d be careful about telling people to keep a lot of cash around. Even pre-Trump, mere possession of “extraordinary” amounts of cash tended to get treated as evidence of criminality.
Thank you. I’m now planning to advise that people keep a small amount of cash (< $2,000) in a fireproof safe with receipts of legitimate withdrawal. High-risk individuals should ultimately consult with asylum experts.
Yes, but the code is open source and independently audited. I don’t see why I should call this out as a trust deficiency in particular.
… which is as good as it gets in most cases. I am not saying I have a better alternative for most people.
But the thing is that supply chains are hard. When you use Proton webmail, do you actually verify that the JavaScript they serve to you is actually the same JavaScript they had audited? Every time? And make sure it doesn’t get changed somehow during the session? If you use the Proton proxy, do you actually rebuild it from source at every update? Even with reproducible builds (which I don’t know whether they use or not), how many people actually check? Another person’s checking does add some value for you, but there’s a limit, especially if it’s possible to guess who will check and who won’t.
Worse, how many “normal” people can actually check? How many can even keep all the issues straight in their minds? Lots of professional programmers get simple PKI issues wrong all the time. PKI is a strict subset of what you have to worry about for supply chain.
So, yeah, you can use that stuff, but by the time you get to the point where you’re actually getting much assurance out of the source code access or the audits, I think it’s more complicated than self-hosting a mail server (which I’ve done for probably about 30 years). Of course, with self-hosting your deliverability goes to hell, and you’re still relying on an incredible amount of software, but you get some protection from the sheer chaos of the environment; it’s usually not so easy for the Bad Guys to actually get the data back reliably and inconspicuously, especially for untargeted surveillance.
If I added hedges about every similar possibility of supply chain attacks due to e.g. non-formally verified build signatures, the guide would grow bloated for reasons outside the comprehension and threat model of the vast majority of my readers. So while I agree with you about the possibility, I don’t think it’s relevant for me to note in the text. (Maybe you agree?)
Yeah. The original article addressed the issue but buried the lede. Will update:
.
IMO—Not Proton’s fault, just how email works sadly. I also warn that most emails will be read by authorities via other access points.
Yes, but the code is open source and independently audited. I don’t see why I should call this out as a trust deficiency in particular.
Yeah, I agree. I’m adding a section on Tor.
Thank you. I’m now planning to advise that people keep a small amount of cash (< $2,000) in a fireproof safe with receipts of legitimate withdrawal. High-risk individuals should ultimately consult with asylum experts.
… which is as good as it gets in most cases. I am not saying I have a better alternative for most people.
But the thing is that supply chains are hard. When you use Proton webmail, do you actually verify that the JavaScript they serve to you is actually the same JavaScript they had audited? Every time? And make sure it doesn’t get changed somehow during the session? If you use the Proton proxy, do you actually rebuild it from source at every update? Even with reproducible builds (which I don’t know whether they use or not), how many people actually check? Another person’s checking does add some value for you, but there’s a limit, especially if it’s possible to guess who will check and who won’t.
Worse, how many “normal” people can actually check? How many can even keep all the issues straight in their minds? Lots of professional programmers get simple PKI issues wrong all the time. PKI is a strict subset of what you have to worry about for supply chain.
So, yeah, you can use that stuff, but by the time you get to the point where you’re actually getting much assurance out of the source code access or the audits, I think it’s more complicated than self-hosting a mail server (which I’ve done for probably about 30 years). Of course, with self-hosting your deliverability goes to hell, and you’re still relying on an incredible amount of software, but you get some protection from the sheer chaos of the environment; it’s usually not so easy for the Bad Guys to actually get the data back reliably and inconspicuously, especially for untargeted surveillance.
If I added hedges about every similar possibility of supply chain attacks due to e.g. non-formally verified build signatures, the guide would grow bloated for reasons outside the comprehension and threat model of the vast majority of my readers. So while I agree with you about the possibility, I don’t think it’s relevant for me to note in the text. (Maybe you agree?)
Yep.