Start with a person, not a feature
Privacy decisions improve when they begin with a person rather than a product. A threat model names who you are protecting against, establishes what access they realistically have, and then chooses controls.
This makes the trade-offs visible: a feature can address one access path while leaving another untouched.
The people, and what each of them can reach
Different adversaries have completely different capabilities, and a control that defeats one may be irrelevant to another.
- A casual borrower: physical access to an unlocked phone, no credentials, short window.
- A family member: repeated physical access, often knows the passcode, may share an account.
- A thief: physical access to a locked device, no credentials, unlimited time.
- A repair technician: physical access, may require the passcode, professional tools.
- An account attacker: no physical access, targets credentials and cloud copies.
- A coercive person: physical access plus the ability to compel you to unlock.
Why no single feature wins
A hidden album can reduce accidental swiping, while its protection against someone with a device credential depends on the current authentication policy. A local-only vault reduces cloud exposure and increases the consequence of losing the phone. A destructive duress option changes local access and introduces irreversible risk; it cannot guarantee physical safety under coercion.
Every control trades something. The question is never which is strongest but which trade matches the person you actually face.
Map every copy before choosing anything
Controls apply to locations, so the model is incomplete until you know where copies exist. The original in the camera roll, the cloud library, message threads, downloads, system backups, exports, and anything a recipient still holds are all separate locations with separate exposure.
A vault covers exactly one of them. That is worth knowing before you conclude the problem is solved.
Build the model in four passes
- Name the likely viewers rather than imagining a generic attacker.
- List each one's physical, credential, account, and device access.
- Map every copy and every recovery route that currently exists.
- Choose the smallest set of controls that changes those specific paths, and write down the risk that remains.
The failure patterns
- Designing only for a dramatic attacker while the realistic risk is a borrowed phone.
- Ignoring accidental sharing and other ordinary exposure paths.
- Choosing privacy controls without a recovery plan, and losing the data yourself.
- Treating the model as permanent when devices, accounts and relationships change.
A fictional example
Noah starts with a non-sensitive test: “Name likely viewers: casual borrower, family member, thief, technician, account attacker, or coercive person.” Next, Noah follows the second check: “List their physical, credential, account, and device access.” This fictional scenario demonstrates the decision process; it is not a report of product testing.
Common mistakes
- Designing only for a dramatic attacker
- Ignoring accidental sharing
- Choosing privacy without recovery
What this workflow does not change
- Designing only for a dramatic attacker
- Ignoring accidental sharing
- Choosing privacy without recovery
Questions people ask
Do I need advanced security knowledge?
No. Concrete questions about people, copies, and loss are enough to begin.
Can one vault handle different risks?
Sometimes, but independent spaces and credentials may better separate work, personal, decoy, or high-risk content.