The limits of banning in an anonymous system (position)
Status: Position doc (2026-07-01). Owner: Mechelle. Companion to the sealed-identity canon (SEALED_IDENTITY.md, SEALED_ACCOUNT_BAN_FLOW.md, SEALED_BAN_RECONCILIATION_SPEC.md). Why this exists: so our banning limits are a stated, defensible position with the governance fence noted next to it, not folklore that gets rediscovered in every conversation.
The one line: the ability to permanently ban a person is the same capability as durably identifying a person. Lantern deliberately cannot do the second, so it cannot do the first. That is a chosen property, not a shortcoming.
1. The theorem
ELI5: To ban someone forever, you have to be able to recognize them forever. Recognizing them forever is exactly the thing our privacy design refuses to do. You can have unlinkable anonymity or permanent person-bans, not both.
A permanent ban of a person requires a durable, unspoofable link to that person. That link is precisely what "identifying a person" means. Anonymity and permanent-person-banning are the same lever pointed in opposite directions: our sealed-identity work (seal phone↔UID, lose-don't-leak, no server-recoverable backdoor) is the guarantee that we cannot durably identify you, which by construction means we cannot permanently ban you either. This is true of any anonymous system, not a Lantern-specific gap.
2. Why every cheap anchor fails
ELI5: Everything we could pin a permanent ban to is either throwaway or the exact thing we refuse to keep.
| Anchor | Why it can't carry a permanent person-ban |
|---|---|
| Phone number | A lease. Recyclable and changeable; new number, they're back. (See reclamation spec.) |
| Free and unlimited. | |
| userId | New account, new id. |
| Device fingerprint | Spoofable and changeable; also §9.4-fenced and anti-anonymity (see §3). |
| Payment method | One of the few hard-to-mint anchors, but §9.4-fenced, and users don't pay Lantern (merchants do). |
| Government ID / biometric | The only thing that truly anchors a person, and the maximal opposite of what Lantern is. Collecting/retaining it is the durable PII the whole product exists to not hold. |
3. Device fingerprinting and behavioral signals: fenced and off-thesis
ELI5: The "just track the device / watch their behavior" approach is both formally off-limits for us and against everything the app stands for.
- Governance fence. Layers 2-5 of the original ban spec (device fingerprinting, behavioral, social-graph, payment-method) are blocked pending Mission Arbiter review per Cofounder Agreement §9.4 (see the header of
bannedAccounts.service.js). Do not add them without governance approval. - Fingerprinting is a re-anonymization vector. It builds a persistent identifier that follows a device across sessions, the exact durable link the sealing work destroys. Adding it would undo with one hand what we seal with the other.
- Behavioral needs surveillance. It requires the server to watch what users do, but chat is E2EE (the server can't read messages, so abuse evidence is user-submitted) and the data posture is "hold as little as possible."
4. Would a native app help?
ELI5: A native app gives better device tools, but the wall is device-is-not-person, and that wall is the same height on native. It helps at the margins (bots, key security), not at the thing you'd actually want (permanent person-bans).
Native gives real device-integrity primitives web can't have (researched 2026-07-01, Apple/Google docs):
- A device flag that survives a factory reset (iOS DeviceCheck = 2 bits; Android Play Integrity Device Recall = 3 bits). Web can't do this.
- An anti-bot / anti-tamper floor (App Attest, Play Integrity verdicts) that kills emulators and scripted signups.
- Hardware-backed key storage (Secure Enclave / StrongBox).
But:
- Device is not person. Every one of these is defeated by a second phone (a ~$40 used handset is a fresh slate). Google says Play Integrity "doesn't have built-in banning mechanisms"; Apple's DeviceCheck is "devices only, not individuals." Best case is raising the cost of return, not permanence.
- Anonymity costs specific to us. These require Google Play Services / Apple's stack, which ropes "anonymous" users into Google/Apple identity graphs and excludes privacy-conscious users (GrapheneOS, de-Googled, sideloaded; GrapheneOS actively campaigns against attestation). A device flag also rides a resold phone to its innocent next owner (the recycled-number problem, one layer down). Rolling our own fingerprint violates Apple's developer agreement and is GDPR "personal data."
- The genuine native win is elsewhere: hardware-backed key custody strengthens the E2EE/PIN/sealed-identity story with no anonymity tax (a pure positive), plus an optional bot floor. Neither is a person-ban.
Reframe: web-vs-native is not the axis that decides permanent person-bans. Anonymity-vs-identity-verification is. The only thing that permanently bans a person (KYC / ID / biometric) is platform-independent.
5. What Lantern uses instead
ELI5: Our accountability anchor isn't the device, it's the venue. You have to physically show up somewhere, and staff can act on someone who's there.
- Venue presence is the friction other apps approximate with fingerprinting: you can't be everywhere at once, and it comes with a human escalation path (venue staff, the in-venue safety note).
- User-submitted reports are the only abuse evidence E2EE allows.
- Cost of return: a banned person loses their account, frens, and history, and needs a fresh (time-boxed, see reclamation spec) number each time.
- The most durable ban Lantern has is human and real-world: venue staff can physically refuse and trespass someone. The app can't make a digital ban follow a person, but a bouncer who recognizes them can.
6. The honest cost
ELI5: Yes, this means a determined person can eventually come back. We accept that as the price of anonymity, and we pay it down with moderation and venue accountability instead of tracking.
Ban evasion is genuinely harder to prevent than on a surveillance-heavy platform. That is the deliberate trade for anonymity, and the defense is behavioral/venue moderation plus the friction of losing everything, not a tracking net. Claiming we can permanently keep a person out would be false.
7. Comparing to Signal (guidance for how we talk about it)
ELI5: Don't say "better than Signal." Say the one specific true thing: we don't keep a link between your number and your identity.
- Not "better encryption." Signal's protocol (the Double Ratchet) is the gold-standard benchmark. Lantern uses Matrix's Olm/Megolm (audited vodozemac), chosen for licensing (Signal's
libsignalis copyleft, incompatible with a closed-source app), not because it's stronger. See CHAT_ENCRYPTION.md. - Not "more private overall." Signal is broader and far more battle-tested (sealed sender hides the social graph; minimal retention; a decade of audits). And Lantern is a venue app, it handles physical-presence data Signal never touches, so on location metadata we are strictly less minimal.
- The defensible, differentiated claim (about unlinkability, not encryption): Signal's server knows your number maps to your account; ours is designed so even we can't. Ship it once the residuals are closed.
- One-liner: "Your number verifies you; it never identifies you."
- Or plainly: "Even we can't connect your phone number to your account."
8. Governance
ELI5: The big "should we ever be able to permanently ban a person?" question isn't an engineering call, it's a founder/Mission-Arbiter one.
The §9.4 fence (device / behavioral / social-graph / payment-method banning) stands until Mission Arbiter review. Any move that would enable permanent person-bans, chiefly an opt-in identity-verification tier (verified users can be permanently banned; anonymous ones can't), is a Cofounder-Agreement-level decision with large privacy tradeoffs, not something to add quietly. This doc is the place to record that decision if it's ever made.