Name: Anonymous 2020-04-11 12:57
Leave your phone at home!
https://threadreaderapp.com/thread/1248707315626201088.html
First look at Apple/Google contact tracing framework:
1) Once a day, your device derives a new key ("daily tracing key").
2) It uses that to derive a new "proximity ID" every time your device's bluetooth address changes (15min), which is broadcast to nearby BT sensors.
1/10
3) Your device keeps track of all "proximity IDs" it sees.
4) If someone tests positive, they choose to publish their (previously secretly) "daily tracing keys."
5) Your device frequently DLs all published daily tracing keys and KDFs to see if they match recorded proximity IDs.
So first obvious caveat is that this is "private" (or at least not worse than BTLE), *until* the moment you test positive.
At that point all of your BTLE mac addrs over the previous period become linkable. Why do they change to begin with? Because tracking is already a problem.
So it takes BTLE privacy a ~step back. I don't see why all of the existing beacon tracking tech wouldn't incorporate this into their stacks.
At that point adtech (at minimum) probably knows who you are, where you've been, and that you are covid+.
Second caveat is that it seems likely location data would have to be combined with what the device framework gives you.
Published keys are 16 bytes, one for each day. If moderate numbers of smartphone users are infected in any given week, that's 100s of MBs for all phones to DL.
That seems untenable. So to be usable, published keys would likely need to be delivered in a more 'targeted' way, which probably means... location data.
Third caveat is that it seems likely some kind of PII would have to be combined with what the device framework gives you.
Keys published by a device have to then be in turn "published" to *all* devices in the world. That's a major DoS vector!
If anyone can anonymously blast up keys, they can create a situation where there's GBs of data for all devices in the world to retrieve and compute. There would likely need to be some kind of rate limiting on a combination of stable IDs (phone number, IP, etc) to prevent it.
Not to mention the "prank" aspect of being able to light up everyone you've been near's devices with "you've been exposed to covid" (without them knowing you're the culprit) at any time, without some kind of pretty heavy manual ID/result verification at the moment of reporting.
All that aside, these APIs are novel in terms of what becomes possible from the app layer.
I'm not super optimistic about opt-in contact tracing becoming a major factor, but I do kind of anticipate that someone will end up using this for some other interesting thing.
https://threadreaderapp.com/thread/1248707315626201088.html
First look at Apple/Google contact tracing framework:
1) Once a day, your device derives a new key ("daily tracing key").
2) It uses that to derive a new "proximity ID" every time your device's bluetooth address changes (15min), which is broadcast to nearby BT sensors.
1/10
3) Your device keeps track of all "proximity IDs" it sees.
4) If someone tests positive, they choose to publish their (previously secretly) "daily tracing keys."
5) Your device frequently DLs all published daily tracing keys and KDFs to see if they match recorded proximity IDs.
So first obvious caveat is that this is "private" (or at least not worse than BTLE), *until* the moment you test positive.
At that point all of your BTLE mac addrs over the previous period become linkable. Why do they change to begin with? Because tracking is already a problem.
So it takes BTLE privacy a ~step back. I don't see why all of the existing beacon tracking tech wouldn't incorporate this into their stacks.
At that point adtech (at minimum) probably knows who you are, where you've been, and that you are covid+.
Second caveat is that it seems likely location data would have to be combined with what the device framework gives you.
Published keys are 16 bytes, one for each day. If moderate numbers of smartphone users are infected in any given week, that's 100s of MBs for all phones to DL.
That seems untenable. So to be usable, published keys would likely need to be delivered in a more 'targeted' way, which probably means... location data.
Third caveat is that it seems likely some kind of PII would have to be combined with what the device framework gives you.
Keys published by a device have to then be in turn "published" to *all* devices in the world. That's a major DoS vector!
If anyone can anonymously blast up keys, they can create a situation where there's GBs of data for all devices in the world to retrieve and compute. There would likely need to be some kind of rate limiting on a combination of stable IDs (phone number, IP, etc) to prevent it.
Not to mention the "prank" aspect of being able to light up everyone you've been near's devices with "you've been exposed to covid" (without them knowing you're the culprit) at any time, without some kind of pretty heavy manual ID/result verification at the moment of reporting.
All that aside, these APIs are novel in terms of what becomes possible from the app layer.
I'm not super optimistic about opt-in contact tracing becoming a major factor, but I do kind of anticipate that someone will end up using this for some other interesting thing.