security and data protection-relevant actor missing: Proximity Tracking industry about documents HOT 4 OPEN

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

from documents.

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)

from documents.

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

from documents.

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.".

from documents.