security and data protection-relevant actor missing: Proximity Tracking industry
pdehaye opened this issue · comments
The Proxbook report on "Proximity marketing in airports and transportation" states the following concerning Munich airport:
The installed hardware includes 120 “bluloc Big Bays”. These “power beacons” [..] make the transmission of signals possible for distances up to 100 m. [..] The beacons also enable to“sniff” WLAN and Bluetooth-data within the reception radius. The data that can be collected includes timestamps for entering and leaving a defined zone. As a result, it is possible to measure visitor streams without the visitors using an app
This is of course just one example of existing deployments of vast arrays of Bluetooth sensors alongside other means of collection of more direct identifiers (security cameras, tickets, etc). Another example could be the deployment of "smart" advertising panels in the subway, or more exotic deployment of roving Bluetooth sensors in taxicabs in a city full of security cameras. There are very many possibilities according this New York Times report and no good reason to expect the situation is very different in Europe (see for instance the company Fluxloop and its high profile European clients, such as advertising panels JCDecaux).
These are obviously relevant as security actors, but they are also relevant to the data protection assessment because there are vast and already existing deployments of Bluetooth passive antennas.
I think this issue is being overlooked by everyone. The Google/Apple Contact Tracing / Exposure Notification specification (based on DP-3T) seems to do nothing to address this. To elaborate (and raise awareness of) the issue, I've written a small PoC that demonstrates BLE sniffing in this context: https://github.com/oseiskar/corona-sniffer . As noted by @pdehaye , systems that are capable of doing the same are already widespread
Thanks, @oseiskar. I think everyone knows this attack exists, but the fact that you implemented it changes the calculus around data protection risks. In other words, the PoC changes the legal calculus present in the White Paper (see many of the issues cross-referencing this one, which are clearly not addressed anywhere yet)
I don't share the opinion that "everyone knows this attack exists". This is really handled so far by broader audiences either as an esoteric hypothetical thing not worth worrying about or totally not understanding the scale and capabilities of existing BT tracking infrastructure. Some countries (e.g. Germany) seem to have no appetite at all to provide any specific legal framework for app-based contact tracing. The typical question is "Why would anyone want to collect and de-anonymize? The collected IDs have a limited lifespan.".
Update: I adjusted my PoC to also work with the DP-3T protocol (previously only targeted the Apple/Google EN protocol) and I verified that it works using the official DP-3T Android test app