-
Notifications
You must be signed in to change notification settings - Fork 178
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
security and data protection-relevant actor missing: Proximity Tracking industry #43
Comments
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 |
The Proxbook report on "Proximity marketing in airports and transportation" states the following concerning Munich airport:
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.
The text was updated successfully, but these errors were encountered: