The article is indeed hard to understand on its own.
From the linked 2022 paper:
BLE sends beacons hundred times per minute, even from phones. For privacy reasons the Mac addresses are randomized.
The attacker can further analyze the beacons for imperfections in the rf signal and get a fingerprint for devices from frequency offsets/drift/iq imbalance.
Haven't seen the new paper, but the article suggests the a firmware change can even reduce this attack vector. I guess that introducing further randomization in chipset parameters for each beacon can make this kind of tracking harder still. I doubt that this hides all aspects of fingerprinting and settings stepsizes would still be observable, just harder to track. "Randomization pattern F is this manufacturer gen 2025 devices"
My take on this: most of the day, I would not need any beacons at all - maybe there is an intelligent limit on avoiding them? Configurable? Only when unlocked? Only when in motion?
Sometimes sending half the beacons would double the time needed for tracking already. Again, this would boil down to "a firmware update could improve privacy"
> Sometimes sending half the beacons would double the time needed
Great, so still within one second. Not seeing how that's doing anything detrimental to the trackers. Even when walking through a store, 50 tracks per second is really accurate.
The best thing you could do to improve privacy from blue tooth trackers is to disable blue tooth
Only within one second if fingerprinting can be done from a single data point. If it takes 10,000 beacons to identify a device with reasonable certainty, doubling that count is significant.
BLE beacons use advertisement packets with a payload, and at the end of the day, are sent actively by an application (like COVID tracing). With MAC address randomization, it's possible to make them anonymous and untrackable at the protocol level. This paper uses data from the physical layer to pull more metadata to track devices, ie. error and drift in its RF frontend. It's not, not a concern, but it's also not data you'd be able to grab with a normal BLE chipset in sniffer mode. You'd likely need an SDR, and that's what they use in the paper. It's an attack that's on a different level of sophistication and cost.
Additionally, I wouldn't worry too much about beacons on their own (at least, in this context). Beacons are just a form of BLE advertisement packet. Your BLE devices need to send out advertisements anyways to let your phone to know they exist and connect to them. I assume this attack works on any advertisement packet (and also data packets to a connected device). Normally, rotating private addresses will mitigate some attacks tracking two devices talking to each other, at the protocol layer. This paper is more just a broader look at what features you can extract at the physical layer with an SDR to identify a specific device or chipset.
I suspect if many people knew how much their phone was broadcasting to the world around them they'd be quite unhappy. I know I'm rather disgruntled at how much my phone talks and how little I can control it outside of manually toggling it on and off with use.
So, just to get the obvious out of the way, all competent dev teams enable random addresses. It's a no-brainer and it has no effect on the usability of most BT products.
Regardless, even if they do that, the payload of the advertising packet is still useful for tracking purposes. You're probably relying on hueristics at that point, but you can also rely on some devices including a service UUID, device name, or some very specific information in the manufacturer-specific data field.
Yeah, at the end of the day, you're probably going to advertise with some sort of unique short name (so humans know what to pick in the a connect/pairing menu), and have at least one Service UUID (even if you only expose the juicy stuff after bonding.) But that still pushes it back up to a software policy concern, and it's up to the developers to make the appropriate privacy/security tradeoffs. The only real way around this is to do discovery out-of-band via NFC or QR codes or something.
The other detail worth mentioning is that generic service advertisements and beacons will have different behaviors and payloads, since they have different goals.
With the former, the device is advertising because it's disconnected and needs to be discovered. Service discovery necessarily means you're sending out some sort of information about what you are. If it only expects to be connected to one device (ie. the phone), it's going to turn off advertising when connected to said phone. You technically don't need to advertise the service UUID either once you're bonded, although I don't think would happen much in practice, as it makes recovering from an unbond event harder.
Meanwhile, a beacon is data that is intentionally being broadcast out to the world by an application. The application will probably send out beacons regularly no matter what, since that's usually the point (Find My, COVID tracing, etc.) I would expect companies like Apple to ensure that these advertising packets aren't leaking any identifying information. This is easier to do than the above case, because the goal isn't service discovery, but to intentionally broadcast a piece of (anonymous) info.
tl;dr Beacons are fine, especially in comparison to your headphones or smartwatch loudly announcing itself to the world because it's disconnected
Since iOS Control Center no longer turns off (only disconnects) radios, a shortcut/automation can be linked to a Control Center button (e.g. low power mode) status, to control radio power with a single tap.
I’m not saying any of this is _good_, just the rationale for the feature being the way it is.
Non-technical people read articles telling them to turn off Bluetooth but they do not understand the consequences of turning off Bluetooth, then Apple gets bad reviews because their IoT door lock “doesn’t work with their phone”, or AirDrop doesn’t work, etc, etc.
So the quick access turn off just disables the connections for the day. If you go to system settings and toggle it off there it’s actually disabled.
Same for why toggling WiFi in control centre only disables searching for networks. People would disable WiFi then blame Apple for the excess cellular data charges.
I wanted to know how practical this BT tracking vulnerability is but TFA is terrible so I read the linked 2022 paper describing the potential tracking vuln and found the answer.
> "In summary, we find that physical layer tracking
of BLE devices is indeed feasible, but it is only reliable under
limited conditions, and for specific devices with extremely
unique fingerprints, and when the target device has a relatively
stable temperature."
So, possibly able to track a BT fingerprint, once seen and positively identified by other means, in a given location on a given day but apparently not unique or reliable enough to consistently differentiate that device out of many devices in another place on another day. BTW, the physical layer traits which may be unique enough for tracking are "Carrier Frequency Offset and I/Q Offset".
From the linked 2022 paper: BLE sends beacons hundred times per minute, even from phones. For privacy reasons the Mac addresses are randomized. The attacker can further analyze the beacons for imperfections in the rf signal and get a fingerprint for devices from frequency offsets/drift/iq imbalance.
Haven't seen the new paper, but the article suggests the a firmware change can even reduce this attack vector. I guess that introducing further randomization in chipset parameters for each beacon can make this kind of tracking harder still. I doubt that this hides all aspects of fingerprinting and settings stepsizes would still be observable, just harder to track. "Randomization pattern F is this manufacturer gen 2025 devices"
My take on this: most of the day, I would not need any beacons at all - maybe there is an intelligent limit on avoiding them? Configurable? Only when unlocked? Only when in motion? Sometimes sending half the beacons would double the time needed for tracking already. Again, this would boil down to "a firmware update could improve privacy"