Metadata Resistance

What "metadata-resistant" means in practice

A messenger is metadata-resistant if a network observer (server, ISP, cloud provider, lawful intercept) cannot answer questions like:

The leading metadata-resistant designs sacrifice features (search, push notifications, group scale) for these properties.

The designs

SimpleX

The most architecturally radical. No user IDs. Pairs of users share a queue ID on a relay (SMP server). Alice and Bob each connect to the queue server via separate one-way connections; the server sees two anonymous connections, not "Alice ↔ Bob".

Properties:

• No user identifiers. Just per-relationship queue IDs.
• Unidirectional queues. Sender and recipient connect separately.
• Optional Tor for full IP anonymization.
• Push notifications via separate notification servers, also without user IDs.
• Multi-server by default; queues split across operators.

Trade-off: contact discovery is out-of-band (QR code or one-time link). No global directory.

Session

Forked from Signal, dropped phone numbers. Uses onion requests through its service-node network. Identity is a public key (05XXX… Session ID).

• No phone, no email.
• Onion requests separate the originating client from the destination node; the entry node still sees the client connection.
• Mailbox-based delivery. Recipient pulls; sender pushes to a swarm of nodes hosting the mailbox.
• Onion-routed message envelopes.

Trade-off: smaller user base, less audited than Signal.

Cwtch (Tor-only)

Tor v3 hidden services as the entire transport. No central server, no message storage, peers must be online to deliver in real time.

• Tor v3 client auth. Only authorized peers connect.
• No accounts, no servers.
• Async via "untrusted infrastructure" — message queueing nodes are blind, just hold ciphertext.
• Open Privacy Research Society project.

Trade-off: synchronous-only without untrusted infra; tiny ecosystem; battery hungry on mobile.

Briar (P2P + Tor + offline)

Built around adversarial network conditions. Three transport modes: Tor, Bluetooth and local Wi-Fi. No servers at all.

• Direct peer-to-peer. No infrastructure.
• Forum / blog model for groups.
• Designed for journalists and activists in repressive regimes.

Trade-off: peers must be reachable (online over Tor, or physically nearby). Async via "Briar Mailbox" — a separate device that holds messages while peers are offline.

Status / Waku v2

DApp-friendly P2P messaging over libp2p with relay-style propagation. Full nodes hold message queues; light nodes use Discovery and ephemeral identities.

Comparing mechanisms

True timing-attack resistance still requires constant-rate cover traffic. Only Loopix-derived mixnets (Overview - Mix Networks) and academic systems (Vuvuzela, Pung) provide it for messaging.

What even the best systems don't hide

• Endpoint compromise. Malware reads everything. Hardware security modules and runtime attestation help; software E2EE alone does not.
• You being a user. Even SimpleX needs some network presence at SMP servers; an adversary at your ISP knows you talk to SimpleX servers.
• Your contacts in non-adversarial settings. Real-world graphs (people you actually talk to in person) leak through phone records, photos, and posts.

The honest framing: metadata-resistance reduces leakage to specific adversaries. There is no "perfect anonymity for messaging" in deployed software.

Composing for maximum privacy

Endpoint:    OS hardened, FDE, biometric or hardware key for unlock
   ↓
App:         SimpleX, Session or Briar (different identifier models)
   ↓
Transport:   Tor or the application’s onion-routing transport
   ↓
Identity:    Per-relationship keys; rotate; don't link to clearnet identity
   ↓
Backups:     Local encrypted; never to cloud

For ultra-high-stakes work (whistleblowing, journalism in repressive regimes), the recommended stack is Tails OS (amnesic) + Tor + (Cwtch or SecureDrop for source-journalist contact, depending on async needs) + an air-gapped device for handling content.

Trade-offs summary

Strengths

• Drastically reduces server-visible information.
• Resists subpoena. Servers literally don't have the data.
• Supports pseudonymity by design. Phone-number registration is impossible.

Limitations

• Discovery is hard. No directory means out-of-band contact establishment.
• Push notifications are tricky. True push requires some identifier; clever workarounds exist.
• Smaller user bases. Network effects favor mainstream apps.
• No multi-device E2EE history sync in some systems.
• Battery cost from always-on Tor / mixnet routing.

Attack surface

Primary sources

• SimpleX Messaging Protocol
• Vuvuzela: Scalable Private Messaging Resistant to Traffic Analysis
• Pung: Unobservable Communication over Fully Untrusted Infrastructure
• Cwtch security design
• Briar protocol specifications
• Session cryptographic design
• Briar: transports and peer-to-peer synchronization

For the specific technique of hiding when and how much you send, see Cover Traffic and Constant-Rate Padding.

Compare identifiers, delivery services and exposed metadata in Choosing a private messenger, including Delta Chat, XMPP with OMEMO and Jami. For submission workflows, see OnionShare and SecureDrop.

Continue with Mobile location privacy.

Also in Anonymity Networks