When a Lost-Item Tag Becomes a Safety Problem
This series examines crowdsourced location-tracking systems: small Bluetooth tags whose whereabouts are reported by nearby phones and later retrieved by an owner. This opening focuses on a deceptively simple question: why does identifying and threatening to punish the owner not, by itself, prevent unwanted location tracking? The answer requires a basic system model and a distinction between stopping exposure, detecting abuse, helping the affected person act, and attributing responsibility. Those are connected goals, but they are not interchangeable.
The two main sources illuminate the question from different angles. The IETF’s DULT Threat Model describes the people, devices, networks, attacks, and design constraints that a detection protocol must account for. It is an Internet-Draft and remains work in progress. A separate security study reconstructs and tests parts of Tile’s deployed system, using the Tile Mate 2022 and the associated Android application as its main case. The study is not a measurement of every tracker, but it shows what can happen when a real service asks accountability to compensate for a weak preventive design.
The same system can find keys—or a person
A crowdsourced tracker is useful because it divides the job among several participants. The tag itself usually has a battery and Bluetooth Low Energy, or BLE, but no direct internet connection. It repeatedly broadcasts a small advertisement containing information that identifies or represents the tag. A nearby phone belonging to another user can hear that advertisement. The phone adds its own location and later sends a report to the service’s crowdsourced network. When the owner wants to find a lost keyring or bag, the owner’s device asks that network for the tag’s latest reported location.
This arrangement makes the tag inexpensive and the network wide-reaching. A tag does not need a cellular subscription or a GPS receiver if enough other phones pass nearby. But the same chain that recovers property can also reveal where a person or their belongings have been. If an attacker hides a tag in a car, backpack, or piece of clothing, the target’s movements become the movements the attacker wants to query. The IETF threat model treats the target as the person being tracked without consent, whether or not they own a tag themselves.
The risk is not limited to the obvious case of a stranger placing a device. A former partner may place a tag on a child’s belongings during a visit. Someone living with the target may hide one in a vehicle that the target must use. An attacker may gain access to the target’s own tag-associated account and use a legitimate ownership relationship as a surveillance channel. In each case, the network may see an ordinary-looking association: a tag, a registered account, and a location report. The harm lies in who can use that association, and whether the affected person can discover it.
The IETF draft also points to a quieter form of exposure. When multiple tags repeatedly appear together, the network or a passive observer may infer social relationships, routines, or group behavior. That inference does not require a dramatic break-in. It can emerge from repeated co-location. A person can therefore be exposed through a tag they carry, a tag carried by someone close to them, or a pattern formed by several tags.
The diagram’s important point is that the tag is not the whole system. The finder device supplies an observation. The network stores, processes, or returns a report. The owner device turns that report into knowledge. A safety failure at any of those boundaries can matter even if the tag’s registered owner is eventually known.
That is why unwanted tracking cannot be reduced to a question of whether the hardware belongs to a bad actor. The target may not know a tag is present. The finder may be an uninvolved bystander. The platform may hold information about many users. The account may have more than one authorized device or shared user. The person who appears as the “owner” in a database may be only one part of the authority chain through which location is accessed.
Why an owner’s identity is not the first line of defense
Once the system is understood, an appealing solution suggests itself: require every user to prove their identity, record their actions, and impose a severe penalty on anyone convicted of stalking. If people know they can be identified, perhaps they will not misuse the network. This is the logic behind Tile’s Anti-Theft mode as described in the security study. Tile wanted a stolen tracker to remain difficult for a thief to find and discard, so the mode made those trackers invisible to the service’s Scan and Secure results. To activate it, a user had to provide a government-issued ID and a live photo, accept terms about sharing information with law enforcement, and consent to a claimed $1 million fine if convicted of illegal tracking.
Those measures may sound like accountability, but they arrive after a crucial choice has already been made: the target is not supposed to see the tag. An identity check can describe who activated the mode. It cannot give a target an alert that the mode suppresses, make a hidden device easier to find, or stop location reports that are already flowing through the network. The IETF draft therefore treats an alert-suppressing mode as fundamentally at odds with the goal that unwanted-tracking alerts should not be circumventable.
The Tile study reports an even more revealing implementation boundary. The service recorded the identifiers encountered during a Scan and Secure operation and filtered Anti-Theft tags out of the results returned to the user. In the researchers’ tested client, that separation between collecting an observation and displaying it could be bypassed by a modified application. The exact result is bounded to the tested Tile implementation; it is not evidence about every tracker. But the design lesson is broader: a policy gate and an identity promise are not the same thing as a technical barrier.
Accountability also does not automatically protect the privacy of people who are not being stalked. The IETF draft says a potential target may need enough information to locate a suspected tag or decide what to do, but should not receive a full owner name or contact details merely because a tag happened to be nearby. A tag may be lost. It may belong to a family member. It may be coincidentally present on public transit. Turning every detection into an owner directory would replace one privacy problem with another.
The security study makes a related distinction between accountability and evidence quality. It defines framing resistance as the ability to prevent an attacker from making convincing evidence point to an innocent tag owner. If a scan result can be replayed, spoofed, or generated through a compromised key, an identified owner may not be the person whose device produced the alleged event. A punishment mechanism built on unreliable observations can harm the very users it claims to protect. The question is not only “Can the system name someone?” It is also “What does the system actually know, how did it learn it, and can the alleged event be shown to be authentic?”
These distinctions change the order in which protection must work. Location privacy should limit unnecessary visibility before abuse becomes a dossier. Detection should give the target a reasonable chance to notice a persistent unknown tag. Finding and disablement should provide a way to interrupt the channel. Records should preserve useful facts without becoming a new surveillance tool. Attribution and punishment may then help with accountability, but they cannot repair a missed alert, an exposed location history, or fabricated evidence.
A better way to judge the promise of safety
A useful evaluation begins with four questions.
Who can learn the location? A changing broadcast identifier may reduce easy tracking by a passerby, but it does not answer what the platform server can see. The Tile study reports that the tested service could persistently learn location information from reports sent by owner and finder devices. The IETF threat model likewise begins from the danger of a central service or observer learning more than the participants intended. Tag privacy and location privacy are separate properties.
Who can detect the unwanted tag, and when? A manual scan is not equivalent to protection that runs in the background. The target may lack the relevant app, may not know to start a scan, may be unable to watch a phone safely, or may be dealing with a tag hidden where its sound is hard to hear. The DULT model consequently considers manual scanning, background scanning, notifications from the tag itself, and activity logs as different ways to expose a threat. The target’s expertise, resources, safety situation, and expectation of tracking all affect whether a nominal feature is usable.
Can the target act after detection? An alert is only the beginning. The person may need help locating the tag, accessible sound or haptic signals, instructions for disabling it, and guidance about preserving evidence or avoiding escalation. Remote disablement may be valuable, but it must not become a way to attack the network or disable legitimate devices. The IETF draft treats finding, disablement, and public guidance as separate design responsibilities because they solve different problems.
Can the evidence support attribution without exposing innocent people? An accountable system needs records about accounts, devices, times, locations, and access to a tag. It also needs rules for who can see those records and how an owner can challenge a false accusation. The Tile study argues that framing resistance is an open research problem in offline-finding systems. The IETF draft similarly insists that target safety must not erase legitimate owner privacy. A trustworthy record is not the same as unrestricted disclosure.
This is the perspective that ties the two sources together. Tile supplies a concrete case in which privacy claims, detection, Anti-Theft behavior, key relationships, and accountability did not align as the labels suggested. The DULT threat model broadens the view: attackers may have different levels of technical skill, physical proximity, money, account access, or control over a target’s devices; tags may be multiplied, modified, impersonated, replayed, mixed across vendors, or replaced by GPS trackers. A design that works only for a technically confident target facing one conforming tag is not a complete safety model.
The answer to the title’s question is therefore precise rather than absolute. Accountability can deter some misuse, help preserve evidence, and support a response when a responsible party can be fairly identified. It cannot, by itself, prevent the initial collection of location, guarantee that a target receives a warning, make a hidden tag findable, revoke every copy of an old authorization, or prove that an observation was genuine. Those protections must be designed into the data path and the target’s available actions first.
The next step is to follow that data path in detail: once the tag’s advertisement reaches a finder device and a crowdsourced network, each handoff reveals a different choice about trust, visibility, and control.