When you send a Signal message, the server has to do two things: receive the ciphertext from you, and route it to the recipient's device. The recipient's identity has to be visible to the server for delivery to happen at all. That seems like an unavoidable cost — until you ask whether the sender's identity needs to be visible too.
Signal's answer, introduced in 2018, was no. The result is sealed sender — a system where the server can deliver a message to its recipient without learning who sent it. It doesn't solve metadata exposure entirely, but it changes the shape of what the server can record.
What the Server Used to See
Before sealed sender, a typical Signal message envelope contained, in plaintext to the server:
- Sender identifier (account UUID)
- Recipient identifier (account UUID)
- Timestamp
- Encrypted payload — the actual message content
The payload is opaque, but everything else is metadata. A motivated adversary with server access — or with legal compulsion against the server operator — could build a complete graph of who communicated with whom and when. That graph is often more sensitive than the message contents themselves. Knowing that a particular phone number messaged a journalist's number at 3am, repeatedly, for two weeks before a leak appeared, is often all the evidence anyone needs.
Metadata-based deanonymization doesn't require breaking encryption. It requires only correlating communication patterns with external events — something an adversary with subpoena power, network observation, or just access to server logs can do trivially.
How Sealed Sender Works
The sealed sender protocol changes the envelope structure. Instead of including the sender's identifier in cleartext, the sender encrypts a wrapper containing their identity to the recipient's public identity key. This wrapper is then sent inside a second envelope addressed only to the recipient.
From the server's perspective, the message becomes "deliver this opaque blob to user X." There's no field that says who sent it. The recipient's client unwraps the outer encryption, learns who the sender claims to be, and verifies that claim against the Signal Protocol session that produced the inner message.
The naïve version of this scheme has an obvious problem: spam. Without sender identification at the server, anyone could flood the network. Signal solves this with delivery tokens — short-lived credentials, signed by the server, that authorize a sender to deposit messages without identifying themselves. The server verifies the token (proving the sender is a legitimate Signal user in good standing), but the token itself doesn't reveal which user it belongs to.
What Sealed Sender Protects
Sealed sender narrows the metadata that an adversary with server access can collect. Specifically, after the protocol is in effect, the server no longer routinely logs:
- Who sent each message (sender UUID)
- The pairwise sender-recipient relationship for individual messages
This matters because it constrains what can be turned over under legal compulsion. Signal's documented response to subpoenas has historically been "the account creation date and the last connection date" — and that's because the company has architected their system so they genuinely don't have more to give. Sealed sender deepens that posture.
What Sealed Sender Does Not Protect
Sealed sender is not anonymity. It's a narrower property: sender unlinkability at the message-delivery layer. A passive adversary with broader observation capabilities can still recover the sender in several ways.
Network-level observation
Sealed sender hides the sender from Signal's server, not from anyone watching the network. If an adversary sees your IP address connect to Signal's servers and upload a message-sized blob, then thirty seconds later a message-sized blob arrives at a known recipient, the correlation is straightforward. This is a traffic analysis problem, and sealed sender is not designed to address it.
Recipient compromise
Once a message reaches the recipient's device, the sender's identity is recovered (otherwise the message couldn't be displayed in the right thread). If the recipient's device is compromised — by malware, by physical seizure, by a forensics tool — the sender is exposed.
Long-term traffic patterns
Even with sealed sender, the server still sees that user X received N messages at specific times. Combining that with externally-observed events — when a journalist published a story, when a protest organizer's account became active — can narrow the candidate sender set substantially. The protocol blurs individual messages but not long-term patterns.
Delivery token analysis
The delivery token system requires that legitimate users acquire tokens periodically. A server that wanted to deanonymize a specific user could in principle issue them distinguishable tokens (a tagging attack) or correlate token issuance and use. Signal mitigates this with batched, rotating tokens, but the threat is not eliminated.
How It Compares to Other Approaches
| System | Hides Sender From Server | Hides Recipient From Server | Resists Traffic Analysis |
|---|---|---|---|
| Standard E2EE chat | No | No | No |
| Signal sealed sender | Yes | No | No |
| Cwtch / Ricochet (Tor-based) | Yes | Yes | Partially |
| Mixnet (Nym, Loopix) | Yes | Yes | Yes (designed for it) |
The pattern is clear: stronger metadata protection generally comes at the cost of latency, complexity, or both. Mixnets add seconds-to-minutes of delay by design. Tor-routed messengers don't scale to billions of users. Sealed sender is a pragmatic middle ground — significantly better than nothing, well short of full anonymity.
Should You Care About This?
The honest answer depends on your threat model. For most users worried about everyday surveillance — corporate data harvesting, ad-driven tracking, casual snooping — message-content encryption is already the dominant protection, and metadata-level adversaries are not in scope.
For users whose threat model includes a state-level adversary with legal compulsion or network observation capability — journalists protecting sources, activists in repressive contexts, lawyers handling sensitive matters — metadata protection becomes critical. In those cases, sealed sender is a useful layer, but it should not be the only one. Pair it with Tor, with disposable identities, with operational security around when and how you communicate.
"We don't have the data because we never collect it" is a stronger position than "we have the data but we encrypt it." Sealed sender is an architectural choice in service of the first position.
Where Haven Stands
Haven uses the MLS protocol for group messaging, which has its own approach to metadata: group operations are authenticated by signature keys distinct from long-term identity keys, and the protocol's design intentionally limits what the server needs to know about group membership transitions. For 1:1 messaging, Haven does not currently implement sealed-sender-equivalent semantics — it's on the list, and we'd rather ship it correctly than market it prematurely.
The broader point: any service that claims metadata protection should be able to describe specifically what metadata they're protecting and from whom. "Privacy-focused" is not an answer. Sealed sender is a useful template precisely because Signal's documentation describes exactly what it does and what it doesn't.