Anonymity Lifecycle

Connect's privacy design is organized around four layers: identity (keypair-only, no PII), network (no IP traffic in offline mode), social (no global namespace; contacts know you only by a name you choose to share), and temporal (forward secrecy and optional message expiry). These layers do not hold equally at every phase of a relationship, and they mean different things depending on who the adversary is.

A distinction that runs throughout: Connect provides strong anonymity from strangers at every phase. Anonymity from contacts is not a design goal — contacts know you because you deliberately chose to meet them. The NFC tap is a voluntary de-anonymisation event between two people. Everyone else retains zero information.

This page traces each layer from the first NFC tap through BLE discovery, feed replication, the optional Tor relay, and key revocation, identifying where anonymity is structural (architecturally guaranteed), where it degrades (residual risk), and where it disappears by design.

Layer 1 — Identity Anonymity

A user's cryptographic identity is an Ed25519 keypair. No name, phone number, email, or other PII is required or stored by the protocol. The feed_id is SHA-256(identity_key.pub) — a stable pseudonym meaningful only to contacts who have already exchanged keys in person.

Residual risk: feed_id is a stable pseudonymous identifier across all messages. Any contact who obtains the feed can link all posts to that identity — this is by design. Structural mitigation: feeds are shared only with direct contacts; friends-of-friends replication is explicitly disabled.

Layer 2 — Network Anonymity

No network observer — ISP, backbone, relay operator — can determine who is communicating, when, or how often.

Structural guarantee in offline mode: there is literally no network traffic to intercept. A backbone-level adversary observing all IP traffic sees nothing. This is the core "never-online" design advantage — see Vision & Principles.

Tor mode degradation: the guard node learns the user's IP and that they run a Tor hidden service. Traffic correlation attacks (adversary controlling both the guard node and the destination) are probabilistic. Cover traffic reduces but does not eliminate this risk.

What breaks network anonymity entirely: routing traffic via a non-Tor internet path. Connect must not offer a direct relay fallback as a default.

Layer 3 — Social Anonymity

No global username namespace exists. Contacts know a user by a name they choose to share, or a name contacts assign locally. No directory, no search, no "people you may know".

Structural guarantee: because there is no central directory and no friends-of-friends replication, extracting the social graph requires compromising individual devices. Each device holds only its own local subgraph.

Residual risk — group membership: MLS groups are structurally visible to all group members. A member can enumerate other members, and group membership should be treated as sensitive data within the group boundary. Zero-knowledge group membership proofs for MLS are an open research problem.

Residual risk — contact introductions: the contact_introduction content type pre-stages cryptographic keys for a future physical meeting between two people. This does not bypass physical-first trust (the in-person exchange is still required), but it means a contact can learn that you know someone before the introduction completes — a partial social graph leak.

Layer 4 — Temporal Anonymity

An adversary who obtains a device or captures network traffic at time T cannot reconstruct communication history before T (forward secrecy) or reliably read messages after T (post-compromise security, restored on the next ratchet step).

Forward secrecy in practice: if a device is seized and the OS is not compromised, all messages whose chain keys have been deleted are unrecoverable — even to the device owner. This protection is unconditional for deleted keys.

What breaks temporal anonymity:

1. Device seized before chain keys are deleted — the pending receive queue is vulnerable. Post-compromise security restores protection only after the next DH ratchet exchange with the other party.
2. Unlocked device seized — the entire local database is readable. App-level SQLCipher encryption (keyed from a separate user PIN) is the defence-in-depth layer here.
3. Tombstones preserve chain integrity — the original envelope row is retained; only content_json is dropped locally. A seized device will show a placeholder entry. This is the correct trade-off between chain integrity and content privacy.
4. BLE chipset fingerprinting — clock drift and RSSI signatures are stable across MAC rotation intervals. A physically co-located passive observer with suitable SDR hardware can correlate a device's presence across rotation events. This is not patchable at the application layer; it is an accepted residual risk.

The Revocation Window

Key revocation is where all four anonymity layers are simultaneously stressed. When a device is stolen, the attacker holds the live keypair and can act as the user until every contact receives a revocation notice.

Device stolen → Attacker holds old keypair
      │
      ├─ Identity: attacker can impersonate until revocation reaches each contact
      ├─ Network: unaffected (revocation gossip is offline; no IP exposure)
      ├─ Social: attacker can read feed entries encrypted to old key
      └─ Temporal: forward secrecy protects deleted chain keys; pending queue readable

Revocation propagates via BLE gossip:
  Alice (new phone) → Bob → Carol (carries notice) → Dave
  Speed: bounded by human movement; sparse graphs have no delivery deadline

The race condition: the attacker can continue to publish feed entries and exchange messages with any contact who has not yet received the revocation notice. For groups, any member holding a valid revocation notice can unilaterally commit a Remove — but the attacker may submit harmful proposals before this happens. Speed of propagation matters.

What survives revocation:

• Forward secrecy on deleted keys: past messages remain protected even if the attacker holds the old private key.
• PQXDH protects against retroactive quantum decryption of ciphertext captured before revocation.
• New contacts made by the attacker via impersonation cannot be revoked retroactively — physical re-meeting is the only ground truth.

For the three-tier recovery model (BIP39 mnemonic, Shamir 2-of-3, guardian threshold), see Key Revocation & Recovery.

Properties Summary

Open Questions

• Is there a practical way to reduce the revocation propagation window below "as fast as human movement" — for example, by issuing each contact a signed delegation certificate that auto-expires and forces re-verification within a bounded period?
• Can contact-introduction messages be redesigned so the introducer does not reveal that they know both parties, while still pre-staging the cryptographic material for a future physical meeting?
• At what BLE rotation interval does the chipset fingerprinting attack (Becker et al., Tracking Anonymized Bluetooth Devices, PoPETS 2019) become impractical given realistic SDR hardware available to a non-state adversary?
• Is the "attacker active in group before Remove" race condition addressable by requiring a minimum quorum of members to acknowledge a revocation before a harmful MLS proposal can be committed?
• How should the app communicate the four anonymity layers to users in plain language — especially the difference between "anonymous from strangers" and "known to contacts"?