Anonymity vs Confidentiality: a Whistleblowing Threat Model

Anonymity and confidentiality are two different security properties, and a whistleblowing platform that uses them as synonyms is selling a promise it cannot keep. Anonymity means the reporter’s identity stays unobservable to the platform, to intermediaries, and to recipients, which operationally requires a Tor onion service v3, the Tor Browser on the reporter’s side, and reporter-side discipline against forensic traces. Confidentiality means the reporter accesses the platform over a regular browser; the ISP, the employer network, or a CDN can log the connection, while the platform encrypts the content, restricts recipient access, and limits what the logs record. Both are valid, and the right default depends on context: corporate compliance programmes usually default to confidential with anonymous opt-in via Tor, whereas human-rights initiatives and investigative newsrooms default to anonymous.

Key Takeaways

• Anonymity and confidentiality are different security properties, not synonyms.
• Anonymous mode requires a Tor onion service v3 plus reporter-side discipline.
• Confidential mode protects content but not connection metadata.
• Recipient credential theft is the dominant insider threat in confidential mode.
• The platform must show the reporter their current mode at all times.

What is the difference between anonymity and confidentiality?

Many readers arrive on this page precisely because the two terms have been used interchangeably in vendor copy for years. A formal split between the two (connection-level anonymity on one axis, operational confidentiality on the other) is the right starting point, and it is the framing the rest of this post borrows.

Anonymity is a technical property. The reporter’s identity stays unobservable to the platform, to intermediaries, and to recipients. The canonical mechanism is the Tor Browser plus an Onion Service v3 endpoint. No IP address reaches the platform, no DNS request leaves the reporter’s machine for a public resolver, and no third-party request fires from the page.

Confidentiality is an operational property. The reporter’s identity may be technically observable by intermediaries (their ISP, their employer’s network, a transparent proxy, a CDN in front of the platform), while the content of the report is protected by access controls, encryption at rest, and recipient discipline. The platform restricts who can read the content and stores no plaintext.

A useful refinement crosses these two axes with a third one, identity disclosure to recipients. A reporter can be:

The platform’s job is to surface the current state to the reporter in plain language (“you are accessing this site anonymously over Tor”, or “you are using a regular browser; the operator can see your IP address”) so the reporter can make informed disclosure choices. When the platform leaves the mode ambiguous, the reporter ends up acting on a false security model.

What does anonymous mode defend against?

Anonymous mode covers five threats.

Network-side observation comes first. ISP logs, employer-network deep packet inspection, public Wi-Fi captures, transparent proxies, captive portals, and DNS resolvers that log queries all stand between the reporter and the platform. A direct connection to a Tor onion service v3 defeats them for connection metadata; an external observer sees Tor traffic to a Tor relay, never a request to the whistleblowing platform.

Recipient subpoena or compulsion is another. A platform that runs onion-only access has no IP addresses, login times, or geolocation to disclose, because Tor onion connections do not carry them. A subpoena for IP logs returns an empty set because the data was never collected in the first place, which is a stronger guarantee than refusing to comply with the subpoena.

Browser fingerprinting is handled by the browser itself. Tor Browser standardises user-agent strings, blocks third-party requests by default, disables canvas and WebGL fingerprinting, restricts font enumeration, and resists timing-based correlation. A platform that embeds Google Analytics, a third-party CDN, or a webfont call from a public CDN undoes those protections without telling the reporter.

Image: Wikpan / Wikimedia Commons, CC-BY-SA 4.0

File-metadata leakage is the next threat. Photographs carry EXIF data with GPS coordinates and camera serial numbers. Office documents carry author fields, edit history, and template paths. PDFs carry creation timestamps and the producing application’s version. A platform serious about anonymous mode strips metadata on attachment ingestion or warns the reporter clearly if it does not.

Forensic traces on the reporter’s own machine (browser history, swap files, temp directories, antivirus quarantine) close the list. They are mostly a reporter-side discipline, and the platform should remind the reporter that highest-stakes reporting belongs in a Tails live-USB session that writes nothing to disk.

Image: DerekTDR / Wikimedia Commons, CC-BY-SA 4.0

What does confidential mode defend against?

Confidential mode protects a different threat surface, and a platform that defaults to confidential is offering a calibrated answer to a context where the reporter accepts their ISP and employer network as outside the threat model. It covers five threats.

Insider abuse on the platform side is stopped by per-recipient encryption (so each recipient unlocks only the reports addressed to them), separation of duties between admin and recipient roles, role-based access control on case data, and audit logs that record actions rather than content. An admin should be unable to read a report; a recipient outside the receiving team should be unable to read a report addressed to a different channel. The seven cooperating components of a whistleblowing platform lay out which boundary owns which protection in this stack.

Recipient credential theft is, in practice, the dominant insider threat in confidential-mode deployments because it is where plaintext finally exists. The defences are unglamorous: two-factor authentication on recipient accounts, password complexity rules, slow-login backoff against brute force, and password-recovery procedures designed for forced rotation rather than self-service email reset.

Against database extraction, an attacker who breaches the data store without compromising the application server pulls only ciphertext. The encryption design that makes this work is documented in the post on encrypting whistleblower reports with SealedBox and SecretBox.

Log over-collection is a separate threat, and confidential mode is incompatible with audit logs that store plaintext “for investigability”. The right shape of audit trail records who acted on what report at what time; the report’s text never enters the log.

Retention overreach is the last of them. Confidential mode does not exempt the platform from per-artifact retention timers. Old data leaks if it survives past its retention window, and a 90-day default for closed cases is a sensible starting point that can be adjusted upward only for documented investigative reasons.

When is each mode the right default?

A usage-scenarios matrix maps four deployment archetypes to a combination of anonymity, identity disclosure, and communication-security level. The mapping is opinionated:

For corporate compliance, picture a Fortune-500 multinational with HinSchG, Sapin II, and SOX 806 and Dodd-Frank exposure running an internal-audit team as recipients. Recipient identities are disclosed (employees know who runs the channel), reporter identity is optionally disclosed (the reporter may choose to identify themselves to access faster acknowledgement and personalised follow-up), and the default access path is HTTPS with anonymous-via-Tor as a clearly visible opt-in. This combination matches what the EU Whistleblower Directive requires; the EU Directive 2019/1937 technical checklist maps the article-by-article requirements, and the HinSchG, Sapin II, and PIDA platform mapping covers the tenant-switch shape that satisfies all three at once.

For a human-rights initiative in a dangerous context, picture an NGO collecting reports from a country with active retaliation. The deployment runs anonymous-by-default via Tor onion v3, recipients use pseudonyms, and identity disclosure is rare and only with explicit reporter consent. The MUST-anonymous default is non-negotiable here because the alternative is real-world physical risk to the reporter.

For an investigative-journalism outlet, anonymous is the default. Recipients are named journalists with public identities so reporters can choose whom to trust, and the platform’s reputation and the journalist’s source-protection record count for as much as the technical controls.

For a citizen-media or community-ethics initiative, the risk profile is medium-low and lower entry barrier is what drives participation. Confidential default with a clearly visible “anonymous mode (Tor)” link is the right calibration. A reporter who wants the stronger property has a one-click path to it; a reporter who does not is no longer blocked by a Tor-installation tutorial.

How does the platform expose the current anonymity status to the reporter?

UX is a security control. When the reporter does not know which mode they are in, they fall back on guesswork and either over-share or under-trust the channel.

A persistent indicator goes on every page: a banner, a corner badge, or a coloured stripe that reads “you are accessing this site anonymously via Tor” or “you are using a regular browser; the operator can see your IP address”. The wording is plain language, never icons alone, and visible without scrolling.

A pre-submission summary screen is the last line of defence against an accidentally identified submission. Before the reporter clicks the final submit, a confirmation page restates the anonymity mode, names who can read the report, and explains what the receipt code means and how to store it.

Receipt-code presentation deserves its own deliberate UX. The receipt is the reporter’s only handle on the case. Phone-number-shaped formatting (groups of four digits) lets reporters store it among contacts, and the platform should explain this pattern explicitly rather than dump a 16-character blob.

Mid-session mode changes need a warning. If the reporter switches from Tor to clearnet (for example by following an external link and returning via a regular browser), the platform should warn that the anonymity property has changed and offer a path back through the Tor onion address.

Error states have to fail safe. When Tor onion access is unavailable, the platform should fall back to a “you are not anonymous” warning instead of degrading to clearnet without telling the reporter.

A three-question decision tree for picking the default

If the matrices feel abstract, three questions collapse them into a Monday-morning answer.

1. Does the reporter need to be hidden from network observers (ISP, employer, state-level surveillance)? If yes, anonymous mode is required. The Tor onion service v3 is the only way to deliver this property.
2. Does the reporter need to be hidden from named recipients (insider threat, cross-team gossip, recipient credential theft)? If yes, confidential mode is required regardless of the answer to question 1; anonymous mode strengthens it without replacing the per-recipient encryption and access-control discipline that confidential mode demands.
3. Is the platform self-hosted in the right jurisdiction, with unnecessary logs stripped and a stated retention policy? If no, anonymous mode is the only defensible default, because confidential mode depends on operational discipline the platform cannot prove it has.

The mappings shake out cleanly: yes-yes-yes points to anonymous-default; no-yes-yes points to confidential-default with anonymous opt-in; no-no-no means the platform is over-scoped for the threat model and a simpler intake (a monitored mailbox, a published phone line) is the right answer.

FAQ

• Threat-Modeling
• Tor
• Encryption
• Compliance