They’ve also published extra technical details about how ENS works. You can, see for example, the source code of an example system (via the Github repository).
The update to the API includes five main changes. First, when an exposure is detected, the public health authorities now have more flexibility in determining the level of risk associated with that exposure based on technical information from the API.
Bluetooth calibration values for hundreds of devices have also been updated to improve the detection of nearby devices, they say.
The API now supports interoperability between countries, following feedback from governments that have launched Exposure Notification apps.
They’ve also added developer debug tools and other reliability improvements.
Finally, they have improved control for users. The Exposure Notifications settings on Android now include a simple on/off toggle at the top of the page and users will also see a periodic reminder if ENS is turned on.
“We’ve continued to improve the technology and provide more transparency based on feedback we’ve received from public health authorities and other experts,” said Google’s VP of Engineering, Dave Burke.
“Public health authorities will continue to make their own decisions about how exposure notifications become part of their plans in controlling COVID-19, and we will work to improve the technology in response to their feedback.”
Apparently, public health authorities have used ENS to launch in 16 countries and regions internationally, with more apps currently under development. It was launched back in May.
The UK declined to use the system with NHSX intending to develop its own rival system enabling centralised control by UK health authorities. It proved unsuccessful.
Following feedback that public health authorities and developers want more technical guidance about how ENS works, the companies have also published the following resources:
- Reference verification server to help guide public health authorities in building a server that allows verification of test results when users report themselves as positive for COVID-19.
- Implementation code showing how the Exposure Notification API works underneath the hood.
- Telemetry design explaining what de-identified diagnostics data is collected to ensure that ENS is functioning properly and securely.
Google emphasises the following points about their non-centralised system: the user decides whether to use Exposure Notifications (it’s off by default), it doesn’t use location data from your device, user identity is n’t shared with anyone (inlcuding Google and Apple) and only public health authorities, not private developers, can use the system.
Android device location
On the question of location data Google has had to explain why – in this case why the Android device location setting has to be turned on if you want to use an Exposure Notification app.
It seems that back in 2015, with the arrival of Bluetooth Beacon technology, and with privacy in mind, the Android OS was designed to prevent Bluetooth scanning unless the device location setting is on…
“At that time no one could have anticipated that Bluetooth scanning might one day be helpful in controlling a global pandemic like COVID-19,” explained Google.
It is working to update the next version of Android with Exposure Notifications in mind, it says. For the forthcoming Android 11, users will be able to use Exposure Notification apps without turning on the device location setting.
This update will apply for Exposure Notifications only, given the design restrains built in – neither the system nor the apps using it can infer device location through Bluetooth scanning, it says.
All other apps and services, however, will still be prohibited from performing Bluetooth scanning unless the device location setting is on.