Almost every piece of software starts the same way: by asking who you are. Name, email address, often a phone number, sometimes a profile photo. Over the last twenty years, we’ve come to accept handing over a dossier as the price of admission for using an app.

It isn’t a technical requirement; it’s just an industry habit. One reasonable product decision at a time — an email for password resets, a first name for the greeting banner, a phone number for two-factor codes — compounded into a reflexive default. Individually, each field made sense. Together, they mean your real identity is replicated across hundreds of databases you have to hope will never be breached, sold, or subpoenaed.

Protection vs. non-collection

When a software company talks about privacy, they usually mean protection: “We encrypt your data at rest and in transit. We are SOC 2 certified. We never sell your information.” Those commitments matter — but they all start from the premise that the company holds your data.

A stronger posture starts one step earlier: not having your data in the first place. You cannot lose, leak, or be compelled to hand over what you never collected.

Serious systems need both. But while protection is a security discipline, non-collection is an architectural choice.

The privacy ladder

Every application sits somewhere on a five-rung ladder:

  1. Full identity. Name, email, phone number, IP logs, and behavioral analytics. Encrypted on disk, perhaps, but fully legible to the operator.
  2. Minimization. Collecting fewer fields — “only what we need” — though in practice, the line between what a product needs and what the marketing team wants tends to blur.
  3. Pseudonymization. Real identifiers are replaced with opaque tokens. The link back to a human identity is either discarded or held by a separate party, so the app operator cannot see who you are on their own.
  4. True anonymity. Even with full database access and external cooperation, the operator cannot tie an account to a person. Far rarer than marketing pages claim.
  5. Unobservability. Not even the fact that a given person used the service at a given time can be reconstructed. Tor and mixnets live here; almost no commercial software does.

Climbing each rung carries a trade-off. Stepping from 1 to 2 costs you growth-marketing funnels. Stepping from 2 to 3 breaks standard customer support (“What’s the email on your account?”). Stepping from 3 to 4 eliminates account recovery, billing reminders, and security alerts — every workflow that assumes the app can tap the user on the shoulder.

For everyday software serving normal users, the richest design space sits around Rung 3. The engineering question is simple: how far up that ladder can you climb before the trade-offs actually hurt the user?

A case study in pseudonymous login

Here is how we approached this on botchat, a workspace for querying multiple AI models side by side. From the user’s perspective, signing in looks completely ordinary: you click “Sign in with Google” or “Sign in with Apple” and you’re in.

The difference happens on the server the moment that login completes. When the identity provider returns its response, our server takes the provider’s unique account ID, runs it through a keyed cryptographic hash, and immediately discards the rest of the payload — name, email address, profile photo, everything. All our database ever writes down is that irreversible hash and a creation timestamp. That is the entire user record.

Active sessions use a short-lived token in a strict, first-party cookie. Chat histories stay in the user’s own browser storage, never on our servers. Uploaded documents are processed in volatile memory and never touch a disk. By design, the server has no idea who its users are.

To be rigorous, this is Rung 3 — pseudonymous, not anonymous. Google or Apple still knows you signed in. And if an attacker ever stole both our database and our secret hashing salt, they could link a hash back to a Google subject ID if they already had it. Being candid about those boundaries matters more than slapping an “anonymous” badge on the landing page.

In product terms, the trade-offs are real but surprisingly painless. We don’t send password-reset emails (OAuth handles credentials). We can’t send “new login from an unfamiliar device” alerts. We can’t run drip-marketing campaigns when a user goes quiet, because we have no inbox to email. And support never starts with “What’s the email on your account?” We traded all of those away on day one — and it turns out we haven’t missed any of them.

Pushing past Rung 3

What would it take to climb even higher? Each step further trades a bit more convenience for a bit more blindness:

  • Blind the identity broker. Apple’s Private Relay and anonymized OAuth proxies mask the user’s identity or destination so neither the broker nor the app gets the full picture.
  • Device-bound passkeys. Instead of routing logins through Google or Apple, the user authenticates with a cryptographic keypair stored in their device’s secure enclave. The server holds only a public key — no email, no identity provider in the middle. The catch: if a user loses their devices without a synced keychain, we cannot recover their account.
  • Zero-knowledge credentials. Using blind signatures or zero-knowledge proofs, a user can prove they hold an active paid subscription without revealing which subscriber they are — separating billing identity from product usage entirely.
  • Dropping network metadata. Stripping IP addresses and user-agents at the edge before logs are written. Most teams carefully scrub emails from logs while unwittingly recording a user’s home IP address on every request.

None of these choices is free. The right engineering question isn’t “What is the most extreme privacy architecture possible?” It’s “Which of these trade-offs would our users actually feel, and which ones would only inconvenience our marketing team?”

Inverting the default

Spend enough time designing this way and you notice that most software starts from the wrong baseline. Teams collect everything by default, then ask, “Is there any reason to delete this field?” Since a field might always be useful someday, the database only grows.

A better discipline starts at zero and asks of every single field: “What breaks for the user today if we don’t know this?” Sometimes the answer is legitimate — you cannot ship a physical package without a street address. More often, the honest answer is that nothing breaks at all.

Treat your users as strangers, and design your systems so they can remain strangers. Usually, you can. And when you think you can’t, the feature demanding their identity is often one you didn’t need to build anyway.