Google & Apple’s Contact Tracing – The Basics And Your Questions Answered (UPDATED)

You’ve heard of it. People have celebrated it or lambasted it. What is it again? 

We at the Developers Alliance are strong proponents of the software developer community’s ability to affect positive change. During this pandemic especially, many have offered access to their company’s tools or services and contributed to large-scale projects. We’ve heard from many developers looking for more or new projects to contribute to, the sheer amount of which has been difficult to track. 

Due to this, we know that developers are among those who have the most questions about the large scale contact tracing project being created by the companies behind the world’s foremost smartphone platforms; Apple and Google. On their announcement and initial documentation pages, Google and Apple noted:

“Software developers are contributing by crafting technical tools to help combat the virus and save lives. In this spirit of collaboration, Google and Apple are announcing a joint effort to enable the use of Bluetooth technology to help governments and health agencies reduce the spread of the virus, with user privacy and security central to the design.“

While the Developers Alliance does not currently have a policy position on this matter, we are happy to aggregate answers to some of your most asked questions. Let’s dive in.

Please note that the publication date of this piece is May 13th. This is a constantly evolving situation. We are currently in the beta testing period of these technologies. Apple and Google are making adjustments to this system in real-time as they address concerns both technical and social. If you are reading this after this point the information may have become outdated. As with everything you read on the internet, be sure to check other trustworthy sources when confirming if this information is still accurate. 

May 20th Update

As of today, May 20th, Apple and Google have launched their contact tracing tools. A total of 22 countries have indicated they plan to use the technology. Additionally, three US states, South Carolina, Alabama, and North Dakota, have announced that their public health authorities will be using the system in their respective apps. iOS 13.5 releases today with service included while Google has made its update available on Play Services today. As mentioned below, any Android device on Android 6.0 (Marshmallow) and above are compatible.

The #COVID19 Exposure Notification technology we built jointly with @Apple is now available to public health agencies in support of their contact tracing efforts. Our goal is to empower them with another tool to help combat the virus while protecting user privacy.

— Sundar Pichai (@sundarpichai) May 20, 2020

Technology can help health officials rapidly tell someone they may have been exposed to COVID-19. Today the Exposure Notification API we created with @Google is available to help public health agencies make their COVID-19 apps effective while protecting user privacy.

— Tim Cook (@tim_cook) May 20, 2020

• Google’s updated page for the project can be found here.

• Apple’s updated page for the project can be found here.

What Is It?

On April 10th, in a joint announcement, Apple and Google wrote on their respective corporate blogs that they had been partnering on a project to create “contact tracing technology” in the form of a shared toolset of APIs for both iOS and Android in response to the novel coronavirus. This toolset is for use only by health authorities across the world to build apps that provide contact tracing services.

First, What Is Contact Tracing? 

Contact tracing is a process in public health that tracks and documents who an infected individual may have come into contact with in order to determine who else may have been exposed and thus control the outbreak of the virus. Traditionally, this has been done with what amounts to small armies of public health officials, conducting interviews, and manually tracking infected individuals. The number of trackers needed depends on the size of the outbreak. This system can be slow, require a lot of physical infrastructure, and relies on human memory and accuracy. Google and Apple are seeking to automate this system by tracking points of contact between individuals by using the supercomputers they carry in their pocket at all times; their smartphone. If you’re interested in reading a comprehensive breakdown of contact tracing as a practice for controlling outbreaks, VOX has added a detailed article in their “…, Explained” series on the topic.

Why Does This API Matter?

If you’re a developer you can skip this section. For our non-developer readers, an API, or Application Programming Interface, is a foundational aspect of software interoperability, enabling two different pieces of software to interact with one another by using specific pieces of code. This is important in this context, as Apple/Google are offering an API that functions on the operating system level. Meaning, it will allow apps to access functionality that exists on a deeper level than what is typically available to applications without an API. This will dramatically reduce the complexity and workload for creating these sorts of apps. It also allows them to function on a specific level that would not be achievable in a single app, the background. Previously, or without this API, apps would need to stay open, as there was no way of running these sorts of tasks in the background (for security and performance reasons). This results in short battery life and prevents other apps or services access to those software or hardware features it uses, such as Bluetooth, for its particular tracing method. Deeper integration into the phone’s hardware also allows for a higher level of contact accuracy, power optimization, and general signal manipulation. 

The Basics Of The Apple/Google Plan

• Public health authority apps created using this API will work across Android and iOS with complete cross-platform compatibility. 

• Only health authorities will have access to this API.

• User consent is required, which can be revoked at any time in the phone’s settings. 

• It uses Bluetooth Low Energy to initiate a “digital handshake” between two phones when they come within 15 feet (give or take) of each other.

• The identifiers, called keys, are an individual’s half of the digital handshake. 

• The keys are anonymous and are randomly regenerated and replaced at periodic intervals to avoid tracking.

• Currently, health authority apps will store each phone’s keys, as well as any keys they receive. 

• Personal and collected keys are both only kept for 14 days.

• When an individual does test positive, a notification will be sent to all phones who came in contact with the affected individual, letting the receiver know they may have been exposed. 

• People who test positive are not identifiable to other users. Notifications only identify that a potential exposure has happened and when it may have occurred in broad terms. 

• The apps don’t collect personal or location data.

• All processing happens on your phone, making this a decentralized tracing system. A Diagnosis Server is only used to distribute notifications for potential exposure. 

• The Diagnosis Server only retains the infected individuals half of any digital handshake for 14 days.

• The full list of people you’ve come into contact with, infected or not, never leaves your phone.

How Does It Work?

Your current smartphone must receive an update in order for this functionality to become available. See the below “Software and Hardware Requirements” sections for more information on compatibility. In short, nearly all active devices in the US and Europe will be able to run the system. Once updated you will be prompted to consent (or not) to the contact tracing capability. Currently, you will then need to install an app from your local health authority to enable the contact tracing and allow it access to the now installed and active beacon system. The health authority’s app will then initiate the beacon, record incoming beacons, alert the diagnosis servers, and coordinate further treatment (see below). 

The Steps

• Your phone has been updated to include the Exposure Notification Service API, and if consent has been given, contact tracing becomes enabled. 

• You download the app from your local health authority, which has been updated to use the Exposure Notification Service. You start the app and enable the broadcasting and receiving “digital handshakes” with other phones who have also been updated and have this functionality enabled.

• Two phones will give each other a “digital handshake” when within about 15 feet of each other. They will continue to shake periodically until one phone leaves the 15 feet perimeter. 

• Later you may receive a notification that you are likely to have been exposed based upon your record of digital handshakes.

• You go to the doctor and receive tests to ascertain if you have become infected but COVID-19. 

• In the situation where you test as positive, and if you consent, a health official will provide a code to input into their iOS or Android app. This is
  a verification code that you have tested positive for COVID-19.

• Your public health authority’s app, having been given the code that you have tested positive, now provides you with local resources, such as best practices, symptoms, what to expect, testing center locations, how to get tested, and more. 

• The app notifies Apple and Google diagnosis servers anonymously. Their servers then send a notification to all individuals whom you may have come into contact with based on your “digital handshakes.” This history is not traceable without multiple components, which are not accessible until a diagnosis is made. Even then, only matching numbers are supplied, not entire histories, individual identities, locations, etc. 

• Anyone you’ve interacted with that meets the distance and length criteria then, receives a notification and the process starts over again. 

Apple/Google Clarifications 

On April 23rd, Apple/Google changed the specification and service names from “Contact Tracing and Contact Detection Service” to  “Exposure Notification and Exposure Notification Service.” A moniker that more accurately described the system as a part of health authorities’ broader contact tracing efforts. Contact tracing itself is a system employed by public health authorities to monitor the spread of an outbreak that we will cover further in a moment. 

They then noted they would release the APIs themselves by May, releasing the first beta on April 29th. On Friday, May 1st, Apple and Google released reference code libraries in the forms of an iOS Xcode toolkit and an Android SDK. The APIs allow public health authorities to build COVID-19 contact tracing apps for both platforms with deeper integration into the phone’s hardware capabilities. The companies have promised a future update that will not require the installation of a public health authority’s app for Bluetooth contact tracing or the exposure notifications. 

Apple and Google have stated that this will become an OS-level feature, likely deploying later in the summer. You will then not need a public health authority’s application in order to begin tracking your points of contact, you will need it later however if you become infected. 

Let’s Get Technical

Now, for the developers whom we represent, here are the technical basics that you were looking for after that basic explanation. Before we get into the more technical details, let’s discuss the requirements for phones in order to run this update.

Software Requirements

Android. In terms of software, phones running Android 6.0 Marshmallow (2015) and higher are compatible with a limited OS update distributed through an app in the Google Play Store. 

iOS. Apple has not explicitly announced what devices will support this update. As of late January however, 77% of all iOS devices were on iOS 13, it’s the latest iteration. An additional 17% were on the previous iOS 12, making comparability for nearly all iOS users likely. iOS users will receive a system update through Apple’s unified updater located in the Settings app. 

Hardware Requirements

This protocol runs entirely on Bluetooth Low Energy, commonly referred to as BLE or Bluetooth LE. The first smartphone to debut with Bluetooth LE was the iPhone 4S in 2011. Android support followed shortly thereafter. It’s safe to say that the vast majority of smartphones in common use in North America and Europe are compatible. 

What Is This API?

This API allows applications to initiate a new kind of background task, the broadcast of a Bluetooth beacon, and scan for other Bluetooth beacons. We’ll go into more detail about these beacons below, but in short, the beacons contain an identifying key and Bluetooth metadata. The keys received from other beacons are stored within the health authority’s app. Keep in mind, only health authorities will have access to this API. Upon the update, where the API is introduced to each respective operating system, the user will be prompted to consent (or not) to the contact tracing capability. Only afterward, can a health authority app initiate the scanning/broadcast. 

Capability and consent alone do not initiate the scanning (currently), a health authority app must be present. Think of it this way; your phone may have the capability to play audio like music or podcasts in the background, but if you have no apps that play audio installed, there won’t be anything to play. This functions similarly, with the added step that you must consent to your phone’s ability to play music at all.   

For those non-developers who are still with us, a key is a unique number string of numerical values that are either 1 or 0. One value in this number string is called a bit. A byte is 16 bits. For more details on the structure of information, from bit to a petabyte, see this article.

What Is A Key?

We’ve thrown the word “key” out quite a bit. Let’s define it in this context. In the most basic sense, your “key” is your half of the digital handshake. The Rolling Proximity Identifier (see below) is the key that your phone will broadcast and what will be received and stored by nearby phones as you encounter them. It is 16 bytes long or 128 bits. It isn’t the only key involved in this system, however. All keys are stored within the health authority’s application and are not accessible by any other application. No key on the device is kept longer than 14 days. Google and Apple’s system uses multiple keys and identifiers working in tandem however in order to provide checks and balances that protect your privacy. 

The Different Keys And Identifiers 

Tracing Key

This is your device’s unique key. This key is created when you enable contact tracing. It is stored on the device and never leaves. 

Temporary Exposure Key or Daily Tracing Key 

The Daily Tracing Key is a key that is randomly regenerated every 24 hours. This key is derived from the device’s Tracing Key but is wholly distinct. There is no way to link two different daily tracing keys together, identifying them as the same person. This key also adds additional information on that specific day. Your daily keys will never leave your device unless you are diagnosed with COVID-19.

Rolling Proximity Identifier 

Often abbreviated as RPI, the Rolling Proximity Identifier is the key that is sent in the Bluetooth Low Energy advertisements. This number is derived from the Daily Tracing Key for that day by a mathematical equation. This key is regenerated every 15 minutes. From Apple and Google’s documentation:

“A user’s Rolling Proximity Identifier changes on average every 15 minutes, and needs the Temporary Exposure Key to be correlated to a contact. This behavior reduces the risk of privacy loss from broadcasting the identifiers.”

If the device and platform support it, the RPI may regenerate at random 10-20 minute intervals on phones that support the Bluetooth Random Private Address. 

Diagnosis Keys 

The Diagnosis Keys are the keys containing the days where the user could have been affected after that have been positively diagnosed as infected. They are uploaded to the Diagnosis Server by an individual when they have tested positive. 

Bluetooth Address 

The Bluetooth address isn’t a key created by this system. It is your phone’s unique Bluetooth address, much like your IP address on a network. This will also be changed every 15 minutes in conjunction with the Rolling Proximity Identifier. This is so one of the two components cannot be used to identify the other in the next round of changes, thereby removing the broadcaster’s anonymity and allowing for ongoing tracking post-key rollover. 

Associated Encrypted Metadata or Bluetooth Metadata 

Often abbreviated as AEM. In addition to your phone’s Rolling Proximity identifier, Bluetooth metadata is also sent. This includes the Transmit Power Level, a measurement of the power provided by the broadcasting device. This determines the intended signal strength of the broadcast. The metadata also includes the major and minor software versions. It should be noted that several bytes in the metadata have been reserved as placeholders for future use, should information need to be added to the system. The metadata’s encryption is also based on the Daily Tracing Key and is decrypted upon an exposure match, which has occurred after the receiving of a matching Diagnosis Key from the Diagnosis Server. As such, this encryption is also randomly regenerated every 15 minutes.

Received Signal Strength Indication 

Often abbreviated as RSSI. This is part of the Bluetooth standard that is a measurement of the strength of a Bluetooth signal as recorded by the receiving phone at the time of reception. It is compared to the Transmit Power Level, in order to determine the distance of the broadcasting device from the receiving device.

A Digital Handshake, The Key Exchange

The signal containing the phone’s current key Is called an “advertisement” by technical documentation, as it is “advertising” your key, (i.e. the key is being broadcast in a way that it is receivable by anyone). The advertisement (again containing the key) being broadcast by the Exposure Notification Service, is read-only, and non-connectable. This means that a phone can only receive the keys being broadcast and cannot connect to the other phone in any way. Think of it as a radio signal; your car’s FM/AM tuner can receive your favorite local station that plays your “favorite-love-ballads-of-the-80s,” but you can’t talk to the DJ or affect the song playing through the radio signal in any way. This works similarly, except in a much more local radius, with the radio station’s specific call-sign and tuning address (calling it frequency would mix metaphors a bit) changing every 15 minutes.

Exposure

Every phone constantly checks the keys it has downloaded from the Diagnosis Server against those it has collected to see if there are any matches. If there are, a notification is sent informing the recipient of possible exposure. It then advises them on their next actions or prompts the individual to seek testing.

Contact is recorded in intervals of five minutes with the maximum indicated contact time capped at thirty minutes. This is designed to reduce the ability to determine who a potential contact of exposure was. This information is provided upon a positive diagnosis in order to ascertain when the exposure occurred so as to estimate how many other individuals the affected person has come into contact with.

Key Upload

Upload of the Diagnosis Keys to the Diagnosis Server is to be handled anonymously by both the health authority app and the Diagnosis Server itself.  The server only holds keys, temporarily, 14 days. They are deleted at the end of that period.

Some concerns have been raised about the use of a phone’s IP address in order to reverse engineer the uploader’s identity. However, these have been largely dismissed as mobile phone IP addresses are notoriously ephemeral, as noted by a 2009 Microsoft study, about trying to use IP addresses to geolocate a smartphone. While a lot has changed in the eleven years since this study, many consider this an unlikely vector of deanonymization. 

Developer Documentation

If you’re a developer, you can find Apple and Google’s documentation on the APIs here. 

• The sample code for the iOS Exposure Notification framework can be found on Apple’s site here.

• The Android sample code for the Exposure Notification framework can be found on Github here.

Common Questions

Who Decides? 

One critical detail, however, is who decides what constitutes exposure to COVID-19? In the FAQ included in the released documentation Apple/Google note: 

“The public health authority will define the way in which the app determines if someone has been exposed.”

As the API tool set is exclusively available to public health authorities around the world, each authority will set its own guidelines for exposure events. 

Google/Apple will not set these guidelines. They have stated that they will only manage the Diagnosis Server and deliver the notifications through each OS’s push notification system. Due to this, each individual public health authority around the world will decide what constitutes exposure. Factors in deciding what constitutes exposure include the length of the time the two devices were positioned near each other, the distance between the two devices, etc. 

Alerts are then also sent by health officials’ apps. They are only routed by Apple and Google through the iOS and Android’s existing push notification systems, for those specific apps. Eventually, after the promised deeper integration by Apple and Google is released, anyone with the operating system updated to include the Exposure Notification Service, and who has allowed it, will receive the updates.

Is A Bluetooth Connection Reliable Or Accurate?

After the announcement, social media was flooded with jokes and serious concerns alike commenting on the reliability of Bluetooth as an accurate tracing method. Apple and Google have stated that Bluetooth was chosen as it was the least invasive technology of the feature options available nearly universally in modern smartphones. 

With RSSI and Bluetooth LE, both technologies designed to improve the reliability and accuracy of Bluetooth, we have seen an explosion in smart devices. Household appliances, lights, remote control toys, health sensors, and more all use this technology. This implementation, however, to be frank, is on another level from those uses. There are situations that may result in a false positive of exposure however, as Bluetooth does continue to transmit through walls. If a phone is deep inside a bag, oriented away from the other nearby device, or large amounts of interference are present, it could create a situation where RSSI is inaccurate.  

Is There A Numerical Possibility Of Exposure False Positives?

As you can see, a lot of disposable number keys will be generated in order to maintain privacy and anonymity. As some have pointed out, this may lead to some numbers being duplicated. This could create a situation where someone receives a notification they’ve been exposed to when in reality, they were not. The system, however, has a very low possibility of this due to the length of the key. Given the large number of iOS and Android users in the world (see below) these occurrences will likely happen but they will also likely be a statistically insignificant amount of cases. In other words, you are very unlikely to receive a false positive. If you do, the worst-case scenario is the potentiality of an infection test. 

What Is Centralized vs Decentralized? Which Structure Will Apple And Google Use?

You may have heard the discussion, particularly in Europe on the merit of “Centralized VS Decentralized systems.” This is a complicated philosophical, political, and technical issue, with nuanced opinions on all sides of the debate. As such we won’t go into the technical or political details of this debate here. The technical details of which are as complex in their own rights as what we have already discussed here. We may cover this debate in a future post, but for the purpose of this article. It’s important to note that the Apple/Google system is, broadly speaking, decentralized as most of the system’s functions happen on the device.    

Challenges To Effectiveness

This is a complicated question no one has the answer to. No one is sure of what percentage of the population would be needed to participate in order to achieve an effective impact. Will the public buy into the system? Will they begin upgrading their phones, downloading the appropriate health authority’s app, and giving their consent to broadcast/collect keys? No one knows fully until the first public uses become available, which we may see in the next month. Will governments adopt the system or use their own? Will changes be mandated in order to remove privacy protections? Or will stricter privacy protections be put into place? As mentioned in the last section, there is an intense philosophical debate in both the technical and political worlds on the very nature of such a system as this. As mentioned previously there are debates about the effectiveness of Bluetooth as a technology, but also about its scope. Would location-services (GPS, cellular triangulation) be more effective? 

This, and all digital contact tracing or exposure notification systems, will also still need to be part of a broader initiative that includes contact tracing and testing. If a person cannot get a test to confirm they have been exposed and become infected, then this system becomes pointless. The short answer is that we are too early into these experimental measures to know what impact they will have.

What Does This Mean For Users?

Whether we develop software and applications for these platforms or not, we are all end-users. As of March 2020, StatCounter reports mobile OS market share divided 72.26% Android and 27.03% iOS. That only leaves 0.71% of the world’s 3.5 billion smartphones (as of April 2020) are not running either iOS or Android. 45% of our global population carries either an iOS or Android device with them, likely everywhere they go. To say a unilateral deployment of operating system level software of this kind is an ambitious undertaking is a vast understatement. 

Can Google, Apple, Or Health Officials See My Location?

No. Per the joint technical documentation released by the companies: 

“The Contact Tracing Bluetooth Specification does not use location for proximity detection. It strictly uses Bluetooth beaconing to detect proximity.”

This means that only the time of a point-of-contact, the
digital handshake itself is recorded. No location data (GPS, cellular, etc.) is tied to this that can identify where the digital handshake took place. Only that it did occur and when. As previously mentioned, the digital handshake contains the phone’s Rolling Proximity Identifier at the time of the handshake and Bluetooth Metadata. That metadata currently only contains the software versions and original transmit power level. The strength of the signal at the time of receiving, its RSSI, is then added by the recipient phone for comparison. The documentation released by the two companies stresses that the GPS, magnetometer (hardware compass), electronic compass, and cellular positioning systems are not connected to the Exposure Notification Service in any way.

Furthermore, health authorities or agencies who currently do use targeted advertising or location services in their apps will need to disable those features for the time being or they will not be allowed access to the API. Apple and Google will not allow apps to gather data of this kind at the same time so that they cannot be used in conjunction to determine an individual’s identity. 

Is There A Database Of All Infected Individuals?

The short answer is, kind-of, but in a real-world sense, no. 

Each phone will be collecting the keys indicating exposure from the server, which is managed by Apple and Google. As previously mentioned, the servers only hold keys for a maximum of 14 days. So each phone will have a list of these keys and at any given moment. The server itself will have a less extensive list of these exposure indication keys on it as well. However, these keys are all anonymous, so functionally they are useless for any purpose other than, “...was I in contact with someone who was or became infected?” A key cannot direct you back to the original device or provide any personal or location data. 

Can Advertisers Or Corporations Take Advantage Of My Broadcast Signal?

No. This API and system are only available to public health officials. Those health authorities or agencies are allowed by the API’s terms of service to monetize the information gathered. Additionally, it would be very difficult to monetize that information without further modifications in an attempt to de-anonymize the data. There is no personally identifiable data connected to the signals and they are read-only. Your device will not display or receive messages through its Bluetooth beacon that are readable by the user, only the anonymous digital handshake is allowed. 

Google and Apple have pledged that the Exposure Notification API would not be used for any reverse functionality, such as advertising or marketing, other than the notification of exposure. Furthermore, the ephemeral and anonymized database mentioned above would not be of much use for this purpose. 

Will It Drain Or Kill My Phone’s Battery?

The short answer is that it shouldn’t. The specifications released by Apple and Google relay that the Contact Detection Service, the primary functioning piece of the entire solution, uses the BLE (Bluetooth Low Energy).

Additionally, since the API process runs in the background, the application does not need to be open or running itself to work, also saving battery life. The respective operating systems will handle the “handshakes” and the health authority apps will handle them when appropriate. 

What If I Don’t Want It? 

Google/Apple has stressed in their statements that the system will be opt-in only. After your phone has been updated to the version of Android or iOS that launches this feature, you will be able to disable the feature in each OS’s settings app. The feature will have its own pane and switch that clearly denotes it. Below, Twitter user Guilherme Rambo has posted a screenshot of iOS’s management of the system. Longtime Apple blog Macrumors has detailed instructions on how to turn the feature off in iOS here. 

As for Android, 9to5Google offers an explainer here. Suffice to say, that the management process for each service seems to be as similar and simple, as disabling any other feature, like an application’s access to the microphone, etc.

What’s Next?

Broader and deeper integrated tracing features have been promised by Apple and Google to be coming to the OS level in the coming months. We’ll cover these in detail in a future update. Apple and Google have each indicated that they will publish their work for 3rd party analysis to confirm that privacy requirements and standards are being met, the effectiveness of the approach, etc. We also provide updates to this post once those analyses have been released.