How To Protect Your Online Privacy With A Threat Model | Tutorial 2022

Main ideas & lessons conveyed

• Privacy tools change and become unreliable over time
  • Recommended tools/countermeasures can be exposed, updated, discontinued, or invalidated by new research—so you can’t safely rely on any single product indefinitely.
• Use a consistent, proactive method instead of chasing tools
  • The video argues for learning a repeatable privacy methodology so you can:
    • Evaluate your own exposure
    • Adapt your privacy strategy as threats evolve
    • Avoid a “false sense of security” caused by misusing tools
• Threat modeling is presented as the core method
  • A tested approach from privacy engineering: the LINDEN privacy threat model, based on seven threat categories that lead to privacy violations.

---

Methodology: “Threat Model” for online privacy (detailed steps)

1) Identify your assets (what you’re trying to protect)

• Create a data inventory of personal information you create or that apps/services generate about you.
• Split assets into two types:
  • Transactional data: content of communication.
  • Contextual data (metadata): metadata that can still be highly identifying (e.g., timestamps, IP address, location, authorship/source, etc.).
• Key point: metadata is often unique, traceable, and rarely well-protected.
• Document not only what data you have, but:
  • Where it travels and resides
  • How it’s collected, stored, and shared
• Build the inventory by listing:
  • Apps, services, and devices you use
  • For each, create a table of data flow components, typically including:
    1. Credentials: usernames, passwords, biometrics, phone numbers, email addresses used to log in.
    2. Data collected by organizations through apps/services (both transactional + contextual).
    3. Data shared with third parties (content and/or context).
    4. Data retained by organizations/entities (including local stores like password manager DBs / phone storage).
    5. Data processing companies that process your data (billing, transactions, booking details, etc.).
• Purpose of inventory: determine whether data collection/processing is proportionate to purpose.

---

2) Identify adversaries (who you’re protecting your data from)

Privacy threats are not only external hacking; they also include legitimate or authorized misuse.

Consider three main threat sources:

1. External attacker: unauthorized access (hackers, intelligence agencies, criminal groups).
2. Organizational source: companies/entities handling your data in privacy-violating ways, including:
   • malicious employees abusing data
3. Receiving party: third parties that organizations share your data with (and may retain copies).

---

3) Identify threats using the LINDEN list (what you want to protect against)

For each service/system in your inventory, create a mapping table:

• Use the same rows as data flow components
• Add seven columns—one per privacy threat category
• Mark when a component indicates a threat

If needed, the video suggests using supporting materials/tools:

• “linda” / “lindencards” from linden.org (as referenced in the subtitles).

The LINDEN threat categories (7)

1. Linkability

   • Ability to connect two items of interest (even without knowing identity).
   • Driven by: data minimization/anonymization practices.
   • Questions include:
     • Are you reusing credentials across services?
     • Are your behaviors unique enough to link?
     • Does the service collect linkable metadata?
     • Does it share data with third parties that can link it?
     • Does it store/anonymize in aggregate rather than as individual profiles?
   • Risk: leads to inference/profiling and discriminatory outcomes.

2. Identifiability

   • Ability to identify a subject inside a dataset when linkage to identity can’t be hidden.
   • Driven by: minimization + anonymization; mitigated by anonymization.
   • Questions include:
     • Do credentials contain identifiable info (real email/name, biometrics, etc.)?
     • Are behavioral patterns unique?
     • Does the provider collect identifiable metadata?
     • Is identifiable data stored without minimization/de-identification?
     • Can identifiers be retrieved from stores?
   • Example cited: pattern recognition / AI that identifies users even when “anonymous browsing” is attempted.

3. Non-repudiation

   • Inability to deny an event/claim (opposite of plausible deniability).
   • Threat depends on context:
     • Useful for security/e-commerce receipts
     • Severe for privacy-sensitive domains (voting, whistleblowing, off-the-record messaging)
   • Questions include:
     • Do you log in with identifiable credentials?
     • Can communications be traced back to origin (location, etc.)?
     • Can you deny receiving a message or storing content?
     • Can future parties retrieve undeniable information?

4. Detectability

   • Ability to determine whether an item of interest exists or not.
   • Persistent threat because the internet is “open” and contextual signals can reveal presence/absence.
   • Questions include:
     • Can credentials be discovered externally (e.g., account recovery prompts)?
     • Is communication hidden/anonymous (e.g., via Tor)?
     • Can behaviors/inferred info be detected?
     • Can storage actions and retrieval be detected?
   • Example given:
     • Knowing someone has a record at a facility can reveal sensitive facts without seeing content.

5. Disclosure of information

   • Confidentiality breaches: data leaks.
   • Common drivers:
     • encryption failures/misuse
     • missing patches
     • compromised privileged access/login secrets
     • phishing/spoofing
     • insecure data flows into/out of data stores
   • Emphasizes: data can be on cloud and devices, so both must be protected.

6. Awareness and non-compliance

   • Unawareness: users not understanding data sharing/impacts; treated as a major neglected privacy threat.
     • Questions include:
       • Are you informed about collection/processing?
       • Are privacy controls user-friendly and privacy-preserving by default?
       • Can you request copy/remove/rectify data?
       • Is informed consent required, and can you withdraw it?
     • Critique: users submit too much data by default; tightening settings helps.
   • Non-compliance: organizations violating laws, regulations, and “best data protection principles” (purpose limitation, proportionality, storage limitation, least privilege).
     • Questions include:
       • Do they collect more than needed?
       • Is processing without consent?
       • Are decisions automated without human verification?
       • Is more data stored than required?

---

4) Threat mitigation (choose and tailor countermeasures)

For each threat-to-asset connection, apply countermeasures. The video provides a strategy set intended to mitigate multiple threats.

Mitigation strategies and recommended actions (as listed in the subtitles)

• Protect identity (primarily for linkability/identifiability/non-repudiation)

  • Use anonymous one-time credentials wherever possible.
  • Never reuse the same username/password across services.
  • Use a secure password manager:
    • Examples mentioned: KeePassXC, Bitwarden.
  • Prefer strong account protection:
    • Enable two-factor authentication (2FA):
      • Prefer non-identifiable methods like OTP apps or FIDO security tokens/keys.
      • FIDO keys also help defend against phishing.
  • Avoid SMS codes using phone numbers (to reduce identifiability).
  • Consider false information / aliases where allowed:
    • The video explicitly notes: “not a legal advice”.
    • Use anonymous email accounts and email aliases for each new service.
  • Treat apps that can’t be dissociated from your identity as violations (in the video’s framing).
  • If using such apps on a phone: compartmentalize via separate user profile (example given: GrapheneOS / separate profiles where possible).

• Guard exposure (confidentiality and metadata)

  • Treat services without end-to-end encryption as untrusted.
  • Don’t share sensitive content on non-E2EE apps.
  • Only use websites/servers that encrypt in transit:
    • HTTPS/TLS.
  • Messaging encryption examples:
    • Signal and Briar
  • Email encryption examples:
    • Tutanota or ProtonMail
  • Keep apps updated and download from official repositories (examples: Google Play/App Store per the subtitles).
  • Device and account hygiene:
    • Get the most secure device possible (budget devices with the security posture described).
  • Avoid high-risk authentication methods:
    • Don’t rely on biometrics for unlocking (fingerprints can be copied).
    • Prefer passphrases/PINs over fingerprint readers.

• Anonymize and minimize contextual/metadata leakage

  • Contextual metadata is “as sensitive as content.”
  • Best mitigation options described:
    • Use Tor on your phone (via Orbot, systemwide or per sensitive app).
    • Use Tor Browser for browsing/search traffic.
    • If Tor isn’t possible: use a reputable VPN to obfuscate IP address (noting limits).
  • Mentioned privacy-invasive metadata policies:
    • iMessage (Apple) and WhatsApp (Meta/Facebook) as examples.
  • Reduce metadata via protocol features:
    • Use messengers implementing versions of off-the-record (OTR) or sealed sender.
    • Subtitles claim: Briar’s metadata approach is described as stronger than Signal in the video’s framing.

• Minimize app/device data collection

  • Use stores that reduce Google dependence on Android-style devices:
    • F-Droid or Aurora Store on a Google-free GrapheneOS phone.
  • Go through settings on every system:
    • look for privacy/security related toggles
    • remove unnecessary data (e.g., image metadata, clear browser history, erase device data when appropriate).
  • Don’t dismiss consent prompts; reject cookies/trackers where possible.

• Harden access controls and encrypt stored data

  • Encrypt data sent to cloud with strong end-to-end encryption and keys you control.
    • Avoid typical cloud storage like iCloud/Dropbox/Google Drive (per subtitles).
    • Use E2EE storage examples: Proton Drive or Cryptomator-style encrypted vaults.
  • Prefer avoiding cloud backups:
    • use an encrypted SD card and potentially a hidden volume for plausible deniability.
  • Use hardware security module device types:
    • Example cited: Pixel devices with Titan M chip.
  • Control permissions:
    • revoke unnecessary access to camera/mic/contacts/files/calendar/messages/sensors.
  • Use apps that don’t need to collect data to monetize (federated learning mentioned).

• Reduce location and sensor inference

  • Location can be revealed by multiple vectors:
    • cellular triangulation
    • radio scanning
  • Mitigations described:
    • use airplane mode + disable Bluetooth/Wi‑Fi scanning when not needed
    • disable background scanning manually
      • GrapheneOS noted as keeping some defaults off
      • iPhones noted as enabling low-energy Bluetooth scanning

• Exercise data rights

  • Request periodic copies of data from services.
  • Request deletion (full deletion when possible).
  • Contact data broker/people-search databases and request removal.
  • Frequency guidance:
    • “every few months or years depending on the amount of data they collect” (as paraphrased in subtitles).

• Use privacy legislation where available

  • Stronger privacy laws can strengthen your legal grounds.
  • Subtitle includes: don’t treat guidance as legal advice.

• Close with process framing

  • Privacy is a long-term routine:
    • continue threat modeling + mitigation until it becomes habit.
  • Tools list is “not exhaustive”; build your own strategy.

---

Speakers / sources featured (from the subtitles)

• Privacy engineers / privacy engineering research (unnamed group credited with developing the methodology)
• Linden (the named “Linden privacy threat model”)
• linden.org (referenced as where to download/play “linda go cards” / “lindencards”)
• The narrator / creator of the guide (speaker not explicitly named in subtitles; references “I” throughout)
• Video platform or cited entities in examples
  • DuckDuckGo (mentioned regarding search engine trust issues)
  • Microsoft (mentioned in context of browser exposure/records)
  • GrapheneOS / Android / iPhone / Apple
  • Tor / Orbot / Tor Browser
  • Signal / Briar
  • Tutanota / ProtonMail / Proton Drive
  • KeePassXC / Bitwarden
  • FIDO security tokens
  • Google Play / App Store / F-Droid / Aurora Store
  • Apple iMessage / WhatsApp (Meta/Facebook)
  • Cryptomator (“crypto matter” as heard in subtitles)
  • Titan M chip / Pixel lineup

Note: No individual person’s name is clearly identifiable as a speaker in the subtitles provided.