SUsunemai·Mar 8, 2020
Hi, I'm the developer behind 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) - 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, s
Read the rest
o 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.