Difference between revisions of "Decentralized autonomous contact tracing using Bluetooth proximity"

From Appiaplus
Jump to navigation Jump to search
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
−
= Type of solution =
 +
= Type of Solution =
   
 
Autonomous contact tracing (person-to-person proximity)
  
Autonomous contact tracing (person-to-person proximity)
Line 5: Line 5:
 
= Examples =
  
= Examples =
   
  +
* DP-3T based solutions
−
* UK
  
  +
* Apple-Google based solutions
−
* Singapore
  
−
* France
  
−
* Australia
  
−  
   
 
= Main Characteristics =
  
= Main Characteristics =
   
  +
* Makes use of fully random pseudonyms not linkable to a user or group of users or his/their devices
−
* Exchanges temporary identifiers during encounters
  
  +
* Decentral data storage of all ephemeral encounter identifiers on user’s devices
−
* Makes use of pseudonyms linked to a device or optionally a user
  
−
* Centralized data storage of all observed encounter identifiers by trusted third party
  
 
* Bluetooth proximity detection between devices equipped with an app that supports that same protocol
  
* 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
  
* 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 =
  
= Outcome Coverage =
Line 30: Line 27:
 
| '''Enabling Research'''
  
| '''Enabling Research'''
 
|-
  
|-
−
| Possible
 +
| Possible for general guidelines
 
| Encounters
  
| Encounters
 
| No
  
| No
  +
| No
−
| Possible
  
  +
| No
−
| Possible
  
  +
| No
−
| Interoperability possible
  
  +
| No
−
| Possible
  
 
|}
  
|}
   
Line 42: Line 39:
   
 
{| class="wikitable"
  
{| class="wikitable"
−
| width="30%" | '''Effectiveness Factor'''
 +
|width="30%"| '''Effectiveness Factor'''
−
| width="50%" | '''Assessment'''
 +
|width="50%"| '''Assessment'''
 
|-
  
|-
 
| Accuracy of information
  
| Accuracy of information
 
|
  
|
−
* Circumstances for false positives and false negatives in encounter detection have been described (see [https://docs.google.com/document/d/1BdxCTwcxbM5-tpvXA3mdrY7qm7U1ZDJDh3nlcetdUyU/edit?usp=sharing Solution Component - BlueTooth]). The impact on the effectiveness is not quantified.
 +
* Circumstances for false positives and false negatives in encounter detection have been described (see [https://docs.google.com/document/d/1BdxCTwcxbM5-tpvXA3mdrY7qm7U1ZDJDh3nlcetdUyU/edit?usp=sharing 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 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.
 +
* Bluetooth as a distance indicator has limitations. [DP3T] Has gone through calibration of Bluetooth proximity to improve the accuracy
−
* Calibration could definitely help with the accuracy of the BLE proximity estimations (but is no silver bullet)
  
 
* See also: [https://docs.google.com/document/d/1BdxCTwcxbM5-tpvXA3mdrY7qm7U1ZDJDh3nlcetdUyU/edit?usp=sharing Solution Component - BlueTooth]
  
* See also: [https://docs.google.com/document/d/1BdxCTwcxbM5-tpvXA3mdrY7qm7U1ZDJDh3nlcetdUyU/edit?usp=sharing Solution Component - BlueTooth]
 
* A mechanism is foreseen to have health authorities issue the confirmation of an infection
  
* A mechanism is foreseen to have health authorities issue the confirmation of an infection
−
* Calibration could definitely help with the accuracy of the BLE proximity estimations (but is no silver bullet)
  
 
|-
  
|-
 
| Speed of the process
  
| Speed of the process
 
|
  
|
 
* After confirmation of infection, first degree contacts can immediately be informed
  
* After confirmation of infection, first degree contacts can immediately be informed
  +
* [Apple/Google] 2nd degree contacts could be possible as well
−
* Possible to model (and inform) up to 5th degree contacts
  
−
* The possibility to coordinate with other actions can further reduce the time between confirmation or suspicion of infection and affective isolation or quarantining.
 +
* 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
  
| Adaptability of the solution
 
|
  
|
−
* The algorithm for deducing the criticality of the health exposure is central, hence easy to update.
 +
* The algorithm for deducing the criticality of the health exposure is located on the devices, requiring updates and/or remote configuration
 
|-
  
|-
 
|
  
|
Line 73: Line 68:
 
* Only encounters are detected (no visits, no health status beyond infection status, no movements
  
* 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.
  
* Proximity tracking only covers person-to-person transmission. Environmental transmission is not covered.
  +
* First degree contacts can immediately be informed
−
* Contacts up to the 5th degree can be detected.
  
  +
* [Apple/Google] 2nd degree contacts could be detected as well
−
* There is not necessarily a filtering of the users being included in the contact graph (eg based on their risk profile)
  
−
* Non-users are not included in the contact graph.
 +
* Non-users are not included in the contact graph, encounters below the threshold are not included
 
* Presymptomatic and asymptomatic cases are covered.
  
* Presymptomatic and asymptomatic cases are covered.
 
|-
  
|-
 
| Support of isolation and quarantining
  
| Support of isolation and quarantining
 
|
  
|
−
* Quarantining is triggered through a notification sent out by a trusted healthcare authority that links with other supporting instances
 +
* 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 by authorized healthcare instances can be supported socially and economically (e.g. proof of absence for their employer)
 +
* Individuals who are advised to quarantine have no official warrant to claim leave of absence (e.g. with their employer)
 
|-
  
|-
 
| Targeted measures
  
| 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.
−
* The collected data can be used for creating insights that can lead to targeted measures
  
 
|-
  
|-
 
|
  
|
Line 93: Line 88:
 
* Contact tracers
  
* Contact tracers
 
|
  
|
  +
* Double work between HCT and ACT is unavoidable, as all identified contact graphs are anonymized
−
* HCT can benefit from the data gathered via ACT and can alleviate their resources
  
 
|-
  
|-
 
| Interoperability
  
| Interoperability
 
|
  
|
  +
* The solution is not meant to interoperate with other systems (see outcome coverage)
−
* With strict user consent, data can be made available for epidemiological research
  
  +
* No data is made available for use in other subdomains of the problem domain.
−
* Research and modeling is possible on aggregated and/or filtered data sets while the pandemic lasts
  
−
* The use of a shared identifier enables many use cases
  
 
|-
  
|-
 
| Acceptable side-effects
  
| 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.
−
* This cannot be stated in general. It is possible to implement this kind of solution with protection against unauthorised insight in the health status of the user through observation or coercion. But lack of attention for this aspect can be harmful.
  
−
* Abuse of data is not impossible.
  
 
|-
  
|-
 
| Adoption and population coverage
  
| Adoption and population coverage
 
|
  
|
  +
* Solutions require the installation and onboarding of apps available through the app stores of Apple and Google.
−
* The adoption rate could be hampered by the inherent distrust of uncertainty that comes with having to trust a central instance with valuable information
  
  +
* 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)
  
| 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 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)
−
* The improvements projected by Apple and Google for their Exposure Notification Framework is not available for apps with centralisation of data, so fallbacks are needed (see [https://docs.google.com/document/d/1BdxCTwcxbM5-tpvXA3mdrY7qm7U1ZDJDh3nlcetdUyU/edit?usp=sharing Solution Component - Bluetooth]), none of which have proven to be satisfactory.
  
 
|-
  
|-
 
| Technical dependability of the solution
  
| Technical dependability of the solution
 
|
  
|
  +
* The backtracking of a contact graph can be interrupted by one device being unavailable (offline, locked)
−
* If implemented with early centralisation of data (as opposed to uploading when an infection is confirmed) the working of the solution is not dependent on the availability of the user devices.
  
 
|-
  
|-
 
| Evidence
  
| Evidence
 
|
  
|
  +
* There is no precedent in using this kind of solution.
−
* Where this kind of solution has been used, uptake has been below expectations (e.g. Singapore) in number of downloads. It is not clear what the actual usage rate is.
  
−
* It is unclear what impact the use of the solution had.
  
 
|}
  
|}
−  
   
 
= Requirements coverage - Privacy and Security =
  
= Requirements coverage - Privacy and Security =
   
 
{| class="wikitable"
  
{| class="wikitable"
−
| width="30%" | '''Privacy Factor'''
 +
|width="30%"| '''Privacy Factor'''
−
| width="50%" | '''Assessment'''
 +
|width="50%"| '''Assessment'''
 
|-
  
|-
 
|
  
|
Line 136: Line 133:
 
* GDPR compliance
  
* GDPR compliance
 
|
  
|
  +
Likely
−
Compliance is possible, but is case-specific.
  
  +
DP3T has published a DPIA
−
Debate possible about the proportionality of the data collection: data of all users are processed regardless of their being infected or potentially affected. One can argue that this comes with the benefit of reduction of the elapsed time between a potentially risky encounter and a warning.
  
 
|-
  
|-
 
|
  
|
Line 153: Line 150:
 
* No support for law and policy enforcement
  
* No support for law and policy enforcement
 
* No commercial exploitation
  
* No commercial exploitation
  +
|
−
| Alignment is possible, but is case-specific.
  
  +
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
  +
*
 
|-
  
|-
 
|
  
|
Line 162: Line 170:
 
* The remaining surface attack must be secured
  
* The remaining surface attack must be secured
 
* Transparency and scrutiny on the security measures
  
* Transparency and scrutiny on the security measures
  +
| The DP3T solution has opened up for public scrutiny on its compliance with these requirements.
−
| Not applicable
  
 
|-
  
|-
 
|
  
|
Line 177: Line 185:
 
* Shortest possible retention period, preferably rolling
  
* Shortest possible retention period, preferably rolling
 
* Applying data minimisation, limit the data centralised
  
* Applying data minimisation, limit the data centralised
  +
| Not Applicable
−
| Compliance is possible, but is case-specific.
  
 
|}
  
|}
   
 
= Trade-off Analysis =
  
= Trade-off Analysis =
  +
  +
Most technical decisions in this solution favor privacy over effectiveness, and especially the effectiveness of the whole system.
   
 
Bluetooth only:
  
Bluetooth only:
   
  +
* limits the transmission routes to proximity
−
* Avoids the privacy challenges linked to gathering location data
  
−
* Limits the transmission routes to person-to-person only
  
   
−
Shared identifier and centralisation of data:
 +
No shared identifier and no data sharing:
   
−
* Allows linking to other data, allowing interoperability and efficient use of resources
 +
* Renders linking to other data impossible, hampering the interoperability and efficient use of resources.
−
* Rules out the use of Apple/Google Exposure Notification Framework and foregoes the Bluetooth improvements
  
−
* Requires more privacy and security safeguards in order to comply with the augmented requirements
  
   
  +
Prohibition of combination with location data:
−
Not being able to use the Apple/Google Exposure Notification Framework:
  
   
  +
* Renders combination of multiple function in a single app impossible (if the Apple/Google framework is used)
−
* Forces suboptimal Bluetooth functioning and resulting battery drain, which in turn might lead to a poorer adoption rate. (see [https://docs.google.com/document/d/1BdxCTwcxbM5-tpvXA3mdrY7qm7U1ZDJDh3nlcetdUyU/edit?usp=sharing Solution Component - Bluetooth])
  
  +
* Renders the addition of location context (eg being inside or outside) for interpretation of transmission risks impossible
   
 
= Discussion and open topics =
  
= Discussion and open topics =
Line 201: Line 209:
 
== Discussion, including ethical considerations ==
  
== 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.
−
The interoperability and adaptability that is enabled by this solution increases its value towards the other parties essential to the effectiveness of the overall system (human contact tracers, healthcare providers, social security, analysts and researchers and in turn policy makers).
  
   
  +
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.
−
This increases the beneficence of the solution, possibly in proportion to the increased privacy footprint. This proportionality is subject to the compliance with the specific requirements for trust-based solutions, which is a high bar to meet and can only be assessed case by case.
  
−  
−
A trusted third party needs to be identified, empowered and shielded from forces that do not adhere to the core of the purpose set forth. Once found, the general public will need to be convinced of those guarantees as well, a tough challenge in any situation.
  
   
 
== Open Topics ==
  
== Open Topics ==
   
  +
* How can the information be used to target test capacity (affected individuals should be tested according to the protocols)
−
Do the benefits of a shared identifier, which enables many use cases for epidemiologists and other researchers and in turn policy makers, outweigh the inherent privacy concerns?
  
  +
* 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.
−
Is there value in 2nd and higher degrees of contact mapping?
  
  +
** 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)
−
Without any notion of location information, it is possible to use the available information be direct test capacity (affected individuals should be tested according to the protocols)
  
  +
** 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.
−
How well will the hybrid BLE approach for contact tracing work (especially compared to the Apple-Google protocol)?
  
  +
** 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.
−  
−
How can the trust in the third party be guaranteed and how can we give credible assurances to the users that there is no way their data would fall in the hands of institutions outside of the scope of the battle against the pandemic?
  
−  
−
And even if such guarantees could be provided, in theory and in practice, creating that perception with the end-users is yet another challenge that needs to be tackled.
  
−  
−  
   
 
= Navigation =
  
= Navigation =
   
−
* [[Human contact tracing|Next: Human contact tracing]]
 +
* [[Decentralized autonomous contact tracing using Bluetooth proximity|Next: Decentralized autonomous contact tracing using Bluetooth proximity]]
  +
* [[List of solutions|Previous: List of solutions]]
−
* [[Centralised autonomous contact tracing using Bluetooth proximity|Previous: Centralised autonomous contact tracing using Bluetooth proximity]]
  
 
* [[Overview|Back to overview]]
  
* [[Overview|Back to overview]]
   

Latest revision as of 12:26, 21 May 2020

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

Retrieved from "https://wiki.appiaplus.eu/index.php?title=Decentralized_autonomous_contact_tracing_using_Bluetooth_proximity&oldid=125"