What Accountability Can—and Cannot—Prevent

This series has examined crowdsourced Bluetooth location-tracking systems through two linked questions: what happens to location information as it moves through tags, finder devices, platforms, and accounts, and what protection reaches the person being followed before the harm is complete? The final judgment is that accountability matters, but it is a downstream capability. It can support investigation and consequences; it cannot, by itself, keep the platform from seeing a location, make an alert appear, find a hidden tag, revoke old tracking authority, or prove that an observed identifier came from a genuine device at a genuine place and time.

That conclusion is grounded in two different kinds of evidence. The Tile security study offers an implementation case: its researchers reverse-engineered an Android application and tested a Tile Mate 2022, reporting specific failures in privacy, detection, Anti-Theft behavior, key lifecycle, and framing resistance. The IETF DULT Threat Model offers a broader design and threat framework, but it is an Internet-Draft marked as work in progress. The first source shows what can fail in a deployed system; the second shows why the problem cannot be reduced to one product feature or one kind of attacker.

The answer is a matter of sequence

Unwanted tracking begins when a tag, account, or other authorized relationship starts supplying information about a person or their belongings. That can happen before anyone knows which account is involved. A planted tag can broadcast while the target is unaware. Finder devices can report observations without the target participating. A platform can receive readable location reports before a target receives any warning. An attacker can use a target’s own tag through a compromised ownership relationship. The causal event is therefore earlier than the accountability decision.

This is the first reason punishment cannot substitute for prevention: the person being tracked may need protection at the moment data is collected, not only after an institution has investigated its use. A platform that can persistently learn locations has already created a privacy exposure even if it later identifies an abusive user. An observer that can link broadcasts has already built a movement trail even if no owner is ever named. An attacker who uses a legitimate account may never trigger the warning designed for an unfamiliar tag. Identification after the fact does not roll those events back.

The Tile case makes the sequence visible. The study reports that the tested service could learn location information from owner and finder reports and that the Tile Mate 2022 broadcast a static MAC address alongside changing private identifiers. It also reports a private-ID set that rotated about every 15 minutes and repeated after about 90 days, and an authKey that was not regenerated during transfer or sharing. These are separate implementation findings, not one generalized “encryption problem.” Together they show how a system can lose privacy through server visibility, hardware fingerprinting, identifier reuse, and authorization that survives a visible relationship change.

The case also shows why a safety feature cannot be evaluated only by its stated purpose. Tile’s Anti-Theft mode was intended to keep a stolen tracker from being discovered and discarded. It used identity verification, law-enforcement terms, and a claimed financial penalty to make misuse punishable. Yet its target-facing effect was to remove the tracker from Scan and Secure results. In the tested flow, the application still sent observed private identifiers to the server, which filtered the results shown to the user; the researchers report that a modified client could reveal what the ordinary interface concealed. The bypass is bounded to the studied application and hardware, and the claimed fine is not independently established as enforceable. The structural point survives those limits: a hidden tag cannot be made safe for the target merely by making its activator identifiable.

The DULT threat model expresses the same sequence as a set of design responsibilities. A target needs manual and background ways to detect unwanted tracking. Alerts may need to come from a phone, the tag, or another accessible channel. After detection, the target may need help finding and disabling the tag, preserving evidence, or choosing a response that does not escalate danger.