|
> My reading of the code and solution architecture is that the system is anonymised, with IDs generated using random rotating keys. Yes - the system is arguably about as private as you can get, if you aim for "level" playing field privacy. It is possible to have more privacy if you accept privacy asymmetry. The decentralised contact tracing approaches, for example, give the "infected" less privacy, as they need to broadcast out a list of "infected" people's temporary IDs. If you log the time of each observed contact, then go back and check your calendar, it's pretty likely you can figure out who you met that was infected, just based on time correlation. In the NHS approach there is a long term (but still randomly generated) identifier for each user, that's encrypted via an ECDH key exchange and included in the "daily" data blob. This lets the clinical model (but not other users) link back together one user's exposure events, and understand the extent to which they've been exposed to the virus, and therefore approximate the likelihood they have it. > My view is that a decentralised approach might not provide enough data to perform adequate contact tracing [...] However, I do feel that, with a centralised approach, there exists a much better chance of doing something useful with the pooled data. This is the view of the NHS as well, it seems. They feel it's important to get reports of symptoms, not just "positive tests". Given the incubation period of the disease, and the reports people are most infective a day or two before the symptoms show, this seems to hold true - the sooner you can alert someone to proactively self-isolate, the better. If you wait for the test result (assuming it takes maybe a day to get a test done, and a day for the result), that's the difference between asking a contact to isolate before they hit their suspected "most infective" time, versus asking someone to isolate as they're about to experience symptoms anyway. Just to demonstrate this: Imagine A is infected on day 1. On day 4, A met with B and C. A experiences symptoms a few hours into day 6. With a decentralised approach, you really need the certainty of a test before uploading anything, to stop Sybil-like attacks. Most probably, A would be tested the following day (day 7), and get a result (while isolating at home) a few hours into day 8. Meanwhile, B and C are walking around in the population, on day 7 and 8 (days 3 and 4 of their own infection, the time they are likely to be most infectious). They get asked to return home, and probably experience symptoms the next morning. In the NHS approach, when A experiences symptoms on day 6, they report this via the app, and are told to go home and self-isolate. B and C might also be asked to isolate, based on their contact with A, at this time. This gets B and C at home and isolated on day 2 of their own infection, and has them at home during their 2 most infectious days. If neither gets symptoms, and others exposed to A don't develop symptoms either, the daily "how are you feeling" polling via the app for symptoms will be able to capture that based on lack of symptoms, there likely wasn't exposure, and the group can leave self-isolation. Testing then augments this for more certainty, but this model does appear to be quite novel and unique, and near impossible to do in the decentralised approach (especially some of the more complex parts like deciding how likely A is to spread the virus, based on A's own exposure to infected people in A's recent past, and the date A reports symptoms). > Even extending the code base to support additional proximity events such as use of public transportation. In essence, public transport is the real goal of this app. The traditional contact tracing approach (people asking you for names and phone numbers, then calling them up to alert them) will catch the social contacts. It's the random encounter type situations, where strangers may be proximate, where the app plays a part. The app itself isn't going to be a single solution. |
Due to all the hardware and environmental factors, it really works as a large spreadsheet of all devices in Bluetooth range over the last 21 days (in the case of the Australian COVIDSafe app).
All it can do to grasp at the environmental context is to record the phone model, and the RSSI over time.
In a dynamic, real-world environment that will vary hugely, especially on public transport, as human bodies could be in the exact same close spot, but due to phone position and rotation the RSSI will vary wildly (as mentioned in the video), making two people close to each other actually look 20 metres or more away.
The huge amount of contacts each have to be manually contacted and interviewed to determine whether they're epidemiologically relevant. That also relies on the recall of the infected and the false 'close contacts' who are at risk of having to isolate for up to 14 days regardless of test or symptoms (according to a reading of the Australian rules).
This reality is extremely divorced from the Oxford University paper, which imagined a system that could accurately determine proximity of users and instantly notify them to isolate. This rapid notification and isolation was, in fact, the central proof of the impact of a digital contact tracing system.
So we have a centralised system that:
* only 'works' in a 'mandatory install' context
* can't determine proximity in the real-world (too much variability)
* would introduce huge numbers of false positives into a system that has to manually follow-up every one
* normalises carrying a tracking device of all nearby people (which in future would be far more useful as a societal monitoring system than as an epidemiological tool)