The current literature on Covid-19 seems unanimous in recognizing that, as no treatment is yet available, the only tools that we can currently deploy to stop the epidemic are contact tracing, social distancing, and quarantine. In this work we discuss contact tracing from an Ethics of Computing point of view. In fact, work on Covid-19 contact tracing, e.g., [Ferretti et al. 2020 ] is mostly focussed on "algorithmic" instantaneous contact tracing assisted by a mobile phone application. The DP-3T project by [Troncoso et al. 2020] is an example of research and implementation effort that addresses this urgent need.
Recently, a short paper by [de Montjoye et al. 2020 ] has introduced and examined three toy protocols that summarise the privacy questions surrounding the Covid-19 tracing. They describe the following 3 toy protocols for discussion:
Each app only records its own location. As a result,
• When a user reports as infected, they send their trajectory (location and time) to the authority.
• The authority, e.g., the NHS in Britain, shares the pseudonymous trajectories of all infected users with every user.
• Users can then check if they were in close contact with an infected individual.
Toy protocol 2: using Bluetooth.
Each app broadcasts a unique identifier assigned by the authority through Bluetooth. So
• When two phones are near to one another, they exchange these identifiers.
• When a user reports as infected, they send all the identifiers they encountered to the authority.
• The authority will contacts all the users whose identifier was encountered by an infected user. Toy protocol 3: again using Bluetooth.
In this version each app broadcasts a unique identifier using Bluetooth, assigned by the authority. This unique identifier is reset every hour. Thanks to temporary indentifiers,
• When two phones are near to one another, they exchange these identifiers.
• When a user reports as infected, they send all the identifiers that they have used (one per hour) to the authority.
• The authority shares the identifiers of all infected users with every user. Users can then check if they encountered one of these identifiers recently. (1) How do you limit the personal data gathered by the authority?
(2) How do you protect the anonymity of every user?
(3) Does your system reveal to the authority the identity of users who are at risk?
(4) Could your system be used by users to learn who is infected or at risk, even in their social circle?
(5) Does your system allow users to learn any personal information about other users?
(6) Could external parties exploit your system to track users or infer whether they are infected?
(7) Do you put in place additional measures to protect the personal data of infected and at risk users?
(8) How can we verify that the system does what it says?
The overall purpose of the game is to maximise (pure) contact information while at the same time minimising (noncontact) personal information. As a typical user, Alice should know that she has been in contact with somebody (in fact Bob) without knowing that her contact is indeed Bob or indeed knowing anything else at all about Bob. Her ignorance of the latter two facts is as important on privacy grounds as her knowledge of the first on grounds of safety [Radaelli et al. 2018 ].
Contact information, however, can connect with personal information in two ways. The first way is that (i) personal information is needed to establish contact information [Nat 2020] , and the second is that (ii) personal information can relatively easily be derived from contact information [Gong et al. 2014 ]. The ideally-designed game will enable the exchange of contact information without such information having to be established on the basis of any more general personal information or being the possible source of a derivation of such more general personal information.
Contact tracing should not involve any sharing with either other users or the authority of trajectory/social graph information (from which identification is possible either by the authority or by the adversary). Given these overall parameters, it seems possible that both the protocols and the questions/answers in the paper could be advantageously altered.
Secondly and more importantly, there is considerable scope for changing the proposed protocols in order to enable optimisation of the data flow objectives. On this basis, the first protocol needs to be amended so that the authority does not reveal the entire trajectory of an infected user to all non-infected users.
To avoid such undesirable disclosure, the authority has to know the trajectories of all users, whether infected or not.
This arrangement, by which all information is accumulated with the authority and the minimum possible disclosed to users, could be protocol "1a. " It seems to be a limitation of trajectory-based apps (and therefore a reason for preferring identifier-based apps) that with them it is not possible to avoid disclosure of entire trajectories to either other users or the authority (or both). A decision therefore has to be taken, on this point, between dispersion and aggregation of information.
This is presumably at least part of the motivation for considering identifier-based protocols; however the differences between the second and third protocols could also be clarified further. There are two such differences. The first is that protocol 2 has a fixed identifier, whereas protocol 3 has a variable identifier (to use a suboptimal term). This is the more conspicuous difference, and it plays a larger part in the response to the questions [The National Cyber Security Centre 2020]. The second difference, however, is that protocol 2 also sends its full history of identifier encounters to the authority, whereas article 3 only sends its identifier change record. In the case of protocol 3, the authority is not able to figure out for itself the now at risk users. So it sends the variable identifiers whose status has changed to infect.
This seems to decrease the privacy of the infected users while increasing that of the non-infected users (both at risk and risk-free), see, e.g., [Sharad and Danezis 2014] for early results on de-anonymisation. This difference also seems to have a material effect on the privacy vulnerability. For example, does it reduce or increase the knowledge of the authority about trajectories/social graphs of either group? If the authority is able to connect the varying identifiers, then it acquires a finer grained level information about the relevant users. Protocol 3 is, therefore, in effect a bet on the inability of the authority to spot the continuities in series of variable identifiers.
There seems to be a further assumption built into protocol 3. Any information available either to the authority or to any or all users is in principle also potentially available to the adversary. The existing game model thus makes the further assumption that identifier information on mobile phones is more open to hacking than trajectory information.
However, such an assumption is not immune to challenge. It needs to be clarified what are the relative strengths and weaknesses of the protocols with respect to the adversary.
Thirdly, the answers to the specific questions also need to be reviewed (partly in the light of the queries about the protocols). We now look in turn at some of the ways in which the answers to the eight questions could be changed.
Protocol 1 obviously discloses the whole trajectory of infected users to the authority. The disclosure also to non-infected users can be avoided, but only at the cost of non-infected users also revealing their entire trajectories to the authority.
This would be the move from protocol 1 to protocol 1a. If there is perceived to be an inverse connection between threat status and privacy entitlement, then it would seem that this change of trajectory-based protocol would be unfair. A larger number of users who do not constitute a threat would see their privacy eroded in order to protect the privacy of the smaller number who have become infected. (It should be noted that this objection applies irrespective of whether or not any form of blame is to be attributed to the change to infected status (e.g. by disregarding social distancing etc).
In terms of the identifier-based protocols, the improvement provided by protocol 3 over protocol 2 depends on the authority not being able to reconstruct the pseudonymous social graph across the changes of identifier. As discussed in connection with the protocols, however, it is not obvious that it will not be possible for the authority to do that. estion 2.
The same objection to the greater innocuousness of protocol 3 over protocol 1 and protocol 2 arises as with question 1.
Presumably if the game is to rely on "special measures" to "limit the risk", then those special measures should be applied at the level of the authority not the users (where they can more easily be circumvented and less easily monitored). It could also be argued that re-identification by either the authority or other users automatically raises the risk of reidentification by the adversary.
estion 3.
Protocol 1 does indeed give the right answer on this question, but only at the cost of giving too much information to non-infected users. Again, the difference between protocol 2 and protocol 3 is not clear. It is a reasonable supposition that the identities of the infected group are more sensitive than those of the non-infected. The former are (presumably) less numerous, but they are more vulnerable to potential stigmatisation/vigilantism. If that assumption is right, it would form a strong objection to protocol 1. What this suggests is that a more nuanced distinction needs to be drawn between the type of threat posed by the authority and that posed by other users.
estion 4.
Protocol 1 obviously fails this test in its existing form, but that can be prevented by letting the authority know the trajectories of non-infected users (protocol 1a again). Protocol 3 seems to be definitely worse than protocol 2 on this question, however it is tweaked. This reinforces the suspicion that protocol 3 is not preferable to protocol 2 in any respect. Given the presumably greater practical difficulty of deploying protocol 3, this would seem to be a very solid grounds for rejection of protocol 3 in general.
This seems to be the crucial question for the overall objective of the game as outlined at the start. It is not obvious how the protocols can be structured to enable either users or the authority to gain only and exclusively specific contact information without either supporting it with more general personal information or creating a situation in which wider personal information can be triangulated from the contact information. This highlights exactly what any privacysecure contact tracing must achieve: the Holy Grail is pure contact information, uncontaminated by any non-contact personal information. estion 6.
This seems to raise again the question whether concentrating information with users or with the authority constitutes the greater security risk. Most recent major hacks have focused on concentrations of data, suggesting the more disaggregation the better. Hacks from large numbers of dispersed users have been less effective, so far as can be known.
It is not clear what additional protections could be made available. One possibility would be some kind of time limitation of the information or preventions on its further disclosure. Presumably this would in practice be a question about encryption rather than game design. The other obvious way to develop such protections would be through legal/regulatory constraints, but they would also clearly fall outside the scope of the intrinsic app-modelling game under consideration.
estion 8.
As in many other areas of data protection, the may be a trade-off between the transparency of the system and its privacy-protection and/or security [de Montjoye et al. 2013 ]. It may not be possible simultaneously to optimise all three parameters. On the other hand, a possible way of at least partially squaring this circle is that some form of blockchain might be deployed here.
The game-design approach of [de Montjoye et al. 2020 ] seems to offer, perhaps with some modification, a good basis for a design intended to optimise the protection of the relevant moral assets. Non-infected users have an interest in learning about vulnerability-increasing contacts, but have no right to any other information about infected users. Infected users have a duty to maximise knowledge about their contacts, but the right not to have any further information about them disclosed. (As we have seen, the right of the infected might outweigh that of the non-infected on the grounds of the risk of vigilantism, whereas it might also be thought to be outweighed because of the possible culpability of infection given the level of public knowledge [Rosand et al. 2020] . This is clearly a value, not a pure design, issue.) The authority has the right (and possibly duty) to be as informed as possible about the pattern of spread of the epidemic, but it should be prevented from acquiring (and indeed retaining) any more than the essential information about the users under its jurisdiction. The adversary has no rights in this context and is simply a threat to be minimised.
The most significant improvement to the approach proposed, in our opinion, would be to replace protocol 1 with our protocol 1a. We are agnostic as to the general preference for trajectory/identifier approaches, but we suspect that with the latter protocol 3 on balance creates a greater privacy risk than protocol 2.
This article is based upon work from COST Action DigForAsp CA17124, supported by COST (European Cooperation in Science and Technology): www.cost.eu.