Recovering the device and protecting the data pull against each other
Aliases: lost mode · anti-theft tradeoff · recovery conflict
What it is
After a device is lost, two goal lines run against each other: recovery (keep the device reachable, locatable, contactable) and data protection (lock it, hide it, wipe if necessary). Every protection action erodes recovery odds — wiping halts location, locking removes the finder's way to reach the owner. The two goals squeeze each other on one timeline, and the disposition flow must order them explicitly rather than pretend they are compatible.
Why it happens
The conflict comes from location and lockdown sharing one device-side capability chain: locating requires the device online and running location services — usually meaning "usable" — and protection actions switch those capabilities off one by one. Worse, the wipe command itself needs the device to connect before it executes, so wiping first almost certainly ends recovery. Time compounds it: recovery odds concentrate in the first hours after loss, precisely when panic pushes toward the strongest protection. Tiered disposition is therefore a structural necessity, not a product preference: first Lost Mode (lock screen plus owner contact, location kept running), then de-escalation (sign-outs, payment freezes), and only last the irreversible wipe.
Where it stops holding
Tiering presupposes that recovery is worth something: when the device is in a stranger's hands and carries high-sensitivity data (corporate fleet, medical records), breach cost outweighs recovery and wiping immediately is correct. How far Lost Mode decouples "show contact info" from "lock" is decided by each platform and cannot be assumed uniform. Tier trigger values (hours without a fix, unlock attempts) have no universal numbers — they scale with device value and data sensitivity — and both error directions must be tolerated in the flow: conservative tiering exposes data a while longer, aggressive tiering kills a recoverable device.
Applying it
- Fix three tiers with explicit triggers: Lost Mode (default first step) → de-escalation (e.g., 24h without a fix) → wipe (recovery abandoned or data confirmed sensitive); encode the triggers in product logic, not support scripts.
- In Lost Mode, contact info uses a secondary number or email, never the primary account; location keeps reporting but stays owner-visible only.
- The UI states each tier's consequence in plain words — "location will stop once wiped" belongs in the wipe confirmation dialog.
- Verification: turn the three tiers into a tabletop drill script (48h without a fix, abnormal unlock attempts), check that each tier's action and trigger cohere, and keep the drill log as the flow's regression cases.