Updates:
- 2020-04-26: Nachdem die Bundesregierung zuletzt einen zentralen Ansatz bevorzugte, wird nun ein dezentraler Ansatz verfolgt. Das ist sehr zu begrüßen.
- 2020-04-22: Die Debatte wird unübersichtlich und hitzig. Weiterhin stehen dezentrale Ansätze wie DP-3T, Apple/Google und der von mir unten beschriebene Ansatz den “zentralen” Ansätzen gegenüber.
Der Hauptunterschied ist, wo die Entscheidung über Alarmierung getroffen wird. In dezentralen Ansätzen erfolgen Analyse und Entscheidung für Alarmierung auf den Geräten der Nutzerinnen. In zentralen Ansätzen geschieht dies auf dem bzw. einem Server.
Ich habe habe den Stand der Debatte und die jeweiligen Argumente in einem Interview mit der Wirtschaftswoche zusammengefasst.
Meine These: Apple und Google geben jetzt den Ton an, die meisten Diskussionen haben sich erübrigt. Ähnlich habe ich den Stand auch in Logbuch:Netzpolitik Folge 341 zusammengefasst. - 2020-04-10: Wie zu erwarten war, haben Apple und Google einen gemeinsamen Standard für Contact Tracing entwickelt und veröffentlicht:
- 2020-04-05: Tim Pritlove und ich diskutieren gesellschaftliche und technische Anforderungen in LNP339 Die Fantasie kennt keine Grenzen beim Setzen von Grenzen
- 2020-04-02: Interview zum Thema bei Markus Lanz (youtube)
- 2020-03-31: Tim Pritlove und erklären das allgemeine Konzept in LNP338 Corona Tracking App
- 2020-03-31: Interview bei phoenix (youtube)
- 2020-03-31: Beitrag WDR aktuelle Stunde hinzugefügt
- 2020-03-29: FAQ am Ende des Artikels hinzugefügt
Über eine technisch gestützte Rückverfolgung von Corona-Infektionen werden zur Zeit verschiedene Debatten heiß geführt. Es begann mit der Weitergabe von Bewegungsdaten durch Mobilfunkanbieter an das Robert-Koch-Institut und natürlich ließen auch Gesetzesänderungen zum vollumfänglichen Location-Tracking nicht lang auf sich warten.
Im Folgenden erkläre ich, warum Location-Tracking völlig ungeeignet ist, und welche Methoden stattdessen zielführend sein könnten. Wichtig ist immer, Sinn und Ziel einer solchen App nicht aus den Augen zu verlieren:
Wenn bei einer Person zum Zeitpunkt t eine Infektion festgestellt wird, soll sie in der Lage sein, ihre Kontakte der letzen t–14 Tage darüber zu informieren. Nicht mehr, aber auch nicht weniger. Primäres Ziel sollte also sein, die Kontakte reliabel zu erfassen.
Datentypen
In der Debatte werden die Begriffe „Standortdaten“, „Bewegungsdaten“ und „Kontaktdaten“ wild gemischt. Zunächst müssen wir also klären, wovon überhaupt die Rede ist.
1. Standortdaten: Person x war zum Zeitpunkt t an Ort A
Problem 1: Die räumliche Auflösung via GPS ist ziemlich ungenau.
Ob sich zwei Personen nah genug gekommen sind, um einander zu infizieren, oder ob sie mehrere Meter voneinander entfernt waren, lässt sich anhand der Genauigkeit von GPS einfach nicht entscheiden – eine Unmenge an false positives wäre die Folge.
Problem 2: Da wir uns bewegen, entsteht natürlich eine sehr lange Liste für jede Person. Die Länge der Liste richtet sich dabei nach der Frequenz der Erfassung. Noch dazu sind die Daten personengebunden. Da wir uns zurzeit weitestgehend isolieren, wäre der größte Teil der erfassten Daten zudem noch absolut irrelevant!
Fazit: Standortdaten sind aufgrund ihrer Ungenauigkeit schlichtweg ungeeignet. Schon das allein disqualifiziert sie, so dass wir die immensen Datenschutz- und Grundrechtsverletzungen gar nicht erst zu diskutieren brauchen.
2. Bewegungsdaten: In Zeitraum Δt haben sich n Personen von Bereich A in Bereich B bewegt.
Bewegungsdaten sind also im Gegensatz zu Standortdaten räumlich und zeitlich geringer aufgelöst. Sie sollten darüber hinaus über mehrere Personen aggregiert sein, so das die Identifikation der Bewegungen einzelner nicht möglich sein sollte.
Anwendungszweck: Diese Art Daten eignen sich gut zur Messung der Effektivität von Maßnahmen zur Senkung der Mobilität.Das ist im weitesten Sinne das, was von den Mobilfunknetzen an das RKI gegeben wird – ein Anspruch also, für den es eine seit Jahren existierende Lösung gibt. Diese Lösung wurde kommerziell übrigens allen angeboten, die bereit sind, dafür zu bezahlen. Das RKI ist in der Reihe der Abnehmer vermutlich noch der am wenigsten problematische.
Problem 1: Je nach zeitlicher und räumlicher Auflösung sind diese Daten ggf. von einer böswilligen Anwenderin durchaus de-anonymisierbar.
Problem 2: Für das Identifizieren von Kontakten sind die Daten nicht geeignet.
3. Kontaktdaten: Person a und Person b hatten zum Zeitpunkt t für einen Zeitraum länger als Δt Kontakt.
Dies ist der einzige relevante Messwert, um den es hier wirklich gehen soll. Wo dieser Kontakt stattgefunden hat, oder an welchem Ort a und b davor und danach waren, ist absolut uninteressant. Wieso sollte das also überhaupt erfasst werden?
Halten wir fest: alles, was erfasst werden muss, sind Kontaktdaten.
Datenspeicherung
Viele vorgeschlagene Konzepte sehen eine zentrale Speicherung von Standort- oder Bewegungsdaten vor. Hierbei würde eine Unmenge an irrelevanten Daten (kein Kontakt) gespeichert. Darüber hinaus ist eine zentrale Datenhaltung aus offensichtlichen Gründen abzulehnen: IANAL; aber nicht nur unterliegen wir hier dem Bereich der DSGVO, sondern auch den besonderen Anforderungen für sensible Gesundheitsdaten.
Die offensichtliche Anforderung ist also, sämtliche Daten dezentral und anonym vorzuhalten – und zwar auf eine Weise anonymisiert, die auch keine Deanonymisierung zulässt.
Es ergeben sich folgende Anforderungen:
- Dezentralität: Jede Person sammelt nur Daten für sich selbst. Diese werden nicht automatisiert weitergegeben.
- Anonymität:
- Die Daten, die jede Person sammelt, sind nicht geeignet zur Deanonymisierung anderer.
- Die Daten, die jede Person sammelt, sind nicht geeignet zur Deanonymisierung der Person selbst.
- Datensparsamkeit: Nur im Infektionsfall kann eine Person ihre Daten weitergeben. Auch in diesem Fall geben die Daten aber weder die Identität der infizierten Person, noch die Identität ihrer Kontaktpersonen preis.
Als Mitglied der Jury des Hackathons „Wir vs Virus“ hatte ich die Freude, eine Reihe von Einreichungen zu begutachten, die eine kluge Lösung gefunden haben, diese Anforderungen zu vereinen. Zur Veranschaulichung stark vereinfacht möchte ich sie hier einmal grob darstellen:
- Mein Handy sendet in regelmäßigen Abständen mittels Bluetooth Low Energy Beacon einen zufälligen Code aus. Dieser Code ändert sich regelmäßig, bspw. alle 30 Minuten.
- Empfängt mein Handy den Code eines anderen Handys, wird anhand der Signalstärke der Abstand geschätzt. Ist der Abstand gering genug, speichert mein Handy diesen Code. Da sich der Code der anderen Person bald wieder ändern wird, hat mein Handy keine personengebundenen Daten erfasst und ist auch nicht in der Lage, die andere Person längere Zeit zu tracken.
- Werde ich als infiziert diagnostiziert, veröffentliche ich an zentraler Stelle alle Codes, die ich je gesendet habe auf einem zentralen Server. Hier werden auch die Codes von allen anderen Menschen veröffentlicht, die diagnostiziert wurden.
- Alle anderen Nutzer laden regelmäßig die veröffentlichten als „infiziert“ markierten Codes herunter. Diese Codes sind ohne jede Aussage über Ort, Zeit oder Personen. Sie haben nur Informationswert für jene Personen, mit denen ich Kontakt hatte.
- Der Abgleich der veröffentlichten mit den lokal auf meinem Handy gespeicherten Codes ermöglicht das Berechnen meiner Exposition. Dabei ist es unerheblich, ob ich 10 Stunden mit einer infizierten Person verbracht habe, oder jeweils 20 halbe Stunden mit unterschiedlichen infizierten Personen. Selbst das kann aus den Daten nicht rekonstruiert werden.
- Auf dem zentralen Server befinden sich keinerlei Daten darüber, welche Personen infiziert sind, wo sie sich wann aufgehalten haben, oder welche Personen sie wo getroffen haben.
Trotzdem haben wir auf diese weise den Datensatz bester Qualität, weil genau nur unsere Kontakte aufgezeichnet wurden – jene Daten also, auf die es wirklich ankommt.
Elegante Lösungen
Diesen Anforderungen entsprechen folgende Einreichungen zum Hackathon „Wir vs. Virus“, die alle mittels Bluetooth ausgetauschte, zeitlich beschränkte Codes nutzen. Ich verlinke sie hier ohne Anspruch auf Vollständigkeit, weil ich nicht weiß ob ich alle Einreichungen zu diesem Thema reviewed habe:
- Update: Inzwischen haben sich drei der Projekte zusammengeschlossen:
ito – track infections, not people!, früher:Den weiteren Fortschriff von ito kann man hier begutachten und sich einbringen. - CovidEncounters
Für Menschen ohne Smartphone würde sich mit leichten Abstrichen in eine QR-Code-Lösung anbieten, bei der die Privatsphäre der Personen zumindest gegenüber wohlmeinenden Kontakten sichergestellt werden könnte – natürlich fehlt dem QR-Code aber die Benachrichtigungsfunktion: Tracking Infection Awareness Alert (IAA)
Wir lernen also: Die Daten der höchsten Qualität und Aussagekraft lassen sich vollständig anonym und dezentral erfassen. Ein wunderschönes Beispiel, wie wir ohne zentralisierte Massenüberwachung sogar ein besseres Ergebnis bekommen – und dabei entspannt und frei weiterleben können, ohne der Corona-Krise gleich noch eine selbstverschuldete Grundrechtskrise folgen zu lassen.
Mein Lob, meine Anerkennung und mein Glückwunsch gilt den „Wir vs Virus“-Teams!
Der Teufel steckt im Detail
Natürlich muss aber auch angemerkt werden, dass nur minimale Änderungen ausreichen würden, die Anonymität oder Dezentralität zu zerstören. Beispielsweise, den Code nicht regelmäßig zu ändern, oder alle Codes immer zentral zu erfassen. Selbstverständlich kann so eine App ausschließlich auf freiwilliger Basis verbreitet werden. Wenn die hier skizzierten Anforderungen kompromisslos erfüllt sind, hätte ich aber keinerlei Bedenken, die App zu nutzen – und ich denke dass es vielen Menschen ähnlich ginge.
Medienberichte
In den Tagesthemen konnte ich gestern diese Gedanken zum Teil ausführen:
Update: Heute wurde in einem Beitrag der aktuellen Stunde das Konzept der Speicherung und Weitergabe ausführlicher und mit guten Grafiken von netzpolitik.org dargestellt:
(Danke für den Hinweis!)
Update: Bei Markus Lanz durfte ich erklären, dass wir auf zentrale Massenüberwachung verzichten müssen, weil es auch anders geht:
FAQ
Muss sich mein Handy dafür nicht die ganze Zeit mit anderen per Bluetooth verbinden?
Die Technik, die hier zur Anwendung kommen soll, nennt sich Bluetooth Low Energy Beacon. Der Beacon ist eine Broadcast-Nachricht, die ohne vorheriges Pairing oder ähnliches gesendet und empfangen werden kann. Es ist dafür nicht nötig, dass mein Handy durch Pairing oder ähnliches besondere Angriffsflächen öffnet:
…the broadcasting device (beacon) is only a 1-way transmitter to the receiving smartphone or receiving device, and necessitates a specific app installed on the device to interact with the beacons.
Wikipedia: Bluetooth low energy beacon
Unsere Geräte würden im vorgeschlagenen Fall nur regelmäßig einen (wechselnden) Code senden und sich nicht weiter darum scheren, ob und wer ihn empfängt. Außerdem würden sie beim Empfangen eines Beacons nur die Signalstärke bestimmen und den Code ggf. in einer Datenbank speichern. Beide Interaktionen sind so schmal und unterkomplex, dass sich keine nennenswerte* Angriffsfläche bieten (sollte). Bei komplexerer Interaktion zwischen den Geräten sähe das anders aus – diese ist aber hier nicht nötig.
Zu Unterscheiden ist der Anwendungsfall von dem vielen vielleicht bekannten “Bluetooth Gerät sichtbar machen”, das beim Pairing von klassischen Bluetooth-Verbindungen zur Anwendung kommt. Davon ist hier nicht die Rede.