3 ms·
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 - an
by sunemai 7y ago
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 7y ago> Does the randomization happen at each new invocation of Bluetooth? Doesn't matter. https://content.sciendo.com/view/journals/popets/2019/3/article-p50.xml 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.
- sunemai 7y agoThe 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 7y ago> 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 7y agoYour 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;-)