In an unprecedented move, Apple and Google are joining forces to develop a contact-tracing system based on Bluetooth technology to track the spread of the coronavirus. The companies will initially develop APIs to ensure interoperability between contact-tracing apps developed by public health authorities, and subsequently will embed contact-tracing capability in both iOS and Android. The companies said they’re relying on Bluetooth technology to prevent wireless tracking of the device.

APIs in May: In the first phase of the project, the two companies, in May, Apple and Google will release Application Program Interfaces (APIs) to enable interoperability between Android and iOS devices using contact-tracing apps from public health authorities, like the Aarogya Setu app. This way, official contact-tracing apps on the two different operating systems (Android and iOS) would be able to communicate better, helping in better contact-tracing, in theory.

OS integration in ‘coming months’: Then, “in the coming months”, the two companies will enable a broader Bluetooth-based contact tracing platform by building this functionality into the underlying platforms. However, at the moment we don’t know if this functionality would remain in both the operating systems after the pandemic ends and there is perhaps no need of contact-tracing; although the companies did say that the system will “only be used for contact tracing by public health authorities for COVID-19 pandemic management”.

How the system would work, in theory

After users update their operating systems with the latest updates, their phones would exchange anonymised keys every 5 minutes. The exchange will only happen after a user has consented to opt-in to the contact-tracing tool. The exchangeable anonymised keys, called rolling proximity identifier, would be sent over Bluetooth, and change every 15 minutes to prevent wireless tracking of the device.

When a user tests positive for the virus and updates the same on the contact tracing app, their phone would upload their keys from the previous 14 days to the cloud, but only if they consent to it. If a user remains healthy and never tests positive, these keys never leave the device. After they choose to upload their keys to the server, other people, who might have come in contact with that person, would be notified of coming in contact with them (without revealing the identity of the person).

Notifying other people becomes possible because their phone periodically downloads the anonymous keys of everyone who has tested positive for COVID-19 in their “region”. Apple and Google have not specified  how big or small a “region” would be; we’ve reached out to them for details.

How the system would be built

A “Tracing Key”, unique to every device would be generated when contact tracing is enabled. This key is stored in users’ devices, and “never leaves the device”. From the Tracing Key, a “Daily Tracing Key” is generated every 24 hours. When a user tests positive for the virus the daily tracing key for days where the user could have been affected are derived on the device from the Tracing Key. This subset, now called the “Diagnosis Key” is then uploaded to the server so that other people who might have come in contact with that user can be notified. The cryptography standards and Bluetooth standards can be found here and here.

Privacy measures

The system, on paper, does take a number of steps to ensure that people can not be identified, including broadcasting an anonymised key over Bluetooth. It also claims that it doesn’t collect personally identifiable information or user location data, and the list of people users have been in contact with never leaves their phone. Also, people who test positive are not identified to other users, Google or Apple. Other privacy measures include:

  • A user’s Rolling Proximity Identifiers cannot be correlated without having the Daily Tracing Key. Apple and Google claim that this will reduce the risk of privacy loss from broadcasting them. Not having the Daily Tracing Key will also prevent impersonation attacks.
  • A server operator implementing this protocol does not learn who users have been in proximity with, or their location “unless it also has the unlikely capability to scan advertisements [Bluetooth broadcasts] from users who recently reported Diagnosis Keys”.
  • Putting onus on the server, the companies said that it “must not retain metadata from clients uploading Diagnosis Keys after including them into the aggregated list of Diagnosis Keys per day”.

Potential problems: However, it is worth noting that relying on Bluetooth alone doesn’t necessarily guarantee privacy. Also, for now, the proposed system doesn’t include any measure to mitigate for false positive confirmations by people. The system will also potentially suffer from the same problem that affects contact-tracing apps —  it needs more people to opt-in to the service, and if that doesn’t happen, the entire system becomes less effective. For instance, a recent report by The Indian Express claims that for India’s Aarogya Setu app to be effective, at least 50% of the country’s population needs to register on it.