What we store

The privacy page has the exhaustive table. This explains the shape of it.

The rule we hold ourselves to

The privacy page claims to be complete: nothing is stored that is not listed there. A claim like that is worth exactly as much as the discipline behind it, so it is enforced by the build. Every table the application creates must have an entry in a manifest, and adding a table without declaring it fails the test suite.

You cannot verify that from outside, but you can read the test, because the code is open.

Metadata, not content

For a forwarding alias we record one row per delivery: which alias, which direction, whether it succeeded. Not the sender, not the subject, not the body. Those rows are deleted after a few days.

That is enough to show you an activity timeline and to notice an alias that has started bouncing. It is not enough to reconstruct who you talk to.

What is encrypted at rest

Encrypted, meaning a stolen database without the key is unreadable blobs:

Your forwarding addresses
Contact addresses and names
Alias notes and display names
Stored message subjects and bodies
Your recovery email and 2FA secret
Your real phone number, if you use phone masking

We have to be able to find things we cannot read. Looking up "which mailbox is this" needs an index, and an index over encrypted data usually means storing it in the clear.

Instead we store a keyed one-way value: HMAC(secret, salt + address). We can compute it when we need to match, and it cannot be reversed.

The salts are the interesting part. They are per scope, not global:

Mailbox lookups are salted per user
Contact lookups are salted per alias
Authorised sender lookups are salted per mailbox

The per-alias contact salt is the one that matters most. The same sender writing to three of your aliases produces three unrelated index values, so even with full database access nobody can tell those are the same person. Without per-alias salting, an alias service's contact table is a social graph.

What we cannot see

If you turn on the private inbox, stored messages are sealed to a key that never leaves your browser. We hold ciphertext we cannot open.

Logs

IP addresses are scrubbed from application logs by default, and web access logging is off. The one place a client address exists at all is a rate-limiting window in memory, and it is HMAC'd rather than stored as an address.

Something here wrong or missing? Tell us. These pages live in the same repository as the code, so a correction is a one-line change.