1/ Who's ready for another Apple/Google contact tracing thread? I know I am!
To me, the most interesting piece of the puzzle is how much trust we place in the phone operating system vs. the app, and the role of the phone's operating system in protecting your privacy *from apps*.
To me, the most interesting piece of the puzzle is how much trust we place in the phone operating system vs. the app, and the role of the phone's operating system in protecting your privacy *from apps*.
2/ Let's start with the most recent news: Germany has relented and is adopting the Apple/Google approach, the so-called "decentralized" approach, vs. the one Germany wanted (along with France).
reuters.com/article/us-hea…
reuters.com/article/us-hea…
3/ Both approaches have in common:
- phones broadcast identifiers over Bluetooth, rotated every 15 min, not linkable to one another.
- phones read broadcasts from others, recording which identifiers they've come in contact with.
- there's a server, run by a health department.
- phones broadcast identifiers over Bluetooth, rotated every 15 min, not linkable to one another.
- phones read broadcasts from others, recording which identifiers they've come in contact with.
- there's a server, run by a health department.
4/ Key differences:
- Apple+Google: server learns only identifiers of infected. Germany+France: server learns all identifiers & identifier pairs where exposure.
- Germany+France: exposed people learn only that they've been exposed. Apple+Google: exposed learn when & where.
- Apple+Google: server learns only identifiers of infected. Germany+France: server learns all identifiers & identifier pairs where exposure.
- Germany+France: exposed people learn only that they've been exposed. Apple+Google: exposed learn when & where.
5/ tradeoff: with Apple+Google, no large server holding lots of sensitive data, but privacy risk that infected individuals might be identified.
I much prefer Apple+Google, especially because they mitigate the infected-individual privacy risk at API level.
I much prefer Apple+Google, especially because they mitigate the infected-individual privacy risk at API level.
6/ Until recently, Germany+France had one more advantage: the exact model for "suspected exposure", duration and distance of exposure, was adjustable over time.
In an API update 2 days ago, Google+Apple added that capability to their API without changing privacy model.
In an API update 2 days ago, Google+Apple added that capability to their API without changing privacy model.
7/ That may be what moved Germany to adopt the Google+Apple model: they won one important feature without any privacy loss, and I bet it's a feature that matters to public health officials for the sake of prioritizing which contacts to talk to.
8/ Now, why was this even a fight? Why couldn't Germany and France just build the app they wanted?
This is where it's worth understanding that Apple especially, but also Google, have done a LOT to protect your privacy from apps that want to do questionable things.
This is where it's worth understanding that Apple especially, but also Google, have done a LOT to protect your privacy from apps that want to do questionable things.
9/ If an app monitors identifiers broadcast over Bluetooth, that's a very questionable thing. It could use that to track you as you walk around. That's why iOS & Android protect you from this problem by letting apps do this monitoring only when in the foreground, actively in use.
10/ Of course the operating system, iOS & Android, can monitor all they want. With the exposure notification API, the're doing the recording of encountered identifiers and releasing a sliver of that information, only with user approval. The OS is protecting you from the app.
11/ The contours of that protection, the *exact* APIs that exist, have to be designed with incredible care. Over the years, Apple and Google have changed app APIs quite a few times to protect against unexpected abuses that almost always targeted user privacy.
12/ For example, I mentioned earlier how Google+Apple protocol technically leaks exactly when (and thus where) an individual was exposed, which could leak the infected individual's identity.
At the API level, however, the exact time of the encounter is hidden. On purpose.
At the API level, however, the exact time of the encounter is hidden. On purpose.
11/ Back to France+Germany. Their original plans involved sending all past observed identifiers to the server upon infection. That requires being always in foreground to collect the identifiers, or getting them from the exposure notification API, which Apple-Google won't support.
12/ This large gap between what the operating system can do and how much it reveals to the application is a critical part of privacy design in modern operating systems.
It genuinely reflects the very different trust users place in Apple/Google vs. an app they just downloaded.
It genuinely reflects the very different trust users place in Apple/Google vs. an app they just downloaded.
13/ In this case, an app -- and not just any app! An app built by a major democratic country's health department in a pandemic -- wanted more access. With good intent! But that was access that Google+Apple considered too risky, and I agree with them.
They pushed back. And won.
They pushed back. And won.
14/ Now, I still would love to hear more about why we think contact tracing apps are going to be useful at all. Assuming they are, Apple+Google's is a great design, and I'm glad Apple & Google are fighting for user privacy.
15/ Worth pointing out their protocol design is inspired by the DP-3T effort (github.com/DP-3T/documents). Lotta smart people involved.
The API/protocol separation, though, is Apple+Google's. And it's a critical piece of the puzzle.
The API/protocol separation, though, is Apple+Google's. And it's a critical piece of the puzzle.
