Can we stop Covid-19 using Bluetooth?
github.com
github.com
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.
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;-)
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".
> 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.
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...
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
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.
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.
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.