The 1st NHS App
Following my talk at Beercon 2: Rise of the Rookie , Bee asked for my opinion on contact tracing apps with regards to privacy and compliance. There are many ways to attempt fighting for privacy with this type of applications, but in the end, to fight the virus some leeway needs to be given. The question is how much leeway and who should be getting the additional data?
Looking at the 1st app deployed by the NHS it seems to work by having devices communicate with a central server announcing what they have seen. The clear advantage of this system is that when a person states they are positive, the government has data on the devices of all the people the infected person was in contact with in the previous X days which then corroborates on the server which people to inform based on risk factors.
You might think “this is great!”. After all, a double confirmation that someone needs to isolate is better than no confirmation. Yet, this approach is risky in regards to privacy and data protection: with enough data points, patterns emerge and people become recognisable. I could not find any policies at the time stipulating how long data was being kept, meaning people could be linked back to their social circles. “But this is great!” you think to yourself, before remembering some people, such as whistle blowers, can’t afford to have that kind of exposure.
So what are the known issues with this app? From a purely technological standpoint, the UK decided not to use the Google-Mac API as they wanted to be able to process the data and potentially get 3rd parties involved in the processing. In doing so, they limited the amount of devices capable of continuously emitting BLE signals and therefore the tracking / tracing capacity of the platform. This is due to both manufacturers limiting how apps can broadcast to avoid spam abuse. On the data side, we have the centralised data approach which generates risks to privacy. Germany initially sought a centralised platform, later moving to decentralised due to the privacy issues.
The 2nd NHS app
Following the issues of the first app, the UK followed Germany’s example and took to working on an app using the Google-Mac APIs. While not the end-all solution to prevent the apocalypse, the Google-Mac platform does allow for active participation in the program with decentralised data. Users’ devices ping each other using BLE, but without establishing a connection. Prolonged periods of proximity lead to a large number of data exchanged. If a person develops symptoms, their emitted pings are made public (central server), and other users’ devices can check their risk. “How is this any better than the centralised system?” you ask.
Well, firstly, each device generates a new ID each day. This means the contents of the ping packets can’t be analysed to then track a single person. In order to avoid flooding of false information, it is the health authorities who can make the packets public, and this (in theory) only with the user’s consent. Secondly, users’ devices have to go online to collect the new infection data and compare against what they came accross. In theory, the risk analysis is done on users’ devices, as opposed to being sent from a central server. This means risk data is not monitored by a central server providing some privacy.
This is not a perfect solution. As the EFF point out, it is possible to combine technologies in order to collect data and reduce users’ anonymity. Additionally, by having daily exposure keys as opposed to having hourly, means these keys can be tracked accross a city with relatively inexpensive devices. However, most of the threats involved already exist through other means. There are of course projects aimed at limiting exposure, but due to the widespread use of iOS and Android in the smartphone market, the Google-Mac APIs seem to be, for the moment, providing the best compromise in useability and privacy protection.
