On Friday, Apple and Google revised their ambitious automatic contact-tracing proposal, just two weeks after the system was first announced. An Apple representative said the changes were the result of feedback both companies had received about the specifications and how they might be improved. The companies also released a “Frequently Asked Questions” page, which rehashes much of the information already made public.
On a call accompanying the announcement, representatives from each company pledged for the first time to disable the service after the outbreak had been sufficiently contained. Such a decision would have to be made on a region-by-region basis, and it’s unclear how public health authorities would reach such a determination. However, the engineers stated definitively that the APIs were not intended to be maintained indefinitely.
Some of the changes seem designed to address privacy concerns that came up after the initial release. Under the new encryption specification, daily tracing keys will now be randomly generated rather than mathematically derived from a user’s private key. Crucially, the daily tracing key is shared with the central database if a user decides to report their positive diagnosis. Some encryption experts worried that under the old encryption protocol certain attacks might be able to link those keys with a particular user. Connecting a person to a diagnosis should be more difficult with the randomly generated keys. As part of the change, the daily key is now referred to as the “temporary tracing key,” and the long-term tracing key included in the original specification is no longer present.
The new encryption specification also establishes specific protections around the metadata associated with the system’s Bluetooth transmissions. Along with the random codes, devices will also broadcast their base power level (used in calculating proximity) and which version of the tool they are running. This information could potentially be used to fingerprint specific users, so the engineers laid out a new system for encrypting them such that they cannot be decoded in transit.
The companies are also changing the language they use to describe the project. The protocols were initially announced as a contact-tracing system, it is now referred to as an “exposure notification” system. While the proposed apps and protocols could stand in for some functions of traditional contact tracing, they can’t do the more sophisticated work of interviewing subjects and identifying clusters of infection, which can then inform future public health efforts. The companies say the name change reflects that the new system should be “in service of broader contact tracing efforts by public health authorities.”
None of Friday’s changes address the question of how health authorities will verify positive diagnoses to prevent trolls or other false positives, and it seems likely that question will be addressed by specific app developers. Given the wide variations in health systems internationally, engineers said they felt it was best for local authorities to develop their own verification system to align with their system for distribution tests.
One of the biggest lingering questions around the project is whether it will be adopted by public health agencies, and the companies gave no further details on specific partnerships. However, they said they had discussed the project with dozens of stakeholders, including public health agencies.
The first phase of the program will be distributed through a whitelisted API, and the new documents give some more detail about the specific limits on who will be allowed access. “Apps will receive approval based on a specific set of criteria designed to ensure they are only administered in conjunction with public health authorities, meet our privacy requirements, and protect user data,” the new documents state. It’s unclear whether those criteria would allow for Android-based apps distributed outside of the Google Play store, but Google has historically raised data privacy concerns around such apps.