The Second Failure: An Alert Is Not a Way Out
This chapter examines the detection and response gap in crowdsourced location-tracking systems. The specific question is whether a person is meaningfully protected when an app technically offers a scan but the scan is manual, temporary, easy to suppress, or disconnected from a safe way to find and disable the tag. The Tile implementation provides the concrete symptom; the IETF DULT threat model supplies a broader response model. Together they let readers judge protection by what a target can do under real conditions, not by whether a feature exists in a menu.
A scan that exists only when requested
Tile’s Scan and Secure illustrates the difference between a detection capability and an available safeguard. In the study’s account of the tested application, the user had to find the feature under the app’s settings and start it manually. The scan performed six consecutive Bluetooth scans, took about ten minutes, required the user to be physically moving, and required them to monitor the results on the screen. It was not a background process, was not enabled by default, and did not continue once the user left the relevant view.
That workflow creates a predictable gap between the moment a tag is placed and the moment a target happens to run a scan. It also assumes that the target knows the feature exists, has the Tile application, can grant the necessary permissions, can move around while scanning, and can safely watch a phone. A person who does not use Tile cannot rely on Tile’s application as a general protection against nearby tags. The study contrasts this application-level design with operating-system capabilities that scan automatically and can alert users without requiring them to initiate a visible session.
The symptom is easy to describe: the system may contain enough information to recognize an unfamiliar tag, yet the person at risk receives no timely warning. The underlying cause is not simply that the scan lasts ten minutes. It is that detection is owned by an application and a user action rather than being available as a persistent platform function. An application can be useful when a person already suspects tracking and can safely operate it. It is a weaker safety net for an unsuspecting person, someone without the app, or someone whose device use is monitored by an abuser.
The IETF threat model makes those conditions concrete. One composite scenario describes a target who suspects a tag is hidden in a car but cannot take the vehicle to a mechanic without the controlling partner knowing. Another describes a target who does not feel safe installing a manual-scanning application because an abusive partner can inspect the phone. A child may not understand the significance of an alert. A tag buried under a vehicle cushion may emit a sound that is too quiet to locate. These are not exotic edge cases in the model; they show why technical availability and safe usability must be evaluated separately.
Anti-Theft mode adds a second cause of the same detection gap. Tile designed that mode so a tracker would not appear in Scan and Secure results, protecting a stolen item from being found and discarded.