How your anonymity works

DrBox exists to let clinicians speak honestly about their employers without losing their careers. This page explains — in plain language, not legalese — what the platform does and does not do to keep that promise. If anything here ever conflicts with the MANIFESTO, the MANIFESTO wins.

What we verify

To post a review, you prove you are a real credentialed clinician:

• Physicians, CRNAs, and other NPI holders — you enter your NPI. We check it against the public NPPES Registry over the network.
• Nurses (v1 launch, top 5 states) — state board lookup. Other states: manual license upload.

Your browser sends the NPI to our server. Our server sends the NPI to NPPES. NPPES never sees your IP — only our server's IP. We read back your specialty, state, and credential.

What we discard

The moment verification succeeds, the following values exist only in the server's request memory and are gone when the request ends:

• Your NPI
• Your name (if NPPES returned it)
• Your address (if NPPES returned it)
• The exact NPPES response body

None of this is written to our database, our logs, our backups, or our metrics. Subpoenaing DrBox for "who posted this review" returns — truthfully — "we do not have that data, because we built the system so we cannot have it."

What we keep

After verification we issue you two things:

1. A voucher. A short-lived signed token that proves you passed NPI verification. It says only "this session was verified" — it does not name the NPI. Valid for 15 minutes.
2. A Privacy Pass token. An unlinkable credential (per RFC 9576) you redeem when you post a review. The server signs the token without ever seeing the nonce you use to redeem it. Reviews carry the nonce as the identity handle, not your NPI.

We also keep the non-PII dimensions from your verification — specialty, state, credential — so review templates can be role-appropriate. These are stored against your anon_user row, not your name.

What we cannot protect you from

The architecture cannot rescue you from everything. In the spirit of the MANIFESTO, the honest list:

• Self-identification. If you write "I am the only pediatric-trained anesthesiologist at St. Elsewhere," we cannot un-name you. Review narratives carry this risk every time. We front-load warnings in the submission form and auto-screen for common patterns, but the final say is yours.
• Your login email provider. If you verify from an email account that is subpoena-able (work email, small personal provider), an adversary can compel that provider to hand over session cookies, login IPs, or timestamps that correlate to your posts on DrBox. Use a personal email you control.
• Browser compromise. If your device is surveilled, DrBox cannot hide your activity from whoever controls the device.
• Aggregate correlation. If you review ten facilities and each review narrows the set of people who could have written it, the intersection can identify you even without any leak. We limit this by publishing reviews as structured aggregates whenever possible.
• Illegal surveillance. Nation-state-level adversaries or unlawful interception are outside our threat model.

What we publish, no matter what

Per MANIFESTO §§2 and 4:

• Every moderation action (hide, restore, flag) is public. You can query our moderation log. We cannot quietly remove an inconvenient review.
• Every 90 days we release an anonymized aggregated dataset of all reviews and compensation reports under an open license. If DrBox goes away, the data survives.
• Our entire codebase is public. The code that discards your NPI is visible, auditable, and runs the production system. If we ever changed the discard behavior, the diff would be in the public commit log.

Visual diagram

How to verify any of this yourself

The code that implements every claim on this page is in the public repository:

• src/auth/verify-npi.ts — the NPI verification path and its explicit "no mirror, no persistence" comment
• web/src/pages/api/auth/verify-npi.ts — the HTTP endpoint; read the inline comments for what gets discarded
• docs/architecture/AUTH_FLOW.md — the full flow including log hygiene and compelled-logging posture
• docs/architecture/AGGREGATION_LAYER.md §C3 — reader-side protection (what we refuse to collect about how you browse)
• MANIFESTO.md — the commitments that bind us

If you find a gap between what this page says and what the code does, open an issue. That is how we stay honest.

This page is a P0 launch requirement per docs/product/MVP_SCOPE.md §"Privacy Transparency Layer" and MANIFESTO §7. Last revised: 2026-04-18. Copy authored with Ryan Schmoll, MD (operator); final wording subject to his review.