Privacy Guardian got accounts this week. Designing them raised a question most products never have to ask out loud: what is the least an account can be made of?
The product finds people on data broker sites and helps them get removed. Its customer list is, by definition, a list of people who believe they are hiding from someone. A leaked mailing list is bad for any company. For this one it would be a betrayal of the exact thing people paid for. So the account system was built to hold as little as possible, and to make what it holds useless on its own.
No password
Sign-in is a link sent to your email. There is no password to choose, reuse, forget, or have cracked.
The link carries a random 32-byte token. The database stores only a hash of it. That means a copy of the database cannot be used to sign in as anyone: the hash does not reverse into the token, and only the token works. The row is deleted the moment the link is redeemed, so a link works once, and it expires after fifteen minutes whether or not anyone clicked it.
Comparing the presented token to the stored hash happens in constant time, so a wrong guess takes exactly as long as a right one and leaks nothing through timing.
The email is stored, but not readable
An account needs an email address. That is the one piece of personal data it keeps, for two reasons: to send the sign-in link, and to reach someone about their subscription.
It is not stored in the clear. Each user row carries two things derived from the address:
A blind index. An HMAC of the normalized address, keyed with a secret the server holds. Same address, same output, every time. Not reversible. This is the lookup key: when you type your email to sign in, the server computes the HMAC and finds the row that matches. It never has to compare against a readable address to do that.
The encrypted address. AES-256-GCM, so the server can decrypt it when it genuinely needs to send you mail. Each user has their own data key, and that key is itself encrypted with the master key. Losing one user's key exposes one user.
The result is that a database dump is a list of opaque hashes and ciphertext. Without the master key, which lives in the server environment and never in the database, it is not a mailing list. It is not anything.
One deliberate non-decision inside this: the normalization is only lowercase and trim. No stripping of dots or plus-tags. Two addresses their owners consider distinct stay distinct, even if a mail provider would deliver them to the same inbox.
No session table
Once you are signed in, the session is a signed cookie. It contains your user id and an expiry, with an HMAC signature over both.
Nothing about it is secret, so it is not encrypted. It is tamper-evident: change the id or the expiry and the signature fails. Forge one from scratch and the signature fails. There is nothing to look up on the server, which means two things. Every request skips a database round trip, which matters on serverless where each request may be a cold start. And there is no session table to leak, because there is no session table.
The cookie is httpOnly, so a script on the page can never read it, and sameSite=lax, which is the setting that survives the click from an email link while still blocking most cross-site requests.
What a dump actually contains
Worth being concrete, because "encrypted" gets said about a lot of systems that are not.
If someone obtained a full copy of the users collection, they would have, per account: a hex string that is the HMAC of an email, a blob of ciphertext, an encrypted data key, a creation date, and some preferences. They could not recover any email address. They could not sign in as anyone. They could not forge a session. The scan results themselves are sealed separately and deleted after ninety days by a database-level expiry rather than a job someone has to remember to run.
What they could do is count how many accounts exist. That is the residue. Everything else needs the master key, and the master key is not in the database.
Why write this down
Because the guarantees only mean anything if they are stated precisely enough to be checked. "We take your privacy seriously" is not a claim. "The database stores an HMAC and a ciphertext, and here is why neither reverses without a key it does not contain" is a claim, and anyone can read the code and verify it.
That is the standard the product is trying to hold itself to, and it is the standard a privacy tool has to meet to deserve the name.