ANNEX AT GUIDELINES 04/2020 – CONTACT TRACING APPLICATIONS ANALYSIS GUIDE

SECTION ANNNEX  CONTACT TRACING APPLICATIONS ANALYSIS GUIDE

0.   Disclaimer

The following guidance is neither prescriptive nor exhaustive, and its sole purpose of this guide is to provide general guidance to designers and implementers of contact tracing applications. Other solutions than the ones described here can be used and can be lawful as long as they comply with the relevant legal framework (i.e. GDPR and the “ePrivacy” Directive). It must also be noted that this guide is of a general nature. Consequently, the recommendations and obligations contained in this document must not be seen as exhaustive. Any assessment must be carried out on a case-by-case basis, and specific applications may require additional measures not included in this guide.

1.  Summary

In many Member States stakeholders are considering the use of contact tracing applications to help the population discover whether they have been in contact with a person infected with SARS-Cov-2.

The conditions under which such applications would contribute effectively to the management of the pandemic are not yet established. And these conditions would need to be established prior to any implementation of such an app. Yet, it is relevant to provide guidelines bringing relevant information to development teams upstream, so that the protection of personal data can be guaranteed from the early designstage.

It must be noted that this guide is of a general nature. Consequently, the recommendations and obligations contained in this document must not be seen as exhaustive. Any assessment must be carried out on acase-by-case basis, and specific applications may require additional measures not included in this guide.The purpose of this guide is to provide general guidance to designers and implementers of contact tracing applications. Some criteria might go beyond the strict requirements stemming from the data protection framework. They aim a ensuring the highest level of transparency, in order to favour social acceptance of such contact tracing applications.

To this end, publishers of contact tracing applications should take into account the following criteria:

• The use of such an application must be strictly voluntary. It may not condition the access to any rights guaranteed by law. Individuals must have full control over their data at all times, and should be able to choose freely to use such an application.

• Contact tracing applications are likely to result in a high risk to the rights and freedoms of natural persons and to require a data protection impact assessment to be conducted prior to their deployment.

• Information on the proximity between users of the application can be obtained without locating them. This kind of application does not need, and, hence, should not involve the use of location data.

• When a user is diagnosed infected with the SARS-Cov-2 virus, only the persons with whom the user has been in close contact within the epidemiologically relevant retention period for contact tracing, should be informed.

• The operation of this type of application might require, depending on the architecture that is chosen, the use of a centralised server. In such a case and in accordance with the principles of data minimisation and data protection by design, the data processed by the centralised server should be limited to the bare minimum:

• a)                           When a user is diagnosed as infected, information regarding its previous close contacts or the identifiers broadcasted by the user’s application can be collected, only with the user’s agreement. A verification method needs to be established that allows asserting that the person is indeed infected without identifying the user. Technically this could be achieved by alerting contacts only following the intervention of a healthcare professional, for example by using a special one-time code.

• b)                          The information stored on the central server should neither allow the controller to identify users diagnosed as infected or having been in contact with those users, nor should it allow the inference of contact patterns not needed for the determination of relevant contacts.

• The operation of this type of application requires to broadcast data that is read by devices ofother users and listening to these broadcasts:

• c)                           It is sufficient to exchange pseudonymous identifiers between users’ mobile equipment (computers, tablets, connected watches, etc.), for example by broadcasting them (e.g. via the Bluetooth Low Energy technology).

• d)                         Identifiers must be generated using state-of-the-art cryptographic processes.

• e)                         Identifiers must be renewed on a regular basis to reduce the risk of physical tracking and linkage attacks.

• This type of application must be secured to guarantee safe technical processes. In particular:

• f)                        The application should not convey to the users information that allows them to infer the identity or the diagnosis of others. The central server must neither identify users, nor infer information about them.

Disclaimer:  the above principles are related to the claimed purpose of contact tracing applications, and to this purpose only, which only aim to automatically inform people potentially exposed to the virus (without having to identify them). The operators of the application and its infrastructure may be controlled by the competent supervisory authority. Following all or part of these guidelines is not necessarily sufficient to ensure a full compliance to the data protection framework.

2. Definitions

Contact           For a contact tracing application, a contact is a user who has participated in an interaction with a user confirmed to be a carrier of the virus, and whose duration and distance induce a risk of significant exposure to the virus infection. Parameters for duration of exposure and distance between people must be estimated by the health authorities and can be set in the application.

Location data   It refers to all data processed in an electronic communications network or by an electronic communications service indicating the geographical position of the terminal equipment of a user of a publicly available electronic communications service (as defined in the e-Privacy Directive), as well as data from potential other sources, relating to:

• the latitude, longitude or altitude of the terminal equipment;

• the direction of travel of the user; or

• the time the location information was recorded.

Interaction     In the context of the contact tracing application, an interaction is defined as the exchange of information between two devices located in close proximity to each other (in space and time), with in the range of the communication technology used (e.g. Bluetooth). This definition excludes the location of the two users of the interaction.

Viruscarrier    In this document, we consider virus carriers to be users who have been tested positive for the virus and who have received an official diagnosis from physicians or health centres.

Contact tracing   People who have been in close contact (according to criteria to be defined by epidemiologists) with an individual infected with the virus run a significant risk of also being infected and of infecting others in turn.

Contact tracing is a disease control methodology that lists all people who have been in close proximity to a carrier of the virus so as to check whether they are at risk of infection and take the appropriate sanitary measures towards them.

3. General

GEN-1      The application must be a complementary tool to traditional contact tracing techniques (notably interviews with infected persons), i.e. be part of a wider public healthprogram. It must be used only up until the point manual contact tracing techniques can manage alone the amount of new infections.

GEN-2      At the latest when ”return to normal” is decided by the competent public authorities, a procedure must be put in place to stop the collection of identifiers (global deactivation of the application, instructions to uninstall the application, automatic uninstallation, etc.) and to activate the deletion of all collected data from all data bases (mobile applications and servers).

GEN-3      The source code of the application and of its backend must be open, and the technical specifications must be made public, so that any concerned party can audit the code, and where relevant-contribute to improving the code, correcting possible bugs and ensuring transparency in the processing of personal data.

GEN-4      The stages of deployment of the application must make it possible to progressively validate its effectiveness from a public health point of view. An evaluation protocol, specifying indicators allowing to measure the effectiveness of the application, must be defined upstream for this purpose.

4. Purposes

PUR-1      The application must pursue the sole purpose of contact tracing so that people potentially exposed to the SARS-Cov-2 virus can be alerted and taken  careof. It must not be used for another purpose.

PUR-2      The application must not be diverted from its primary use for the purpose of monitoring compliance with quarantine or confinement measures and/or social distancing.

PUR-3      The application must not be used to draw conclusions on the location of the users based on their interaction and/or anyother means.

5. Functional considerations

FUNC-1     The application must provide a functionality enabling users to be informed that they have been potentially exposed to the virus, this information being based on proximity to an infected user within a window of X days prior to the positive screening test (the X value being defined by the health authorities).

FUNC-2     The application should provide recommendations to users identified as having being potentially exposed to the virus. It should relay instructions regarding the measures they should follow, and they should allow the user to request advises. In such cases, a human intervention would be mandatory.

FUNC-3      The algorithm measuring  the risk of infection by taking into account factors of distance and time and thus determining when a contact has to be recorded in the contact tracing list, must be securely tuneable to take into account the most recent knowledge on the spread of the virus.

FUNC-4     Users must be informed incase they have been exposed to the virus, or must regularly obtain information on whether or not they have been exposed to the virus, within the incubation period of thevirus.

FUNC-5     The application should be interoperable with other applications developed across EU MemberStates, so that users travelling across different Member States can be efficiently notified.

6.  Data

DATA-1     The application must be able to broadcast and receive data via proximity communication technologies like Bluetooth Low Energy so that contact tracing can be carried out.

DATA-2     This broadcast data must include cryptographically strong pseudo-random identifiers, generated by and specific to the application.

DATA-3     The risk of collision between pseudo-random identifiers should be sufficiently low.

DATA-4     Pseudo-random identifiers must be renewed regularly, at a frequency sufficient to limit the risk of re-identification, physical tracking or linkage of individuals, by anyone including central server operators, other application users or malicious third parties. These identifiers must be generated by the user’s application, possibly based on a seed provided by the central server.

DATA-5     According to the data minimisation principle, the application must not collect data other than what is strictly necessary for the purpose of contacttracing.

DATA-6     The application must not collect location data for the purpose of contact tracing. Location data can be processed for the sole purpose of allowing the application to interact with similar applications in other countries and should be limited inprecision to what is strictly necessary for this sole purpose.

DATA-7     The application should not collect health data in addition to those that are strictly necessary for the purposes of the app, except on an optional basis and for the sole purpose of assisting in the decision making process of informing the user.

DATA-8     Users must be informed of all personal data that will be collected. This data should be collected only with the user authorization.

7.  Technical properties

TECH-1     The application should available technologies such as use proximity communication technology (e.g. Bluetooth Low Energy) to detect users in the vicinity of the device running the application.

TECH-2     The application should keep the history of a user’s contacts in the equipment, for a predefined limited period of time.

TECH-3     The application may rely on a central server to implement some of its functionalities.

TECH-4     The application must be based on an architecture relying as much as possible on users’ devices.

TECH-5     At the initiative of users reported as infected by the virus and after confirmation of their status by an appropriately certified health professional, their contact history or their own identifiers should be transmitted to the central server.

8.  Security

SEC-1      A mechanism must verify the status of users who report as SARS-CoV-2 positive in the application, for example by providing a single-use code linked to  a test station or health care professional. If confirmation cannot be obtained in a  secure manner, data must not beprocessed.

SEC-2      The data sent to the  central server must be transmitted over a secure channel. The use of notification services provided by OS platform providers should be carefully assessed, and should not lead to disclosing any data to third parties.

SEC-3      Requests must not be vulnerable to tampering by a maliciou suser.

SEC-4      State-of-the-art cryptographic techniques must be implemented to secure exchanges between the application and the server and between applications and as a general rule to protect the information stored in the applications and on the server. Examples of techniques that can be used include for example: symmetric and asymmetric encryption, hash functions, private membership test, private set intersection, Bloom filters, private information retrieval, homomorphic encryption,etc.

SEC-5      The central server must not keep network connection identifiers (e.g., IP addresses) of any users including those who have been positively diagnosed and who transmitted their contacts history or their own identifiers.

SEC-6      In order to avoid impersonation  or the creation of fake users, the server must authenticate the application.

SEC-7      The application must authenticate the central server.

SEC-8      The server functionalities should be protected from replay attacks.

SEC-9      The information transmitted by the central server must be signed in order to authenticate its origin and integrity.

SEC-10      Access to all data stored in the central server and not publicly available must be restricted to authorised persons only.

SEC-11      The device’s permission manager at the operating system level must only  request the permissions necessary to access and use when necessary the communication modules, to store the data in the terminal, and to exchange information with the central server.

9.  Protection of personal data and privacy of natural persons

Reminder: the following guidelines concern an application whose sole purpose is contact tracing.

PRIV-1     Data exchanges must be respectful of the users’ privacy (and notably respect the principle of data minimisation).

PRIV-2     The application must not allow users to be directly identified when using the application.

PRIV-3     The application must not allow users’ movements to betraced.

PRIV-4     The use of the application should not allow users to learn anything about other users (and notably whether they are virus carriers or not).

PRIV-5     Trust in the central server must be limited. The management of the central server must follow clearly defined governance rules and include all necessary measures to ensure its security. The localization of the central server should allow an effective super vision by the competent supervisory authority.

PRIV-6     A Data Protection Impact Assessment  must be carried out and should be made public.

PRIV-7     The application should only reveal to the user whether they have been exposed to the virus, and, if possible without revealing information about other users, the number of times and dates of exposure.

PRIV-8     The information conveyed by the application must not allow users to identify users carrying the virus, nor their movements.

PRIV-9     The information conveyed by the application must not allow health authorities to identify potentially exposed users without their agreement.

PRIV-10     Requests made by the applications to the central server must not reveal anything about the virus carrier.

PRIV-11    Requests made by the applications to the central server must not reveal any unnecessary information about the user, except, possibly, and only when necessary, for their pseudonymous identifiers and their contact list.

PRIV-12    Linkage attacks must not be possible.

PRIV-13    Users must be able to exercise their rights via the application.

PRIV-14    Deletion of the application must result in the deletion of all locally collected data.

PRIV-15    The application should only collect data transmitted by instances of the application or interoperable equivalent applications. No data relating to other applications and/or proximity communication devices shall be collected.

PRIV-16    In order to avoid re-identification by the central server, proxy servers should be implemented. The purpose of these non-colluding servers is to mix the identifiers of several users (both those of virus carriers and those sent by requesters) before sharing them with the central server, so as to prevent the central server from knowing the identifiers (such as IP addresses) of users.

PRIV-17    The application and the server must be carefully developed and configured in order not to collect any unnecessary data (e.g., no identifiers should be included in the server logs, etc.) and in order to avoid the use of any third party SDK collecting data for other purposes.

Most contact tracing applications currently being discussed follow basically two approaches when a user is declared infected:  they can either send to a server the history of proximity contacts they have obtained through scanning, or they can send the list of their own identifiers that were broadcasted. The following principles are declined according to these two approaches. While these approaches are discussed here, that does not mean other approaches are not possible or even preferable, for example approaches that implement some form of E2E encryption or apply other security or privacy enhancing technologies.

9.1.  Principles that apply only when the application sends to the server a list of contacts:

CON-1      The central server must collect the contact history of users reported as positive to COVID-19 as a result of voluntary action on their part.

CON-2      The central server must not maintain nor circulate a list of the pseudonymous identifiers of users carrying the virus.

CON-3      Contact history stored on the central server must be deleted once users are notified of their proximity with a positively diagnosed person.

CON-4      Except when the user detected as positive shares his contact history with the central server or when the user makes a request to the server to find out his potential exposure to the virus, no data must leave the user’s equipment.

CON-5      Any identifier included in the local history must be deleted after X days from its collection (the X value being defined by the health authorities).

CON-6      Contact histories submitted by distinct users should not further be processed e.g. cross-correlated to build global proximity maps.

CON-7      Data in server logs must be minimised and must comply with data protection requirements.

9.2.  Principles that apply only when the application sends to a server a list of its own identifiers:

ID-1       The central server must collect the identifiers broadcast by the application of users reported as positive to COVID-19, as a result of voluntary action on their part.

ID-2       The central server must not maintain nor circulate the contact history of users carrying the virus.

ID-3       Identifiers stored on the central server must be deleted once they were distributed to the other applications.

ID-4       Except when the user detected as positive shares his identifiers with the central server, no data must leave the user’s equipment or when the user makes a request to the server to find out his potential exposure to the virus, no data must leave the user’s equipment.

ID-5       Data in server logs must be minimised and must comply with data protection requirements.