This is a fantastic idea for retrospective infectious disease contact tracking. I hope this concept is picked up by WHO/government or at least put on a local trial.
Why don't phones already keep a local log of recent Bluetooth device IDs?
> Why don't phones already keep a local log of recent Bluetooth device IDs?
Because embedded hardware like phones usually only persistently store the information for which an actual use case exists. "recent BT device IDs" amounts to quite a bit of information (that is occasionally pretty useless in the case of unknown devices) and would require frequent scanning when you are on the move with little practical purpose outside the tracking space. There's enough approaches to create these profiles from the IT security and ad space but I consider myself lucky in living in a jurisdiction where such tracking is likely considered illegal.
I've heard that everybody is connected with a surprisingly low number of intermediate steps. Maybe now would be a good time to try that out;-) So, if you know anybody...
Unless you love fascism this is a train wreck of awful.
It's also full of incorrect statements.
This is not true. The medical community does not agree with this for many diseases and many levels of "non-negligible virus threat"
> Every responsible human being should be interested in knowing if he or she presents a non-negligible virus threat to family, friends, colleagues and thus – ultimately – society in general.
Wanted to chime in. We currently OEM a product to Purell (GOJO) on exactly this concept. Albeit additional hardware is required, we have been extremely successful locating staff and monitoring of dispensers with BLE.
Our goal has been to prevent the spread of infection in hospitals by monitoring hand hygiene compliance.
I read the article and largely agree with aaron965 on this.
There's a number of problems with saying "every responsible human being should be interested in knowing ...":
1) does knowing make you legally or criminally responsible for spreading the virus, as in the case of early AIDS patients?
2) Being exposed doesn't mean you'll get sick. So what to do next with the info you met somebody who is in the database?
3) In most Western countries, citizens can afford health care. However, in the USA and other developing nations, affording a hospital is not an option. So what's the point?
The article presents an interesting idea, but separating policy and technology concerns when it comes to healthcare is really not a great idea.
For now I think the traditional methods of dealing with seasonal flu make the most sense: offer information in the press and make affordable shots available.
Not sure OP is the same as the GitHub developer, but I want to applaud whoever took the time to write out this idea in a professional yet understandable manner. I had fun reading the paper.
Unfortunately this idea is (mostly) dead in the water if it sticks with its current implementation. The reason is that both Android and iOS now engage in MAC address randomization specifically to prevent being tracked by their unique IDs. This "feature" was previously commercialized by stores and private surveillance to track people moving around in a city or indoor building.
Fixing this is not impossible. Instead of Bluetooth tracking, the app could simply just record your location every poll update and save it locally. There is no invasion of privacy if the location file is never uploaded to the cloud. When someone tests positive, they could just have their location file uploaded (anonymously) and every device could cross check its location history with the infected person's.
Technology is likely not the barrier here. Notifying and training medical personnel to effectively use the app is, and getting the general public to "buy in" will cost an absolute fortune (in advertising dollars) for little to no return. This is one of those network paradox problems where you need lots of people for the network to be useful, but the network has to be useful to attract lots of people. How do you solve that?
> they could just have their location file uploaded (anonymously)
Anonymity is going to be hard, even with traditional methods, but I don't think a person's location history can ever be anonymous. Especially when presented with timestamps and spanning days. People generally spend a lot of time, or at least their night, in their home.
> This is one of those network paradox problems where you need lots of people for the network to be useful, but the network has to be useful to attract lots of people. How do you solve that?
Bake it into an existing app that already has the network, I.E. Facebook.
In principle it could be installed as a system/default app on Android and iOS by Google and Apple respectively. Even more reach for people that haven't installed Facebook.
I think you can get around this. Break the physical space up into blocks, say 100' square. Break the time component into 1 hour blocks. Concatenate the space and time components and hash them, then upload the hashes. If someone wants to see if they've potentially been exposed they can just hash their own time/location history and see if it gets a hit against the database.
Why not? To correlate any meaningful data an attacker would have to reverse a significant portion of the database. The most serious attack I see would be a brute force over time of Bob's location segment. At most this gives Eve retroactive information about when Bob was home after Bob has tested positive and uploaded his data. It still doesn't give any insight into where Bob went when he left except perhaps in extremely sparse areas. Our imaginary service can help reduce the impact of this attack further by rate limiting requests and discarding old data as soon as it's no longer relevant.
This failure mode is probably still less intrusive than the current system of asking people in quarantine to detail all of their recent movements.
Ironically, you might achieve better anonymity by making the time and space boundaries smaller, but at the expense of more false negatives when checking for exposure.
If you are able to check whether you've been in a "dangerous" space-time box yourself, then you are probably also able to check where these boxes are, I suppose? One way would be brute force hashing all possible space-time blocks and comparing with the public hashed list. This mechanism was why I abandoned the space-time box approach to begin with - but if you have an idea for a workaround, please get in touch!
1. Each client will sha256 hash their space-time box (lat,lon,timestamp each rounded to some suitable size). This is their space-time box hash.
2. Each client takes the first N bytes of their space-time box hash and registers it with a service. This must occur within M hours, to limit after the fact analysis. These are privately stored on the server and deleted after R days (R ~= 14 for corona virus IIRC).
3. Each person can blacklist certain places, like their home from getting reported. When home you probably know who you interact with, and don't need software to help. Also times, most people can probably recall who they sleep with so bedtime->alarm doesn't need to be tracked.
4. Someone gets sick. They can now choose to report and share their fine grained location history with the service. Ideally people choose to report and share for the sake of public health. They (or realistically a trusted healthy person) can shift through the location stats to see if there's any locations to skip (again, at home and sleeping times probably don't need to be reported as most folks recall who was there).
5. The service records the fine grained location data and notifies the app for everyone who reported a space-time hash prefix that matches. This will notify lots of non-matches as we only reported the first N bytes.
6. Each notified client then looks at their space-time hash and sends additional bytes to the service, checking if they match one by one. If a mismatch is found the client stops. The service refuses to allow this type of lookup except from clients that previously registered a matching hash prefix.
Someone needs to do the math to pick a good value for N and others.
This provides some protection from the service deanonymizing people and tries hard to only share matches with clients that were matched.
I like your added protections. Allowing people to filter their reported data might be enough to convince people to use it even without additional security.
Don't use sha256 for the hash, we need a slow hash like bcrypt or scrypt. Since entries only need to be updated when moving between time boxes or space boxes we can in fact configure this to be quite slow.
You could make it a bit more robust by requiring clients to upload a minimum number of unique hashes with their query then respond only with an "exposed" or "not exposed" response. Then you can check for clients that are repeatedly uploading the same hashes to weed out brute forcers.
I think it would be pretty impractical to brute force all possible space-time blocks. Even if you just wanted to look at the state of California over 24 hours you're looking at 1.0952599e+12 hashes [0]. Say your rig can try 500k hashes a second, that's still almost a month. So now you know the rough locations of every infected person in California over the course of one day, you still have to disentangle the movements of overlapping users. You can make this even harder by requiring people to loiter in a space box for a minimum amount of time before creating an entry, so travel by bike/train/plane/automobile wont be tracked at all.
Clearly the scheme is resistant against mass de-anonymization, but if you knew some specific locations where you thought a specific person might go you could target those space-boxes and, assuming there are not many other infected users in the area, get a sense of when that person was at those places.
[0] 163,696 sq miles = 4.563583e+12 sqft = 45,635,830,000 100sqft space boxes * 24 = 1.0952599e+12
Ah good point about overlapping location data for sick users, that would add ambiguity.
This approach still puts a lot of trust in the server. Every client needs to upload their hashes to the server, so if the group running the server wanted to reverse the hashes they'd get everyone's location, not just sick people. The server would also know which hashes were popular, indicating that they are crowded areas like a city or event center. From a tracking perspective the fact that two people were in the same location is useful to start making inferences, even if the location isn't known.
The "buy in" issue is why I consider using Denmark (which is where I live) as an initial test area before internationalization: Danes are generally well educated, and they have a high trust in public authorities compared to many other countries. The use of open source software is also widespread in Denmark.
So an app/server solution developed with 100% transparency on GitHub could easily be pushed to everybody by public authorities - under the critical assumption that we can both make it work technically, and make it completely anonymous.
Just for reference, the same "scale problem" is also the challenge with ordinary vaccines, as I understand it:
They don't really need to give 100% protection to each individual. The critical point is that if a large enough percentage of the population has the vaccine, the R_0 parameter of the given disease will drop below 1, and the exponential spreading turns into an exponential decline.
I have another app idea. Quite a bit less sophisticated than what's proposed in the article. But still technically challenging: it's called FaceWatch.
You use the accelerometers in a smartwatch to detect a hand getting closer to the face. If a threshold is breached an alarm is raised on your phone. The pavlovian response is to avoid touching your face and potentially spreading diseases from you hands.
I've written such an app, which was originally designed for Eczema sufferers to stop touching/scratching their face. I am about to release a beta version (free) aimed at reducing face touching for the Coronavirus. Would you mind if I used your proposed app name "FaceWatch"?
Great, thank you. I'll comment back here with any updates. The app is very simplistic but I thought it might be worth getting it out there sooner rather than later in case it turns out to be useful to someone. Even if one person can help themselves learn to avoid touching their face and reduce the risk of COVID-19 it will have been worth doing.
The Chinese Government already deployed Health Code, which pulls data from cell towers to check for cross paths with confirmed or suspected patients, and shows on screen as green, yellow or red colored QR code.
To have this Bluetooth idea effective, you need to have sufficiently numbers of installation, and which can be insanely difficult if it weren't pushed by big corps or the government
I agree -- I would say the government should recognize the utility of the idea and request an emergency technical team from both Apple and Google to join up in a public-health emergency response consortium (to ensure interoperability) and brainstorm this idea. And Microsoft too, if they are still making windows phones.
I'm sorry but are you literally asking governments to cooperate with Apple and Google to backdoor all of our devices or do so and bully the population into submitting their data? There's a point where we need to talk about trade-offs between tracking potential disease contacts and what this does to our society. China isn't supposed to be a role model in this regard people.
I'm not sure how the section on GDPR actually answers the question it poses. "Any technological solution that tries to mimic the contact tracking performed by medical authorities will automatically break GDPR. Or will it really?" The former has little to do with the latter. If you track PII that's a potential GDPR issue, no matter how humanistic the purpose of your app is. NAL but from the legal side this use case does not seem any different from ad tracking companies doing the same thing. What is the fictional "rephrasing" of what this does supposed to change about the legal implications?
The point is that, currently, people are "tracked down" by medical authorities and put in quarantine.
The AVICOT-APP concept is opposite: People would (should) like to know if they represents a danger to, say, their elderly parents, who may die if infected. Thus, there is no need for "the system" to be able to track or identify them at all. Only you, the end user, will ever know if you are in high risk.
People are infected by contact with another infected person. There's a middle ground between "ineffective tracking by authorities through Excel sheets" (as seen in Germany) and giving up privacy and this proposal honestly can't be it.
> Only you, the end user, will ever know if you are in high risk.
In it's current iteration the protocol you propose contains this:
"3. Regularly, e.g. every 6 hours, the AVICOT-APP checks the public “COVID-19 level 0” list on a WHO-organized AVICOT-SERVER. Entries in this are Bluetooth IDs of devices owned/used by officially diagnosed COVID-19 cases, who have given their consent to this publication. The list may be regionally organized, to limit mobile data requirements."
If it is regionally organized this seems like a technical gimmick. If it has a larger scale, there remain privacy implications that would have to be carefully investigated, even with user consent - which dismisses it completely for any form of rapid deployment. Take the above, you either risk exposing Bluetooth hardware identifiers of those consenting known infected or, rely on me uploading my data to whoever it is that runs this. A better model for that part would be something like what HIBP does for password breaches but my point is that the proposal does not address this and since puts doubt on the "anonymity" part of the title. Even if it did, a large part of HIBP is that I can't control that HIBP has the information in the first place. The submission calls all this "sufficiently anonymous" and I would argue that there is no such thing, especially in this context.
Or point 4. "The server then evaluates the data with an algorithm designed to estimate the infection risk." why? We have people that can do that, more effectively than a hastily written algorithm. This just adds unnecessary fluff. Point 5 is just redundant with point 4.
I have no doubt that this is done with the best intentions in mind but the road to privacy hell is paved with those. We would be better off if we used our collective tech knowledge to build something that makes us more prepared and facilitates collaboration on the authority level for the next time we might need it.
Thank you all for your valuable input - and sorry for the late reply: I posted under my own account (https://news.ycombinator.com/item?id=22462696) - but this thread initiated by a friend was the one to be picked up.
I'll try to address some of the issues brought up under each comment later, but here is a few things to consider first:
The MAC address randomization is a key issue here. For the "level 0 list", though, it might not be that much of a problem: If the app also keeps track of its own actual MAC address(es), then these are what would be published in the "level 0 list", along with the corresponding time-index. I'll update the GitHub description to take this into account, but please help me answer some of these questions first (or, better, write me an email, so you can contribute directly to the AVICOT/Documentation repo) :
Does the randomization happen at each new invocation of Bluetooth?
Is it coupled with the "location services" as suggested by jackweirdy below?
Another important point is that of using location tracking instead, as suggested by c22. I had this exact scheme as the initial AVICOT concept, but abandoned it because even with one-way hashing of the coordinates of the space-time boxes, the locations (and thus identity) of the infected person can easily be calculated if the (hashed) "dangerous" space-time boxes are publicly available.
One really good point of using space-time location boxes is, that you can assign an infection risk to being at the same location, say 3 hours later (e.g. use an exponential risk decay with some suitable half-life parameter). This is not possible with the Bluetooth IDs. But unless we solve the anonymity issue in some way, I think the Bluetooth way is easier.
> Does the randomization happen at each new invocation of Bluetooth?
Doesn't matter. https://content.sciendo.com/view/journals/popets/2019/3/arti... - note that this is seemingly aptly published in a conference on privacy. Yes, what you want to use bluetooth for would likely work but we've worked a decade or so to prevent it.
You'll likely realize from my other comment that I dislike the general idea of this but honestly, I don't get the approach from a technical perspective. The idea is an app for smartphones, right? You have all kinds of sensors on those besides BT, e.g. WiFi, GPS. Comparing timestamped movement profiles would give you much better matching than approximating this stuff via BT environments, which these days at least theoretically are designed to explicitly prevent your use case and just seem to limit yourself artificially. The reason you dismissed geolocation is perfectly valid but that also applies to Bluetooth identifiers if you treat them as reliable indicators. If I get a (hashed or not) BT ID of infected persons, I can identify those - at the very least if their device is in my vicinity. And not only while this issue is active but afterwards. You would have to protect that data just as much, putting another ding in the "potential privacy implications" of the approach.
The privacy issue is complex. My take on it is quite simple:
I personally wouldn't mind if my (possibly randomized) BT address was made public, potentially identifying me as currently COVID-19 infected - heck, we will probably all have been on that list in a year or two as things stand today.
What someone (not me, of course) would probably mind, however, is if the geolocation data was used instead - and it showed what clubs I went to during the last 14 days.
> What someone (not me, of course) would probably mind, however, is if the geolocation data was used instead - and it showed what clubs I went to during the last 14 days.
And my point remains that, from a privacy perspective, that distinction is artificial and misleading. Your phone in this mode is seeing BT/BTLE devices all the time, which is why this (or WiFi / GPS profiling) work. On my route to work I pass by dozens if not more BT devices with static location, somebody with detailed log data over a few days will be able to mark both locations in a pretty fine grained manner. The proposed process is not and can not be anonymized sufficiently. Correlation is cheap these days, with big enough adoption a company with enough incentive or something like wigle.net for bluetooth devices will appear and the data will be misused. That might not present a viable problem in the short term during the current outbreak but the long term implications of tracking like this need to be discussed before releasing such a tool to the public.
There's other issues, e.g. a more direct and immediate scenario where Alice knows Bobs bluetooth MAC, as well as an infected in likely proximity, and dumps fake data into your service in order to quarantine him.
Your comments are very interesting, and I'd like more input/thoughts about such issues.
However, from your description of the Alice/Bob part, I'm still confused whether you realize that nobody is (or can be) quarantined in the proposed scheme?
The case you describe would, as I understand it be:
"Bob is then advised by his own app not to visit his parents and be careful about not infecting others". A bad joke, sure, but not something that can "send him into quarantine", since nobody on the server side knows that he is in any danger.
I may be missing your point here - but if I am, please clarify and bare with me;-)
The point of that scenario was that, if the app takes off it it could quickly turn from a bad joke scenario to one with real impact. Either by Bob taking the reasonable step of self quarantine, unnecessary test + fearful waiting time, or in the worst case the app could be, like it's Chinese equivalent, used to restrict Bob's movement by others at checkpoints. Severside knowledge is pretty irrelevant if an armed guard or angry mob wants you to show the app before letting you get your Sunday brunch.
This idea reminds me of Apple’s approach to Find My offline device: [1]
> Find My can help you locate a missing device — even if it’s offline and sleeping — by sending out Bluetooth signals that can be detected by Apple devices in use nearby. These devices then relay the detected location of your device to iCloud so you can locate it in the Find My app. It’s all anonymous and encrypted end-to-end so no one, including Apple, knows the identity of any reporting device.
41 comments
[ 3.7 ms ] story [ 77.2 ms ] threadWhy don't phones already keep a local log of recent Bluetooth device IDs?
Because embedded hardware like phones usually only persistently store the information for which an actual use case exists. "recent BT device IDs" amounts to quite a bit of information (that is occasionally pretty useless in the case of unknown devices) and would require frequent scanning when you are on the move with little practical purpose outside the tracking space. There's enough approaches to create these profiles from the IT security and ad space but I consider myself lucky in living in a jurisdiction where such tracking is likely considered illegal.
It's also full of incorrect statements.
This is not true. The medical community does not agree with this for many diseases and many levels of "non-negligible virus threat"
> Every responsible human being should be interested in knowing if he or she presents a non-negligible virus threat to family, friends, colleagues and thus – ultimately – society in general.
Our goal has been to prevent the spread of infection in hospitals by monitoring hand hygiene compliance.
‘https://www.gojo.com/en/Newsroom/Press-Releases/2019/GOJO-Ex...
There's a number of problems with saying "every responsible human being should be interested in knowing ...":
1) does knowing make you legally or criminally responsible for spreading the virus, as in the case of early AIDS patients?
2) Being exposed doesn't mean you'll get sick. So what to do next with the info you met somebody who is in the database?
3) In most Western countries, citizens can afford health care. However, in the USA and other developing nations, affording a hospital is not an option. So what's the point?
The article presents an interesting idea, but separating policy and technology concerns when it comes to healthcare is really not a great idea.
For now I think the traditional methods of dealing with seasonal flu make the most sense: offer information in the press and make affordable shots available.
Unfortunately this idea is (mostly) dead in the water if it sticks with its current implementation. The reason is that both Android and iOS now engage in MAC address randomization specifically to prevent being tracked by their unique IDs. This "feature" was previously commercialized by stores and private surveillance to track people moving around in a city or indoor building.
Fixing this is not impossible. Instead of Bluetooth tracking, the app could simply just record your location every poll update and save it locally. There is no invasion of privacy if the location file is never uploaded to the cloud. When someone tests positive, they could just have their location file uploaded (anonymously) and every device could cross check its location history with the infected person's.
Technology is likely not the barrier here. Notifying and training medical personnel to effectively use the app is, and getting the general public to "buy in" will cost an absolute fortune (in advertising dollars) for little to no return. This is one of those network paradox problems where you need lots of people for the network to be useful, but the network has to be useful to attract lots of people. How do you solve that?
Anonymity is going to be hard, even with traditional methods, but I don't think a person's location history can ever be anonymous. Especially when presented with timestamps and spanning days. People generally spend a lot of time, or at least their night, in their home.
> This is one of those network paradox problems where you need lots of people for the network to be useful, but the network has to be useful to attract lots of people. How do you solve that?
Bake it into an existing app that already has the network, I.E. Facebook.
This failure mode is probably still less intrusive than the current system of asking people in quarantine to detail all of their recent movements.
Ironically, you might achieve better anonymity by making the time and space boundaries smaller, but at the expense of more false negatives when checking for exposure.
Here's the best I got:
1. Each client will sha256 hash their space-time box (lat,lon,timestamp each rounded to some suitable size). This is their space-time box hash. 2. Each client takes the first N bytes of their space-time box hash and registers it with a service. This must occur within M hours, to limit after the fact analysis. These are privately stored on the server and deleted after R days (R ~= 14 for corona virus IIRC). 3. Each person can blacklist certain places, like their home from getting reported. When home you probably know who you interact with, and don't need software to help. Also times, most people can probably recall who they sleep with so bedtime->alarm doesn't need to be tracked. 4. Someone gets sick. They can now choose to report and share their fine grained location history with the service. Ideally people choose to report and share for the sake of public health. They (or realistically a trusted healthy person) can shift through the location stats to see if there's any locations to skip (again, at home and sleeping times probably don't need to be reported as most folks recall who was there). 5. The service records the fine grained location data and notifies the app for everyone who reported a space-time hash prefix that matches. This will notify lots of non-matches as we only reported the first N bytes. 6. Each notified client then looks at their space-time hash and sends additional bytes to the service, checking if they match one by one. If a mismatch is found the client stops. The service refuses to allow this type of lookup except from clients that previously registered a matching hash prefix.
Someone needs to do the math to pick a good value for N and others.
This provides some protection from the service deanonymizing people and tries hard to only share matches with clients that were matched.
How's that work?
Don't use sha256 for the hash, we need a slow hash like bcrypt or scrypt. Since entries only need to be updated when moving between time boxes or space boxes we can in fact configure this to be quite slow.
I think it would be pretty impractical to brute force all possible space-time blocks. Even if you just wanted to look at the state of California over 24 hours you're looking at 1.0952599e+12 hashes [0]. Say your rig can try 500k hashes a second, that's still almost a month. So now you know the rough locations of every infected person in California over the course of one day, you still have to disentangle the movements of overlapping users. You can make this even harder by requiring people to loiter in a space box for a minimum amount of time before creating an entry, so travel by bike/train/plane/automobile wont be tracked at all.
Clearly the scheme is resistant against mass de-anonymization, but if you knew some specific locations where you thought a specific person might go you could target those space-boxes and, assuming there are not many other infected users in the area, get a sense of when that person was at those places.
[0] 163,696 sq miles = 4.563583e+12 sqft = 45,635,830,000 100sqft space boxes * 24 = 1.0952599e+12
This approach still puts a lot of trust in the server. Every client needs to upload their hashes to the server, so if the group running the server wanted to reverse the hashes they'd get everyone's location, not just sick people. The server would also know which hashes were popular, indicating that they are crowded areas like a city or event center. From a tracking perspective the fact that two people were in the same location is useful to start making inferences, even if the location isn't known.
So an app/server solution developed with 100% transparency on GitHub could easily be pushed to everybody by public authorities - under the critical assumption that we can both make it work technically, and make it completely anonymous.
Just for reference, the same "scale problem" is also the challenge with ordinary vaccines, as I understand it:
They don't really need to give 100% protection to each individual. The critical point is that if a large enough percentage of the population has the vaccine, the R_0 parameter of the given disease will drop below 1, and the exponential spreading turns into an exponential decline.
You use the accelerometers in a smartwatch to detect a hand getting closer to the face. If a threshold is breached an alarm is raised on your phone. The pavlovian response is to avoid touching your face and potentially spreading diseases from you hands.
Downsides:
You would need two smart watches.
You would need to code an "eating mode".
The Chinese Government already deployed Health Code, which pulls data from cell towers to check for cross paths with confirmed or suspected patients, and shows on screen as green, yellow or red colored QR code.
To have this Bluetooth idea effective, you need to have sufficiently numbers of installation, and which can be insanely difficult if it weren't pushed by big corps or the government
The AVICOT-APP concept is opposite: People would (should) like to know if they represents a danger to, say, their elderly parents, who may die if infected. Thus, there is no need for "the system" to be able to track or identify them at all. Only you, the end user, will ever know if you are in high risk.
> Only you, the end user, will ever know if you are in high risk.
In it's current iteration the protocol you propose contains this:
"3. Regularly, e.g. every 6 hours, the AVICOT-APP checks the public “COVID-19 level 0” list on a WHO-organized AVICOT-SERVER. Entries in this are Bluetooth IDs of devices owned/used by officially diagnosed COVID-19 cases, who have given their consent to this publication. The list may be regionally organized, to limit mobile data requirements."
If it is regionally organized this seems like a technical gimmick. If it has a larger scale, there remain privacy implications that would have to be carefully investigated, even with user consent - which dismisses it completely for any form of rapid deployment. Take the above, you either risk exposing Bluetooth hardware identifiers of those consenting known infected or, rely on me uploading my data to whoever it is that runs this. A better model for that part would be something like what HIBP does for password breaches but my point is that the proposal does not address this and since puts doubt on the "anonymity" part of the title. Even if it did, a large part of HIBP is that I can't control that HIBP has the information in the first place. The submission calls all this "sufficiently anonymous" and I would argue that there is no such thing, especially in this context.
Or point 4. "The server then evaluates the data with an algorithm designed to estimate the infection risk." why? We have people that can do that, more effectively than a hastily written algorithm. This just adds unnecessary fluff. Point 5 is just redundant with point 4.
I have no doubt that this is done with the best intentions in mind but the road to privacy hell is paved with those. We would be better off if we used our collective tech knowledge to build something that makes us more prepared and facilitates collaboration on the authority level for the next time we might need it.
Thank you all for your valuable input - and sorry for the late reply: I posted under my own account (https://news.ycombinator.com/item?id=22462696) - but this thread initiated by a friend was the one to be picked up.
I'll try to address some of the issues brought up under each comment later, but here is a few things to consider first:
The MAC address randomization is a key issue here. For the "level 0 list", though, it might not be that much of a problem: If the app also keeps track of its own actual MAC address(es), then these are what would be published in the "level 0 list", along with the corresponding time-index. I'll update the GitHub description to take this into account, but please help me answer some of these questions first (or, better, write me an email, so you can contribute directly to the AVICOT/Documentation repo) :
Does the randomization happen at each new invocation of Bluetooth?
Is it coupled with the "location services" as suggested by jackweirdy below?
Another important point is that of using location tracking instead, as suggested by c22. I had this exact scheme as the initial AVICOT concept, but abandoned it because even with one-way hashing of the coordinates of the space-time boxes, the locations (and thus identity) of the infected person can easily be calculated if the (hashed) "dangerous" space-time boxes are publicly available.
One really good point of using space-time location boxes is, that you can assign an infection risk to being at the same location, say 3 hours later (e.g. use an exponential risk decay with some suitable half-life parameter). This is not possible with the Bluetooth IDs. But unless we solve the anonymity issue in some way, I think the Bluetooth way is easier.
Doesn't matter. https://content.sciendo.com/view/journals/popets/2019/3/arti... - note that this is seemingly aptly published in a conference on privacy. Yes, what you want to use bluetooth for would likely work but we've worked a decade or so to prevent it.
You'll likely realize from my other comment that I dislike the general idea of this but honestly, I don't get the approach from a technical perspective. The idea is an app for smartphones, right? You have all kinds of sensors on those besides BT, e.g. WiFi, GPS. Comparing timestamped movement profiles would give you much better matching than approximating this stuff via BT environments, which these days at least theoretically are designed to explicitly prevent your use case and just seem to limit yourself artificially. The reason you dismissed geolocation is perfectly valid but that also applies to Bluetooth identifiers if you treat them as reliable indicators. If I get a (hashed or not) BT ID of infected persons, I can identify those - at the very least if their device is in my vicinity. And not only while this issue is active but afterwards. You would have to protect that data just as much, putting another ding in the "potential privacy implications" of the approach.
I personally wouldn't mind if my (possibly randomized) BT address was made public, potentially identifying me as currently COVID-19 infected - heck, we will probably all have been on that list in a year or two as things stand today.
What someone (not me, of course) would probably mind, however, is if the geolocation data was used instead - and it showed what clubs I went to during the last 14 days.
And my point remains that, from a privacy perspective, that distinction is artificial and misleading. Your phone in this mode is seeing BT/BTLE devices all the time, which is why this (or WiFi / GPS profiling) work. On my route to work I pass by dozens if not more BT devices with static location, somebody with detailed log data over a few days will be able to mark both locations in a pretty fine grained manner. The proposed process is not and can not be anonymized sufficiently. Correlation is cheap these days, with big enough adoption a company with enough incentive or something like wigle.net for bluetooth devices will appear and the data will be misused. That might not present a viable problem in the short term during the current outbreak but the long term implications of tracking like this need to be discussed before releasing such a tool to the public.
There's other issues, e.g. a more direct and immediate scenario where Alice knows Bobs bluetooth MAC, as well as an infected in likely proximity, and dumps fake data into your service in order to quarantine him.
However, from your description of the Alice/Bob part, I'm still confused whether you realize that nobody is (or can be) quarantined in the proposed scheme?
The case you describe would, as I understand it be: "Bob is then advised by his own app not to visit his parents and be careful about not infecting others". A bad joke, sure, but not something that can "send him into quarantine", since nobody on the server side knows that he is in any danger.
I may be missing your point here - but if I am, please clarify and bare with me;-)
> Find My can help you locate a missing device — even if it’s offline and sleeping — by sending out Bluetooth signals that can be detected by Apple devices in use nearby. These devices then relay the detected location of your device to iCloud so you can locate it in the Find My app. It’s all anonymous and encrypted end-to-end so no one, including Apple, knows the identity of any reporting device.
[1]: https://www.apple.com/icloud/find-my/
Just fyi, here in Germany a medical uni and some companies seem to currently do the geodata approach:
https://www.heise.de/newsticker/meldung/Medizinische-Hochsch...
https://www.geohealthapp.de/