Categories
GDPR Privacy Tech

Protect Scotland & Privacy

Interconnectivity in the UK

Following my last post on privacy and the NHS apps in the UK, I was informed the different services in circulation in the UK were talking to each other. The main change for users was that they no longer needed to download different apps when moving accross the UK, being able to use their local app in Scotland, England, Wales, Northern Ireland or Gibraltar. While it certainly provides a better user experience, the backend implementation can be a nightmare for privacy conscious people.

The simplest implementation would be to move from local servers to a centralised location, and have all apps communicate with a single entity. Such a solution would provide the advantage of having an increased manpower which can focus on securing and protecting the infrastructure. On the other hand, with no geolocation data, such a system increases the amount of data devices need to check against drastically, specially with the rising number of cases in the UK at the moment.

Another possibility would be to let all apps communicate with all servers with distributed connection times. Given the data is distributed across devices there is little concern for data misuse, access to the data on the device would need to be as restricted as possible, given positive matches would allow for fingerprinting when an user was in which region.

Finally, a third solution would be a handshake protocol between devices. I remember a colleague who also worked IT in hospitality mentioning the physical access control system he used meant physical access only needed to be used on a single door, with the information being spread “like a virus” as employees and clients alike would load updated access control from locks and distribute it to any locks they opened. Now, imagine a handshake between 2 Bluetooth devices (A&B) before they start sending out their pings:

A: “I’m SCO” – PING
B: “I’m ENG” – PING
A: “Here are some cases from SCO” – PING
B: “Here are some cases from ENG” – PING

There are 2 possible implementations for this I can see, each with their drawbacks.
1. Non-local data is distributed only in a P2P fashion, with local devices sharing it locally. That is the local device would then share the new information with other local devices and update its own datapoints. This means the people most at risk from contact with folks travelling the country would be sharing this information with the people they expose (family, coworkers) without the need for a central repository. Additionaly, people with limited contact/exposure to travelers would not be checking oudated datapoints themselves.

2. Local devices update the local servers with the non-local positive cases daily, whereby all local residents can check their data. This of course leads to increased processing on the devices, and essentially the same situation as each app connecting to each server.

What concerns would a P2P infrastructure imply? Well, for starters, when a traveller is tested positive, the people they were in contact with while abroad would not be informed until at least 24 if not 48h after the infected person’s data is made public, at which point some or most of the data points may have been deleted from old age. In terms of privacy, a P2P protocol would be easier to reverse engineer and exfiltrate data / poison existing data due to the limited authentication required. However, a P2P infrastructure would make sharing data internationally far easier, for example by updating national systems from the data obtained from flight crews.

The debate between national & international health and privacy will not be going away overnight. However, regardless of which data sharing method was implemented, it is nice to see that Protect Scotland uses a clear and concise privacy policy, most notably specifying for how long data is retained. One can only hope private sector would follow suit accross the board, rather than only on a case-by-case basis.

Categories
GDPR Privacy Tech

COVID-19 & Privacy

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.