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?)
… 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.