What you have to trust

Any security tool moves trust rather than removing it. Here is exactly where it moves it to.

"Trust us" is not an answer. This page sets out, specifically, what you are relying on when you believe a badge — and what you are not.

What you do NOT have to trust

The server your plugin talks to

Your plugin does not ask a server "is this sender verified?" and believe the answer. It fetches signed records and checks every signature itself, on your machine. A server that lies produces records that fail verification, and a failed record is treated as absent — never as a weaker yes.

A hostile or broken server can therefore withhold a badge. It cannot create one. That asymmetry is the design.

Your mail provider

For an encrypted message, they carry a sealed block. They cannot open it, and neither can we. For a signed message they can read it as before, but they cannot change a word without your recipient being told.

Us

Your keys are made on your device from your recovery phrase and are never transmitted. We never receive them, so there is nothing for us to lose, hand over, or be compelled to produce. The clients are open source, so this sentence is checkable rather than merely stated.

What you DO have to trust

The software you installed

Unavoidable, and true of everything on your computer. A plugin that verified nothing and drew a green badge anyway would look identical from outside. What you can do about it: the source is public, the downloads are built from it, and the clients send no telemetry, so anyone with the skill can check the claim rather than take it.

Honestly: the downloads are not yet code-signed, so your operating system cannot confirm they came from us. That is a real gap, not a formality.

Your own device

Your private key lives there. Software on your computer that can read your files can read your key. No mail tool can fix that.

The validators, for badges specifically

A mailbox proof is issued by a gateway — the server that mails the confirmation code and checks the reply. Which gateways may do that is decided by the network's validators, and the list of validators is built into the plugin you installed, not fetched.

So a "verified" badge rests on: those validators only authorising honest gateways, and those gateways only issuing a proof to whoever actually answered the code. If a validator authorised a dishonest gateway, that gateway could vouch for mailboxes it does not control.

This is the same shape as the certificate authorities your browser trusts, with the same weakness and one difference: the list is small, fixed at install time, and visible in the source rather than in a store of hundreds you have never looked at.

That the mailbox is still theirs

A proof says someone controlled that mailbox when it was made. It expires, and it is re-checked — but between two checks an account can be sold, taken over or handed to a successor. The new key warning is what covers the common version of that.

Where the current design is weaker than it should be

Two things, stated because you should hear them here rather than discover them:

• A message is not bound to its recipient. The signature covers the sender, the subject and the text. It does not yet cover who it was sent to, so a genuine protected message could in principle be re-sent to somebody else with its proof intact. Its words and subject would still have to be the original ones, so this cannot produce a message the sender never wrote — but it is a gap, and closing it is the next piece of work.
• Attachments are not signed. Only the message body is. If the contents of an attachment matter, describe them in the body: that text is covered.

← All documentation