- The NHS COVID-19 app appears to work correctly when running in the background on iOS devices, unlike the Australian COVIDSafe app
- The app prevents false reports by providing users with symptoms with a reference code: that code is then associated with formal test results before action is taken
- NHS COVID-19 instructs healthcare workers to turn off Bluetooth on their device whilst wearing PPE, explaining “your interactions at work should not be captured when you are wearing PPE”
- Update 0925 BST 7th May: We’ve added a “Just how does the app manage to stay effective in the background?” section below, explaining how the app manages to stay alive when communicating with Android devices, and covering some of the challenges and techniques for iOS-to-iOS communication
- Update 1145 BST 7th May: We've added a "Does the app collect personal data and reveal my identity?" section below.
Challenges in contact tracing when an app isn’t shown on screen
App developers have few options when it comes to keeping apps “alive” when they’re not up front and center on a user’s device. Apple carefully manages these options to ensure that apps don’t invade user privacy, or unduly run down user batteries. In particular, they draw a distinction as to whether an app has focus— ie. it’s shown on the screen — or is running in the background. Recent updates to iOS have limited the ability developers have to access data whilst backgrounded: for instance, prior to being able to limit background collection so effectively, Uber was able to track a user’s movements even when not in a cab.
In order to run in a meaningful sense in the background, an app’s publisher needs to get permission from Apple when it is submitted to the App Store, by marking it with a set of “Background Modes”. These background modes are limited for use when transmitting video from one device to another, when collecting location updates, acting as a phone, or using Bluetooth. For instance, these modes are what let your phone run AirPlay in the background, play music without Spotify always showing, call someone with WhatsApp and then put it in the background, or track your run on Strava.
These modes are limited, however, and users may be familiar with the iPhone notifications asking if apps should be allowed to access your location in the background. Even when a user grants these permissions, the phone may continue to request confirmation that this is the right thing to do.
Contact tracing apps are built using Bluetooth low-energy (BLE), which — simply put — allows devices to recognise each other. Theoretically, Apple’s “Uses Bluetooth LE accessories” and “Acts as a Bluetooth LE accessory” modes are ideal for this, and allow use of BLE in the background. However, whilst a backgrounded app using these modes will be able to continue to communicate with any BLE devices it’s already in communication with (such as a Bluetooth smart-lock), it won’t be able to control the rate of broadcast to poll devices that it hasn’t seen before. When backgrounded, this makes it harder to look for signs of new devices, to communicate with them meaningfully, and in particular to identify non-Apple devices. This rather hampers contact tracing apps that must run continuously in the background.
To quote Apple’s documentation on the service:
All service UUIDs [...] can be discovered only by an iOS device that is explicitly scanning for them. [...and for] apps that are advertising are in the background, the frequency at which your peripheral device sends advertising packets may decrease
Workarounds and alternative approaches for tracing
Of course, this isn’t a new challenge for developers: they’ve long been trying to find methods for apps to stay backgrounded and collect restrictionstracing data. Frameworks such as the open source AltBeacons have emerged to tackle this, aren’t viable for contact tracing where a device must continuously be looking for new devices. As ABC found in Australia, when looking at their national COVIDSafe app, there’s not been a practical solution to this. A few exploits exist that might be temporarily useful — such as registering one’s app as an audio player and making it play music — but these and other exploits of this nature are frowned on by Apple, stand to inconvenience users, and rarely pass approval to the App Store.
In the meantime, Apple has been preparing to release iOS 13.5, which is currently available in beta. Apple are able to make changes to their own system that are advantageous to tracking in this way. 13.5 will introduce a number of more obvious features — such as support for FaceID for users wearing a mask, or at least a more rapid route to entering a passcode — and some less obvious features, such as the ExposureNotification framework which enables just what the contact tracing apps need. This won’t result in the perfect system, of course: not every user will be able to take advantage of this, as devices like the iPhone 6 (2015) aren’t able to run iOS 13. Whilst Apple’s system uses a global standard identifier, each country that implements it uses a siloed national database. Thus if an infected European from one country is exposed to a citizen from another European country, they won’t discover it through contact tracing.
Apple’s COVID-19 ExposureNotification provides a solution for what’s needed here, but there are caveats. Most significantly, Apple has indicated that only their app will be able to make use of it in order to prevent misuse of the technology by others.
So how do the NHS do it with their COVID-19 app?
How then, can the British NHS COVID-19 effectively trace new devices whilst backgrounded, without “falling asleep” (technically, “being suspended”) and thus being rendered ineffective? From our testing with version 1.0.1b341 of “NHS COVID-19” app, we can see does indeed communicate effectively in the background. It appears that this is done through use of a series of clever workarounds using keepalives and notifications.
Force quitting the app will stop background tracing, however, if instead the phone is powered off and back on, it will continue to communicate properly in the background. This workaround may or may not fall foul of Apple, but at this point it hasn’t been disclosed, and Apple have approved the builds of the app they’ve seen so far.
We’re continuing to look into this and will be publishing more detail as things develop.
Does the NHS COVID-19 app store sensitive data?
No. The app seems very well put together, using sensible security practises, and without storage of unnecessary data. It revolves around a linkingId that gets generated for each install of the app. This ID persists across install of the app, so uninstalling and reinstalling it won’t reset the identifier.
Looking at data from the app using iPhone Backup Extractor under the uk.nhs.nhsx.sonar path, we can see there are a series of files coupled to Google Firebase and a collection of small Plists (configuration files) for the rest of the app’s data.
Can users falsely self-report that they have COVID-19?
If a user reports symptoms, the app provides a number to call to arrange a test, along with a reference code. The idea is that the test result is then associated with the user’s reference code. Were a user to falsely report symptoms, confirmation would not happen without the NHS updating the test result to match the user’s code.
Does the app request location permissions?
No, it does not.
Did the NHS mislead the public about using Google APIs?
No. The NHS COVID-19 app is deeply integrated with Google’s industry-standard Firebase API for data storage and management. (The NHS is not using Google or Apple’s contact tracing framework; aside from anything else, this will not be available until the release of iOS 13.5.)
Which services does the app communicate with?
As with the Android app, all material communication is run through to the NHS’ COVID19 API, hosted under *.covid19.nhs.uk. The app makes a few other requests as a consequence of using Microsoft’s AppCenter service, but none that are material or sensitive.
If NHS workers use the app, won’t it lead to false positives?
The app prompts healthcare workers to disable Bluetooth on their devices whilst wearing PPE, stating “your interactions at work should not be captured when you are wearing personal protective equipment”.
We’ve been pleased to take a deeper dive into the NHS’s COVID-19 app. Whilst there’s been a lot of speculation around its functionality, what we’ve seen is a well-built and secure app. The background tracing appears to work, although it remains very much in Apple’s control as to whether this will continue to be effective. As a consequence, the effectiveness of the British response to COVID-19 is now also in Apple’s control.
The choice to go it alone or use Apple’s framework will have been a challenging one. Following Apple’s lead would likely have been a less controversial choice. However, iOS 13.5 is not live yet, whereas the British app releases in beta tomorrow, and there’s nothing to stop the UK moving to follow Apple in subsequent updates. Seen through that lens — why not ship a trial in the Isle of Wight first?
Just how does the app manage to stay effective in the background?
We’ve added this answer 0925 BST, May 7th, to answer questions we’ve received on the specifics of the app staying alive. NHSX have used a few smart techniques to better outcomes here.
The Sun reported last night that the app uses private Bluetooth APIs, but we’ve seen no sign of this and they’ve since amended their story to retract this assertion. The NHS COVID-19 app uses public Bluetooth APIs within iOS and doesn’t appear to take advantage of any special privileges. Instead, there are some clever techniques.
The first technique is in response to iOS’s Bluetooth behaviour for suspended apps. We noted that Apple changes how an app can scan for new devices when suspended. Suspended apps aren’t able to correctly recognise devices that they haven’t seen before. As we wrote above, it’s “harder to look for signs of new devices, to communicate with them meaningfully, and in particular to identify non-Apple devices”.
NHSX approached the non-Apple device challenge the other way around: realising they couldn’t influence what iOS was doing in this regard, they’ve built clever stuff in their Android app to recognise the restricted, Apple-specific messages that a backgrounded app on an iOS device would send. This gives the Android device enough information to be able to talk to the iOS device, waking it back up into a state they can communicate.
The situation without iOS is a little different; there’s a threshold whereby the NHS COVID-19 app can go quiet when left in the background for a period of time, and device logs show examples of this. In this case, the app has been pushed to the background, but will be able to continue to scan (technically, “broadcast”) for over an hour and a half. Other events on the phone — including other apps using Bluetooth — can extend this.
Session uk.nhs.nhsx.sonar-peripheral-11919-319 can advertise in background for 6240 seconds
As a consequence, it’s not possible to say “the app will become ineffective in iOS-to-iOS communication after X period of time”: there’s a generous variable window that the app has to stay alive, and a number of reasonable factors that can trigger this window being extended including other use of Bluetooth, the presence of Android devices, and the effectiveness of notifications.
There are some less common situations where iOS might try to completely suspend a background app, for instance where the system is running low on memory. When this occurs, the reliability of the service is affected. The app tries to address this by triggering a push notification asking users to re-open the app, but this won’t always work, depending on the state of the device. In our tests, the iOS devices we’ve run the app on have continued to keep the background service running overnight.
Does the app collect personal data and reveal my identity?
We’ve added this answer 1145 BST, May 7th, to answer questions we’ve received on the app’s collection and transmission of data
The iOS app captures really very little data: it’s all about their linkingId. That could only get tied to a person if they reported symptoms and arranged a test with the NHS using that ID.
A positive test result being coded against an ID is effectively what sets the tracing alarm off. The question then is whether the NHS would centrally store a person’s details collected at the time of test alongside that ID. This wouldn’t be necessary for the app to work, and isn’t intrinsic to the app. As we wrote earlier, the app does not have access to location data beyond the first few digits of a user’s postcode (which are entered by the user on setup, and are not validated.)
The question here then isn’t about what the app stores: it’s about what information the NHS requests when booking a test, and how that information is stored.
If a user was to report symptoms and not arrange a test (or arrange a test without providing their ID), there would be absolutely no way for the two types of information to be linked. Of course, in this extreme scenario this would also prevent the app from alerting if the user had COVID-19.
We’re continuing to look into this and will be publishing more detail as things develop.
