The Government of Alberta advertises that ABTraceTogether, their COVID contact tracing app, works on iPhones when run in the background. They are incorrect.

This research was originally published on Google Docs (ABTraceTogether iPhone Background Capability Analysis) on November 11, 2020, with a short summary described on Twitter. The tweets and research notes are archived and reproduced here with some formatting edits.

Executive Summary

(Reproduced from Twitter)

On the weekend, I tweeted about how ABTraceTogether doesn’t work correctly between iPhones. Steve Buick, press secretary to the Minister of Health of Alberta, replied on Twitter and told me that I was wrong. So, I tested it.

It doesn’t work in the background, iPhone/iPhone. Doesn’t work consistently iPhone/Android, either.

iPhone/iPhone: In over 12 hours of close exposure between two iPhones with ABTraceTogether in the background, zero records of exposure were recorded. After bringing the app into the foreground on one iPhone, exposure records began being collected immediately.

Android/iPhone: While some exposure was recorded while both devices were in the background, it did not occur consistently w/ physical exposure. One hour of physical exposure is more than sufficient to contract COVID-19, but did not trigger ABTraceTogether’s exposure recording.

Overview

(Special thanks to my collaborator and iPhone contributor: Amanda Fenniak 😘)

ABTraceTogether is an application distributed by the Government of Alberta for the purpose of aiding Alberta Health Services contact tracers in reaching out to potential subjects of COVID-19 exposure. ABTraceTogether is based off a Singapore application called TraceTogether, which has been developed based upon the OpenTrace protocol for bluetooth exposure notification.

Concerns have been raised over the effectiveness of ABTraceTogether at detecting exposure when the application is running in the “background” on an iOS device, such as an iPhone.

In this document, a real-world test of the exposure notification capability of an iPhone is performed and analyzed.

Background

When ABTraceTogether was launched, it was clearly communicated that the application did not work in the “background”. For example, Global News reported May 22, 2020, that “An update to Apple’s iOS will allow the Alberta government’s ABTraceTogether app to operate in the background and when the iPhone is locked. However, the ABTraceTogether app is not using the software update yet.” (https://globalnews.ca/news/6969842/ios-update-abtracetogether-app-apple-alberta-coronavirus/)

On September 24 2020, an update to ABTraceTogether was launched which included in the release notes “added capability to do contact tracing while the application is in the background” (https://apps.apple.com/ca/app/abtracetogether/id1508213665).

Screen capture of the Version History from ABTraceTogether sourced from the Apple App store, indicating an update in version 1.4.0 that "added capability to do contact tracing while the application is in the background"

However, doubts arose that this was an accurate description of the capabilities. The Singaporean application TraceTogether also had an update to allow background utilization, but it included the notes that “Except for very limited circumstances, iOS apps are still unable to exchange signals with other iOS apps if both apps are in the background.” (https://support.tracetogether.gov.sg/hc/en-sg/articles/360050556334-I-see-COVID-19-Exposure-Notifications-in-my-phone-s-operating-system-Do-I-need-to-turn-it-on-for-my-TraceTogether-App-to-work-in-the-background-)

Screen capture of the release notes from the Singaporean application, noting that "Except for very limited circumstances, iOS apps are still unable to exchange signals with other iOS apps if both apps are in the background"

Based upon a review of public literature, it seems unlikely that ABTraceTogether can work correctly as expected. Reference literature:

It seems that there is sufficient reason to believe that Apple enforces app restrictions that would prevent ABTraceTogether from performing the type of background scanning that is required for OpenTrace bluetooth protocol to work correctly.

Experimental testing will resolve whether the ABTraceTogether application has capabilities beyond those documented in the TraceTogether application.

Test Protocol

  • ABTraceTogether was installed on two iPhones
  • The iPhones were exposed to each other with ABTraceTogether in the “foreground” for a period of time
    • Foreground: Both phones were left unlocked, with the ABTraceTogether application running
  • Other apps on the phones were used, to make ABTraceTogether run in the “background” for an extended period of time
    • ABTraceTogether was not closed via the App Switcher
  • Data collected from one of the phones was analyzed
    • See Appendix for more detailed information on the data collection procedure

Test Details

  • iPhone #1:
    • iPhone 11 Pro
    • iOS 14.2
    • ABTraceTogether version 1.4.0 installed from the Apple App Store
  • iPhone #2:
    • iPhone 6s
    • iOS 14.1
    • ABTraceTogether version 1.4.0 installed from the Apple App Store
  • Android #1:
    • OnePlus 7T
    • OxygenOS (Android) 10.0.14.HD65AA
    • ABTraceTogether version 1.4.0 installed from the Google Play Store
  • After the installation, the two iPhones were left with ABTraceTogether running in the foreground between 7:22am and 8:00am on November 10th
  • Other applications were used on both iPhones; the two iPhones were physically within 2 meters of each other throughout November 10th between 8am and 6pm
  • Android #1 entered physical proximity of both iPhones around 8am for less than 10 minutes
  • Android #1 entered physical proximity of both iPhones around 12pm for about 1 hour
  • Android #1 entered physical proximity of both iPhones around 5pm for about 1 hour
  • Between 6pm and the next morning around 7am, iPhone #1 and iPhone #2 were physically separated
  • The next morning around 6:30am, iPhone #1, iPhone #2, and Android #1 were all physically reunited
  • Test data was collected from iPhone #2 at 6:49am by performing a backup to a macOS device, extracting the SQLite tracer.sqlite DB from the application, and exporting all data to a spreadsheet for analysis and reformatting
  • Between 7:39am and 7:50am (Nov 11) iPhone #1 started running ABTraceTogether in the foreground
  • A second test data set was collected from iPhone #2 at 7:50am, following the same procedure as the first test data set.

Data & Analysis

  • Raw data from both data sets is was imported into a spreadsheet for analysis
  • ABTraceTogether collects all exposures in a table named ZENCOUNTER with the following fields:
    • Z_PK INTEGER PRIMARY KEY
      • Analysis: sequentially incrementing primary key of the record
    • Z_ENT INTEGER
      • Analysis: always contains the value 1
    • Z_OPT INTEGER
      • Analysis: always contains the value 1
    • ZV INTEGER
      • Analysis: Contains the value 1 for an initial record “Scanning started”, and contains the value 2 for all exposure records
    • ZRSSI FLOAT
      • Analysis: measurement of the received signal strength indicator, likely in dBm; the values range from -49 to -101
    • ZTIMESTAMP TIMESTAMP
      • Analysis: Cocoa date-time value, which is measured in seconds since midnight, January 1, 2001, in UTC
    • ZTXPOWER FLOAT
      • Data: NULL, 8, 12, or -1
      • Analysis: Not clear
    • ZMODELC VARCHAR
      • Data: “iPhone” or “Android”
      • Analysis: In the Bluetooth protocol, “central” devices are host devices, and “peripheral” devices connect to central devices. The “C” suffix indicates that this suggests which type of device was the “central” device in this exposure.
    • ZMODELP VARCHAR
      • Data: “iPhone” or “Android”
      • Analysis: As per field ZMODELC, this is believed to be the model of the peripheral device.
    • ZMSG VARCHAR
      • Data: 61 bytes of BASE64 encoded data; repeated multiple times for each exposure
      • Analysis: This is the exposure ID of the target device; there seems to be no confidential information in the base64 decoded data
      • The data published in this spreadsheet has been trimmed to the first 30 characters in the unlikely event that confidential or sensitive information is contained in the token
    • ZORG VARCHAR
      • Data: String “CA_AB”
      • Analysis: Possible future expansion to multiple regions, or integration with other OpenTrace-supported applications
  • Data collected:
    • 47 exposures were collected between 7:22am Nov 10 and 6:49am Nov 11
    • Three unique ZMSGs were found between iPhone devices
      • One ZMSG occurred 28 times
      • One ZMSG occurred 13 times
      • One ZMSG occurred 2 times
    • Two unique ZMSGs were found between iPhone and Android devices
      • One ZMSG occurred 1 time
      • One ZMSG occurred 2 times
    • An additional 16 exposures were collected between 6:49am Nov 11 and 7:50am Nov 11
  • Analysis:
    • The three iPhone exposures are believed to be:
      • iPhone #1 -> iPhone #2
      • iPhone #2 -> iPhone #2
      • An unidentified iPhone -> iPhone #2 (2 times
        • These rarer iPhone to iPhone connections had a much lower RSSI, -101 and -98, as compared to the RSSIs in the range of -68 between the more common exposures
    • The two Android exposures are believed to be:
      • Android #1 -> iPhone #2
      • An unidentified Android -> iPhone #2
    • In test data set #1, all iPhone to iPhone exposures occurred while iPhone #2 had the ABTraceTogether application running in the foreground
      • 44 iPhone/iPhone exposures occurred in the 30 minutes that the app was running in the foreground on both devices
      • 0 iPhone/iPhone exposures occurred in the 23 hours that the app was running in the background on both devices
    • In test data set #2, 16 additional exposures occurred
      • 2 iPhone/iPhone exposures occurred while both devices were believed to have the app running in the background
      • 14 exposures occurred in the 10 minutes that the app was running in the foreground on at least one iPhone device
    • Android/iPhone exposures also occurred rarely considering the proximity of the devices; during two 1hr windows of exposure on Nov 10 no exposures were recorded on the iPhone

Conclusion

ABTraceTogether does not effectively record iPhone-to-iPhone exposures while both devices have ABTraceTogether running in the background. In over 12 hours of close exposure between two iPhones with ABTraceTogether in the background, zero records of exposure were recorded. After bringing the app into the foreground on an iPhone, exposure records began being collected immediately.

Android/iPhone exposure notification is also quite inconsistent. While some exposure was recorded while both devices were in the background, it did not occur consistently at the same time as physical prolonged exposure occurred. One hour of physical exposure is more than sufficient to contract COVID-19, but did not trigger ABTraceTogether’s exposure recording.

Follow-Up Work

iPhone/iPhone exposure notification was collected once when neither device is believed to have the app in the foreground. It is likely a testing error occurred, as this abnormal finding is inconsistent with many hours of previous data collection. Continued data collection will be performed to identify the likelihood of this occurring again.

  • Update 2020-11-11 @ 11:05am – Twitter user @ZiadFazel has offered a theory that this exposure may have occurred because one iPhone was plugged in, allowing the power-saving features of Apple’s platform to be disabled. It is true that one phone was plugged in; iPhone #2 was prep’d for another data backup during this time window. This theory is unproven, but a plausible explanation for the background exposure in this small time window.
  • Update 2011-11-12 @ 6:00am – An analysis of an additional 24 hours of exposure data from iPhone #2 has shown results consistent with the first 24 hours of data; no iPhone to iPhone exposures were recorded despite iPhone #1 and #2 being in close proximity, with the apps in the background. iPhone #2 to Android #1 exposures were observed in two roughly 10 minute windows, 12 hours apart, despite ongoing daily exposure, which continues to indicate that iPhone-Android exposure is also not consistent.

Android/Android exposure notification could not be tested with the data source used in this testing. Future experimentation on the effectiveness of Android exposure detection is recommended, but a rooted Android device is likely required to collect an Android exposure database.

Appendix

Collecting iPhone Exposure Database

Using the software iMazing, a full iPhone backup was performed. Accessing tracer.sqlite from the application is trivial, as demonstrated in the below screenshot.

Screen capture of extracting the "tracer.sqlite" file from an iPhone using the tool iMazing

As with most Core Data based iOS applications, the data is stored in a SQLite database. This specific database was a SQLite 3.x database, last written using SQLite version 3032003.

Data was exported from the SQLite database for analysis in Google Sheets by exporting the ZENCOUNTER table to CSV:

Screen capture of extracting the SQLite database "tracer.sqlite" to a CSV files