Modern demands on email privacy are exceeding its original design and are still growing even more enormous. This is morbid.

Let’s take a look at some certain use case: Alice created a banking/finance account (something similar to Revolut/Paypal), and her login credential are listed below:

username: alice@example.org
password: You1-Should9-Use0-A7-Password4-Manager2!

Alice was careless, she didn’t follow the best practice of backup and lost her KeePass database (or her Vaultwarden database, or she forgot master password, or the paper that she wrote passwords on). Unfortunately, this is the only copy of the above username/password combination, there’s no way to retrieve.

Nevertheless, Alice can reset her password by providing OTP sent to email address alice@example.org . That’s wonderful, isn’t it?

Well, that’s not a good idea, because OTP is transmitted in clear text email. There’s no insurance that only the sender and Alice could read the content. If Bob wants to access Alice’s bank account, which he is not permitted to, all he has to do is getting the email content and entering OTP before it expires (let’s say 30 minutes).

Email and SMS have never been built with such consideration. It’s generally a bad idea to use email or SMS as some kind of account recovery method or 2-step verification method.

Instead of coming up with something else, people start fixing email with the problem of storing and transmitting sensitive data in clear text. The transmission part is 90% done, as long as you force SSL/TLS instead of STARTTLS every handshake with mail server. But storing is a bit tricky.

Technically, if Alice doesn’t want to do anything, and her email provider, as well as the bank’s email provider, use SSL/TLS and encrypt the data at rest (the key is selected by the provider, we assume, since Alice doesn’t do anything), then Bob won’t be able to decrypt email from network traffic (that’s how TLS works) or hacking the provider’s machine.

Under some circumstances, this is more than enough. However, four entities still holds the ability to read the email. Ideally, only Alice and the bank should be able to read the email, but as both their email providers hold the encryption key, they could read them if they want to. In most cases, we could safely assume that Alice’s OTP doesn’t interest the provider. But they might still be interested in Alice’s financial situation, like which bank she is dealing with, how much money she spends each month for what purpose, and in which country she is. This is a big no for privacy advocates and pursuits.

With such concerns, PGP emerges, and evolves. Nowadays, the most widely accepted email end-to-end encryption standard is OpenPGP. The downsides would be quite clear:

  • Unless the sender is willing to do encryption, you can’t guarantee e2ee for the incoming email. That is to say, if Alice want to keep her banking emails private with OpenPGP, she has to reach out to the bank, provide them her public key and says “Please use encryption every time you send a report to email address alice@example.org “, and get refused.
  • Sender and receiver address remain in cleartext. I’m not sure if that would count as a downside, since you can’t send/receive any type of messages without an identifier. (But I’m still listing, since UUID or random numbers are less likely to be associated with a real identity of Alice than alice@example.org.)
  • Subject remains in cleartext. You use encryption, good. But “Subject: Your OTP is 123456” would just disclose everything (as far as I am concerned, WhatsApp does this).

To handle with the above problems,

  • Some email providers, for example, Tuta, ditched OpenPGP and refuses to be compatible with universal email protocols such as IMAP. The advantage is evident, they can encrypt subject now, but the cost is high - you have to use their email client (although it’s open source on each platform, free to use and does not contain trackers), which makes it a lock-in. The worst part is without OpenPGP, you can only do symmetric encryption if your correspondent isn’t on Tuta.
  • Milder workarounds would be SimpleLogin and Addy.io’s “Generic Subject” function when encrypting incoming emails, but you can’t pretend the clear text subject is non-existent on your correspondent’s mail server.
  • mailbox.org as well as Proton provides inbox encryption, this is technically the same as the second one, when you receive an email, the provider uses your public key to encrypt immediately (it’s kind of worth noticing that while SL, addy and mailbox doesn’t require your private key to do this, Proton would generate and manage the key pair for you, and there doesn’t really seem to be an option to encrypt incoming emails with only your public key uploaded. My experience on Proton is limited and if this got fixed in the future please kindly inform me), but this isn’t end-to-end encryption, and it would only be useful if you trust every entity that could access your email except your email provider (ironically, this is the real threat model for many people).
  • open.email looks forward to an email network over https, but can it really be called email if you can’t communicate with traditional protocol accounts?

Encryption enjoyers are very rare among all the email users, but those who rely on email for critical or sensitive information are the majority. Modern expectations for email include being an authenticator, a secret manager, a platform to issue invoice and pay for them, and so on. To satisfy all the exceedingly serious demands, more and more patches have been introduced, but non of them can be as convincing as email itself to forge an evolution. What would be waiting for us in the future of email?