Tile sucks in any country compared to the Apple and Samsung networks so you’re not missing out on much.

Well, as things stand, yeah, probably.

So, in theory, you could have a Bluetooth device randomize its unique ID. The problem is that I believe that devices use that to identify devices that they’ve paired with, so you’d need to re-pair, as things stand.

I don’t know if there’s a way to do Bluetooth without exposing a unique ID today. But I’d imagine that it’s possible to modify the protocol such that it’s possible.

I think that there are two problems here (and this is without going and digging through the protocol specs, to see if anything else is exposed).

The first is that a device type is exposed pre-authentication. That’s useful, since it lets people choose a device for initial pairing from a list of inscrutable IDs. Coupled with location, that’s likely to do a pretty good job of uniquely-identifying a number of devices. I don’t know whether that’s just done via a database based on OUI (MAC addresses get allocated across the world in “blocks” to manufacturers, so you can use this to identify devices; Ethernet devices can be identified in this way, as they also use MAC addresses) or whether the device additionally broadcasts information about what it is. But either way, that does a limited amount to expose identity on its own.

The second is that the MAC, the unique identifier on each Bluetooth device, gets broadcast. That’s a problem.

Laptops started randomizing the MAC on WiFi transmitters precisely because of this concern about privacy. But there are a hell of a lot more Bluetooth mobile devices out there than WiFi devices, making it even more of a privacy issue for Bluetooth. For WiFi, this isn’t an issue, because you don’t randomize the MAC on the wireless access point – which generally, aside from some cases like cars that are now an issue – but on the phone/laptop/etc side.

One thing I suspect that might work is to randomize the MAC on Bluetooth devices – say, a pair of Bluetooth earbuds. At pairing time, have some kind of shared secret that is allocated on a device, shared with devices that pair. Then whenever the Bluetooth device broadcasts its presence, it sends out a number based on a hash of that secret and the current time, same sort of thing that time-based one-time-passwords do. A phone or laptop that has previously paired with a pair of earphones knows that secret, and can identify a device based on what the current TOTP for the device is. That’d prevent an arbitrary receiver just listening to broadcasts from uniquely-identifying the broadcasting device. It does mean that you’d need to deal with the issue of having an accurate clock on the device, and maybe re-synchronizing it periodically in some way.

There are a couple of caveats there. One big one is that if you can pair to the device, you can get its secret, and from then on, you can uniquely identify to it…and if someone just runs around pairing with devices, they can harvest those. That’s harder, since typically Bluetooth devices don’t permit pairing with multiple things at once, but there are a lot of things that aren’t going to be paired at any point in time. Originally, I believe that Bluetooth devices tended to require authorization to pair on each end, would have some sort of shared secret that needed to travel via some other channel. For example, I have a Bluetooth keyboard. When I pair it with my phone, it requires me to type out a code provided on the phone screen on the keyboard. That avoids stuff like man-in-the-middle attacks, is really the ideal thing to do…but isn’t quite as user-friendly, and requires the device to have some form of input/output capabilities.

Other devices devices required one to throw them into a “pairing” mode. I have some game controllers like that – they’ll only let a computer pair with them if I’ve held down the “Bluetooth pairing” button for a while. That’s not quite as good, as someone could theoretically attack them in that window, but for almost all of their life, they’re not in “pairing” mode. You can’t just travel around and pair with them.

But a lot of devices don’t seem to do that now. Like, I have a couple pairs of Bluetooth earbuds. It’s not the case that either the phone or the earbuds give a number or anything like that and have you punch it in on the other end. They just permit anything that wants to to pair with them as long as they haven’t actually paired with the phone. That’s not great, and my guess is that for those devices, you could pair and harvest secrets and then track them the way you do existing Bluetooth devices.

It’s actually kind of unfortunate, because it’s legitimately-useful to have things like Google Location Services. It permits obtaining a location fix rapidly, and permits doing so when GPS reception isn’t functioning, like indoors. And it helps improve location accuracy. Like, I’d be very happy if there were little, low-power radios that did broadcast unique IDs. The thing is, though, you don’t want to have them moving around with someone, because that introduces tracking problems. You want to have them only at fixed locations. In fact, one of the problems that the Google Location Services people had to solve would have been filtering out Bluetooth radios that did move around, because those mess with a phone’s location; if you’re trying to detect a smartphone’s location on the smartphone, you only want to know the strength of static, unmoving radios.

It might be kind of nice if there were a radio protocol specifically for that, for doing nothing other than detecting location. I’d want a given device to permit regenerating its unique ID, so that you could move it. Maybe have the protocol permit broadcasting a location, so that you can bootstrap the database by initially trusting where devices say that they are. And maybe have the device also broadcast at different signal strengths periodically, less-frequently at high power, and indicating its broadcast power to receivers. Finally, it might be useful for ones with multiple receivers to do beamformed transmission and indicate to receivers the direction in which it is broadcasting. Hmm. If you mandated GPS, you could maybe just regenerate the ID automatically if the device thought that its position had dramatically changed, which would also defeat tracking attempts, even if someone moved a theoretically-static radio station. All that would be useful information to beat the existing WiFi/Bluetooth mechanisms for getting a better position fix. I mean, I’d put a small radio device like that at my place if it’d speed up location fixes for myself and other people.

But that isn’t the situation in which we find ourselves.

Android detects air tags and notifies users. https://support.google.com/android/answer/13658562?hl=en#zippy=%2Ccompatible-trackers