Privacy advice often arrives as a shopping list: install a particular browser, buy a particular device, use a VPN, move to an encrypted messenger, or publish through a hidden service. Some of those tools may be excellent. None can tell you whether it solves the problem you actually have.

A threat model is the short explanation that comes first. It identifies what needs protection, who or what could cause harm, how that harm might occur, how serious the consequences would be, and what constraints shape the response. NIST describes threat modeling as a form of risk assessment. The Electronic Frontier Foundation makes the same idea practical: protecting all data from everything all the time is exhausting and unrealistic, so begin with the threats that matter in your situation.

This is not an exercise reserved for security teams. A publisher can build a useful first model on one page. Its value comes from making assumptions visible and helping people choose controls for reasons they can explain.

Define the problem before choosing the protection

Start with assets. An asset is not limited to a secret file. It can be an unpublished draft, a contributor’s identity, account credentials, a hidden-service private key, a list of readers, the integrity of a public article, the availability of a website, or the trust attached to a known address. Different assets require different protections. A public article does not need confidentiality after publication, but it still needs integrity and availability.

Next, describe adverse events in plain language. Avoid beginning with a dramatic adversary label. Write what could happen: an account could be taken over; two pseudonyms could be linked; a draft could expose a source; a service could become unreachable; an impostor could publish a false address; an administrator could accidentally include location data in an image. Specific events lead to testable controls.

Then consider who or what could cause each event and what capabilities are plausible. Threats include deliberate attackers, abusive partners, opportunistic criminals, platform operators, investigators, hostile insiders, and well-resourced state actors. They also include accidents, software defects, lost devices, provider failures, and team members who misunderstand a workflow. The same tool performs differently against each case. Encryption may protect a stolen powered-off drive, for example, while doing little if an unlocked account is already compromised.

Finally, estimate consequence and likelihood without pretending to have perfect numbers. A simple low, medium, or high rating is enough to start. A rare event with catastrophic consequences may deserve attention, as may a common event with moderate cost. Record uncertainty instead of disguising it. A model is a decision aid, not a mathematical guarantee.

Map controls to claims they can actually support

Every control should have a sentence that begins, This helps because… Tor Browser may help reduce cross-site linkability and browser fingerprinting because its design attempts to make users look more alike and isolates browsing state. It does not prevent a person from typing identifying information into a form. A Tor onion service can reduce direct exposure between a visitor and a service, but it does not make unsafe application code safe. Full-disk encryption can protect stored data when a device is powered off; it does not protect files from someone using an already unlocked session.

The sentence should also name the residual risk. No tool needs to be dismissed because it is incomplete—every control is incomplete. The important question is whether the remaining risk is understood and acceptable. Stating residual risk prevents a feature from quietly turning into a promise of total anonymity or security.

Tools introduce costs and sometimes new exposure. Adding non-default extensions—especially in Tor Browser—can alter observable behavior and may make that browser easier to distinguish. A new account creates credentials and recovery data. A self-hosted service gives the operator more control while also creating patching, monitoring, and backup responsibilities. A third-party service may simplify operations while gaining access to metadata. Include those costs in the decision rather than treating more tools as automatically safer.

Prefer a small set of controls that can be maintained. Updates, recovery tests, account reviews, and clear team procedures usually matter more than an impressive pile of abandoned software. If a control depends on behavior that the team cannot perform consistently, redesign the workflow or lower the claim.

Use a five-question publisher worksheet

A lightweight model can be built by answering five questions for each important activity:

  1. What are we protecting? Name the data, identity, service, relationship, or capability.
  2. What failure are we concerned about? Describe an observable event rather than a vague fear.
  3. Who or what could cause it? Include accidents and infrastructure failures as well as adversaries.
  4. Which controls reduce the risk, and what remains? Connect every tool or procedure to a specific claim.
  5. How will we know the plan still works? Assign an owner, a review date, and a test.

Consider a pseudonymous article submission. Assets may include the author’s private identity, manuscript, account, correspondence, and public byline. Possible failures include accidental name disclosure in document properties, reuse of an identifying email address, account takeover, or an editor publishing private notes. Controls could include a dedicated submission workflow, private identity fields separated from public author data, file inspection, least-privilege editorial access, and a final prepublication check. Residual risk includes identifying details in the prose itself and lawful disclosure obligations that depend on circumstances.

Now consider service availability. The asset is not only the running server; it includes the service address, content, configuration, keys, and the people who know how to restore it. Threats include software failure, provider suspension, expired resources, operator absence, and corrupted backups. A second server alone is not a complete answer if it depends on the same credentials, provider, and untested configuration.

The worksheet also exposes conflicts. Collecting detailed logs may help investigate abuse or outages, but those logs may become sensitive assets. Requiring a personal phone number may simplify account recovery, but it changes the identity risk. Threat modeling does not make tradeoffs disappear. It makes them reviewable.

Keep the model alive

A model becomes stale when the audience, software, team, provider, law, or consequences change. Review it before launching a new discovery channel, accepting a new type of user content, connecting identities, adding payment infrastructure, or promising a higher support level. Also revisit it after an incident or near miss. The question is not only what failed, but which assumption made the failure surprising.

Keep changes short and dated. Record why a control was added, what it is expected to do, who owns it, and how it is tested. Remove controls that no longer serve the model. A written reason is especially helpful when a future operator is tempted to disable a seemingly inconvenient safeguard.

People affected by the plan should participate in it. Editors understand manuscript handling; operators understand recovery; contributors understand risks around attribution; support staff understand common mistakes. Security planning is stronger when it reflects the whole workflow rather than only the server.

Practical Takeaway

Choose one real publishing activity and complete the five-question worksheet. Limit the first session to thirty minutes. Select the three highest-priority adverse events, assign one maintained control to each, and write down the residual risk in ordinary language.

Then audit the current tool list. For every tool, finish the sentence, We use this to reduce… If the answer is unclear, the tool may be unnecessary, misconfigured, or standing in for a decision the team has not made. If an important risk has no control, decide whether to reduce the activity, add a safeguard, transfer responsibility, or accept the risk explicitly.

The result will not cover every imaginable adversary. It will be more useful than a generic checklist because it connects the project’s real assets and constraints to protections the team can operate and review. For a worked example of one publishing risk surface, continue with Metadata You Can Leak Without Publishing Your Name.

Sources and Further Reading