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.


PEPP-PT, DP-3T und die Frage des Vertrauens

Auf meinem privaten Blog habe ich in den vergangenen Wochen einen durchaus kritischen und besorgten Blick auf den Umgang mit sogenannten “Corona Apps” geworfen.

In der Financial Times findet sich heute ein Zitat, das es sehr schön auf den Punkt bringt:

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

The Computer Scientists Forum for Peace and Responsibility

An dieser Stelle ein Disclaimer: Ich schreibe hier persönlich und privat. Das von mir gegründete Unternehmen grandcentrix wurde im November 2019 von Vodafone übernommen. Vodafone unterstützt derzeit offiziell PEPP-PT. Weder ich persönlich, noch grandcentrix sind Mitglied von PEPP-PT. Mein authentischer und kritischer Blick auf diese Themen blieb und bleibt auch weiterhin von unternehmerischer Zugehörigkeit unberührt.

Grundsätzlich befürworte ich die technologie-unterstützte, effiziente Unterbrechung von Infektionsketten. Ich würde selbst an einem solchen System teilnehmen und damit den Empfehlungen vieler Virologen folgen.

Essentiell für die Wirksamkeit aller angedachten Kontakt-Verfolgungs-Ansätze (“Corona Apps”, “Contact Tracing”, “Proximity Tracing”) ist das Mitmachen von über 60% der Bevölkerung.

Dazu muss man vor allem eines: Vertrauen schaffen. Gleichzeitig trägt man die Verantwortung, transparent, ehrlich, proaktiv und offen zu informieren.

Spätestens als Hans-Christian Boos am 08.04.2020 im SPIEGEL verkündete, die von ihm mit initiierte PEPP-PT würde bereits in 10 Tagen eine App veröffentlichen, wurde ich mißtrauisch. (Tatsächlich kam heute die Meldung, so schnell gehe es nun doch nicht.)

In Interviews wird der Zugang zu PEPP-PT für Start-up-Communities und die allgemeine Offenheit der Initiative betont. Parallel werden PEPP-PT / Corona-Apps fast schon wie bei einem controlled narrative durch die Boulevard-Medien getrieben; Frank Thelen mahnte bei Lanz gar absolute Unbedenklichkeit an, weil “die Amis ja sowieso alles tracken würden”.

Auch Ranga Yogeshwar wird jetzt durch die Talkshows getrieben und fällt dort mit Statements auf wie “Mit App können wir schon in wenigen Monaten zur Normalität zurück kehren, ohne dauert es bis weit ins nächste Jahr.” Das ist für einen Nicht-Virologen bestenfalls gewagt.

Erstaunlich: Tatsächlich ist die Kommunikation von PEPP-PT bislang absolut spärlich. Der Twitter Account ist über ein “Hello World” bis heute nicht hinausgekommen. Ein Blog gibt es nicht. Teilnehmer des größten deutschen Hackathons #WirVsVirus berichten von erfolglosen Kontaktversuchen. Quell-offenen Code oder gar Spezifikationen sucht man vergebens.

Das verursacht Bauchschmerzen.

Apps, die unter absolutem Schutz der Privatsphäre Kontaktketten abgleichen sollen, stellen eine schwierige Herausforderung dar. Noch komplizierter wird es auf Ebene der Plattformen, also quasi den Gegenstücken zu diesen Apps. Richtig ist: Es gibt dafür wahrscheinlich technische Lösungen. Diese brauchen aber Zeit um gut verstanden, unabhängig begutachtet und hervorragend umgesetzt zu werden.

Apple und Google helfen

Den schwierigen Teil der Aufgabe auf den Geräten lösen nun Apple und Google und zwar Mitte Mai direkt im Betriebssystem. Das sind gute Nachrichten. Man weiß dort, was man tut und hat – so wie man es erwarten darf – direkt mit der Ankündigung erste technische Spezifikationen veröffentlicht um die öffentliche Debatte zu ermöglichen. Das nennt man Transparenz.

Offen ist nach wie vor aber dennoch:

  • Wer stellt die Server?
  • Wie wird sichergestellt, dass diese verteilt und dezentral betrieben werden können?
  • Wie wird verhindert, dass an diesen Eingangstoren die Pseudonymisierung der Geräte kompromittiert wird?

In der Presse ist häufig zu lesen, das Bundesamt für Sicherheit in der Informationstechnik (BSI) sei bei PEPP-PT mit an Board, dies alleine sei Grund genug für eine gewisse Gelassenheit. Wenn dem so ist, bekennt sich das BSI auf der PEPP-PT Webseite dazu Stand heute zumindest jedoch noch nicht. Auf der öffentlichen Mitgliederliste steht das BSI nicht.

Gleiches gilt für den Chaos Computer Club. Dessen Sprecher, Linus Neumann, hat zwar einen viel beachteten Artikel zu Anforderungen an ein System formuliert, ist aber gleichwohl (auch) kein Mitglied von PEPP-PT.

Am heutigen Abend habe ich mit Vertretern von Apple Health in Cupertino telefoniert, um Apple’s Position insbesondere rund um offene, unabhängige Ökosysteme zu erfahren. Auch dort habe ich für klare Vorgaben bezogen auf die Plattform geworben, bevor Apple die neuen Schnittstellen für die Telefone ihrer Kunden freigibt. Der Idealfall wäre, wenn Apple zentralen Servern einen Riegel vorschiebt und damit quasi als Gatekeeper über das Privacy Versprechen fungiert. Wir haben vereinbart, im Austausch zu bleiben.


Einer der vielversprechendsten Ansätze wird von einer Initiative der Eidgenössische Technische Hochschule Lausanne (EPFL) unter dem Namen DP-3T entwickelt – und zwar schon deutlich bevor PEPP-PT für so viel mediale Aufmerksamkeit gesorgt hat. Deren führender Epidemiologe Marcel Salathé hat heute den Ausstieg aus der PEPP-PT Initiative mit diesen Worten verkündet:

Ich bin nicht mehr Teil von PEPP-PT. Ich weiss nicht mehr, wofür das Projekt eigentlich steht, und habe kein Vertrauen mehr in das, was passiert. Mir fehlt die Transparenz.

Neue Zürcher Zeitung, 17.04.2020

Es wird noch schlimmer. Der Internet-Nachrichtendienst Golem zitiert Kenny Paterson, Kryptograph an der ETH Zürich und Mitwirkender am DP-3T Protokoll.

“Bislang hat uns niemand erklärt, warum die Informationen zu DP-3T von der Webseite entfernt wurden”, sagte Paterson im Gespräch mit Bei einem am Donnerstag geplanten Online-Meeting seien die Vertreter von PEPP-PT aus Deutschland nicht aufgetaucht.

Golem, 16.04.2020

Scheinbar hat PEPP-PT die Referenzen zum dezentralen DP-3T Ansatz am Donnerstag “still und heimlich” von der eigenen Webseite entfernt. Da fragt man sich zurecht: Warum?

Dass man über die Wayback Machine solche Änderungen jederzeit nachvollziehen kann, scheint den bei PEPP-PT für Kommunikation Verantwortlichen nicht bekannt zu sein.

Und wieder deutet sich ein Muster an: Intransparente oder gar keine Kommunikation. Lobbyismus statt Offenheit. Entscheidungen hinter verschlossenen Türen.

Michael Veale, Dozent für Digitale Rechte und Regulierung an der renommierten UCL, mahnte bereits am 05. April 2020 auf Twitter an:

Tweet von Michael Veale, 05.04.2020

Überraschend ist diese Entwicklung also nicht.

Es deutet sich an, dass unter PEPP-PT eine Lösung mit zentralen Server-Systemen entstehen wird, bei denen das Matching zwischen als infiziert gemeldeten Nutzern und deren Kontaktgraph auf dem Server erfolgt. Aus vielerlei Perspektive ein offensichtliches Privacy No Go.

Das Robert Koch Institut hatte schon bei der Datenspende App eine solche Entscheidung getroffen und mit dem Betrieb der Server ein einzelnes, privatwirtschaftlich organisiertes Unternehmen beauftragt. Bis heute ist in Teilen unklar, was mit den gespendeten Daten passiert und wer Zugriff darauf hat.

Am 08. April warb ich unter dem Titel “Was PEPP-PT von der Corona Datenspende App lernen kann” für Transparenz und Offenheit und habe dafür durchaus hier und dort Kritik geerntet.

In Anbetracht der heutigen Ereignisse erscheint eine Wiederholung mehr denn je sinnvoll:

Proaktive Kommunikation

Nichts befeuert Unsicherheit und Verschwörungstheorien so sehr, wie mangelnde Kommunikation. Eine Initiative die sich eine spürbare, länderübergreifende Auswirkung auf die Fahnen schreibt, muss viel und 100% transparent kommunizieren. Zum Stand der Dinge. Zu technischen Herausforderungen. Zu eventuellen Kompromissen.

Konsequent Open Source

PEPP-PT und darauf basierende Apps und Stand-alone-Tracer müssen von Anfang an durchgängig unter den Augen der Öffentlichkeit entwickelt werden.

Nur so kann eine kontinuierliche und unabhängige Einschätzung der Community erfolgen und zwar insbesondere auch von Experten, die sich gleich aus welchem Grund der Initiative selbst vielleicht nicht anschließen wollen.

Es gibt schlicht keinen Grund, dies nicht zu tun.

Die richtigen Entscheidungen für ein verteiltes Backend

Frank Thelen spricht von einem “europäischen Server”, anderenorts sagt man “diese Kontakte werden dann an das RKI gesendet”.

Ein großer Teil der informationstechnologischen Herausforderung besteht aber gerade darin, dass die Apps mit einem verteilten System kommunizieren müssen, welches in sich ebenfalls konsequent den Schutz der Privatsphäre aller am System teilnehmenden Nutzer gewährleisten muss – und zwar auf allen Ebenen. Denn Teile des Systems werden vielleicht in Ländern betrieben, in denen nicht unsere gesetzlichen Rahmenbedingungen gelten.

Dass PEPP-PT die eigene Webseite zwischenzeitlich auch um Aspekte der Dezentralität bereinigt hat, erscheint insbesondere für eine Initiative, die pan-europäisch im Namen trägt doch sehr verwunderlich.


Ein Virus hält sich nicht an Zeitpläne. Auch das höre ich oft und es ist leider wahr.

Taugt diese reale Bedrohung aber als Argument für hastige Software-Releases? Meines Erachtens ist es umgekehrt. Sie verbietet sich mehr denn je.

Und noch eines sei gesagt: Man kann natürlich auch mit kleineren Lösungen starten. Man darf ausprobieren und sich iterativ verbessern. Man darf Fehler machen und dazu lernen.

Es ist, wie so oft, eine Frage von Authentizität und Glaubwürdigkeit.

Wahrscheinlich ist ein länderübergreifendes Proximity-Tracing System, dem im Fall von SARS-CoV-2 über 60% der Bevölkerung vertrauen müssen, damit es überhaupt wirksam sein kann, eine Aufgabenstellung für mehr als ein paar Wochen. Dann sollten wir darüber auch sprechen.

Es geht im Kern um Vertrauen und den offenen, ehrlichen Dialog. Es geht nicht um Technologie-Showcases. Es geht nicht um gute PR. Nicht um privatwirtschaftliche Interessen.

Und erst recht nicht darum, dass sich die Digitalbranche ins rechte Licht setzt.



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

The Computer Scientists Forum for Peace and Responsibility