Common misconceptions about Apple & Google contact tracing

Today, Germany’s government officially dropped the centralized design for its upcoming contact tracing app, advocated for pretty vocally by PEPP-PT. With this, they finally end a passionate debate about the value of privacy in times of a global crisis and PEPP-PT’s failure to communicate transparently and consistently.

These are good news, however, I start hearing some common misconceptions about the role of Apple and Google in this. Some folks try to paint this as a victory of Corporate America over Germany’s best interests.

Make no mistake: The failure for Europe to deliver any successful mobile operating system platform has in deed created a very strong dependency. However, this is not new and civil society organizations have been criticizing it since forever. It has nothing to do specifically with Apple and Google enabling contact tracing on mobile devices.

Here are the top arguments I keep hearing:

  • Apple and Google want to own your data and will run the contact tracing servers. –
    No, they don’t. They leave the server side to authorized governmental institutions, e.g. health organizations.
  • Apple and Google gain access to your entire contact history.
    Wrong. Nobody will. They designed the system in a way, that the proximity history will never actually leave your phone. That’s the entire point of enforcing a decentralized design.
  • Apple and Google should not be trusted.
    Well, all of us already trust the two to a certain degree, since they own the Operating Systems which power our smartphones.

Folks who see this as an alarming victory of Apple and Google have yet to provide a non-political, technical analysis of why – regarding the collection of data – this might be worse than what PEPP-PT was trying to push through.

The core contact tracing feature can now hopefully be built within weeks. We’ve lost enough valuable time for a debate mainly driven by lobbyists with an at least questionable agenda.

Jens Spahn and Helge Braun hopefully learned a lesson about proactive and open communication from the PEPP-PT disaster and will provide an update, soon.

  • Who has been tasked with developing the apps?
  • What’s the current status?
  • When will the code be published as open source for independent reviews and audits?
  • What are the plans for developing, hosting and operating the server systems?

In parallel, I’d love to see experts in Differential Privacy to gather and start thinking about features which would allow users to voluntarily and optionally provide epidemiologists with additional information that would facilitate better research.


Apple, please continue to enforce decentralization in Contact Tracing

The topic of decentralized versus centralized Contact Tracing is currently being debated fiercely.

PEPP-PT partner Inria proposes a centralized approach, where data about infected people is matched to their contacts on a central system. A group of experts working on a fully decentralized approach named DP-3T are warning the public about the obvious bad implications of centralized solutions for privacy.

Given the potential for abuse that centralized implementations open up, at the end of this post, I am going to suggest a small addition to Apple’s preliminary specification, which would completely prevent the currently envisioned centralized solutions on the OS level.

Apple enforces decentralization on the device

Luckily, Apple’s iOS mobile operating system has prevented third party apps from continuously background scanning Bluetooth Low Energy (BLE) advertisements for a long time. Therefore, contact tracing leveraging BLE is not going to happen without Apple’s support. App developers simply cannot build it.

On April 10th, 2020, Apple and Google have announced to work on interoperable contact tracing features which will become parts of their mobile operating systems.

The preliminary Apple specifications released so far are crystal clear: iOS Contact Tracing will be decentralized.

It’s as simple as this: As per the API documentation, at no time any app will ever have access to the contact history IDs.

The only information exposed to apps for “positive” contact events is:

  • The number of contacts.
  • How long the contact was in proximity. Minimum duration is 5 minutes and increments by 5 minutes: 5, 10, 15, etc.
  • The time when the contact occurred. This may have reduced precision, such as within one day of the actual time.

But never any IDs of any contacts “seen”.

Consequently, the centralized implementation suggested by Inria is not going to happen on iOS devices. Thanks god.

What about the server?

Apple specification mandates, that Diagnosis Servers must not store any meta data with the IDs uploaded by confirmed diagnosed users. [Emphasis added by me.]

Right now, the concrete mechanism how apps are supposed to upload diagnosed IDs to these servers is outside the scope of the Apple specification.

I would love to see Apple (and Google) to expand the scope of the specification to handle these uploads on the operating system level!

In case a user is confirmed diagnosed, the following would happen (draft):

  1. For every app using contact tracing features, iOS allows users to manually enter (or override) the Diagnosis Server address through the built-in iOS Settings apps.
  2. In case the diagnosed user decides to provide her data, the app requests the operating system to upload the IDs.
  3. The OS will access the IDs without ever exposing them to the app and upload to the Diagnosis Server according to an Apple defined interface with absolutely zero meta-data attached. It’ll use the Diagnosis Server address set in step 1. An OS level dialog keeps the user informed about the upload and the server address used.

This would effectively decouple the ID uploads from any potential additional meta-data generated and sent home by the app in parallel.

It would also

  • allow multiple and many (trusted) third parties to offer Diagnosis Relay Servers,
  • provide technology savvy users with means to run their own relay servers, provided e.g. by open source initiatives,
  • facilitate largely distributed setups with federated servers using a standardized interface for interoperability.

Apple could also add a certificate infrastructure, which would allow additional control over who could run Diagnosis Servers and Diagnosis Relay Servers.

iOS would reject the upload of IDs to unverified Diagnosis Servers.

Users wanting to run their own relay servers, could use individual certificates made available to them via iCloud. Their personal Diagnosis Relay Servers can only receive uploads from devices associated with their iCloud account.

This would in no way make server development more complex or time consuming, since in the most simple scenario, a government organization could just develop a single service adhering to Apple’s defined upload interface, receive a certificate from Apple and operate it.

I would love to hear from the community at large and also contribute to any open source efforts around Diagnosis Relay Servers. You can find me on Twitter.


PEPP-PT partner Inria publishes approach likely in direct violation with Apple’s specification

Today, the French National Institute for Research in Digital Science and Technology (Inria) published a PDF document titled “Proximity Tracing Applications: The misleading debate about centralised versus decentralised approaches”.

Inria is one of the few academic partners left in PEPP-PT, after growing concerns by former PEPP-PT members about the initiative’s take on transparency, openness and commitment towards open source.

In the three page document, Inria favors a centralized approach.

In short, Inria wants the matching between diagnosed users and their contact graph to happen on the server.

This would very likely be in direct violation of Apple’s take on privacy. The preliminary Cryptographic Specification published by Apple earlier this week is very clear:

“The server must not retain metadata from clients uploading Diagnosis Keys after including them into the aggregated list of Diagnosis Keys per day.”

Apple Contact Tracing Cryptographic Specification, Page 6

Since the approach Inria suggests would require the server to actively send out notifications, a direct consequence would be for the server to hold at least additional meta data to facilitate a notification infrastructure. Which Apple rules out for very good reasons.

The rest of Inria’s document primarily tries to downplay privacy risks by making broad assumptions like these:

“In particular, it does not pave the way to mass surveillance […], unless malicious authorities massively deploy Bluetooth receivers.”

“This back-end system must nevertheless be secured,
and regularly audited and controlled by trusted independent authorities”

Inria Proximity Tracing Applications: The
misleading debate about centralised
versus decentralised approaches

This is as much as saying: As long as nobody tries to exploit our solution, it is secure and therefore not exploitable.

Obviously, the entire debate is about creating a solution which is privacy-preserving knowing that there is potential for attacks. Inria’s underlying assumption that all entities involved in building Contact Tracing solutions can be blindly trusted now and in the future is a bad argument for an approach, which should be ruled out from the beginning.

Luckily, Apple has made this very clear.

What this means for PEPP-PT remains to be seen. Right now, the most promising and open solution seems to be DP-3T.



In emergencies we must be particularly vigilant and resist the swift temptations of simple technical solutions.

The Computer Scientists Forum for Peace and Responsibility