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.


Fighting with Geany & Terminator

After several years with CrunchBang Linux, learning in 2013 that it was discontinued was horrifying. The distro worked out of the box, provided an easy to use interface but also gave the user enough freedom to tweak settings and interfaces in order to help making it a little friendlier. In early 2014 I fried a hard drive. Well, the hard drive died and the CPU went with it. Could have been a flaw in the BIOS that let the system overheat, could have been that I dropped the laptop a fair number of times and the heat sink wasn’t working as intended. Potato potato.

Upon changing hardware, the first requirement was getting CrunchBang back on board. Alas, it didn’t exist anymore… or so it seemed. Fortunately, the community rebuilt it around BunsenLabs. The first installation, BL-Hydrogen… was a major headache. Arguably, a bad case of PEBCAK. After some tinkering, it was running again with the same and improved welcome script. The decisions on the packaged software… everything made sense. Terminator provides an excellent experience, allowing to have the man page for a command on one pane, and the 5 3000 attempts at getting the flags right on the other, with no need to change windows or tabs. But more importantly, it came with Geany as the default text editor. Geany was like a personal assistant when I was writing any form of code, no matter the language. F5 and a terminal would open, display the result and request I press “enter” to close the window.

Attempting to run the same code from a terminal as ./ or python3 would throw errors left right and centre. Geany and F5? Just results. So after deciding to tackle the Project Euler challenges one more time, it made perfect sense to go back to this winning combo.

Except somewhere along the line the system broke. Pressing the F5 key instead of running the code only opened a new terminal window in the location of the file. F5 here, F5 there, nothing. Internet searches showed that I was not alone, but for some reason I could not find the settings affected users were changing to fix the issue. Fortunately, Geany is more than just a text editor, and comes with a built in terminal emulator. A single result, but incredibly useful nonetheless, allowed me to at least get F5 working again. Solution was here.

While this is only a workaround, it does provide the same functionality I had before while using less screen real estate. Maybe I need to start looking at a map to escape VIM….

If you are looking for a lightweight text editor, capable of doing more than editing text but without being in your face about it, give Geany a try. Do take a look at the settings, specially if using a language which cares about whitespace.