> In fact, in the daily traffic, as described above, a large percentage of emails is sent “in plain text” without the adoption of cryptographic solutions that p

> In fact, in the daily traffic, as described above, a large percentage of emails is sent “in plain text” without the adoption of cryptographic solutions that protect the content of each message. I would not expect this to be true. TLS adoption is not universal (and it would be nice to make it so), but I don’t believe it’s that far off it. This hop-by-hop encryption protects the traffic from all but your own email service provider. Yes, I am misconstruing the article’s intent, which seems to be talking about end-to-end encrypted message content, so that your email service provider can’t see it either, but what it actually says here is just flatly wrong. The messages are sent encrypted (conditions apply), and promptly decrypted by the receiving mail server, so that it can do useful stuff with it rather than just treating it as an opaque blob. The article completely fails to note the harsh compromises that must be made if you want to further encrypt messages with PGP or S/MIME or whatever. For most people, the most obvious one is that any form of webmail is crippled and you lose all server-side search, meaning that you need to fetch all the mail locally and index it locally. This is normally infeasible for phones. Fastmail explains the compromises well in this article on why they don’t offer PGP: https://fastmail.blog/advanced/why-we-dont-offer-pgp/ https://fastmail.blog/advanced/why-we-dont-offer-pgp/. It boils down to (a) it crippling the service, and (b) not actually being useful anyway, because first-party encryption is pretty much unavoidably broken. Most of what ProtonMail sells as privacy in their encrypted messages stuff is snake oil, plain and simple. As long as they provide the software that holds the keys, they can obtain those keys (this is a style of attack Fastmail refers to in that article—though Fastmail assumes you’d send the key with each request, rather than the email service provider being just a blob store and decryption happening on the client, but changing the code makes exfiltrating that trivial). This is a systemic failing of first-party encryption in the presence of automatic software updates (which is the default on almost all platforms, and fundamental to the web). The only path to real success requires that the platform and the encryption provider be distinct. To ProtonMail’s credit, they have done at least some pushing in the direction of what’s essentially reproducible builds for the web, so that clients can actually reliably detect when something’s changed (subresource integrity is a starting point, but insufficient as it doesn’t protect the top-level resource). I don’t think anything has actually come of it (it’s a fairly tiny niche that there’s not much interest in), but they are trying. (Disclosure: I worked on Fastmail’s webmail in 2017–2020. I do not believe this has significantly influenced my position on these matters, save that my opinions are better informed than they were before; but I already saw and understood the problems of first-party end-to-end encryption. I find Fastmail’s position in this matter to be eminently reasonable and well-expressed.)