Tracing App Thoughts and Links

Posted on

As many countries are now managing to drive down their COVID-19 epidemic, thoughts are turning to how to manage the outbreak beyond the “lockdown”. The restrictions we live under now do appear to work, but for multiple reasons, they’ll be hard to maintain.

When the epidemic was small, it was possible to trace every new infection and isolate potential new cases. This did buy time, but for most countries, “the cat was out the bag already”. With too many cases, tracing proved to be impossible and also no longer useful.

However, given our awareness now, it may be possible to restart the tracing effort once things have calmed down. Many of us are thinking how phones and the internet might help. People have locked into the idea of “automated contact tracing”.

And I have to admit, it excites me as well - it appears plausible we can write apps that may deliver automated contact tracing while preserving privacy.

In this post, I hope to share some observations and links that may be helpful for anyone pondering if apps could help us. Personally I am not sure, so please know I write all this from a neutral position.

Please do check back from time to time - more information will be added to this page as it comes in. And also PLEASE send me any relevant links - there are many efforts ongoing, I hope to link all of them that appear to be useful! bert@hubertnet.nl or @bert_hu_bert.

How phone location data could help (or not)

In this page I focus on how phones could measure directly how close they are to other phones. Some countries use localization technologies (GPS, GNSS, Wifi) in an attempt to trace contacts. This can be suitable for mass gatherings (“people all present at this big event”), but appears not to be precise enough to tell when two people sat close together in a bus, or on a subway.

GPS still has a role, but it appears to be limited for few meter distance measurements. Similarly, phone companies have a rough idea of where phones are, but very much not with a few meter precision.

The idea of phone-based proximity detection

For the rest of this page, I focus on the decentralized privacy preserving proposals out there, like DP-3T, CEN/TCN, or the Apple/Google protocol. These proposals strive to help public health without turning ourselves into a police state.

In pictures, the idea of automated contact tracing is explained very well on this page by Nicky Case (thanks!).

Note that “an app” can in no way solve our problems. Apps can help us with contact tracing as part of a strong public health effort. Do not expect the app to deliver perfection!

Existing efforts

Protocols:

UPDATE! Apple and Google have released an API, just an hour ago. On first glance, it seems to offer a DP-3T-like interface, with powerful privacy preserving features. This seems to be a very good thing.

Projects:

Implementations:

How it works

We now know that the combination of:

  1. Physical distancing
  2. Improved handwashing
  3. Coughing hygiene

Is able to effectively arrest the spread of the virus. We don’t yet know which of these three is most important, although several papers are reporting numbers on different measures. I do not yet see a consensus.

But let’s assume that spending time close to infected people is an important factor. Note there are two components to this: proximity of infected people, longevity of contact.

Now, phones might be able to measure the proximity and duration of contacts. Many phones can emit beacons via Bluetooth Low Energy (BLE). These are radio signals that supposedly do not travel very far. So they could be used to detect who has been close to us. The idea is then that if you are within reach of a BLE beacon, you might also be close enough to get infected.

As ideas go, this is not the worst. However, anecdotal evidence suggests BLE can travel 15 meters, plus go through walls and windows. Unlike virus particles.

It appears BLE does come with some possibility to measure distance. In this Twitter thread, Jiska sets out that this measurement might be accurate on iPhones but not on Android. She also notes that the Singapore app sets up actual “BLE/GATT” connections to improve accuracy, at the cost of battery life. There are also security implications.

It is also possible for phones to emit ultrasound, and the idea is then that if two phones can hear each other, the owners may be close enough to run the risk of infection.

Here we run the opposite risk - sound travels badly through pockets, jackets, other clothing, and is affected by ambient noise levels. The virus notably does not care about these things.

How it would work in practice

There are variations on the theme, but the idea is that our phones store anonymous identifiers of everyone we were within BLE/audio reach from. If at a later stage the owner of the phone turns out to be infected, a signal is transmitted via the internet that corresponds to the transmitted beacons.

Our phones now check if they saw any signals that match the infected person. If there are matches, an algorithm determines if this is a risk worth reporting to to the user. For example, picking up a single BLE beacon from an infected person may not warrant an alert.

If we picked up a lot of these beacons over a 2-hour period, this may well be worth telling the user about. “You spent hours close to a known infected person”. The app may also inform the users of the location and time of the potential infection. Let’s say this was a stuffy meeting room, you may be far more worried than if it happened in an outdoors park, where you don’t recall being very close to someone.

Here you already see how much judgement is involved. An alert first needs to be filtered by the app, and then be presented in its context to the user so they can make sense of it. Hopefully.

Privacy preserving protocols

In the simplest case, the phone would be broadcasting your social security number (or equivalent) all the time. Finding infected people would then be easy, and we could broadcast the numbers from these people.

For a ton of reasons, this is a bad idea.

So in practice, protocols transmit seemingly random numbers. These are then stored by receiving phones. The numbers are not actually random however, they are generated by keys. These keys are tied to the phone of the transmitter. A new key gets generated every day.

If someone is found infected on, say, the 10th of April, we might distribute the keys that corresponded to the 14 days before that.

All apps then receive these keys and determine which of the seemingly random numbers they received match to these keys.

Because the numbers appear to be random, emitters can not easily be tracked using the app. And we can still correlate all their numbers once we know the key.

I explained this a bit more in this Twitter thread which also has links.

And then what?

We don’t make these apps because they are using cool privacy preserving technology. We use them for public health purposes. I know enough of public health messaging to know this is fiendishly difficult.

The overriding goal is to let the right people self-isolate. If there is a credible suspicion someone is infected, the sooner they get indoors and perhaps even in a separate room, the better it is for everyone.

The notifications users get will most definitely not be very sensitive (“pick up every potential infection”) nor very specific - they will often alert users that turn out not to have been infected.

Such alerts can however still be useful depending on context. For example, let’s say you notice you may be coming down with a flu-like illness, and THEN you get an alert. In such a case, it is far more likely that the notification is correct, and will also motivate you to isolate, likely earlier than you would usually have done.

In short - writing the app is only half the work (at most!), there needs to be an equally strong effort to tailor the messaging.

Bogus notifications

There are many many reasons why users might get bogus (incorrect) notifications. These are very dangerous as these might teach people to ignore the notifications (“all my friends received one, no one got ill, what a joke”).

As an example, if you live in an appartment building, you may well be receiving beacons from 17 neighbours, despite rarely meeting them. If any of the dozens of people living in those appartments reports as infected, loads of folks will now receive a notification they got infected while at home.

Similarly, a bus driver in his now closed compartment can be within BLE reach of passengers for the duration of their trip. The bus driver is not at risk, but will still get flagged a lot. Similarly, if the bus driver (who again is isolated in their own compartment) turns out to be infected, hundreds of passengers may get an alert.

Both these examples can be countered with clever algorithms (“we’re CONSTANTLY surrounded by these sources, either they are roommates and we’d know if they fell ill, or they are neighbours”), or appropriate guidance: turn off the app if you know you are behind a barrier.

But it still needs work, and it is unknown if we can make this work well enough.

Non-happy flow

The ‘happy flow’ is when a process works as it should. Person is infected, gets diagnosed by a professional, professional provides a code that allows the user to declare themselves infected in the app. Note that this authorization is likely required because otherwise people can declare themselves infected for fun. This will certainly happen (“lol!”).

However, mistakes are also made. There needs to be a way to unflag someone as infected. Such an “undo” is tremendously complicated, since there may now be many users that need to be notified they might not have been exposed after all.

Similarly, the proverbial infected bus-driver might need to double check if he should report himself as infected if he left the app on while safely isolated in his compartment.

Bad actors

Many of the riskiest kinds of work already ban employees from bringing their phones to their places of work.

Such employers may also ban people from running the app, afraid it might lead to a spate of reported infections and government attention.

Organizational details

Initially this app will likely be developed nationally. Although the EU prefers a European app, it will already be hard enough to make a national one!

If the app is only national, it will not work if you travel to a neighbouring country, which would be sad.

Additionally, the “app” needs significant backend support. The notification of infected users needs to happen through a server, where care must be taken this server is hosted on a platform we fully trust.

To make sure only healthcare professionals can authorize the “infected” status also requires a way to authenticate healthcare labs or offices that might be allowed to do this. This alone would normally take a year to figure out.

Technical details

From what I understand, as of the 10th of April, iPhones will only broadcast BLE beacons if the app is running in the foreground. This is a lot of hassle.

UPDATE: Apple and Google have released an API that will enable this to work.

It also seems likely this app will drain your battery faster than you are used to. Governments might do well to procure powerbanks to hand these out.

How many people have phones that can even do this?

Will decentralized be enough? Might we want to give users the option to share their travel history with public health contact tracers?