Contact Tracing: 7 Ways Google and Apple are Protecting User Privacy

Contact tracing capabilities are likely coming to your device sometime in the near future. Google and Apple are taking a stance to protect your privacy while still supporting tracing efforts. In this post, we will break down the measures taken by Google and Apple when architecting their solution to contact tracing.

During an epidemic or a pandemic, contact tracing is part of the routine protocols followed by a health organization. Traditionally, this has been a very manual process, whereby a healthcare-worker interviews a patient with a positive diagnosis to track their whereabouts prior to the diagnosis. The goal is to create a list of people the patient came in contact with and to notify them of the exposure so they too can get tested. Given that we live in a world where everyone carries a smartphone, technology can potentially facilitate this function easily and efficiently.

Contact Tracing vs. Exposure Notifications

During this global pandemic, many countries have created their own solution to digital contact tracing, though many of these technical solutions have privacy concerns. Not to mention that the name “contact tracing” itself has a big brother connotation to it, which elicits the notion of a nanny state. Google and Apple have joined forces to create a privacy-preserving contact tracing solution. They have stated that user privacy and security are central to the design of their contact tracing capabilities. This is reflected in Apple’s and Google’s careful naming of the technology called Exposure Notifications rather than Contract Tracing. Furthermore, their design gives a user fine-grained control over permissions.

At a high level, devices are essentially using Bluetooth to exchange some data. Exposure Notification leverages Bluetooth Low Energy (BLE) to transmit data to nearby devices. The transmission of data via BLE is known as a beacon. The beacon contains a randomized string of numbers that changes every 15 minutes. The device is constantly broadcasting beacons while scanning for beacons from other devices. When a device comes near another device broadcasting the Exposure Notification beacons it stores them locally on the device. At least once a day, the device downloads a list of keys for the beacons that have been identified as belonging to people with a confirmed positive diagnosis. Each device locally matches the beacons it has stored against the ones downloaded from the server to see if there is a match to confirm exposure. Once confirmed, the user is notified of the exposure and advised on the next steps.

Exposure Notifications: User Privacy in the Data Exchange

Let’s dive deeper to find out how the Exposure Notification API preserves the user’s privacy in this beacon data exchange:

1. Bluetooth only: Some contact tracing solutions have resorted to using GPS and Bluetooth. The drawback of using GPS is that it is a major privacy violation because it is constantly monitoring a user’s every move. Exposure Notifications rely solely on Bluetooth and don’t exchange any personally identifiable data, and so it gets points for privacy. The drawback of only using Bluetooth is that you might risk having more false positives, meaning a person was notified that they were exposed when they weren’t, however that is a separate topic of discussion.
2. User Opt-in: The technology provides an end-user complete control over whether they want to participate or not. Opting-in is as easy as turning on a toggle switch within the settings app. You will not be required to install an app to access these settings as it will be part of the OS. Even after a user has opted in, they have the power to delete the exposure logs, which contains a list of beacons stored on the device. If the user does not delete the logs manually, they are automatically erased after 14 days.
3. Broadcasting: The device is continuously broadcasting beacons to share data with other devices. The beacon data consists of three pieces of information in its payload:
   • Exposure Notification Service UUID: this is a service identifier used by the Bluetooth service when scanning for Exposure Notification beacons.
   • Rolling Proximity Identifier (RPI): contains a randomized string of numbers that changes every 15 minutes. This number is derived using the Temporary Exposure Key, which is a key generated every 24 hours. The RPI gets broadcasted to devices in the vicinity as part of the beacon payload but not the Temporary Exposure Key.
   • Associated Encrypted Metadata (AEM): contains protocol versioning and transmit power for distance approximation. The transmission power is the Received Signal Strength Indicator or RSSI, which is part of the Bluetooth protocol. AEM along with the RPI synchronously gets updated every 15 minutes as well to avoid any tracking.
4. Scanning: when scanning for Exposure Notification beacons, the device is searching for beacons with the specific Exposure Notification Service UUID. If found, it receives the beacon payload containing the PRI and AEM, which are stored locally on the device along with a timestamp.
5. Diagnosis submission: When a user receives a positive diagnosis, they have to enter their diagnosis within an app. Prior to submitting the positive diagnosis, the user is asked for permission, once authorized, the app submits their diagnosis keys to a server. The diagnosis keys are a subset of Temporary Exposure Keys which are sent to a centralized server hosted by the creators of the app. Future releases of Exposure Notifications will not require a central server as it will be hosted by Apple/Google.
6. Exposure: the final piece of the puzzle is determining whether the user was exposed to a person with a positive diagnosis. At least once every 24 hours, the device downloads all the Diagnosis Keys from the server. These are the keys that were submitted when a user received a positive diagnosis. The Diagnosis Keys are a subset of the Temporary Exposure Keys, which are used to generate RPIs. The RPIs generated are using the keys from the server and are matched against the RPIs stored locally on the device. When a match is found, a Risk score is calculated based on factors such as days since the exposure incident, cumulative duration of the exposure days, Bluetooth signal strength, and a transmission value which is a level of diagnosis verification or other determination from the app/health authority. The calculation of the Risk score and matching of keys are all conducted on the device. Upon finding a match, the end-user is notified that they were exposed to the virus. This information is never sent to the server. Finally, if the exposed user is diagnosed positive they will have to manually self-identify.

Conclusion

Upon examining all the pieces from opting-in, broadcasting beacons, scanning beacons, diagnosis submission, and finding a match, we find that Apple and Google have built privacy protections for individuals at many key steps in the data flow. The implementation, however, is not without some risk. Specifically, in the first phase of the rollout of Exposure Notifications, Apple and Google require developers of the app to host a centralized server of their own to store the diagnosis keys. In the second phase, the server requirement is eliminated because Apple and Google take on that burden themselves.

Contact tracing apps are already being built without a standard of privacy set; regardless of the efficacy of contact tracing as a solution, there’s a moral responsibility to build these apps with privacy in mind. It appears Apple and Google are taking this responsibility seriously as they pioneer their Exposure Notification APIs.

Curious about building an app with Exposure Notifications? Get in touch and let’s see how we can partner together to keep people’s health and privacy safe and sound by leveraging Exposure Notifications