Roger Clarke's Web-Site
© Xamax Consultancy Pty Ltd, 1995-2019
|Identity Matters||Other Topics||Waltzing Matilda||What's New|
Version of 30 April 2020, with minor revisions of 2-3 May 2020
Roger Clarke **
© Xamax Consultancy Pty Ltd, 2020
Available under an AEShareNet licence or a Creative Commons licence.
This document is at http://rogerclarke.com/EC/EBPA.html
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.
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.
The objective appears to be to use a device to:
The following paragraphs consider each of those phases in a little more detail:
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'.
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:
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).
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).
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.
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.
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:
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).
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.
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/
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).
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 60 million in early 2019.
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