12-11-2020, 11:41 AM
(12-11-2020, 03:24 AM)M T Wrote: I am someone who is tech-savvy and concerned about how much data is gathered about me that I don't think others should collect (and sell!). In March, before I saw the details of the Apple/Google system, I heard of the concept of a phone keeping track of who was in its vicinity, so one could do contact-tracing. I worked through how one could do something with the app that maintains privacy but does the association of a infected person with you.
As it turned out, my design was pretty similar to the Apple-Google methodology. That similarity isn't surprising as it is fairly obvious how one would approach this to maintain privacy. Actually, compared to mine, the Apple-Google design was better in one important way.
I'm sure others have shown their own explanations of how it works, but you can see the basic concept of the method in question 4 of the Apple-Google FAQ about their Exposure-Notification system. If you want more technical information, more can be found at this page. In particular, what I consider the interesting information can be found in the Bluetooth Specification for the system.
Note that you can use this system to alert you to an exposure but then decline to share the fact that you get COVID.
===========
The "rolling proximity indicator" (RPI, the temporary id for your device) is a 128-bit number. It is broadcast by your device about 4 times a second. It is changed every 10-20 minutes (actual interval is random). Also broadcast in the same message4 is Associated Encrypted Metadata AEM, which encodes the version of the algorithm used and the transmit strength. Each is the result of encrypting a time-based string via the 128-bit pseudorandom number (temporary exposure key, TEK) generated daily.
Your device remembers your 14 TEK's for the last 14 days. It also keeps track of all the RPIs (with their associated, AEM) and measured signal strength and time of detection, for the last 14 days.
If you get COVID, you can choose to reveal your 14 TEKs. This can be done in a way that can be authenticated by your health department. (I'm not sure how that authentication is done. If some bad guy wanted to upload a million such keys, maybe it could be done. But the likelihood that a million or even a trillion such false keys would match even one real key is vanishingly small.)
These revealed 14 TEKs are now called Diagnosis Keys. They would be supplied to the app of anyone in the public health area (for instance, California). If you were in multiple areas during that 14 days, they would need to be distributed there too.
Every user's app will download all Diagnosis Keys they haven't yet processed. From those keys, your app will generate all the RPIs that would have been broadcast using each key and see if there are any matches. If there are matches, your app will decode the associated encrypted metadata received with the RPI and compare the transmit strength with the received strength of the signal. It will also see how many times it saw that signal. The app will then apply an algorithm to determine whether your are a close contact or not. If so, you will be notified that you may have been exposed. In theory, it could tell you the 10-minute windows when you had the contact, but I believe that is not done.
=======
Privacy risks that I have thought of:
1. If you are ever close enough to someone, you could record his RPI. It wouldn't be hard to detect a particular person's RPI at some point. If they ever broadcast their TEK for that day, then you know that person probably has COVID and chose to release his TEKs.
2. If you monitored a location, you could record the RPIs at the location. If you identified a person's RPI from that day, and he later revealed his TEKs, you could prove that person was in the location at the time you recorded it.
3. If you wanted to disrupt a target(s), you could intentionally "expose" him/them with a device that was close enough to him for long enough. Subsequently you could associate that device with someone who tested positive. That would cause a notification to the target(s) that he/they was/were exposed. This could be used to attempt to identify people in a group meeting. (Suppose you sent an FBI agent into a KKK meeting where everyone was masked. The agent's TEK for that day was released, causing the people in that meeting to get a notification all about the same time that they had been exposed. You can't prove they were in the meeting from that, but see (4).)
3a. This anonymity of the exposure notification is both a strength and a weakness. It protects the privacy of the person reporting COVID, but it simultaneously hides the identity of a person who intentionally causes a notification to a person with the intent to cause problems for that person.
4. If phones were seized and the authorities were able to get to the TEKs of the devices, they would then be able to show they were together at some period in time. If (2) were also done, they may be able to prove that they were at the location. (For instance, a phone accessible to authorities was in a bank vault when a bunch of bank robbers broke into it.) (Knowing Apple, I bet the TEKs are in an encrypted storage that requires your phone to be on & unlocked to be accessible. I'd expect that of Google too.)
5. You could use an app or device that records the RPIs, but also the location and time. If you get access to the Diagnosis Keys, you could identify just when & where you were exposed, making it likely that you could identify the individual. For instance, a business might put a device near an entrance (with video recording) that records the RPI. If it can get the Diagnosis Keys, it then could find if any of those that entered their property submitted a Diagnosis Key within 14 days. Whether you can get those Diagnosis Keys outside the app, I'm not sure, but I'd expect so.
If either (1) or (2) concerns you, you should not reveal your TEKs. For most of us, I doubt they are of concern.
If you're concerned about (3) or (4), you probably do not want to enable this app.
My problem is that I don’t trust either Google or Apple.