Writing promises is easy. Noticing where a promise says more than the product can do is harder. We look for these places on purpose: catching ourselves is unpleasant, but better us than our readers. Here are five we found before publishing.
The rule
Before we publish a promise, we check it against how the product is built. And again and again we find places where the words say more than the design. Then we change the words or the design, and we don’t hide the gap.
Each case has the same format: what we wrote, what we write now, and why.
Five cases
Invites: we fixed the words twice
- Before. At first we wrote that we would not know who invited whom.
- First fix. Checking showed that the server would see whom it issues a code to. The honest version was only “we won’t keep it”, so that is what we wrote.
- After. Then we changed the design. We won’t know who invited whom. The invite code will be created on the inviter’s device, and our server will certify it blindly, without seeing the code, so it can’t link the code to the person who issued it or to the person who uses it.
- What remains. The server will see when an account takes an invite and when someone uses one. If hardly anyone else takes or uses invites around that time, the link could be guessed from timing.
Account deletion: we changed the design, not the words
- Before. Your account will be deleted right away.
- After. Deleting your account won’t take effect at once: after 72 hours if you have a device you signed in on more than a week ago, and after 7 days if you don’t. Until then you can cancel it, and your mail keeps arriving. It takes effect at once only if you confirm it with your recovery phrase or a passkey with account recovery turned on.
- Why. Nobody will be able to take a deleted address on a Methmail domain again, not even you: otherwise its new owner would get someone else’s email, including password resets from other services. But then anyone who learned your password could delete your account and take the address away for good. The delay gives the owner time to notice and cancel. It is shorter where there is an old device: a hijacker with the password can only start fresh sessions, and the owner will have time to stop them from the old device when opening Methmail.
The search index
- Before. The search index will be only on your devices.
- After. The search index will be built on your devices. If a copy of it is ever sent to our servers, it will be sent only encrypted with your keys.
- Why. We plan a copy of the index for syncing devices, and the word “only” would stop being true once it appears. So we write a condition, not a promise. The limits of our encryption are under What Methmail won’t be able to do.
Spam filters
- Before. The filters will keep nothing.
- After. They will keep none of the content: only the verdict, spam or not, will be kept.
- Why. Without that verdict, a message can’t be put in Spam.
“Retroactively”
- Before. This cannot be done retroactively.
- After. What we won’t keep can’t be obtained retroactively. But what hasn’t been deleted yet we will be able to hand over: mail to other providers without PGP still in the send queue (up to 48 hours) and technical logs within their retention periods.
- Why. The send queue and the logs have a lifetime, and until it runs out, the data exists.
What it costs us
- Fewer big words. Where we would like to write “never” or “only”, we write what will actually happen.
- Caveats sit next to promises. Not in small print at the bottom, but in the same line or paragraph.
- On this site we talk about encryption in the future tense, even after launch, as long as there is no published audit.
What’s next
From the first publication, fixes like these will show in the inventory change log on the Privacy page, with a date and a reason.
The inventory is on the Privacy page, and what Methmail won’t be able to do is listed on the Security page.