Solve the trust issue, and privacy falls out for free

In 1999, researchers gave twelve people ninety minutes to sign and encrypt a single email using PGP 5.0, software they had chosen precisely because its interface was good by the standards of the day. Four of them managed it. Three sent the secret they were meant to protect in the clear, believing they had encrypted it.

That was more than twenty-five years ago, and the striking part is how little it moved. PGP had already shipped in 1991. S/MIME has been built into corporate mail clients for decades since. The cryptography was never in question, and it still isn't: the algorithms are sound, the implementations are mature, and the software is free.

But almost nobody uses it. The usual explanation is that people do not care about privacy, and I think that explanation is both unfair and wrong.

The ask was the problem

Here is what selling privacy directly actually asks of a person.

Do some work now. Understand what a key is. Generate one. Keep the private half secret and safe, hand the public half to your correspondent, and don't mix the two up. Then get your correspondent to do all of the same, before you can exchange a single useful message. In return you receive a benefit you cannot see, against a threat you cannot name, at a time you cannot predict.

The follow-ups are unusually blunt, starting with their titles. Seven years later, Sheng and colleagues found key management no easier, and encryption by then so invisible that people could not tell whether a message they received had been encrypted at all. In 2015 a study of Mailvelope, a PGP client built directly into webmail, put twenty people to work in pairs: one pair in ten completed the task. That paper is called Why Johnny Still, Still Can't Encrypt.

These were motivated participants, in a lab, being asked to do the thing on purpose, with researchers watching.

People are not failing an intelligence test. They are declining a bad trade, correctly. The work is immediate and certain; the benefit is abstract and deferred. Anyone would decline it.

Meanwhile around nine in ten emails now travel encrypted in transit, and that happened precisely because it asked users for nothing at all. That is the whole lesson, and the industry mostly took the wrong half of it: not "people want less security", but "security that requires a process does not get followed".

Trust asks a different question

Now consider the question people do answer, dozens of times a day, without any prompting:

Who is this, and do I want to hear from them?

Nobody has to be taught to care about that. It is not abstract, it is not deferred, and there is no threat model to understand first. You already do it manually every time you look at a sender name and decide whether to open something. You do it badly, because your mail system gives you almost nothing to do it with, but you do it.

So it is a question worth building a protocol around. Not because trust matters more than privacy, but because it is the one people will actually engage with.

And here is the part that makes it interesting

The machinery that answers "who is this" turns out to be the same machinery that encrypts.

To verify a sender, your client has to resolve their address to a published identity record and check the message signature against the key in it. That record does not only contain a signing key. It contains the sender's encryption key too, published in the same place, resolved by the same lookup, verified by the same chain.

Which means that the moment you can answer "who is this", you are already holding everything you need to seal a message that only they can open. You did not ask for that. You did not configure it. It arrived as a side effect of the question you actually wanted answered.

Encryption stops being a feature. It becomes a happy byproduct.

What that changes in practice

Because it is a byproduct, nobody has to opt in. There is no encryption setting in DMCN, because a setting implies a decision, and every decision is a place where adoption goes to die. Mail between DMCN addresses is sealed because sealing it is the cheapest thing to do once the keys are already there.

The keys are generated in your browser and stay there. They are non-extractable, meaning the browser will use them to sign and decrypt but will not hand the private bytes back to any code, including ours. We operate no key store on our servers, so in ordinary use there are no keys of yours on our side to lose.

One exception, which belongs in the text rather than in a footnote. Adding a second device is the single moment key material crosses the network. The new device mints a throwaway key, you type the last four digits of the code it shows into your existing device, and that device seals a copy of your keys to that throwaway key and leaves it in a mailbox for the new device to collect. We carry that copy and cannot open it, because the key it is sealed to was generated on your new device and never reaches us. The new device deletes that copy as soon as it has adopted the keys, and because that delete is best effort rather than guaranteed, the one-time address it waits at expires within fifteen minutes. It is still the one moment an encrypted copy of your keys sits on our side, and we would rather name it than have you find it. The other route is an encrypted backup file you export from one device and import on another, which keeps your keys off our servers entirely. The new device still has to be approved by one you already use, or, if you have none left, wait out a recovery period that your other devices could cancel.

You will notice that none of this asked you to understand a key. The 1999 study failed not because the participants were incapable but because the software made key management their job. It should never have been anyone's job.

What it does not cover

Beyond DMCN. Mail to and from the rest of the world crosses a bridge into SMTP, and on that side it is ordinary email: protected in transit, not end to end. There is no version of talking to a system from 1982 where that is otherwise, and anyone claiming otherwise is describing a portal you have to log into, not email.

Delivery metadata is not content. Our relays cannot read a message, but they do handle it, which means they see who sent it, which key it is addressed to, and when. What sits inside the sealed header is the part worth having: the subject, the full recipient list, the thread it belongs to, the attachment count and the preview line, none of which a relay can read, and all of which are cleartext at every hop on ordinary email. That is a real difference and a narrow one, and it is worth stating narrowly.

Your keys are genuinely yours, with everything that implies in both directions. Add a second device and the keys move to it under your control, verified by a code you check on both screens.

But the key is the weakest link in all of this, and that is worth saying plainly rather than burying. Lose every device with no second one paired, and there are real limits to what anyone can do for you. Your mail was sealed to that key and stays sealed. And we cannot hand your account to someone who asks us for it, which protects you right up until the person asking is you.

So keep a second device paired or export an encrypted keystore file from Settings and put it somewhere safe. That is the whole of the backup story, and it takes about a minute.

The short version

Privacy has been sold as a product for twenty-five years and has barely moved. It was never going to work, because it asked people to do something for a reason they could not feel.

Trust is a question people are already asking. Answer that one properly and the encryption comes along on its own, on by default, invisible, and requiring nothing of anyone. Not because we were generous with it. Because once you know who someone is, keeping the message between the two of you is the easy part.