
Can we stop Covid-19 using Bluetooth? - grafelic
https://github.com/AVICOT-APP/Documentation
======
nexuist
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?

~~~
thanksforfish
> 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.

~~~
c22
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.

~~~
sunemai
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!

~~~
c22
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

~~~
thanksforfish
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.

------
sunemai
Hi, I'm the developer behind [https://github.com/AVICOT-
APP/Documentation](https://github.com/AVICOT-APP/Documentation)

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](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.

~~~
tastroder
> Does the randomization happen at each new invocation of Bluetooth?

Doesn't matter.
[https://content.sciendo.com/view/journals/popets/2019/3/arti...](https://content.sciendo.com/view/journals/popets/2019/3/article-p50.xml)
\- 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.

~~~
sunemai
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.

~~~
tastroder
> 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.

~~~
sunemai
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;-)

~~~
tastroder
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.

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

Downsides:

You would need two smart watches.

You would need to code an "eating mode".

~~~
tailspin2019
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"?

~~~
anonu
It's yours!

~~~
tailspin2019
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.

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

[1]: [https://www.apple.com/icloud/find-
my/](https://www.apple.com/icloud/find-my/)

------
tastroder
@sunemai:

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.heise.de/newsticker/meldung/Medizinische-Hochschule-
Hannover-und-Ubilabs-entwickeln-Corona-App-4680487.html)

[https://www.geohealthapp.de/](https://www.geohealthapp.de/)

------
viztor
You can't.

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

~~~
georgeam
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.

~~~
tastroder
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.

------
fudged71
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?

~~~
tastroder
> 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.

------
jamesgeck0
This is basically just a more invasive StreetPass, as seen on Nintendo 3DS.

------
tastroder
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?

~~~
sunemai
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.

~~~
tastroder
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.

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

~~~
brookish
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.

‘[https://www.gojo.com/en/Newsroom/Press-Releases/2019/GOJO-
Ex...](https://www.gojo.com/en/Newsroom/Press-Releases/2019/GOJO-Expands-
PURELL-SMARTLINK-Portfolio-with-Individual-Monitoring-Solution‘)

