"You might be missing the point a little bit. You're correct, but end-to-end encryption is irrelevant if the operator changes the (e.g., Javascript) code in a w

"You might be missing the point a little bit. You're correct, but end-to-end encryption is irrelevant if the operator changes the (e.g., Javascript) code in a webmail app and maybe even just for a single user." Which is why, as I have said elsewhere, webmail is the problem here; more generally, you cannot have security or privacy as a service. As for the government pushing back doors into products, that is at least upping the ante. It is harder to sneak back doors into software that people are actually using, especially software that is widely used, than it is to sneak a back door onto a server than only a handful of people can inspect. It is also harder to sneak in a back door when there are many, separately maintained implementations of a common protocol; you are forced to try to sneak a back door into an abstract description, which a lot of experts will be reviewing (see e.g. DUAL_EC_DBRG; the backdoor was discovered within a year of the PRNG being publicized). There are also limits to what sort of back doors can be put at a lower level. Suppose you sneak a back door into my CPU, but I am running software that was developed after you developed your back door. You can make a straightforward computability argument that in general, your back door will be rendered useless by unexpected changes to software, particularly sweeping changes to it. In any case, my point is not that encryption is a panacea, but rather that webmail is, by its nature, insecure. There was no way that Lavabit's security could have ever been more than just a handwave.