Sealed Sender

Sealed Sender is a metadata-reduction feature in Signal that removes the sender's identity from what the server can observe. End-to-end encryption already hides message content from the relay, but by default the service still sees who is talking to whom — and that social graph is often more revealing than the words themselves. Sealed Sender attacks that residual leak by letting a sender deliver a message without authenticating to the server in the clear, so the server learns the destination but not the origin.

How It Works

The analogy is physical mail: a normal letter shows both a sender and recipient address, but a sealed-sender message omits the return address. The true sender identity is encrypted inside the message envelope, where only the recipient's device can recover it; the outer layer the server handles carries no authenticated sender at all. To prevent this from becoming an open door for spam and abuse, delivery is gated by a token derived from the recipient's profile key, which is only shared with contacts and people the recipient has messaged — strangers cannot silently sealed-send you messages by default. A short-lived sender certificate, validated cryptographically by the recipient, proves the hidden sender is a legitimate, registered account without revealing which one to the server. The recipient's device decrypts the inner envelope, verifies the certificate, and displays the true sender as usual; from the user's perspective nothing changed except a small icon.

What It Does and Does Not Protect

Sealed Sender provides one-way anonymity at the application layer: the server cannot read the sender field. It is meaningful hardening, but it is not a full anonymity system, and treating it as one is a threat-modeling error. The server still necessarily learns the recipient and the delivery time. Network-level observers — or the server operator itself — can still correlate traffic by IP address and timing: if the same connection that just received a message immediately sends one, statistical correlation can re-identify likely conversation pairs regardless of what the envelope says. Researchers have demonstrated exactly this class of attack. Routing your connection over Tor or a trusted VPN addresses the IP dimension; the timing dimension is harder, and genuinely hiding it requires the heavier machinery of cover traffic and mix networks.

Where It Sits in the Privacy Stack

Sealed Sender is best understood as one layer in a defense-in-depth stack built on the Signal Protocol: content encryption hides what you said, Sealed Sender hides who said it from the relay, and network-layer defenses hide that you said anything at all. Each layer defeats a different observer. For most users, content encryption plus sealed sending against an honest-but-curious server is a huge practical win at zero usability cost. For threat models involving a global network observer or a compelled server operator, you need architectures designed for metadata-resistant messaging, up to and including a full mixnet.

The Sovereign Takeaway

The lesson generalizes well beyond messaging, and Bitcoiners should take it personally: encrypting content while leaking metadata is how most "private" systems fail in practice, whether the system is a messenger, a wallet broadcasting transactions from a home IP, or a miner's pool connection. Sealed Sender is a well-engineered example of chipping away at metadata within a pragmatic, mass-market design — honest about what it hides, explicit about what it cannot. Evaluate every privacy tool you depend on with the same question it answers so cleanly: not "is it encrypted?" but "who can still see the envelope?"

Practical configuration takes two minutes: Sealed Sender is on by default between contacts, and a setting allows receiving sealed messages from everyone if you accept the spam trade-off. Pair it with a network-layer shield — Tor, or at minimum a VPN you actually trust more than your ISP — and you have covered the two leaks that matter most for everyday threat models.