Centralised versus decentralised

The most popular digital contact tracing app variants use Bluetooth signals to gauge when two people with the app come into close contact, and for how long. Each person is assigned a frequently-changing series of ID-numbers (‘ephemeral identifiers’). When two people come into close proximity, their phones exchange their ephemeral identifiers via Bluetooth. If someone reports on the app that they are positive for COVID-19, anyone who has this person’s ephemeral identifiers stored on their phone (and meets the conditions of ‘close contact’) during the period of infection can be instantaneously alerted.

These apps are often divided into two camps, depending on where information is stored. In a so-called ‘decentralised’ app, ephemeral identifiers are generated on the user’s own smartphone and exchanged directly between users when they come into contact. When an index case registers as positive, his ephemeral identifiers for the period of infection are uploaded to a central server, and broadcast to all other app users. Anyone who has one of the index case’s ephemeral identifiers stored will be alerted. In a ‘centralised’ app, each user is assigned a permanent identifier, which is stored on a central server. The server then creates ephemeral identifiers for each user and sends them to the user’s phone. Phones exchange ephemeral identifiers, and when a user registers as positive, the ephemeral identifiers of his contactsiii are sent to the central server. These are then matched with their permanent identifier, and the corresponding contact is alerted.10

The centralised app’s storage of a permanent identifier for each user provides us with a way to speed up the contact tracing process significantly. The reason for this can be drawn out by looking at a problem for digital contact tracing: How do we make sure that positive reports from users are accurate? There are two options here. The first (which many countries with both decentralised and centralised apps opt for) is to require a positive test before it is possible to report as positive in the app.11 12 This is clearly a good way to ensure that reports are accurate, but it leads to delays in reporting. Although testing turnaround times are rapidly reducing in some countries, the wait between experiencing symptoms, accessing a test, and receiving the results could undermine the success of the measure.

The other option is to allow users to self-report that they are positive for COVID-19 as soon as they experience symptoms. This would speed up the process enough to make the success of the measure much more likely, but we are then hit with the risk that the system will become flooded with false positive reports,13 either because users are genuinely mistaken, or because of malicious reporting. This would result in many contacts being falsely quarantined, possibly sending us back into conditions approaching a general lockdown. We could require that positive self-reports are followed up with a test within a certain window of time, allowing for the rapid release of unnecessarily quarantined contacts, but this will only work if every user can quickly and easily access a test, and if users are sufficiently diligent to voluntarily seek a test and submit a follow-up report quickly. It seems, in sum, very difficult to sort the false from the true positives in a system that allows for self-reporting.

The need for centralised data storage

It is here that the permanent identifiers stored by the central server become crucial. These give us a way to distinguish the (likely) false from the (likely) true positives when no follow-up test is forthcoming. In a centralised system, where the permanent identifiers of users can be associated with each other, the server can keep track of whether a positive report is followed by further positive reports from the people with whom the index case has been in contact. Where an initial positive report is not followed by further positive reports, the index case could be identified by the server as a likely false positive, and all his contacts could be rapidly released from quarantine. Such a measure is not possible in a decentralised system, because there is no way to keep track of who has been in contact with whom over time—the server only holds the ephemeral identifiers of infected persons during their period of infection, and each smartphone only holds the ephemeral identifiers of direct contacts. There is no way to get an overview of clusters of infections, and thus see where no cluster results from an initial report, indicating a likely false positive.

There are three things that should be noted about this proposed system. The first is that the process of identifying clusters (or the lack of one) can take place without directly identifying any individual user—this can all proceed on the basis of assigning each user in a centralised app a permanent pseudonymous identifier. This, however, leads to concerns that users will be easier to unmask in a centralised system than in a decentralised one, as we shall see below. The second is that nothing like this kind of system has actually been implemented in real life thus far. The centralised systems initially trialled in the UK and Australia were abandoned after they could not identify contacts with sufficient accuracy14 15—not due to an inherent problem with the system, but as a result of the difficulty of designing a functional app on Android and iPhones without the support of Apple and Google (who only support decentralised app architectures). The centralised system in France has been plagued by low uptake, and requires a positive test before reporting is possible.12 16 Thus, the systems developed so far have not taken full advantage of the opportunity offered by digital tools for effective contact tracing. Third, it should be noted that digital contact tracing alone, even as envisioned here, which has the potential to improve on systems currently in operation, will not suffice to curb the pandemic. Rather, it should be embedded in a comprehensive strategy that includes testing and ensuring that individuals do self-quarantine when alerted by the app, which may require removing disincentives related to missing work, among other things.iv

Ethical risks are unavoidable

Safety engineering does not require that inherent safety always be realised. Inherent safety may reduce the likelihood that the purpose of a given design be achieved, or it may even entirely preclude the achievement of this purpose, such as when a hazardous element is an essential part of the system, as in the case of nuclear power plants.20 In such cases, secondary prevention is preferable if this allows the achievement of the design purpose while sufficiently minimising the risks. We have argued that a centralised design increases the likelihood of effective contact tracing, and we may thus be in a situation where a centralised design is preferable, if its associated risks of breaches can be sufficiently minimised through secondary preventions.

There is reason to think that they can. In many countries, data pertaining to health are among the most strictly regulated, and in many places, such as some US states, legislation has been introduced specifically preventing information gathered by COVID-19 contact tracing efforts from being shared for non-public health purposes under any circumstances.22 The Provincial Court of British Colombia in Canada similarly blocked the sharing of information pertaining to an HIV-infected person with law enforcement, accepting that the ‘compelled disclosure of confidential information would undermine the ability (to pursue) effective treatment of HIV and endanger the lives of HIV-positive persons, thereby placing at risk the health interests of the population as a whole’.23

This is all to say that, just as sprinkler systems can be an effective means of preventing a fire, whether the information gathered by contact tracing can be shared, and with whom, can be successfully regulated. As with any secondary prevention, risks of breaches cannot be eliminated entirely. However, it should be noted that the alternatives are also not risk-free. Decentralised apps, even if they were privacy-preserving (which we argue below is not the case), entail considerable ethical risks as they are less likely to be effective in containing the pandemic, and failing to do so will involve harm (loss of lives, economic damage etc.). Furthermore, alternative means of fighting the pandemic, such as selectively locking down the elderly, involve ethical risks too, as they severely discriminate against the elderly.24 In our fight against the pandemic, there are no risk-free options.

Decentralised systems are not inherently safe

The second fallacy of the above-stated defence of decentralised systems stems from the assumption that these systems are inherently safe (‘privacy preserving by design’). Cryptographers have noted that both centralised and decentralised systems are vulnerable to hacking attacks, but their vulnerabilities differ.10 25 A major concern for centralised systems is that a hacker might be able to identify app users through their centrally stored permanent pseudonymous identifiers, as well as the identities of the people they have been in contact with. Serge Vaudenay argues that such an attack would be difficult to achieve, and would probably require a malicious government authority to store additional information as an app user registers in order to make identification possible.10 Others, such as Richard Baskerville et al., emphasise that highly integrated systems in general have fewer, controllable vulnerability points, and can thus be expected to allow for better auditing. At the same time, increased integration means that they are more severely affected if compromised, as breaches affect all integrated functions.26 In the context of contact tracing, we might thus expect breaches to be more likely in dispersed decentralised systems while being less likely but more severe in more integrated centralised systems.

The kinds of breaches we should be concerned about in decentralised systems are attacks that could expose the identities of infected users. When a user of a decentralised system reports that he is infected with COVID-19, all of his ephemeral identifiers are uploaded to the central server, where they are accessible to everyone. This makes it possible to record the ephemeral identifiers broadcasted by particular users, and then to check them later against the identifiers stored on the server. This would enable the identification of those that have become infected.27 Such attacks, Vaudenay contends, could be conducted by any tech-savvy user, and ‘are undetectable, can be done at a wide scale, and…proposed countermeasures are, at best, able to mitigate attacks in a limited number of scenarios.’ Attacks on centralised systems, on the other hand, can be better identified and mitigated ‘by accounting and auditing’. Vaudenay even suggests that privacy-conscious users would in fact be less likely to report that they are infected in a decentralised system than a centralised one. Vaudenay also notes that information stored in a decentralised manner could be utilised by law enforcement—for example, ‘after a burglary during which a Bluetooth sensor captured an ephemeral identifier, suspects could have their phones inspected for 2 weeks to find evidence.’ Because one’s own ephemeral identifiers are stored on one’s phone in a decentralised system, access to someone’s phone would yield more information than under a centralised system.

It follows from these arguments that it would be false to see decentralised systems as inherently safe design, or ‘privacy preserving’. Rather, both centralised and decentralised systems entail risks of different kinds of breaches. Our evaluation of these risks should then be sensitive to the question of how much they are worth taking: if a technology has only a small chance of being effective, there is reason to be wary of its associated risks (and cognisant of the risks of opting for an inefficient means of preventing significant harm); while if a technology has a higher chance of preventing significant harm, the level of risk we should be prepared to accept should arguably be higher. As we have argued in the previous section, centralised apps are more likely to be an effective means in our fight against the pandemic. Given the potential risks and benefits of each option, we need to revisit the assumption that decentralised apps are clearly ethically superior.