Understanding the NHS contact tracing App
The NHS COVID-19 contact tracing App uses Bluetooth communication to determine which other phones you have been close to, and if you are later tested positive for the virus the system can then notify those other users that they may have contracted the virus. However, the way this is achieved is restricted, particularly on iOS, where Apple are very cautious about Apps consuming too much battery life.
Apple and Google saw this problem coming, and teamed up to develop a joint solution for countries to use. However, the NHS has decided against using this framework, because it would not provide them with the data they felt was sufficient to tackle the transmission of the virus. This means that they had to build their own solution, and attempt to work around the limitations imposed on them by the platforms, particularly iOS.
A technical deep-dive
So, how does the NHS App work, and what are the restrictions? The App works by advertising a Bluetooth service, scanning for the same service on other devices, connecting to another device when it discovers one, and exchanging an identifier. We’ll not focus on the security and privacy aspects here, which are discussed widely elsewhere, but instead on the technical limitations of the App.
The main limitation imposed on the App is when it operates in the background. The App asks the OS to scan for and advertise its service, which can continue even if the App’s process is not running. If another device is discovered or connects, the process is re-started in the background to handle the event. Apple’s documentation states that this should be short lived, and the App should only handle the specific event that occurred before becoming inactive again:
Apps should be session based and provide an interface that allows the user to decide when to start and stop the delivery of Bluetooth-related events.
Upon being woken up, an app has around 10 seconds to complete a task. Ideally, it should complete the task as fast as possible and allow itself to be suspended again. Apps that spend too much time executing in the background can be throttled back by the system or killed.
Apps should not use being woken up as an opportunity to perform extraneous tasks that are unrelated to why the app was woken up by the system.
However, the NHS App does not do that, so it may fall foul of Apple’s App Store review in the future. When the App connects to another device it sends “keep alive” data every 8s (“comfortably under” the 10s limit imposed by Apple) in order to keep the connection and the process alive. This works, at least for a while. Eventually iOS may kill the process anyway, or the device will go out of range.
When the App goes into the background iOS will continue advertising for around 4-7000 seconds (1-2h), and it will scan for the service on other devices. If it connects to another device this timeout might be reset, further research is required here. It seems based on reports that hopes are being pinned on Android devices “waking” the iOS process, so perhaps it does reset this timeout.
When iOS puts the App into the background the service is not advertised directly, instead it is placed into an “overflow area”. This is a proprietary iOS mechanism, but as Bluetooth is standardised we can attempt to determine how it works. Essentially a flag is set in the advertisement’s manufacturer data which corresponds to the UUID of the service. Android scans for this flag and so can discover iOS devices advertising in the background (although there is a bug which means it will currently not discover all iOS devices).
Failure cases
So when will the App not work? It ultimately fails when the user turns Bluetooth off, quits the App manually from the app switcher, or when the adverisements are stopped due to the timeout.
The first of those cases is worked around by sending the user a notification to turn Bluetooth back on. The second case is also user controlled, and while there is a notification to reopen the App it might not always work. The third case is not user controlled, and in our testing the timeout will occur even if iOS devices with the App are left in range of each other for period of time (but it might not occur if either of those devices are woken up during that period).
However, this is just the theory with a small number of devices. In practice, large numbers of devices may struggle to communicate consistently, and battery life may be impacted heavily. Testing this system is difficult and needs further research, but it’s not too early to draw some conclusions.
This App won’t work all the time
While it seems like the App will work most of the time, as identified here there are edge cases where it won’t. That’s a risk weighed up against the benefit of gaining more data by using a centralised system. However, the UK is an outlier here. It seems that most countries will use Apple and Google’s approach when it becomes available. Building a bespoke system which doesn’t work in some edge cases seems like a big risk, and one that the NHS may now be reconsidering.