We ended the last blog talking about how Bluetooth enabled apps give better recall and rapid exposure notification without you remembering who you were in contact with as part of the COVID19 test and trace process.

Test and Trace in the traditional sense is a very manual task. It is challenging, at best, to take it to scale. For that, you would need plenty of people doing the repetitive task of contacting individuals asking for their contacts. It is manual and costly, and as we said last week, it can be difficult to recall information on who we have been in contact with.

Bluetooth based apps on the other hand give better recall and rapid exposure notification without you having to remember who you were in contact with.

But, in the real world, apps augment rather than replace the manual process of contact tracing which still needs to happen even when you have a well-functioning app.

The idea of using an app for verifying proximity is not new and, as you would expect, the United States has already issued a patent on it: Describing an approach an approach to contact tracing using Wifi or Bluetooth monitoring signals.

In the UK, for the NHS contact tracing app, a debate around the app operation i.e. centralised vs decentralised raged for some time. One interesting concern flagged on the app during development and piloting was that it could be gamified, with users going for increasing their proximity score and therefore ignoring social distancing in the process.

Under the centralised model, the anonymised data gathered by the app is uploaded to a remote server where matches are made with other contacts, should a person start to develop Covid-19 symptoms. Privacy is a risk with this approach.

For a decentralised app, a crucial difference is that the phone is doing the mapping on its own rather than relying on a central server. One implication here is that in a decentralised system, you get greater user control of the data with the implicit limitation on purpose and future use – which has been a significant concern with the Australia app for example. Who has our data and what they can do with it after COVID must be a concern to all of us.

The main functionality piece that enables apps to trace is that apps exchange what are called TempIDs with other phones nearby. These TempIDs are signature codes or encrypted tokens generated by the server with which the phone communicates. These codes do not mean much to anyone except the server and only it holds the decryption key to turn them back into a primary key that is used by the contact tracers to look up your name and contact details.

The server gives the app on the phone a TempID which it then uses for the next two hours (although the BlueTrace protocol recommends 15 minutes). The app will exchange these TempIDs with all nearby phones in the process recording the details in a database on the phone.

If someone tests positive for COVID19, they can trigger the app to upload all collected TempIDs to the central server, which in turn decrypts them so that the contact tracers know who to contact. TempIDs are only uploaded to the server if the user clicks the button to do so, hence why I underlined ‘can’.

The lifetime of the TempID is important because it will uniquely identify your phone for this time interval, whether 2 hours or 15 minutes. It won’t identify you, but it will allow any Bluetooth device in range to know that it’s the same phone it saw earlier. One example of how this could be abused is that it allows someone to track your movement as your ID shows up in multiple locations. So the longer you keep the ID the easier you are to track.

More on this next week!