Tile Chose Paperwork Over Cryptography, and Stalkers Won
Georgia Tech's teardown of Tile's protocol is a checklist of how not to threat-model a BLE product.
A Bluetooth tracker has exactly one job: broadcast its presence to strangers' phones without letting the wrong stranger learn anything. Tile — the second-largest crowd-sourced tracking network, owned by Life360 since 2021 — got that one job wrong in almost every way it can be gotten wrong, according to the first full security analysis of its protocol, published by Georgia Tech researchers Akshaya Kumar, Anna Raymaker, and Michael Specter (arXiv:2510.00350).
The findings resurfaced on Hacker News this year under a headline that's only slightly unfair: Tile's security is so bad it's a feature for stalkers. The more useful framing for anyone who builds connected hardware is different. Tile's failures aren't exotic bugs. They're the predictable output of a threat model that treats the vendor's server as trustworthy, the client app as tamper-proof, and terms of service as a security control. Every one of those assumptions is wrong, and Tile stacked all three.
What the tags actually leak
Three findings, in ascending order of embarrassment.
First, Tile tags broadcast a static MAC address alongside a rotating unique ID — over plain, unencrypted BLE advertisements. Rotating the ID while keeping the MAC fixed is security theater: anyone with an RF antenna who captures a single message can fingerprint that tag for the rest of its life. Worse, the researchers found the ID rotation itself is linkable — reuse patterns let an adversary correlate "rotated" IDs back to the same device even without the MAC.
Second, the data flowing up to Tile's servers — tag locations, MAC addresses, IDs — travels in cleartext, per the researchers. That means Tile can see the real-time location of every tag and every phone running its app, despite the company's public claims that it can't track users. Life360 disputes the encryption characterization, saying data is encrypted in transit and at rest, and that it's moving toward rotating MAC addresses. But encryption to the server is precisely the wrong property. Apple and Google's tracker networks are end-to-end encrypted so that the platform operator can't read finder reports even if subpoenaed. TLS just changes who you have to trust — it doesn't remove the trusted party.
Third, and most damning: Anti-Theft Mode. Tile launched it in 2023 as a way to hide a tag from Scan and Secure, its own anti-stalking scan — the theory being that a thief shouldn't be able to find the tracker in a stolen bag. Tile knew this was stalker bait, so it wrapped the feature in policy: government-ID verification with a biometric check, and a terms-of-service clause imposing a $1 million penalty on anyone convicted of stalking with it. The Georgia Tech team found the "hiding" is implemented server-side — the tag broadcasts identically, and the server simply omits it from scan results. A modified client displays every hidden tag. So the mode is fully transparent to a technical stalker while remaining opaque to the victim running the official app. The deterrent's accountability story collapses too: because broadcasts are unauthenticated and replayable, an attacker can record someone else's tag and rebroadcast it elsewhere — spoofing location history or framing an innocent Tile owner as a stalker.
The industry already solved this — in public
None of this required novel research to avoid. The AirTag stalking wave of 2021–2022 forced the whole category through this exact fire, and the resulting design is documented. Apple's Find My protocol has tags broadcast a rotating public key; finder devices encrypt their location against it, so only the owner's keys can decrypt reports and the broadcast identifier changes too often to trail. Apple and Google then co-authored the Detecting Unwanted Location Trackers specification — an IETF draft — so iOS and Android both alert you, passively and by default, when an unknown tag travels with you.
Tile sits outside that regime on both axes. Cryptographically, it never adopted rotating identifiers or E2E finder reports. On detection, Scan and Secure is opt-in, manual, and demands roughly ten minutes of walking around while it runs — compare that to an automatic OS-level alert a victim never has to know to ask for. The disclosure timeline completes the picture: the researchers reported everything to Life360 in November 2024, the dialogue went silent that February, and the company shipped no publicly documented protocol fix before the paper landed the following fall — only an unspecified claim of "a number of improvements."
The lesson for anyone shipping BLE hardware
If you're building anything that beacons — trackers, wearables, badges, fleet sensors — Tile is the case study to put in your design review, because each failure maps to a checklist item:
- Rotate the whole identity, not part of it. BLE has supported resolvable private addresses for over a decade; a rotating payload ID over a static MAC is a tracking beacon with extra steps. Your anonymity is only as good as the most stable field in the packet.
- Design so the server is an untrusted courier. If your architecture lets you read user location, you've built the surveillance capability — for yourself, for a breach, for legal process. E2E encryption of finder reports costs you some product features (Tile's fraud-detection and accountability claims depend on server visibility) and that trade-off is worth making anyway.
- Never enforce a security property in a place the attacker controls. Server-side result filtering and client-side hiding are policy, not security. If the radio still transmits, the property doesn't exist.
- Legal deterrents deter the law-abiding. An ID check and a million-dollar TOS clause raise the cost for a stalker who expects to be caught and convicted. The population you're defending against is, definitionally, not that.
The uncomfortable subtext is that Tile's anti-theft feature isn't an implementation accident — it's a genuine product conflict. A tag that's hidden from thieves is hidden from stalking victims; you cannot serve both with one broadcast. Apple resolved the tension by picking a side: AirTags are deliberately bad theft trackers because they announce themselves. Tile picked the other side and tried to paper over the consequences with paperwork.
That's the editorial call, and it's not close: until Life360 ships rotating identifiers, E2E-encrypted reports, and joins the cross-platform detection spec — and documents all three — Tile tags are unfit to recommend, and their protocol belongs in your threat-modeling deck as the negative example. The crowd-sourced-tracking design space had already converged on an answer. Tile's real vulnerability was deciding the answer was optional.
Sources & further reading
- Tile's security is so bad it's a feature for stalkers — blog.adafruit.com
- Security and Privacy Analysis of Tile's Location Tracking Protocol — arxiv.org
- Tile trackers leak unencrypted Bluetooth data, say boffins — theregister.com
- Tile's Lack of Encryption Is a Danger for Users Everywhere — eff.org
- Tile trackers plagued by weak security, researchers warn — malwarebytes.com
- Tile Adds Undetectable Anti-Theft Mode to Tracking Devices, With $1 Million Fine If Used for Stalking — macrumors.com
Emeka has spent over a decade tracking threat actors, vulnerability disclosures, and the evolving landscape of application security, bringing a sharp continent-spanning perspective to his reporting. He's known for translating dense CVE advisories into clear, actionable context that developers and security teams alike actually read.
Discussion 0
No comments yet
Be the first to weigh in.