Roger Clarke's Web-Site © Xamax Consultancy Pty Ltd,  1995-2024
HOME	eBusiness	Information Infrastructure	Dataveillance & Privacy	Identity Matters	Other Topics
What's New		Waltzing Matilda	Advanced Site-Search

The Effectiveness of Bluetooth Proximity Apps
in Tracing People with COVID-19 Exposure Risk

Version of 30 April 2020, with minor revisions of 2-3 May 2020

Roger Clarke **

© Xamax Consultancy Pty Ltd, 2020

This document is at http://rogerclarke.com/EC/EBPA.html

Abstract

Public health teams trace people who may have been exposed to a person infected with COVID-19. I'm a sceptic about the effectiveness of apps based on Bluetooth proximity data in supporting the efforts of those teams. These notes frame the problem, and guide the search for evidence to support or debunk my scepticism.

Contents

• Introduction
• 1. Requirements Statement
• 2. Effectiveness Factors
• 3. Analyses
• 4. Empirical Results
• References

Introduction

The COVID-19 pandemic of (roughly) the first half of 2020 gave rise to social lockdown and an economic jolt. As a response, technologists grabbed at tools that were at their disposal, and looked for ways to apply them. A better approach would have been to model the problem-domain, analyse problems within the domain, and consult with people who are active in the area. However, 'technological solutionism' is the current fashion, and 'code-first, design-later-if-ever' is the mantra.

One tool that attracted a lot of attention was Bluetooth and its use to gauge the distance between devices. When individuals were diagnosed with COVID-19, a small army of employees in public health agencies set out to trace people who had been exposed to the risk of catching it during the period when the newly-diagnosed patient was contagious (referred to in this document as 'exposure risks'). It was proposed that Bluetooth apps would enable the automation of 'contact tracing'.

I'm seeking analyses of the reliability of Bluetooth proximity apps applied to this purpose, and empirical evidence that provides insights into their reliability.

The context is set by the abrupt and unaudited release of the Australian government's 'CovidSafe' app on Sunday 26 April 2020; but the issues are generic. These notes explain why I'm sceptical about the effectiveness of the tool for the purpose it's being applied to. That should assist in the search for analyses and evidence.

1. Requirements Statement

The objective appears to be to use a device to:

1. detect other nearby devices and gather data about them while they are within-range
2. use that data to identify devices that satisfy defined criteria
3. retain defined data about those devices
4. flush the stored data after a defined period
5. subject to defined criteria, transfer the stored data elsewhere

The following paragraphs consider each of those phases in a little more detail:

(1) Device Detection

Devices may be detected on the basis of their Bluetooth transmissions. The most relevant data would appear to be an identifier or pseudonym for the device, the apparent distance separating the devices, and the date-time-stamp of the interaction. Given the potential for considerable numbers of nearby devices and the high volume of data that might be involved, some data-compression technique may need to be applied.

The Singaporean 'TraceTogether' scheme involves the exchange of Bluetooth signals between phones to detect other participating TraceTogether users in close proximity. It is built over a locally-designed protocol called BlueTrace (Bay et al. (2020), which uses Bluetooth Relative Signal Strength Indicator (RSSI) readings between devices across time to approximate the proximity of an encounter between two users. RSSI is recorded on a relative 100-point scale, but manufacturers may differ in how they assign the value.

The Australian 'CovidSafe' app is understood to require the nearby device to be participating in the scheme, i.e. to have the app installed and operating.

The registration process for each device includes the allocation of an identifier, pseudonym or reference-code, misleadingly referred to as a 'token'. The allocation is nominally by an Australian government agency, but is actually by a service run by US cloud operator Amazon. It is understood that the 'token' is changed every 2 hours, as a security safeguard against tracking by other parties. It is unclear what else happens during the nominally 2-hourly interaction between devices and the cloud-server run by Amazon. (However, it appears that poor design results in the same code often being used for an extended period, possibly many hours).

When two devices interact, it is understood that each gathers from the other at least its 'token', the signal-strength (RSSI, as a proxy measure of distance), and the date and time. (The Australian government's failure to publish the design has forced people to interpolate how it actually works).

The data exchanged between devices also includes each device's precise model-type (presumably because this is a factor in the computation of proximity). It appears that the model-type may be in cleartext, i.e. unencrypted, both during the exchange between devices, and in storage. Little or no information about this aspect appears to have been published by the government.

By experimentation, researchers have inferred that interactions between devices are attempted about every 30-60 seconds, and successful interactions are recorded. If so, this would generate a reasonably small data-collection, i.e. a mere 15-30 consecutive records is sufficient to fulfil the criterion of '15 minutes in close proximity'.

(2) Device Selection

Carriers of the virus are commonly infectious for a period of time before they're detected as being carriers. Many remain undetected, particularly those who are asymptomatic. When carriers are detected, public health teams conduct 'contact-tracing' activities. They endeavour to reconstruct the person's movements, and identify and communicate with people who may have been exposed to the virus during the carrier's period of contagiousness ('exposure risks'), in order to propose, or impose, isolation, testing and/or quarantine.

The criterion for selecting nearby devices for data retention is therefore functionally defined as any device used by a person who is an exposure risk.

This needs to be expressed in operational terms, taking into account the capabilities of and constraints on the devices. As proxy criteria, the following might be postulated:

• the nearby device must have spent at least:
  • one episode of longer than 15 seconds in very close proximity to the other device; or
  • one episode of longer than 15 minutes in close proximity to the other device; or
  • any number of episodes totalling longer than 15 minutes within any 7-day period in close proximity to the other device.

Desirably, 'close proximity' and 'very close proximity' would be defined in metres and centimetres respectively. However, it may be necessary to use a proxy-measure for distance.

Other proxies may be possible. For example, if the device's microphone is activated, sounds interpreted as coughs or sneezes could perhaps be factored into the evaluation.

The Australian 'CovidSafe' scheme defines 'close contact' as "within approximately 1.5 metres ... for 15 minutes or more" (DoH 2020, p.2).

It is unclear whether the 15-minute threshold must be reached during a continuous period (i.e. 15-30 successive c. half-minutely device interactions) or can be satisfied by the accumulation of multiple periods (e.g. 4 separate periods of 4 minutes each).

(3) Data Storage

Where a device satisfies the proximity criteria, data needs to be stored, including the device identifier, the criteria that were satisfied, and date-time-stamps as appropriate to the particular criteria. The data-storage may be local, remote or both. If remote, it may be under the user's sole control or accessible to others, and it may be cryptographically protected or not.

The Australian 'CovidSafe' app appears, as promised by the government, to initially store the data solely on the users' mobile devices.

However, the Australian app stores data about every device it encounters, not only about those that satisfy the proximity criterion. So, for those people who test positive to the virus and authorise upload of their data, data about every device (and hence person) is added to the central data store, not just data about the relevant devices and people, i.e. the exposure risks. That excess data may also be provided to the relevant public health agency.

If the Privacy By Design principle of Data Minimisation had been applied, the criterion would have been applied on the device, either prior to storage, or prior to upload. In that case, the only data transferred to the cloud-server would relate to the mobiles that satisfied the criterion. This is probably a very small minority of the mobiles that an infected person's mobile has interacted with. It has been argued that the collection of excessive data opens up the possibility of creating a comprehensive social contacts map of the nation (Middleton 2020).

Moreover the sole criterion appears to be "within approximately 1.5 metres ... for 15 minutes or more". If this means 'apparently continuous proximity for at least 15 minutes', the proxy measure is 15-30 successive interactions 30-60 seconds apart. Upload of a single entry saying in effect 'surpassed 15-minutes consecutively at <date-and-time>' is sufficient. Any additional data-transfer is at best 'just-in-case 'data-collection, and an invitation to look for secondary uses of unnecessarily intensive data.

The Australian government has failed to provide much information about its design, but it appears that the criterion is applied only after an intensive set of data has been uploaded to cloud-storage operated by a US company (and hence subject to the demand powers of US government agencies).

(4) Data Deletion

The time when the data for each nearby device is to be flushed needs to be set in advance (but the parameter may need to be amendable by the system operator). For example, if it is determined that contact-tracing is not necessary for encounters more than 14 days in the past, then the data should be flushed once the relevant date-time-stamp passes that time.

The Australian 'CovidSafe' app has been reported as using a 21-day sliding window.

(5) Data Transfer

The criteria for transmitting data may be, for example, an instruction by the user of the device, that has to be navigated to, and that requires some kind of check, perhaps including user authentication. Alternatively, the cloud-server could initiate the upload, with or without consent, and even with or without notification, based on a positive test result for the person associated with the device. The data's destination, the data formats, the communications protocol and any integrity and data protection safeguards also need to be defined.

The Australian 'CovidSafe' app has been reported as requiring an action by a person with physical possession of the device. Ambiguities in the user interface design have caused some confusion. There is also some ambiguity about whether a user of the app who has tested positive for the virus is obliged by law to transfer the data.

As noted above, data about every device (and hence every person) is added to the central data store, and is presumably also provided to the relevant public health agency, not just data about relevant devices and people, i.e. exposure risks.

2. Effectiveness Factors

Given the above assumptions (all of which are at least somewhat tentative), many factors are evident that influence the effectiveness of a scheme. These include:

1. The appropriateness of the criteria used to determine that a nearby device-id is to be treated as belonging to a person who is an exposure risk
   Reports suggest that a large majority of infections occur within-household. It is therefore normal to treat household members of an infected person as exposure risks, and a Bluetooth proximity app adds no value.
   Proximity over an arbitrarily-chosen period of time correlates poorly with the primary sources of infection, which are thought to be droplets up to 2m and vapour up to 5m.
   Proximity and time are even more poorly correlated with other sources of infection, such as passers-by who sneeze during the critical 3-5 seconds, and viral matter left on surfaces, which may survive for some hours, and which may travel (e.g. on packaging)
2. The accuracy, reliability and consistency of the computation of very close proximity and close proximity, under a wide range of circumstances
   Relevant circumstances include obstacles (such as walls, office-dividers, human bodies and clothing fabric), device orientation, other transmissions on the same frequencies as Bluetooth, the models and software versions on each of the devices, and remaining battery-power on each of the devices. As regards obstacles and orientation, see O'Neill (2020)
   In relation to the Australian 'Covidsafe' app, there have been reports of mutual interference between different apps attempting to use Bluetooth transmissions at the same time, including an app that diabetics depend on.
3. The extent to which the following are achieved:
   • high true-positive and low false-negative rates (the key measures for control of the epidemic)
   • high true-negative rates (which avoid the waste of resources and inconvenience)
   • low false-positive rates (which waste resources, create unjustified inconveniences in the form of tests and quarantining, and risk reducing the public's support for public health measures).
     However, it's generally not feasible to achieve low false-negative rates without relatively high false-positive rates, and designers are likely to err on the side of drawing more uninfected people into the net rather than missing infected people
4. The proportions of the relevant population that possess mobile devices
   For a variety of reasons, many people do not possess mobile devices.
   Australia's population is about 25m. Of the active population of 19m, 90% carry mobile devices, of which about 55% are iPhone/iOS and 45% are Android devices.
   So 10% of the active population (2m people) don't have a mobile.
   In addition, it's likely that, for a number of social and economic reasons, a significant proportion of those who don't have one are among the most vulnerable populations, such as the over-70s, people with relevant prior health conditions, the institutionalised, people in lower socio-economic segments, and street-livers
5. The proportions of the relevant population that possess mobile devices that are capable of performing the function
   Some mobiles are not Bluetooth-capable, and some Bluetooth devices are not capable of installing the app, e.g. some smart-watches. Moreover, even with mainstream smartphones, the app may not work on all models and under all operating system versions.
   The Australian 'CovidSafe' app has been interpolated by observers as being separately developed for two different environments, using Swift for iOS and Kotlin for Android.
   The iOS version of the app works only on relatively recent iPhones (5S onwards, which was released 6-1/2 years ago) and only under relatively recent versions of iOS (10 onwards, which was released only 3-1/2 years ago). So about 15% of iPhones in Australia aren't supported.
   The Android version only works under relatively recent versions (6.0 Marshmallow onwards, released 4-1/2 years ago). So about 7% of Android mobiles aren't supported.
   Together (reflecting 55%/45% market-shares), 11-12% of all mobiles aren't supported, used by about 2m people.
   In addition, it's likely that, for a number of social and economic reasons, a significant proportion of those whose device can't perform the function are among the most vulnerable populations, such as the over-70s, people with relevant prior health conditions, the institutionalised, people in lower socio-economic segments, and street-livers.
   Further, it appears that the Australian 'Covidsafe' app may only be downloadable by devices using 0400-series numbers, so anyone using an overseas SIM on global roaming cannot participate. It is also not available via app store subscriptions that are not in Australia.
   In all, rather more than 20% of the active population of 19m, well over 4m people, have no access to the app
6. The proportions of participating devices (i.e. that have the app installed) that are actually operational, i.e.:
   • are on
   • are operating in full-power rather than low-power mode
   • have the app on
   • have Bluetooth switched on
   • have authorised the app to access Bluetooth (which, on Android, because of its bundled consent mechanism, also authorises use of other location services); and
   • have the app on in such a manner that it can perform its functions.
     The iOS version of the Australian 'CovidSafe' app appears not to perform after it has slid into the background, e.g. when multiple apps are competing in the foreground, or half-an-hour after it was last invoked. (iOS is specifically designed to protect battery-life by suppressing network activity by apps running in the background)
7. The reliability of the process whereby people who test positive to the virus are linked to their record in the Amazon cloud-service, and asked to upload their contact data
   It appears that little or nothing has been published by the Australian government about this process, and it is difficult to interpolate and analyse
8. The reliability of the process whereby uploaded data is interpreted in order to identify people who are infection risks
   It appears that little or nothing has been published by the Australian government about this process, and it is difficult to interpolate and analyse
9. The extent to which the data provided by the app-based scheme is usable by the public health teams who make contact with people suspected as having been in close contact with a person now found to have been infected.
   For example, depending on the specific data model that's implemented, the team may be able to say no more than 'A person we can't name was carrying a mobile that recorded your mobile as being in close proximity to it for 15 minutes during the period <time> to <time> on <date>; but we don't know where the contact occurred'.
   No statements have been located about how the Australian 'CovidSafe' app plays information forward to public health teams, what data is provided, how well that data fits with teams' existing modi operandi, and whether the process is as effective and as efficient as the assertions made by proponents.
   At the end of April, the rate of new infections in Australia was about 75 per week. Even if all 3 million downloads of the app to 30 April had been fully operational that week, data would have been available for only 12 of those 75 cases, delivering data for perhaps 6 of 30 cases in NSW that week, 3 of 15 cases in Victoria, and very few in the other jurisdictions.

3. Analyses

There are two approaches to assessing the effectiveness of a design. The first is to bring multiple perspectives to a benchcheck of the abstract design, perhaps supported by ways of making the design 'come to life', such as demonstrations of partial implementations, dummy user-interfaces, or a cluster of archetypal use cases. A related approach is to find a live product that has considerable similarity with the design, imagine modifications to that product to fit the current need, and assess the feasibility and the usefulness of the idea.

Bluetooth transmissions have featured in many products and services, including marketing, ad-targeting, check-in to physical sites, asset-tracking and local navigation (Adarsh 2020). It is reasonable to expect that analyses of such uses exist that would represent useful examplars for analysis of prospective uses of proximity apps in managing public health.

In relation to the Australian 'CovidSafe' app, few reports on such analyses have been published, hampered as they are by the government's failure to release any design documents, and the increasingly long delay in making the source-code available. See, however, Culnane et al. (2020).

4. Empirical Results

Analyses of the design need to be complemented by studies of the scheme's operation. These need to be first undertaken under controlled 'laboratory' conditions, where various circumstances can be contrived, and the scheme's performance observed. The initial deployment can be through small-scale pilots, typically within a real-world but somewhat enclosed environment, such as a retirement village, or a hospital campus. Before the scheme moves into full operation, features need to be included that will enable key aspects of its performance to be monitored.

Australia is not the first country to develop such a scheme. Reports could be sought out concerning the pioneer-scheme, which was Singapore's 'TraceTogether' app, and those in India and Colombia. However, on 30 April 2020, "there is little concrete evidence that they have any measurable effect" (Burgess 2020).

In relation to the Australian 'CovidSafe' app, no mention has been seen of any laboratory-testing, or of any pilots. The sole indicator of the scheme's performance that has been reported comprises daily updates of the number of times the app has been downloaded. No data appears to be available for failures to download, nor of queries and complaints, nor of data-uploads, matches or contact-tracing.

Such data as may exist is entirely under the government's control, and very little is being published. At this stage, it is unclear what, if any, assessments of the effectiveness of live deployment are being undertaken.

References

Adarsh M. (2020) ' Bluetooth Low Energy (BLE) beacon technology made simple: A complete guide to Bluetooth Low Energy Beacons' BeaconStac, 23 April 2020, at https://blog.beaconstac.com/2018/08/ble-made-simple-a-complete-guide-to-ble-bluetooth-beacons/

Asghar H. (2020) 'On the privacy of TraceTogether, the Singaporean COVID-19 contact tracing mobile app, and recommendations for Australia' Melbourne School of Engineering, 6 April 2020, at https://eng.unimelb.edu.au/ingenium/research-stories/world-class-research/real-world-impact/on-the-privacy-of-tracetogether,-the-singaporean-covid-19-contact-tracing-mobile-app,-and-recommendations-for-australia

Bay J. et al. (2020) 'BlueTrace: A privacy-preserving protocol for community-driven contact tracing across borders' Government Technology Agency Singapore, 2020, at https://bluetrace.io/static/bluetrace_whitepaper-938063656596c104632def383eb33b3c.pdf

Burgess M. (2020) 'Coronavirus contact tracing apps were meant to save us. They won't' Wired Magazine, 30 April 2020, at https://www.wired.co.uk/article/contact-tracing-apps-coronavirus

CTCD (2020) 'Why should you install the COVIDSafe app?' Crush The Curve Today, 1-3 May 2020, at CTCD (2020) 'Why should you install the COVIDSafe app?' Crush The Curve Today, 1-3 May 2020, at https://blog.crushthecurve.today/why-should-you-install-the-covidsafe-app-part-1/

Culnane C., McMurtry E., Merkel R. & Teague V. (2020) 'Tracing the challenges of COVIDSafe' Github, 27 April 2020,, at https://github.com/vteague/contactTracing

DoH (2020) 'Coronavirus Contact App FAQs' Department of Health, undated, bnut presumably of 26 APril 2020 et seq., at https://www.health.gov.au/sites/default/files/documents/2020/04/covidsafe-app-faqs-coronavirus-contact-app-covidsafe-faqs.pdf

Langford S. (2020) 'Not Sure Whether to Install the Government's Covidsafe App? Here's Everything We Know' SBS News, 28 April 2020, at https://www.sbs.com.au/news/the-feed/not-sure-whether-to-install-the-government-s-covidsafe-app-here-s-everything-we-know

Middleton K. (2020) ' How the COVIDSafe data could be used' The Saturday Paper, 2 May 2020, at https://www.thesaturdaypaper.com.au/news/politics/2020/05/02/how-the-covidsafe-data-could-be-used/15883416009764

O'Neill P.H. (2020) 'Bluetooth contact tracing needs bigger, better data' MIT Technology Review, April 22, 2020, at https://www.technologyreview.com/2020/04/22/1000353/bluetooth-contact-tracing-needs-bigger-better-data/

Acknowledgements

This document has benefited from feedback from APF Board colleagues, particularly David Vaile, Graham Greenleaf, Bernard Robertson-Dunn and Nigel Waters, and from several privacy-list and link-list subscribers. The judgement-calls remain my responsibility.

An analysis that covers some of the same ground was published as a series in the days following this paper - 1-3 May 2020 (CTCD 2020).

Author Affiliations

Roger Clarke is Principal of Xamax Consultancy Pty Ltd, Canberra. He is also a Visiting Professor associated with the Allens Hub for Technology, Law and Innovation in UNSW Law., and a Visiting Professor in the Research School of Computer Science at the Australian National University.

The content and infrastructure for these community service pages are provided by Roger Clarke through his consultancy company, Xamax. From the site's beginnings in August 1994 until February 2009, the infrastructure was provided by the Australian National University. During that time, the site accumulated close to 30 million hits. It passed 75 million in late 2024. Sponsored by the Gallery, Bunhybee Grasslands, the extended Clarke Family, Knights of the Spatchcock and their drummer

Xamax Consultancy Pty Ltd ACN: 002 360 456 78 Sidaway St, Chapman ACT 2611 AUSTRALIA Tel: +61 2 6288 6916

Created: 28 April 2020 - Last Amended: 3 May 2020 by Roger Clarke - Site Last Verified: 15 February 2009
This document is at www.rogerclarke.com/EC/EBPA.html
Mail to Webmaster   -    © Xamax Consultancy Pty Ltd, 1995-2024   -    Privacy Policy