Privacy by Promise, Privacy by Math

When we started building Pass It On we had to decide, early, what kind of relationship we wanted with the data inside it. Specifically: what kind of relationship we wanted to make possible.

The cheap answer is we promise we won’t read your stuff. Every consumer product says that. Most of them mean it, in the sense that nobody on the team is sitting down at a terminal at 3am reading the diary of a stranger. But “we promise” is a sentence, not a guarantee. The team turns over. The company gets bought. A subpoena lands on a Tuesday. Whatever the founders meant on day one, the capability to read your data lives forever, and capabilities tend to get used eventually.

The more honest answer — the one we picked — is to build the product so that we can’t read it. Not “won’t” — can’t. The data sitting on our servers is encrypted on your device before it leaves you, with a key we have never seen and have no way to derive. We could be served a warrant and the only thing we could hand over is ciphertext. The story your grandfather told about the watch stays unreadable to us, to a future buyer, to law enforcement, to a hypothetical bad actor who breaks in through some weakness we haven’t found yet.

This pattern has a few different names in the industry. Zero-knowledge. End-to-end encryption. Client-side encryption. They all mean roughly the same thing: the keys live with the user, the server only stores opaque blobs, and the engineering work is in making that feel as effortless as a normal app while keeping the math intact.

It is harder to build software this way. A lot harder. You can’t ship a feature that does fuzzy-search across users’ stories on the server. You can’t easily email someone a recovery link with a “click here to view your most recent entry” preview. You can’t have a customer-support workflow that involves looking at the user’s data to understand what they’re confused about. Every UX shortcut that involves the server reading user data is closed to you. You build a slightly more constrained product, and the constraint is the point.

We made the trade because of what this product is for.

The things people will put into Pass It On — the story of the ring, the reason the house was always quiet on the anniversary of the accident, the cousin nobody talks about — are the kinds of things people consider before telling their family. Asking them to also trust a startup with the same material is asking too much. The right answer is to not be in a position where that trust matters. The data should be unreadable to us by construction, so that the question of whether to trust us simplifies to do you trust the math? — and the math has been peer-reviewed for thirty years.

There’s a recovery mechanism, of course — a twelve-word phrase, generated on your device, that you write down and keep. That phrase is the key. Lose it, and the encrypted data is gone for good. We can’t help. We can’t help sounds like a bug; it is the feature. It is the same property that makes a court order useless against us. The recovery phrase is the only thing standing between you and your data, and it should be — because if there were a back door for us to use to help you, there would be a back door for everyone else, too.

A few practical consequences of this design that we want to be honest about:

Your password is not recoverable. We never see it. If you forget it, the twelve-word phrase is what restores access. Treat that phrase the way you would a deed.

We can’t preview your stories in emails. Our notifications will say “you have a new comment on an item”, not “Maria commented on the watch”. That’s not coyness; we don’t have the cleartext.

We can’t migrate your data into another product for you. If you want to export, you do it from a logged-in browser where the keys are in memory. We can hand you ciphertext; we can’t translate it.

Search runs on your device. Future search and AI features, if and when they exist, will run client-side on data the server can’t see. This is a constraint we’re choosing to live inside.

The shorter version of all of this is: we’d rather build a product that’s a little harder to use than one that requires you to trust a stranger with the parts of your life you trust the least number of people with. The trust we’re asking for is small and well-defined — trust the math, hold onto your phrase — and the kind we explicitly aren’t asking for is the kind that historically gets betrayed.

That’s the promise. We built it into the keys so the promise doesn’t have to do the work alone.