Here's a problem that sounds impossible. A messaging app can't read your end-to-end encrypted messages — that's the whole point. But when someone receives a threat or illegal content and hits "report," the platform needs to verify the report is genuine before acting on it. How do you prove what an encrypted message said without ever giving the server the ability to read it? The answer is a clever piece of cryptography called message franking.
Content moderation and end-to-end encryption look like irreconcilable opposites, and that tension drives most of the political fights over encrypted messaging — including proposals for client-side scanning that would undermine encryption entirely. But there's a narrow, important problem hiding inside the broad debate, and it actually has a clean cryptographic solution: not "let the platform scan everything," but "let a recipient who chooses to report a specific message prove to the platform exactly what was sent, without the platform being able to read anything else."
That's message franking, sometimes called verifiable abuse reporting. Facebook introduced it for Messenger's secret conversations in 2017, and Facebook cryptographers Paul Grubbs, Jiahui Lu, and Thomas Ristenpart formalized the security properties in an academic paper the same year. It's a quietly elegant answer to a question that's usually argued about in bad faith.
The Two Requirements That Seem to Conflict
A workable reporting system for E2EE has to satisfy two properties that pull against each other:
- Accountability — if Alice reports a message from Bob, the platform must be cryptographically certain that Bob really sent exactly that message. Otherwise Alice could frame Bob by reporting something he never wrote.
- Confidentiality — the platform must learn nothing about any message unless and until a recipient voluntarily reports it. No standing ability to read, scan, or decrypt.
Naive approaches fail one or the other. If the recipient just forwards the plaintext to the platform, there's no accountability — Alice typed it herself, so it proves nothing about Bob. If the platform keeps a decryption key, there's no confidentiality. Message franking threads the needle with a commitment.
How Franking Works
The mechanism rests on a cryptographic commitment — think of it as a sealed, tamper-evident envelope. The scheme uses a committing authenticated-encryption construction, in practice built from an HMAC, that produces a tag binding the exact message content.
Walking through a single message:
- Sender commits. When Bob sends a message, his app computes a commitment to the plaintext (an HMAC under a random per-message key) and includes it alongside the encrypted message.
- Server franks. The platform's server signs that commitment — adding its own tag over the commitment plus metadata like a timestamp and the sender's identity — and passes it along. The server never sees the plaintext; it's signing the sealed envelope, not its contents. This signature is the "franking tag," the term borrowed from postal franking marks.
- Recipient verifies. Bob's app reveals the per-message key to Alice's app as part of normal delivery, so Alice can open the commitment and confirm it matches the message she actually received. The system is now armed: Alice holds a message plus a server-signed proof of its authenticity.
- Recipient reports (optionally). If Alice reports the message, she sends the plaintext, the commitment, the revealed key, and the server's franking signature back to the platform. The server checks its own signature (proving it franked this exact commitment) and re-opens the commitment against the plaintext (proving the plaintext matches what was committed). Both checks passing means the message is genuine.
The key insight: the server signs a commitment to the message without seeing the message. Later, a recipient who chooses to report can open that commitment and prove the plaintext matches what the server already vouched for. Verification happens only when a human decides to report — never preemptively, never in bulk.
What Franking Does and Doesn't Give You
| Property | Status |
|---|---|
| Server can read messages preemptively | No — confidentiality preserved |
| Recipient can frame the sender | No — commitment binds exact content |
| Reported message is provably authentic | Yes — server signature + commitment |
| Reporting requires recipient consent | Yes — recipient initiates |
| Sender can deny to third parties | Depends on deniability design |
The Limits Worth Being Honest About
Message franking is genuinely useful, but it is not a moderation panacea, and it interacts with other security properties in ways that deserve plain statement.
It only covers content a recipient chooses to report. Franking does nothing about messages nobody reports — it's a verification tool for voluntary reports, not a scanning system. That's a feature, not a bug, but it means franking can't satisfy demands for proactive detection. Anyone claiming franking lets platforms "find all the bad content" is misunderstanding it.
It's in tension with deniability. Deniability — the property that you can't cryptographically prove to an outsider who sent a message — is something protocols like Signal's deliberately provide. Franking creates a server-signed artifact tying a sender to content, which cuts against deniability. Designs handle this by scoping the proof carefully: the franking tag convinces the platform within its own reporting flow but is constructed so it doesn't transfer into a general-purpose, court-usable proof of authorship. Getting this boundary right is subtle, and it's where franking schemes most often go wrong.
It requires trusting the server to frank honestly. The server must actually sign commitments and not, say, refuse to frank certain messages or backdate timestamps. Franking constrains what a misbehaving server can do, but it doesn't make the server irrelevant — it shifts trust to a smaller, more auditable surface.
The lesson of message franking is that "encryption versus safety" is often a false binary built to justify the wrong fix. Specific, narrow problems frequently have specific, narrow cryptographic solutions that don't require tearing down end-to-end encryption for everyone.
Why This Matters for the Encryption Debate
The political pressure on encrypted messaging usually frames the choice as binary: either platforms can moderate content (and therefore must be able to read it) or they offer real encryption (and therefore can't help with abuse at all). Message franking is a standing counterexample. It shows that a thoughtfully designed system can give victims a real, verifiable reporting path without handing the platform a master key — which is exactly what client-side scanning and "exceptional access" proposals would do.
This is the same design philosophy behind modern group messaging protocols and metadata-minimizing techniques: don't accept the framing that safety requires surveillance. Look for the cryptography that gives you the specific property you actually need. The hard problems are real. The claim that solving them requires breaking encryption usually isn't.
Originally published at havenmessenger.com
