Further to the European Commission’s (Commission) Guidance on COVID-19 smartphone apps (Guidance), global efforts to develop app-based COVID-19 threat detectors are progressing. As different approaches are taken to the processing of data, we consider the emerging privacy concerns for consumers: the risks as well as the advantages associated with centralised processing and ensuring interoperability between the apps. Our April Perspectives (https://www.hausfeld.com/perspectives/covid-19-the-european-commission-emphasises-privacy-is-key-to-the-effectiveness-of-cv-19-apps) concluded that to secure a high level of take-up of the apps - key to their effectiveness - users’ privacy must be promoted. Recent developments have highlighted the tension between ensuring privacy concerns and achieving the most effective outcome.

Centralised or decentralised processing?

Common to all contact tracing apps currently in consideration is their use of Bluetooth identifiers to track encounters between smartphones. These apps then fall into two groups based on how they process data: the centralised and the decentralised processing model.

Under a centralised model, the smartphone of a user who has reported COVID-19 symptoms or tests positive uploads to a central server its own identifier. In the process, that user also uploads the identifiers of other devices which (s)he has encountered within a certain proximity and timeframe. The server then notifies the users of those other devices with, for example, instructions to self-isolate.

Conversely, apps based on decentralised processing rely solely on the user’s own identifier, which is uploaded to a centralised database in the event of COVID-19 symptoms/diagnosis. It is the smartphone itself, and not the central server, that then notifies the users of other devices encountered within a certain proximity and timeframe. The joint initiative from Apple and Google for a Bluetooth API (Application Programming Interface) relies on decentralised processing.

The Guidance indicates that decentralised processing complies with the principle of data minimisation under the General Data Protection Regulation (GDPR) and emphasises that national health agencies should only have proximity data from infected users after those users proactively share it. Further, data should only be retained for as long as is necessary and only for the purpose of contact tracing. As such, it prevents a scenario where a central database stores and could therefore potentially reveal the identities of infected individuals and those with whom they have come into contact.

The Isle of Wight Trial

Some countries have opted to develop apps based on centralised processing. Two weeks ago, the NHS began a trial of its app on the Isle of Wight, suggesting it may be rolled out across the UK within weeks. According to its FAQ page, the app processes data centrally in order to inform people rapidly if they are at risk of infection. The NHS app goes beyond purely collecting proximity data by requesting that users input part of their postcode on registration; technically allowing for geographical tracking of infection and requiring some centralised processing beyond that of Apple and Google’s stricter API . The app’s Data Protection Impact Assessment (DPIA) currently under review by the ICO has been criticised.

Dr Michael Veale, Lecturer in Digital Rights and Regulation at UCL’s Faculty of Laws, finds that data collected and processed centrally by the app could enable the identification of individuals; as the data is pseudonymised rather than anonymised(1). The current proposal may also prevent users’ right to access and delete their data. In order to enshrine user privacy on the NHS app, the House of Commons Joint Committee on Human Rights has drafted a Digital Contact Tracing (Data Protection) Bill.

Other countries

Similarly, France has opted for centralised processing in its StopCovid app, which may be launched as early as 2 June. Australia’s CovidSAFE app processes data centrally and has been available since the end of April.

On the other hand, Germany has opted for a decentralised approach currently under development by SAP and Deutsche Telekom. Chancellor Angela Merkel recently acknowledged that the decentralised processing model is likely to promote privacy and therefore user trust.

Yet, such concerns may be tempered as it appears some processing at the backend is required even for decentralised solutions. Furthermore, despite Apple and Google’s recent tougher stance to data protection in the joint initiative, users may not trust the tech giants at the helm, whose previous handling of data has come under much scrutiny. Finally, health agencies in some countries have criticised the decentralised model, saying that it precludes analysis of infection levels and hotspots.

Interoperability

The divergence of approaches between countries creates another problem: once travel restrictions are lifted, how can contact be traced between users from different countries, using different apps? Apps using the decentralised API from Apple and Google are likely to interoperate more easily than those using centralised processing.

On 13 May, the EU Member States’ eHealth Network published draft interoperability guides to address such concerns, building on its earlier Toolbox for developers. On one hand, these guidelines promote privacy across the EU through common standards of data processing. On the other hand, in proposing that national health agencies securely exchange data with each other “using a trusted and secure mechanism”, the guidelines’ interoperability requirements blur the distinction between centralised and decentralised processing. Even decentralised models will have to exchange some data to facilitate the necessary exposure notifications irrespective of the user’s location in Europe.

Notably, the above guidelines do not address the issue of interoperability with app solutions of non-EU countries. Data transfers outside the EEA are subject to additional restrictions.(2)

We continue to monitor this rapidly developing area and will keep you posted.

With thanks to intern Adel Msolly for his assistance with this blog. 

(1) Recital 26 GDPR.

(2) Chapter V GDPR