You cannot be compelled to hand over what does not exist
Policies and promises matter less than system boundaries. If the product never stores personal identity, breaches, subpoenas, and internal misuse all have less to work with.
Anonymity by design
Build without identity.
Most products say they respect privacy while still collecting email addresses, phone numbers, recovery paths, and behavioral logs. That is still possession. A stronger model is to avoid knowing who the user is in the first place and operate on a random account number instead.
Built around the idea that a service should operate on anonymous continuity rather than personal identity, with random account number as the implementation pattern.
- You cannot leak what you never collected
- Support cannot reveal what it cannot know
- Business logic can run without personal identity
Privacy theater
- phone number
- full name
- password reset path
- identity correlation
Random account number architecture
- random account number
- entitlements
- passkey or credential proof
- minimal service state
- purpose-limited audit events
Protection is weaker than minimization
Traditional security assumes you will collect sensitive data and defend it forever. An anonymity-first design removes much of that attack surface by not collecting identity data at all.
Email is usually the trapdoor back to identity
The moment an account depends on email recovery, the system has a durable way to tie service activity back to a person. That may be acceptable for regulated products, but it is not anonymity.
Tradeoffs are real and should be stated honestly
If the user loses the only credential that proves continuity, recovery may be impossible by design. That is not a bug in the model. It is the cost of a system that does not know who the user is.
Implementation example
A random account number turns the argument into a system
The role of a random account number is to give the backend a stable handle for account state without collecting the user’s private identity.
Reference: rehacktive/unknown_id
-
1
User proves continuity without revealing identity
A passkey, random credential, wallet, or device-bound secret shows that the same account holder returned, without asking who that person is.
-
2
The system derives or assigns a random account number
The identifier is stable inside the product, meaningless outside it, and unsuitable as a real-world identity handle.
-
3
Business logic attaches to the opaque ID
Purchases, quotas, feature access, and preferences are linked to the random account number. The service can operate normally without names, inboxes, or phone numbers.
-
4
Recovery is limited on purpose
Support does not fall back to “prove it’s you with your email” because that would reintroduce identity. The system is safer precisely because staff cannot override anonymity so easily.
Signup to login and verification flow
An identity-free account model from signup through authentication and request verification.
flowchart TD
A["Client: signup or first use
nickname or device proof
no email or phone"] -->|POST /users| B["Backend: create anonymous account"]
B --> C["Store account state
internal_id
public_id
empty profile shell"]
C --> D["Bind credential
passkey, wallet proof,
or device secret"]
D --> E["Persisted account record
anonymous account number
credential verifier or pubkey
prefs, quotas, purchases"]
E -. "Not stored" .-> F["email
phone
legal name
identity recovery inbox"]
G["Returning user
login with credential"] -->|POST /auth| H["Backend verifies challenge or proof"]
H --> I["Map proof to anonymous account"]
I --> J["Issue signed token
expiry + scoped claims"]
K["Protected request
Authorization: Bearer token"] -->|POST /verify| L["Verify signature and expiry"]
J --> K
L --> M["Read public_id and entitlements"]
M --> N["Allow or deny request
without real-world identity lookup"]
Data protection
Minimization becomes enforceable, not aspirational
If personal data never enters the core account model, retention, access requests, breach disclosure, and internal access control all become simpler. There is less sensitive context to govern.
Security
The blast radius of compromise is smaller
Attackers can still target infrastructure, but a table full of opaque IDs and service state is materially less valuable than a dataset full of contact details and identity signals.
Privacy
The company has less power over the user
If there is no email reset path, no phone checkpoint, and no support-led identity matching, the service has fewer ways to correlate activity back to a real person.
UX
The UX is lighter upfront and stricter on recovery
Onboarding can skip forms and identity rituals, but users must treat credentials seriously. A product can be simpler to enter and less forgiving to lose.
Old assumption vs anonymity-first default
Many products collect identity because legacy account design assumes they should, not because the service actually needs it.
Common assumption
Privacy-first alternative
Every account needs personal identity
Every account needs continuity, not identity
Support should be able to verify the person
Support should only see service state and limits
More user data is always better for the business
Purpose-limited data is often enough to run the business
Privacy is mostly policy language
Anonymity is a property of the system design
Can this still work for paid products?
Yes. Billing can be handled by a payment processor while your application stores only the resulting entitlement state against the random account number. The core product does not need to keep private billing identity to function.
What is the main tradeoff?
Recovery is weaker by design. If you want staff to restore access through identity checks, then the system has to know more about the user. If you want stronger anonymity, recovery must be limited and explicit.
Does anonymity mean invisibility or impunity?
No. Infrastructure still emits network signals, abuse still exists, and systems still require security controls. The point is narrower: the company should not hold unnecessary identity data just because it is convenient.