Notes on the Apple + Google Contact Tracing Partnership

On Friday April 10, 2020, Apple and Google announced a partnership to provide new tools on top of which comprehensive at-scale digital contact tracing solutions can be built.

The primary contributions are a bluetooth and a cryptographic specification, plus the promise that these specifications will be implemented on tens of millions of mobile devices by very early May, 2020. I expect the number of supporting devices to reach the billions in the months following. Scale is essential in any successful tracing solution; as a result, any viable solution going forward will probably need to utilize these specifications. I’ll be surprised if any competing proposal achieves the necessary scale.

While their specifications are an important piece of the puzzle, Apple and Google have not built (and do not seem to want to build) a complete solution for digital contact tracing. Instead, they’ve focused on the low-level question of how mobile devices will interact with one another to exchange anonymized data that can — in tandem with both apps and data services presumably built by others — be tied back to an infection and scored based on time and distance of exposure. The details of the underlying protocols are not specific to COVID-19 and should provide a foundation for future epidemics.

The current specifications appear to strike a balance between privacy and anonymity and the need to share diagnostic information with arbitrary third parties. In the assumed common case where the mobile device’s owner remains healthy, no identifiable information of any kind is obtainable by any third party, including the operators of back-end data services and the developers of contact tracing applications. (Contact tracing applications can of course explicitly ask for PII and can share this information with data services, but the Apple + Google protocols themselves stay silent on this point.) On the other hand, in the assumed rare case where a mobile device’s owner gets sick, that owner voluntarily shares cryptographic identifiers associated with the specific days when they might have been contagious. With access to these identifiers, owners of mobile devices that were within Bluetooth range of the symptomatic individual can rank the severity of their exposure without the ability to determine the infected individual’s identity. In addition, it is not possible for data service providers to determine which set of users may be at risk; the information necessary to make this determination lives on, and never leaves, the at-risk mobile devices.

Because the Apple + Google partnership does not provide a contact tracing app or a contact tracing data service — and because these are necessary components of an at-scale solution — there are many open questions about how digital contact tracing will work in practice.

For instance: it is unclear who will be allowed to ship applications that use these new protocols. Will Apple and Google limit access to public entities, select private partners, or will they open the floodgates wide?

It’s also unclear who is likely to operate back-end data services in practice. The Apple + Google design naturally lends itself to the creation of federated rather than centralized data services. We might expect multiple or even competing services to emerge. To achieve scale, these services will need to speak with one another; with what schema and semantics will this conversation take place?

Griefing is also an important consideration in the development of apps and data services. If anybody can press a button that says “I have COVID-19” then anybody will, including the uninfected. Apps and services may need to place hard restrictions on who can share what the protocol calls “diagnostic keys”. As a simple example, an app may allow an individual to share their diagnostic keys with their doctor but only allow authorized medical professionals to share the diagnostic keys with participating data services.

There are many other important factors to consider. On the technical front, well-known cryptographers have begun to ask pointed questions about the chosen cryptographic scheme and its real-world privacy considerations. On the privacy and policy front, there are many deep and complex issues to tackle. Perhaps the best discussion I’ve run across in the context of the United States comes from a recent Lawfare Podcast episode that dives deep on the question of whether contact tracing is a privacy threat.

Pandemic

The COVID-19 pandemic is a once-in-a-century world altering event. It’s a juggernaut that has, and will continue to, exact an immense human and economic toll. I’m still trying to wrap my head around it.

The next few months feel like a maze with high walls. No way to see around; the only way out is through.

After that, there’s another even fuzzier period of time before vaccines become widely available. I assume we’re talking a year or two, which means COVID-19 will be a threat for a long time to come.

Stay healthy. Stay safe, my friends.

Glow

Kimberlite is now called Glow; the new glow.fm website is live!

I’m excited about this project on two fronts.

First, the people: Amira Valliani is Glow’s co-founder and CEO; Brian Elieson is co-founder and CPO. They’re both fantastic. Without Amira and Brian’s tireless efforts over the past half a year, Glow simply wouldn’t exist today.

Second, the principles: Glow is the rare business that embraces podcasting’s distributed nature. As a result, Glow can provide powerful tools to podcasters without standing between them and their listeners. Embracing podcasting as it is, not as a b-school grad might wish it would be, eliminates entire categories of problematic outcomes like walled gardens, privacy-violating advertising, and experiences that require listeners to download an unfamiliar podcasting app.

If you’re a podcaster and you’re interested in direct monetization, say hello.

Modular Pocket Operator

Teenage Engineering builds zany music machines. Their synthesizers create all manner of sonic mayhem and they’re weirdly beautiful objects to boot.

One thing I particularly admire is TE’s anti-emphasis on usability: their devices are intentionally — almost gleefully — obscure. A good deal of brute exploration is often required just to figure out what the buttons do. It feels like music-machines-as-puzzle-box shouldn’t work, but it does: there’s a certain delight as serendipitous discovery gives way to mastery.

The upcoming modular pocket operators look ridiculous:

Teenage Engineering Modular Pocket Operator 400

If you haven’t seen them, the original pocket operators are also wacky fun. They look like a crossbreed between old-school four-function calculators and Nintendo’s handheld Game and Watch devices from the early ’80s:

Teenage Engineering K.O. Pocket Operator

What’s not to love?