Privacy first contact tracing for the next pandemic

I wrote a thing, go have a play with it at then pop back to read all about it.

Contact tracing apps are rather a topical subject, we all wish that wasn’t so, but we are where we are. This article discusses a design for such a tool, however this is not a discussion of a practical tool that will be used by anyone. It isn’t an attempt to design an app that people will use, or that governments will want to roll out. This is about designing a privacy maximising solution – or one that leaks an absolute minimum of information to the parties involved. The one that gets rolled out will be very different, but I can’t do anything about that.

The first thing I like to consider when designing something to automate a business process is to look at how we do it now, and how we should do it if computers didn’t exist. Right now the contact tracing process is to ask someone who they have been in contact with for the last few weeks. They remember some of the people they spoke to, and attempts are made to get in touch with and inform those people. The way to improve this as a paper process is for everyone to keep a contact diary. For everyone you meet, you write down who it was. This solves the bad memory problem, and gives a list of people you have had a meaningful contact with. It notably doesn’t include people you were near, but didn’t have meaningful contact with. This is our baseline – the tool we design has to be at least as good as the best paper process we can come up with – and not worse in any disturbing way.

Lets introduce you to our cast of characters. As is traditional in information technology the first people we meet are Alice and Bob. They are two members of the public who have a contact with each other. Some days later one of them will get ill and be diagnosed with coronavirus by Dave who is the doctor in our scenario (we are not allowing self-diagnosis). The final member of the cast is Grace who is the government running a central service to facilitate the process.

Lets first establish a level of trust. Grace is trusted to run the server, but is not to be given any information that can be data mined and exploited in any way. Dave is trusted by Grace to perform diagnosis and tell a patient they need to inform their contacts. Alice and Bob are not really trusted at all, by each other or anyone else.

If Alice and Bob go for 14 days (the presumed maximum incubation period) without getting ill, then nobody, especially Grace, needs to know that they ever met each other. This is key to keeping a massive amount of data away from Grace and also is a vast reduction in the performance requirements of the system. If Alice gets ill and is diagnosed with Sars-CoV-2 then Bob needs to be informed that he has had contact with a person who may have been infectious. He doesn’t really need to know who that person was, just the date on which the contact occurred. Bob can then take whatever steps are appropriate – but we are trusting Bob to do that, there can’t be any enforcement by others.

I have been mulling over how a contact tracing tool could be designed to maximise safety and anonymity, whilst remaining effective and useful. I am, like many others, quite concerned that websites springing up to log your contacts and symptoms are a data harvesting exercise that should be treated with extreme caution. Bad people can do bad things with too much data, and these websites are gathering contact details and medical status of large numbers of people including children. This is not a presentation of a working contact tracing solution for the COVID-19 situation, more of a discussion piece and reference implementation for a type of tool that could be used in future. If this does grow into a functional app, it still won’t be a perfect contact tracing app, it might no be a usable one, it won’t be popular without government support – and popular is important. These things are useless without mass adoption.

  • The ideal system would have no centrally held data at all about people who are perfectly well and remain perfectly well. It should have a very low barrier to entry – no registration or dependency on having any other form of internet account (Facebook/Twitter/email etc). It should also not keep data beyond what is necessary to function. Users of the system might want to share some details with each other, but an absolute minimum will be shared with the server. The server isn’t to be considered actively evil – it might be government run. The point of the server is to facilitate contact tracing without knowing anything it doesn’t need to know.
  • Assumptions that I will allow are that everyone using the system has exactly one smartphone, which they have with them all the time, and they will sometimes have an internet connection. The smartphone will have a browser and camera, but may run any operating system so it might not have NFC available.
  • The system will make extensive use of the indexeddb API. This allows a phone to store and manage data relating to a particular domain without actually sending it to the server. We don’t want much going to the server – it is private until it matters, then it only needs to be shared to the extent that it helps others.
  • If I am ill, I submit to the server the interactions that may be risky. I may need a diagnosis code from a doctor to confirm – only the doctor would have to be registered with the site, perhaps using a different application. There could be some other process of getting a diagnosis code to a user, such as a letter with a QR code on it.
  • People might meet other people and want plausible deniability of the interaction – the assumption is that someone else can have full access to your phone and not know who you met, or how many people, but alerts should still function.
  • There might be a need to record a contact between a person and a place – so for example a shop. This should have deniability – optionally recording nothing about what the place is.
  • I would rather not have a native app for Android and iPhone – that means people have to go and install it, which is a barrier compared to just visiting a web page and it works. The native app has the dubious advantage of getting access to bluetooth APIs, including the new background contact tracing API that Apple and Google have provided. That essentially does the same thing as the QR code bumping but invisibly and through walls – creating contacts with people you really didn’t have a meaningful contact with.
  • There is no blockchain involved in any way.

With those requirements in mind, I put a little website together. The front page starts with a QR code and a video from the camera, you point your device at someone else’s QR code and that is it. The interaction is recorded. Job done. You can optionally put some contact details in the QR code, if you want to give the other person your name and number for some reason – it makes no difference to the ability of the contact notification to work but it might give people more of an incentive to use the app. If you are sharing contact details with the person you bump into then you can scan each others QR code, which will be a double bump.

If you become ill you can scan a diagnosis code. This will in principle be something issued by the government via a doctor or perhaps with a test result – control of this prevents people randomly self-diagnosing and scaring their contacts. On scanning the diagnosis code your recent interaction ids will be uploaded to the server, which then makes them available for others to view, to see if they share any of those interaction ids. The server acts as a noticeboard, and it will know how many diagnosis IDs were issued and how many were used but not much else. The server can see how many users are looking at the list of interactions, but has no information about who may share an interaction with someone who was diagnosed.

Current status and next steps

Diagnosis doesn’t fully work, background notifications don’t work, I had to rewrite it from using localstorage to indexeddb so that I can write a service worker to do the background checking of the server and popup notifications. That is coming soon.

I am thinking about interactions with places rather than people. For example, a shop or bus could have a QR code printed out, anyone going in scans the code. If any one gets sick, everyone else who also scanned that place on that day could be alerted and informed which place they went to may have exposed them to some risk – just to be a bit more self aware of potential symptoms. Of course the QR code could contain details of the place, which again could be anonymised if people are going to a place that they might not want to admit to going to if someone examines their phone.

It might be good to allow manual contact entries, so you can make a note of someone you met who for whatever reason didn’t automatically enter via the QR code system. This would be nothing to do with alerting, just a contact diary with entries that evaporate after 14 days, so that you could attempt to contact them if needed, or provide their details to a health authority for followup.

I think it may be interesting to have different types of diagnosis, so you can have self-diagnosis, or diagnosis verified by one or more authorities. This would in principle allow it to work multi nationally, with several testing authorities having the ability to issue diagnosis codes. People being alerted might take different actions depending on the authority that diagnosed the person they have bumped into.

0 0 votes
Article Rating
Notify of
Inline Feedbacks
View all comments
Would love your thoughts, please comment.x