This time! This time it’s really happening!
(maybe)
Can’t wait to add another tracker to the ol’ keyring 😅
Am I misunderstanding, is this not that? My understanding is the this will allow you to find devices other than your phone–tablets, earbuds, etc–by triangulating the location using not just your own phone but all Android phones local enough to detect the device being sought.
Yep, but as Google’s network (which would be the most comprehensive) is not yet ready, I’m using the next best thing: both Samsung and Apple’s - combined.
Note: I don’t live in a country where Tiled is sold or used too often, so they’re a no-go.
Tile sucks in any country compared to the Apple and Samsung networks so you’re not missing out on much.
IMO Tile is fine because usually you forget where something is because you left it there, and so your phone will tell you where you left it, you really only need a network if the thing moves after you left it somewhere.
I can’t wait to turn that shit off.
Google was already building a huge database with the locations of all the WiFi and Bluetooth devices at given times that they could. That’s how the high-resolution location services they use work.
Bluetooth and WiFi radios broadcast unique IDs. Google has any Android phones in the area tell them signal strengths and location, which is sufficient not just to locate the phone sending them the data, but also all those devices. And due to how those IDs are allocated, they can identify device types, data-mine that.
Google already knows what Bluetooth devices you have and can follow them as they move and knows where and when they were powered on. Bluetooth-enabled smart TVs, Bluetooth-enabled earbuds, Bluetooth-enabled smart lightbulbs, Bluetooth-enabled keyboards, Bluetooth-enabled mice, Bluetooth-enabled game controllers, Bluetooth-enabled (or WiFi-enabled) cars. If you flipped on a Bluetooth-enabled vibrating buttplug in a hotel room that also happened to contain two Bluetooth-enabled smartphones anywhere in range of an Android device using Google Location Services – including potentially either of the two phones themselves – Google knows about the location and time of that incident and has logged it in their database.
They’ve already got that data. This is just exposing some of that data that they already have to the device owners.
Still turning that shit off, and not buying corpo tracking devices.
So you’re saying Bluetooth in general is a no-go if you care about privacy at all.
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.
Couldn’t you be tracked by other phones nearby?
Fuck their shit
There is a much more sinister issue that Google is trying to resolve with this: it’s currently possible to stalk somebody by placing a tracker fob in their bag or on their car, so long as you know the victim’s device doesn’t support it.
Suppose some creeper with an iPhone is stalking a victim with an Android phone. So long as they use an Apple AirTag, the victim will never know they have a tracker trailing them wherever they go. And in reverse, the issue is the same.
Apple isn’t concerned about this, because they hold a monopoly in the market they care most about and can leverage this as an iPhone-only feature. After all, so long as you have an iPhone, you’ll be warned about an AirTag you don’t own following you. Apple wants to leverage this as an exclusive safety feature and have no intention of allowing other devices to do the same.
Apologies for providing this background as I know that this goes against the circle jerk of accusing Google of infringing our privacy. Feel free to disregard this context of it being beneficial to our collective privacy.
This is not correct. Android devices can detect apple’s air tags and alert users when an unauthorized tag is nearby. Google delayed the launch of their network to wait for Apple to implement the same feature for Android compatible tags, which is finally coming in the next iOS update.
Android has no way of knowing if a tag is “unauthorized” because Apple does not provision access to their tag network. You could, in principle, ignore tags that you know about, but you’d have to do it by identifying it by some arbitrary hexadecimal GATT ID.
As always, Apple wants to keep it that way, because it gives a poor experience on Android.
Theoretically (and I might be wrong about this), without attempting to reverse engineer how Apple assigns these codes, there would be no to differentiate AirTags, AirPods, iPhones, etc.
Android detects air tags and notifies users. https://support.google.com/android/answer/13658562?hl=en#zippy=%2Ccompatible-trackers
Yes, users have begun to be alerted of trackers—this is the recent change by Google as it relates to this post. An ongoing issue is, to my knowledge, that there’s no way to identify what kind of device it is. Goggle’s instructions literally suggest taking a screenshot of the serial number for later reference.
Cool, looks like no more Bluetooth anything for me…