Decentralized autonomous contact tracing using Bluetooth proximity

Type of Solution

Autonomous contact tracing (person-to-person proximity)

Examples

• DP-3T based solutions
• Apple-Google based solutions

Main Characteristics

• Makes use of fully random pseudonyms not linkable to a user or group of users or his/their devices
• Decentral data storage of all ephemeral encounter identifiers on user’s devices
• Bluetooth proximity detection between devices equipped with an app that supports that same protocol
• Out-of-band attribution of ‘infection confirmation’ code by a government approved healthcare instance
• Backend service to temporary collect, store and distribute the ephemeral data from confirmed infected users

Outcome Coverage

Informing Citizens	Transmission Tracing	Supporting healthcare provisioning	Informing Policy Making and monitoring effectiveness	Optimising resource allocation	Organising Quarantining	Enabling Research
Possible for general guidelines	Encounters	No	No	No	No	No

Requirements coverage - effectiveness

Effectiveness Factor	Assessment
Accuracy of information	Circumstances for false positives and false negatives in encounter detection have been described (see Solution Component - BlueTooth). The impact on the effectiveness is not quantified. [Apple/Google] foresee risk levels to avoid false positives. Bluetooth only is not enough to assess the criticality of the encounter. Were people face-to-face, wearing face masks, having physical contact, …? Bluetooth as a distance indicator has limitations. [DP3T] Has gone through calibration of Bluetooth proximity to improve the accuracy See also: Solution Component - BlueTooth A mechanism is foreseen to have health authorities issue the confirmation of an infection
Speed of the process	After confirmation of infection, first degree contacts can immediately be informed [Apple/Google] 2nd degree contacts could be possible as well The absence of coordination with other actions necessary to test and effectively isolate or quarantine the subject might negatively impact the speed of the total process
Adaptability of the solution	The algorithm for deducing the criticality of the health exposure is located on the devices, requiring updates and/or remote configuration
Insights in transmission routes Person-to-person, environmental Presymptomatic Asymptomatic	Only encounters are detected (no visits, no health status beyond infection status, no movements Proximity tracking only covers person-to-person transmission. Environmental transmission is not covered. First degree contacts can immediately be informed [Apple/Google] 2nd degree contacts could be detected as well Non-users are not included in the contact graph, encounters below the threshold are not included Presymptomatic and asymptomatic cases are covered.
Support of isolation and quarantining	Quarantining is triggered through a notification only. Actual quarantining and access to testing might be hampered by the isolation of the system from healthcare authorities Individuals who are advised to quarantine have no official warrant to claim leave of absence (e.g. with their employer)
Targeted measures	It is not the purpose of this kind of solution to contribute to targeted measures, except for targeted communication to the users based on their individual data.
Efficient use of resources Triage Testing Contact tracers	Double work between HCT and ACT is unavoidable, as all identified contact graphs are anonymized
Interoperability	The solution is not meant to interoperate with other systems (see outcome coverage) No data is made available for use in other subdomains of the problem domain.
Acceptable side-effects	A lot of attention has been given to avoid the infection status of the users to be deduced from the behaviour of the app, especially the communication patterns.
Adoption and population coverage	Solutions require the installation and onboarding of apps available through the app stores of Apple and Google. The Apple/Google solution requires an update of the Operating System Depending on the OS requirements of the solution, older hardware might be incompatible. The adoption rate could be impacted by the isolation of the system from the rest of the healthcare system The backing of this solution by Apple, Google and privacy experts and activists probably have a positive impact on the take up of this solution. Interoperability between users of different implementations of the same protocol is foreseen Austria, Estonia, Finland, Germany, Italy, Portugal and Switzerland have announced a roadmap to enable their Apple/google based solutions to interoperate, regardless of the (decentral) protocol adopted by each country. (see Apple-style contact tracing agreed by seven European countries - 9to5Mac - https://9to5mac.com/2020/05/07/apple-style-contact-tracing/)
Feasibility and elapsed time (Experience, Initial TTM, Scaling)	The Bluetooth technology was not designed with this type of application in mind. Shortcomings include energy consumption and limitations in the support in Android and iOS. The Apple/Google initiative removes some limitations (while imposing limitations on the interoperability with other parts of the full process)
Technical dependability of the solution	The backtracking of a contact graph can be interrupted by one device being unavailable (offline, locked)
Evidence	There is no precedent in using this kind of solution.

Requirements coverage - Privacy and Security

Privacy Factor	Assessment
Minimal Requirements GDPR compliance	Likely DP3T has published a DPIA
Augmented Requirements Adhere to the joint civil society statement: “States use of digital surveillance technologies to fight pandemic must respect human rights” (see Joint Civil Society Statement) Solution is temporary Purposes are limited to responding to the pandemic and phasing out the restrictive measures Principle of least privilege The way back to normality is known Full Transparency (code, data, algorithms) Granular user consent, regardless of the legal base No mandatory use by citizens No access to data except for public health authorities, subject to consent Strictly limited retention period No support for law and policy enforcement No commercial exploitation	Compatible, with special attention given to multiple factors: Temporary solution Strictly limited purpose Principle of least privilege Way back through graceful dismantling (in DP3T), depending on Apple/Google intervention in the Apple/Google solution DP3T has offered full transparency Consent-based Voluntary installation Data is not accessed by anyone, so no access for enforcement purposes, commercial exploitation Strict limitation of retention period
Zero-Trust model specific requirements No trust must be expected from any party besides the developer The solution must only transfer and centralise truly anonymous data The anonymous nature of the data must be transparent and under scrutiny The remaining surface attack must be secured Transparency and scrutiny on the security measures	The DP3T solution has opened up for public scrutiny on its compliance with these requirements.
Trust-based specific requirements Proper governance and oversight on the Trusted Party to strictly limit the processing to the stated purpose Vetting of the personnel having access to the data Applying the Principle of Least Privilege among the personnel of the data processor Code of conduct for the personnel, actively enforced Strict application of encryption in transit and at rest until the latest possible moment before processing Reducing the attack surface to a minimum and securing it Systematically distrusting any party not under direct control of the Trusted Party (like infrastructure providers) Transparency and scrutiny on the security measures Pseudonymisation without storage of re-personalisation data Shortest possible retention period, preferably rolling Applying data minimisation, limit the data centralised	Not Applicable

Trade-off Analysis

Most technical decisions in this solution favor privacy over effectiveness, and especially the effectiveness of the whole system.

Bluetooth only:

• limits the transmission routes to proximity

No shared identifier and no data sharing:

• Renders linking to other data impossible, hampering the interoperability and efficient use of resources.

Prohibition of combination with location data:

• Renders combination of multiple function in a single app impossible (if the Apple/Google framework is used)
• Renders the addition of location context (eg being inside or outside) for interpretation of transmission risks impossible

Discussion and open topics

Discussion, including ethical considerations

When looked at from a strict scope of autonomous proximity tracking, these solutions hit a good trade-off between privacy and effectiveness thanks to their strict anonymisation and data minimisation. When looked at from the perspective of the full landscape, it is however sub-optimal. Its isolation towards other parties (like human contact tracing centers, social security, researchers, policy makers, etc) can cause adverse effects. It might increase the burden on contact tracers who might detect the same infected person through both HCT and ACT procedures and the compliance with quarantining advice might be hampered by the lack of coordination with social security agents.

From a beneficence point-of-view, the solutions bring more speed and more coverage than human contact tracing. However, by trying to avoid maleficence (primarily by wanting to avoid any trust in a data custodian) it might introduce inefficiencies in the system as a whole.

Open Topics

• How can the information be used to target test capacity (affected individuals should be tested according to the protocols)
• What happens when a user gets a quarantine notification? Will they contact their GP? Will the GP contact the contact tracers? There is no way for the contact tracers to link the case to a known index case.
• The interaction between the Apple/Google initiative (Exposure Notification Framework) and DP-3T remains unclear on some aspects. The Google/Apple Framework solves the cross-operating-system interoperability issues, mainly addressing the limitations around BLE usage in the background on iOS. It is unclear however whether this can be used without adhering to the remainder of the Apple/Google solution, which DP-3T does not need.
  • A/G handle the security & encryption functionality
  • A/G provide a framework to calculate risk scores for encounters with infected contacts (which DP-3T does not)
  • A/G have made the guarantee (and have the power to do it) that they will dismantle the system when the pandemic has been mitigated, calls will be made per country/district when this will be the case
• DP-3T states that they wish to adopt the Apple/Google Exposure Notification framework, however it is unclear if that would completely replace the DP-3T implementation as the only element that sets them apart from A/G is the availability of a back-end, which can also be implemented together with the A/G framework independent of the DP-3T specification.
  • DP-3T states that they want to use the wireprotocol set out by A/G, however our current understanding is that A/G will only allow app builders to use the high level framework (Mobile API) to make use of the exposure notification protocol, which would lock DP-3T out of reusing any underlying components for their solution.

Navigation

• Next: Decentralized autonomous contact tracing using Bluetooth proximity
• Previous: List of solutions
• Back to overview