Researchers from the Georgia Institute of Technology have disclosed multiple privacy weaknesses in Tile Bluetooth trackers that could enable long-term tracking of users. The team reports that Tile devices broadcast key identifiers in the clear, rely on static MAC addresses, and send telemetry that the vendor can access without end‑to‑end encryption (E2EE), increasing the risk of deanonymization and movement profiling.
What Georgia Tech uncovered in Tile’s BLE protocol
The analysis combined decompilation of the Tile Android app, inspection of Bluetooth Low Energy (BLE) traffic, and network captures between a Tile Mate and a Google Pixel 3 XL. Investigators observed continuous BLE advertising with identifiers that can be linked to a device, alongside a non‑rotating MAC address. While some unique IDs appear randomized, the study found they are reused over time, enabling correlation of sightings across days or weeks.
On the backend, the researchers noted that Tile servers receive location data, MAC addresses, and unique identifiers without E2EE. In practical terms, this means the service provider can access content and metadata even if transport encryption (e.g., TLS) is in place. An adversary sniffing BLE traffic could therefore identify a specific tracker and infer a user’s routine by linking repeated broadcasts to physical locations.
Anti‑stalking trade‑offs: detection vs. stealth
Scan and Secure and “Theft Mode” can work at cross‑purposes
Tile’s Scan and Secure feature is designed to help people find unknown trackers nearby. However, the vendor’s “anti‑theft” option aims to make trackers harder to discover. According to the researchers, when “Theft Mode” is active, server‑side results are suppressed, but a modified client could still display collected privateID values observed during scans. This design gap could be exploited to defeat anti‑stalking protections.
Why OS‑level protections matter for unwanted tracking
Most competing solutions integrate anti‑stalking at the operating system level: background BLE scanning runs continuously and users receive automatic alerts about unknown trackers. Because Tile is a third‑party app, it cannot match the depth of OS integration and relies more on manual checks, creating detection blind spots. Apple and Google have introduced system alerts for unknown trackers and, in 2024, published a joint Detecting Unwanted Location Trackers specification to standardize cross‑platform warnings; Tile’s current architecture makes full parity challenging.
Privacy risks and the legal backdrop
In 2023, lawsuits against Life360 (Tile’s parent company) argued that integration with the Amazon Sidewalk network increases detection range and may heighten stalking risks. While both iOS and Android have shipped additional unwanted-tracking protections, the Georgia Tech findings indicate that Tile’s protocol still permits undue correlation of devices and travel patterns.
The encryption model is pivotal. Vendors often state that “data is encrypted to the server,” which typically means transport encryption only. Without E2EE and aggressive identifier randomization, servers—and potentially attackers with vantage points—can link repeated identifiers or static MACs to a person’s movements.
Vendor response and recommended mitigations
The researchers reported their findings to Life360 in November 2024. They state the company initially acknowledged the issues, after which communication slowed, and noted the absence of a public vulnerability disclosure channel. In comments to The Register, Life360 confirmed receipt of the report and said it is implementing improvements, including encrypting data in transit and moving to rotating MAC addresses. Detailed technical timelines were not disclosed.
Recommended mitigations include: BLE Privacy with Resolvable Private Addresses (RPA) for MAC randomization; true end‑to‑end encryption to prevent server‑side access to location data; cryptographically bound, rotating ephemeral identifiers; and strict minimization of server‑side correlation and geodata retention.
Practical guidance for users and organizations
For users: keep the Tile app and mobile OS updated; act on OS‑level “unknown tracker” alerts; run periodic scans; limit participation in third‑party location networks (including Sidewalk) if privacy is a priority; and favor trackers that rotate IDs and MAC addresses frequently.
For organizations: treat trackers as IT assets in threat models; review vendors’ geodata retention and sharing policies; require transparent vulnerability disclosure processes and roadmaps for E2EE and full identifier randomization; and conduct periodic BLE audits in sensitive environments such as offices and critical infrastructure.
BLE trackers are genuinely useful, but privacy depends on protocol details. If a vendor uses static identifiers and relies solely on transport encryption, the likelihood of deanonymization and covert tracking rises. Evaluate vendors’ cryptographic architecture and data‑handling policies, enable anti‑stalking features, and press manufacturers for transparency, independent audits, and concrete timelines for E2EE and robust identifier rotation.
