Threat models checklist (setup and decisions)

A threat model checklist helps you turn “privacy worries” into specific setup choices you can reason about. Start by writing down three things: (1) what you want to protect, (2) who or what might try to defeat it, and (3) where and how you’ll use your devices and connection. Then decide what evidence would change your mind.

This matters for digital nomads and independent users because your risks shift with location, network type (home Wi‑Fi, hotel Wi‑Fi, mobile hotspots), device changes, and local legal or infrastructure realities. Use stable security thinking, but treat every current claim (product features, policies, and real-world performance) as something you must verify for your situation.

How it works: operating conditions and a usable definition

A useful threat model is specific enough to guide decisions. Consider these parts:

  1. Assets (what you’re protecting)
  • Browsing content (sites visited)
  • Account data (logins, cookies)
  • Messages and files (including cloud sync traffic)
  • Identity signals (IP address, timing patterns)
  1. Adversaries (who you’re worried about)
  • Local network observers on public Wi‑Fi (watching traffic at the hotspot)
  • Web services and advertisers (tracking via identifiers and fingerprints)
  • Your device environment (malware, malicious extensions, compromised apps)
  • Authorities or legal processes (access to records where applicable)
  • The service/provider you rely on (what they can see or log)

  1. Capabilities and goals (what they can do and why) Example goals: prevent observation, reduce linkage, avoid censorship triggers, or protect credentials.

  2. Operating conditions (where your setup will run)

  • Device OS and security posture (updates, firewall, extension hygiene)
  • Network types you expect (public Wi‑Fi vs. tethered mobile)
  • Travel patterns (frequent IP/region changes)
  • Whether you’ll do high-risk activities (banking, work accounts, sensitive messaging)

Decision rule: if you can’t explain how your setup reduces an identified risk in a specific condition, you’re probably choosing based on marketing rather than a threat model.

Practical context: the most common limitations to include

Build your checklist so it includes limitations, not just hopes.

  • A VPN does not guarantee anonymity, safety or access. Even with encrypted transport, other parts of the system can still reveal information (browser fingerprinting, account logins, device malware, or traffic patterns).
  • Performance and availability vary by network, device, location, provider and time. When you rely on connectivity for work, plan for degraded performance and temporary failures.
  • Expect different risk profiles by network type. Public Wi‑Fi increases local observation risk; captive portals and unstable DNS behavior can create edge cases.
  • Product capabilities and policies can change. Treat feature lists and privacy claims as “current as of when you verify.”

Include these limitations explicitly in your threat model document. They are not “fine print”; they define what you should and should not build your workflow around.

Verification steps (evidence you can repeat)

Use verification steps that are practical for independent travel use. The goal is to reduce reliance on promises.

1) Check for data leaks

  • Run reputable leak checks after connecting.
  • Test that DNS queries and traffic behave as expected.
  • Repeat tests on at least two networks (e.g., home Wi‑Fi and a mobile hotspot) because behavior can differ.

2) Validate “fail-closed” behavior (where applicable)

If your setup claims to prevent traffic from bypassing protections when the secure connection drops, test that scenario intentionally:

  • Turn the secure connection off/on.
  • Confirm whether traffic continues, pauses, or reroutes.
  • Make sure your expectation matches reality on your device.

3) Confirm configuration basics

  • Ensure browser and system privacy settings aren’t undoing your goals.
  • Review installed extensions and remove anything unnecessary.
  • Keep the OS and key apps updated; many “tracking” incidents are actually security hygiene problems.

4) Evaluate provider and policy signals (without assuming)

Because current product, legal and empirical claims require authoritative sources, verify the provider’s current materials before relying on them:

  • Review the current privacy policy and any relevant documentation.
  • Look for transparency about logging practices and how they handle requests.
  • Confirm how they describe uptime, maintenance behavior, and operational scope.

5) Measure real-world usability

For nomads, usability is part of threat modeling.

  • Test latency and stability during work hours.
  • Check whether connections drop during typical travel changes.
  • Verify that common services you use (email, calendars, collaboration tools) remain workable.

When is the checklist “complete” (clear stop criteria)

A threat model checklist is complete when you can answer these without hand-waving:

  • Which risks matter most for your assets (content, identity, credentials) and adversaries?
  • Which setup choices reduce those risks under your actual operating conditions?
  • Which limitations you accept (and what fallback plan you have when things degrade)?
  • What evidence you collected (leak checks, fail-closed behavior tests, policy review dates, and usability tests) and when you collected it.

If you cannot define evidence or stop criteria, treat the setup as provisional.

Practical mistakes to avoid

  • Treating one setting as a complete solution. Your browsing identity is influenced by device, accounts, and browser behavior.
  • Skipping tests on real networks. “Works at home” often fails during travel.
  • Ignoring device hygiene. Compromised endpoints can defeat network-layer protections.
  • Believing absolute statements. If a claim implies guaranteed anonymity or guaranteed access, your threat model should mark it as unsubstantiated.

Optional: keep a short decision record

For every change (new network, new device, new routing behavior), maintain a brief log:

  • date/time
  • device and OS version
  • network type
  • what you tested and the result This turns repeated travel into an informed baseline rather than a fresh guess each time.

If you want, tell me your typical setup (device types, common networks like hotel Wi‑Fi or mobile hotspot, and your top two assets to protect). I can help you turn this into a tighter checklist with clearer stop criteria for your specific conditions.