Privacy threat-model worksheet
Complete one row for one activity. A work login, health search, private message, and public post have different observers, consequences, retention, and realistic controls.
| Field | Question to answer |
|---|---|
| Activity | What are you doing, on which device and account? |
| Data | What content, metadata, location, contacts, or identifiers are created? |
| Observers | Which network, provider, app, employer, person, or attacker can access it? |
| Consequence | What happens if the data is disclosed, linked, retained, altered, or lost? |
| Control | Can you minimize, separate, encrypt, restrict, delete, or avoid the data? |
| Verification | Which setting, export, test, or policy confirms the control? |
How to build a privacy threat model
Define the observer and data first. Use HTTPS and a trusted remote-access or VPN service when local-network exposure is the concern. Choose a provider based on operator identity, protocol, update support, data handling, account security, and a clear exit path.
Example: deciding whether a VPN solves the stated problem
A remote worker wants privacy on hotel Wi-Fi and assumes a VPN will make every online activity anonymous. The local-network concern is real, but account logins, browser identifiers, payment records, and the VPN provider still affect linkability.
Check whether the chosen observer lost access
Verify that the intended traffic uses the protected path, DNS behavior matches the design, and applications do not bypass policy unexpectedly. Then review which services still identify the user directly through accounts or submitted data.
Map the data path
Draw the path for one real activity, such as reading news, making a purchase, or sending a work file. Note the device, local network, internet provider, intermediary services, destination, account identity, and payment path. The map reveals which observer each proposed control changes and which observers remain.
| Observer | May see | Control to evaluate |
|---|---|---|
| Local network | Destinations and unencrypted traffic | HTTPS, encrypted DNS tradeoffs, trusted access |
| Service provider | Account activity and submitted content | Data minimization, settings, deletion policy |
| Advertiser or tracker | Cross-site identifiers and behavior | Browser isolation and tracking controls |
| Device compromise | Content before encryption | Updates, endpoint protection, restricted access |
Avoid absolute privacy claims
No single product makes a person anonymous in every context. Login identity, payment details, browser fingerprinting, traffic timing, contacts, and content can still link activity.
Demand a bounded claim from every privacy feature. Encryption may protect content in transit while leaving account identity and destination visible. A blocker may reduce third-party requests but not data submitted to the site. A separate profile can reduce linking without making the person anonymous.
- Prefer precise claims over 'military-grade' language.
- Check who operates the service and which law applies.
- Review retention, third-party sharing, audits, and incident history.
Start with high-impact account controls
Unique passwords, strong MFA, recovery-method review, device updates, and careful app permissions often reduce more practical risk than adding a new privacy subscription without a defined threat model.
Start by deleting unused accounts, limiting public profile data, reviewing app access, and securing primary email and recovery methods. These steps reduce stored data and takeover risk without adding another provider. Add a paid or technical tool only when the threat model names the observation it must change.
Privacy control decision checklist
- Describe the activity, observer, data, and consequence.
- Minimize collection and permissions before adding another service.
- Review operator identity, retention, sharing, audits, and incident history.
- Secure the service account and recovery method.
- Verify the actual data path and remaining identifiers.
Privacy tool evaluation mistakes
- Buying a privacy product before stating who should be prevented from observing which activity.
- Treating a no-logs slogan as complete evidence without scope, jurisdiction, architecture, retention detail, or independent verification.
- Ignoring the endpoint. Malware, unsafe extensions, and account compromise can observe content before or after network encryption.
Online privacy questions
Does private browsing hide activity from the network?
It mainly limits local browser history and some stored state. Networks, services, accounts, and other software can still observe activity.
Does a VPN make me anonymous?
No. It changes part of the network path and shifts trust. Accounts, payments, browser characteristics, traffic patterns, and content can still identify or link activity.
Should I use encrypted DNS?
It can protect DNS queries from some observers, but the resolver still receives them and destinations may remain inferable. Choose it for a defined threat and operational model.