Corona-Tracing-Apps: zentral, dezentral, egal?

Speicherdauer der Kontakte
Als weiteres Relevanzkriterium wird noch der Zeitraum berücksichtigt, den der jeweilige Kontakt schon zurückliegt. Denn man geht davon aus, dass ein Infizierter nur eine begrenzte Zeit vor Ausbruch von COVID-19 selbst für andere infektiös ist. Zwar nimmt das RKI eine Inkubationszeit (zwischen Infektion und Ausbruch der Erkrankung) von bis zu zwei Wochen an [11]. Das RKI geht allerdings auch davon aus, dass ein Infizierter erst zwei bis drei Tage vor Auftreten der ersten Symptome selbst infektiös ist. Vor diesem Hintergrund erscheinen die im Bund-Länder-Beschluss vorgesehenen drei Wochen für die Speicherung der Kontakte bzw. IDs zunächst recht lang.

Letztlich maßgeblich ist jedoch der Zeitraum vom Beginn der Infektiosität bis zu dem Zeitpunkt, an dem nach einem positiven Testergebnis mit einer Warnung der Kontakte über die App zu rechnen ist. Üblicherweise wird man davon ausgehen können, dass ein Infizierter noch am Tag, an dem ihm das positive Testergebnis mitgeteilt wird, seine Kontakte warnt. Allerdings dauert es häufig ein paar Tage, bis nach ersten, oft wenig spezifischen Symptomen eine Probenentnahme zur Testung auf SARS-CoV-2 erfolgt. Die reine Bearbeitungsdauer eines entsprechenden PCR-Tests im Labor beträgt laut RKI etwa 4-5 Stunden; jedoch könne die Zeit zwischen Probenentnahme und Ergebnismitteilung ein bis zwei Tage betragen, bei hohem Probenaufkommen auch deutlich mehr [12]. So waren es z. B. in der Zeit hoher Neuinfektionsraten Mitte März in Bayern fünf bis sieben Tage [13]. Bei einem Wiederanstieg der Neuinfektionen nach Lockerung der Kontaktrestriktonen könnte die Mitteilung der Testergebnisse u. U. trotz des ebenfalls von Bund und Ländern [1] geforderten Ausbaus der entsprechenden Kapazitäten teilweise wieder so lange dauern. Nimmt man also sieben Tage zwischen Ergebnismitteilung und Probenentnahme sowie drei Tage zwischen Beginn der Infektiosität und dem Auftreten von Symptomen, bliebe nach diesem Vorschlag eine Warnung der Kontakte möglich, wenn der Infizierte sich innerhalb von elf Tagen nach dem Auftreten der ersten Symptome eine Probe zur Testung entnehmen lässt. Auch der zuletzt genannte Zeitraum erscheint eher großzügig.

Die vorgesehene Gesamtspeicherdauer von 21 Tagen dürfte vor diesem Hintergrund immer noch hoch gegriffen sein. Allerdings ist einzuräumen, dass der Verlauf von SARS-CoV-2-Infektionen noch keineswegs abschließend erforscht ist, von den biomedizinischen Grundlagen bis zur epidemiologischen Ausbreitung unter Berücksichtigung sozialer Faktoren und der Kapazitäten des Gesundheitswesens. Dies macht einen gewissen Sicherheitspuffer nachvollziehbar und die geplante Speicherfrist vertretbar. Wenn sich neue Erkenntnisse ergeben, könnte diese gegebenenfalls abgekürzt werden oder zumindest keine Warnung länger zurückliegender Kontakte mehr erfolgen. Allerdings ist wichtig, dass nach Ablauf der Speicherdauer eine effektive Löschung der Kontakte bzw. Kennungen erfolgt. Eine entsprechende Speicherbegrenzung wird durch Artikel 5 Absatz 1 Buchstabe e der Datenschutz-Grundverordnung vorgeschrieben.

Warnung der Kontakte
Wird nun bei einem Nutzer der App eine SARS-CoV-2-Infektion festgestellt, soll dieser seine entsprechend qualifizierten und daher (noch) gespeicherten Kontakte hierüber mittels seiner App informieren können. Diese Kontakte erhalten dann über die App auf ihrem eigenen Smartphone eine entsprechende Warnung mit der Bitte, sich in Quarantäne zu begeben und mit dem Gesundheitsamt Kontakt aufzunehmen [9].

Im technischen Detail ist eine solche Kontakt-Warn-Prozedur für einen weitgehend auf Anonymität setzenden Ansatz allerdings nicht ganz so einfach, wie es auf den ersten Blick scheinen mag. In den noch immer eher spärlichen Informationen hierzu auf der PEPP-PT-Website (https://www.pepp-pt.org/content) ist insoweit lediglich die Rede davon, dass die – gegebenenfalls um ein Länderkennzeichen ergänzten – temporären IDs der Kontakte im Fall einer offiziell bestätigten Infektion an einen nationalen Server übermittelt werden, von wo aus die Benachrichtigung der Kontakte über deren App erfolgen kann. Mit dem Server ist hierfür also ein zentrales Element vorgesehen.

Autorisierung einer Infektionsmeldung
Um versehentliche oder böswillige Falschmeldungen zu vermeiden, ist im PEPP-PT-Modell auch vorgesehen, dass die Meldung einer Infektion durch den Nutzer der App nur erfolgen kann, wenn diese z. B. durch eine TAN oder einen QR-Code autorisiert wird, die von Gesundheitsbehörden oder zumindest Personal im Gesundheitswesen an den infizierten Nutzer vergeben wird (https://www.pepp-pt.org/content). Dieser „Freischalt-Code“ würde dann von der App zusammen mit den Kennungen der Kontakte im Infektionsfall auf den Server übertragen und dort „authentifiziert“, d. h. auf seine Echtheit geprüft.

Dies kann so erfolgen, dass die Gesundheitsämter oder das Fachpersonal vom gleichen Server die Freischalt-Codes abrufen und der Server die vergebenen Codes im Hintergrund speichert und später dann abgleicht. Wichtig wäre hier im Sinne der Anonymität natürlich, dass das autorisierende Personal zu diesen Codes auf dem Server keine personenbezogenen Angaben hinterlegen kann. Auch wären die Codes auf dem Server nach erfolgter Prüfung und Freigabe einer Warnung unmittelbar zu löschen, um möglichst keine unnötige Spur zur Person des Infizierten zu hinterlassen.

Diese Autorisierung erscheint auch sinnvoll, wenn entsprechende Infektionsbenachrichtigungen von anderen App-Nutzern ernst genommen werden sollen. Solche Benachrichtigungen dürften beschleunigt werden, wenn die entsprechenden Freischalt-Codes durch zugelassene Labore, gegebenenfalls vermittelt über die beauftragenden Arztpraxen, an die Infizierten vergeben würden. Würde die Vergabe der Codes durch das Gesundheitsamt erfolgen, dürfte das trotz nachgelagerter Automatisierung aufgrund von deren Auslastung wohl zu einer gewissen Verzögerung der Benachrichtigungen führen.

Zentraler Abgleich der Kontakte auf einem Server
Im Folgenden wird kurz wiedergegeben, wie die Warnung der Kontakte nach dem Ende März veröffentlichte Vorschlag einer PEPP-PT entsprechenden Architektur durchgeführt werden soll [9]: Die App des Infizierten sendet hier nach entsprechender Freigabe durch diesen die im relevanten Zeitraum gesammelten temporären IDs der Kontakte an einen zentralen Server. Trotzdem bleibt es eine Herausforderung, die hinter diesen IDs stehenden Kontakte über ihre Apps zu informieren, denn diese lassen weder das dahinterstehende Smartphone noch – erst recht nicht – die Person des Nutzers unmittelbar erkennen.

Warnung über sogenannten Push-Token
Als Lösung hierfür wurde vorgeschlagen, dass jede App bei Installation einen sogenannten Push-Token als eindeutige und dauerhafte elektronische Adresse erhält, über welche diese App dann auch für Warnungen erreichbar ist. Um Missbrauch zu verhindern soll dieser Token jedoch nicht per Bluetooth gesendet, auf anderen Smartphones gespeichert und lediglich im Infektionsfall hochgeladen werden, sondern jede App soll – unabhängig von einem Kontakt oder einer Warnung – alle von ihr per Bluetooth lokal gesendeten IDs zusammen mit ihrem Token laufend über das Internet auf den Server übertragen. Dort würde somit eine zentrale Datenbank aller IDs mit den jeweils zugehörigen Token der einzelnen Apps entstehen. Wenn im Rahmen einer Warn-Prozedur auf dem Server dann IDs der Kontakte von infizierten Nutzern eingehen, könnten diese mit der Datenbank abgeglichen und eine entsprechende Information an die Apps der Kontakte mittels der jeweiligen Push-Token verschickt werden.

Erste Kritik an zentralem Abgleich und Push-Token
Dieses Konzept hat schon bald nach seiner Veröffentlichung Ende März Kritik hervorgerufen, denn der Push-Token stellt eine potenzielle Schwachstelle dar (vgl. die unter dem Artikel [9] veröffentlichten Ergänzungen). Er ist zwar nicht klar personenbezogen wie eine Mobiltelefonnummer, welche über den entsprechenden Anbieter ohne Weiteres einem bestimmten, namentlich benennbaren Inhaber zugeordnet werden kann. Allerdings wird teils befürchtet, dass der Server-Betreiber die Adressierbarkeit der App über den Push-Token dazu missbrauchen könnte, weitere Informationen über das Handy und seinen Nutzer bis hin zu dessen Identität zu erlangen.

Wenn sich der Server zudem auch merken würde, von welchen Apps bzw. Push-Token nach Infektion die IDs von Kontakten hochgeladen würden, könnte an zentraler Stelle ein Beziehungsgeflecht von Infizierten mit ihren Kontakten und, falls diese ebenfalls infiziert wurden, auch noch weiteren Kontakten erstellt werden. Der „Link“ zwischen den Infizierten und ihren jeweiligen Kontakten wären dann die „kontaminierten“ Kontakt-IDs. Diese werden zur Warnung vom Infizierten unter seinem Push-Token hochgeladen, stammen ursprünglich aber von den Kontakten des Infizierten und wurden dem Server laufend unter deren jeweiligen Push-Token bereitgestellt. Eine direkte Identifizierung der Personen hinter den Token im Kontaktgefüge, einem sogenannten sozialen Graphen, wäre damit allerdings noch nicht verbunden.

Man könnte jedoch an zentraler Stelle die Entwicklung des Infektionsgeschehens u. U. schneller und etwas präziser verfolgen, als dies über die Meldungen der Gesundheitsämter an das RKI bislang möglich ist und diese Daten aggregiert auswerten, z. B. in Bezug auf die Neuinfektionsmeldungen per App sowie die Anzahl der davon betroffenen Kontakte. Mit der Zeit könnten sich aber auch einzelne Infektionsketten anhand von „kontaminierten“ IDs und Token aus der Datenbank nachverfolgen lassen. So können z. B. potenzielle „Superspreader“, also Infizierte mit vielen relevanten Kontakten, erkannt, wenn auch – wie gesagt – nicht unmittelbar identifiziert werden.

Wenn Teile dieser Infektionsketten aber schon personenbezogen durch die Gesundheitsämter aufgeklärt wurden, könnten durch einen Abgleich der dortigen Daten mit dem zentralen Datenbestand unter Umständen bei besonderen Infektionsmustern auch personenbezogene Zusatzinformationen gewonnen werden, z. B. über die Existenz von Kontakten eines bekannten Infizierten, die gegenüber dem Gesundheitsamt nicht angegeben wurden. Dies gilt erst recht dann, wenn z. B. die Mobiltelefonnummer doch auf den Server übertragen würde oder die IP-Adresse des Smartphones zu einer Datenmeldung gespeichert und zeitnah mit der Zuordnung zu Anschlussinhabern bei den Internetzugangsanbietern abgeglichen würde.

Zum Infektionsschutz eingesetzt, könnten entsprechende Auswertungen sogar über die anonyme Warnung von Kontakten hinaus einen epidemiologischen Nutzen haben. Eine Re-Identifizierung, auch zu diesem Zweck, ist von den Autoren des Vorschlags keineswegs intendiert. Sie fordern, dass App bzw. Push-Token nicht mit der Identität des Nutzers verknüpft werden [9]. Zu praktisch anonymen, wenn auch vielleicht noch einzelfallbezogenen Auswertungen, äußern sich die Autoren dagegen nicht.

Den eine Re-Identifizierung ausschließenden Ansatz verfolgen auch PEPP-PT und die Bundesregierung. Lediglich der Deutsche Landkreistag forderte, dass die App auch „die Kontaktdaten der betroffenen Personen sowie die örtlichen und zeitlichen Gegebenheiten“ an die örtlichen Gesundheitsämter übermitteln solle, was die Bundesregierung jedoch ablehnte [14]. Gleichwohl setzt ein zentraler Abgleich größeres Vertrauen in den Betreiber des Servers voraus. Vollkommen ausgeschlossen erscheint ein Missbrauch bzw. ein nicht zweckentsprechender Gebrauch oder eine spätere Zweckerweiterung nicht, weshalb sich Gedanken über Alternativen oder besondere Schutzmaßnahmen anboten.

Mögliche Vorteile eines zentralen Abgleichs: zentrale Risikobewertung
Nicht direkt personenbezogene Auswertungen über die eigentliche Kontaktwarnung hinaus intendierte aber jedenfalls der aus RKI und HHI bestehende deutsche PEPP-PT-Lead, wie allerdings erst in der vergangenen Woche nach verstärkter Kritik am Modell des zentralen Kontakt-Abgleichs auf dem Server als Rechtfertigung für dieses öffentlich eingeräumt wurde [15]. Dies war auch ein Grund, warum man sich hier mit Billigung des Bundesgesundheitsministeriums für eine solche zentrale Architektur entschieden hatte [16].

Hauptgrund war allerdings vorgelagert die Überzeugung, „dass das staatliche Gesundheitswesen die Souveränität darüber haben muss, nach welchen Kriterien Risikoberechnungen, Handlungsempfehlungen und Rückmeldungen innerhalb eines solchen Systems erfolgen“ [17]. Dies sah man am besten durch eine Server-Lösung gewährleistet, die nicht nur die Kontakte bzw. deren, wenn nicht anonyme, so doch zumindest pseudonyme Kennungen zentral abgleicht, sondern auch das Risiko dieser Kontakte bewertet und danach jeweils über Ob und Wie der Warnung entscheidet.

Eine einheitliche Nachsteuerung dieser Risikobewertung bei neuen wissenschaftlichen Erkenntnissen sah man über den Server wesentlich leichter gewährleistet als bei einer App-seitigen Risikobewertung, die dann gegebenenfalls per Update aktualisiert werden müsste. Neue Erkenntnisse können und sollen zudem, soweit möglich, auch aus der Gesamtheit der übertragenen Daten gewonnen werden [15].

Übertragung von Dauer und Nähe der Kontakte an den Server
Hierfür müsste dann aber jedenfalls die Dauer der Kontakte sowie gegebenenfalls auch deren Intensität bzw. Nähe von der App an den Server übertragen werden. Die Intensität lässt sich dabei automatisiert nur annähernd bestimmen, insbesondere über die Stärke des Bluetooth-Signals und/oder die Laufzeit von Daten über die Bluetooth-Verbindung. Diese Werte können als Indikatoren für die Entfernung zwischen zwei Personen gewertet werden bzw. für Barrieren wie Glasscheiben zwischen diesen, die auch Signalstärke oder Laufzeit beeinträchtigen können. Beide Faktoren, Entfernung und Barrieren, wirken sich auch auf die Ansteckungsgefahr aus, weshalb deren Heranziehung epidemiologisch sinnvoll erscheint.

Solche sensibleren Daten erhöhen auf der anderen Seite jedoch auch die Risiken für die Privatheit der Nutzer. Ein denkbarer sozialer Graph würde dann nicht nur ausweisen, dass Person X mit Person Y nach allgemeinen Standards (derzeit etwa: > 15 min, < 2 m) in relevantem Kontakt stand, sondern wie lange man genau Kontakt hatte und wie nah man sich dabei gekommen ist. Die dadurch erhöhten Risiken für eine Re-Identifizierung und die daraus möglicherweise folgenden Nachteile müssten im Rahmen einer Datenschutz-Folgenabschätzung (Art. 35 DSGVO) mit den denkbaren Vorteilen abgewogen und, soweit möglich und angemessen, reduziert werden – sei es durch besondere Schutzmaßnahmen oder durch Auswahl einer anderen Lösung.

Alternative „Pull-Modelle“ zur Warnung der Kontakte
Anstelle des Einsatzes eines Push-Tokens wurden als Maßnahmen zur Risikoreduktion schnell sogenannte „Pull-Modelle“ ins Spiel gebracht, bei denen keine aktive Benachrichtigung vom Server auf eine möglicherweise „kontaminierte“ App geschickt würde, sondern die Apps beim Server anfragen, ob eine Infektionswarnung zu ihren IDs vorliegt (vgl. bereits die unter dem Artikel [9] veröffentlichten Ergänzungen). Auch in diesem Modell müssten jedoch entweder

1. alle IDs der anfragenden App im relevanten (3-Wochen-)Zeitraum zum zentralen Abgleich temporär – nur für dessen Dauer – auf den Server hochgeladen werden, oder es müssten
2. alle „kontaminierten“ IDs aus dem genannten Zeitraum vom Server temporär in die App heruntergeladen und dort – lokal bzw. dezentral – mit den eigenen IDs abgeglichen werden.

Vorteil bei beiden Pull-Varianten im Hinblick auf den Datenschutz wäre, dass kein übergreifender Token zur Identifikation der App nötig wäre. Bei Variante 1 würde die umfassende ID-Liste der anfragenden App wesentlich kürzer als im Push-Modell auf dem Server gespeichert, in Variante 2 würde diese dort überhaupt nicht gespeichert. In dieser dezentralen zweiten Variante würde der Server nur der Durchleitung der temporären IDs der Kontakte des Infizierten dienen. Diese Variante wäre damit noch datenschutzfreundlicher als die erste, stellte dafür aber höhere Ansprüche an die Bandbreite der Datenverbindungen zu den Smartphones sowie deren Verarbeitungskapazität. Auch wäre in Variante 2 keine Server-seitige Datenauswertung samt Risikobewertung möglich.

Ein um Ostern veröffentlichtes Übersichtsdokument von nationalen Teams aus Deutschland, Frankreich und Italien zur Implementierung des PEPP-PT-Designs nach dem Need-To-Know-Prinzip zeigte sich auch für ein Pull-Modell offen, ohne dieses jedoch näher zu beschreiben oder sich näher festzulegen: „The user is informed through a pull or push mechanism.“ Dieses Papier wurde jedoch kurz nach Veröffentlichung ohne Begründung wieder zurückgezogen. Und das Pull-Modell im Sinne eines dezentralen Abgleiches wurde weder von der deutschen Arbeitsgruppe um das HHI und das RKI noch von der französischen Arbeitsgruppe weiter verfolgt [17].

Decentralized Privacy-Preserving Proximity Tracing (DP3T)
Ein solches Pull-Modell mit dezentralem Abgleich in der jeweiligen App verfolgt das Projekt „Decentralized Privacy-Preserving Proximity Tracing“, kurz DP3T. Hier geht es ebenfalls um die Entwicklung eines Systems, das eine anonyme Verfolgung von COVID-19-Kontakten auf Bluetooth-Basis ermöglicht. Das Open-Source-Projekt startete an den Eidgenössischen Technischen Hochschulen (ETH) Lausanne und Zürich, die immer noch den Großteil des Teams stellen. Mittlerweile sind aber auch Experten aus Belgien, Deutschland, den Niederlanden, Italien und dem Vereinigten Königreich vertreten.

Ganz ohne Server kommt zwar auch die DP3T-Architektur nicht aus, sie verfügt in diesem Sinne also über ein zentrales Element. Allerdings werden auf den Server weit weniger Daten als im zentralen PEPP-PT-Modell übertragen (ausführlich github.com/DP-3T/documents, zusammenfassend [18]). Laufende Datenübertragungen, wie solche der temporären IDs beim zentralen PEPP-PT-Ansatz, finden im DP3T-Modell nicht statt. Die einzelnen Apps, die hinreichend langen und engen Kontakt miteinander hatten, speichern voneinander lokal auf dem Smartphone einen Zeitstempel (Zeitpunkt des Kontakts) und – statt einer temporären ID – eine Prüfsumme, die aus dem Zeitstempel und einem persönlichen Schlüssel der jeweils anderen App generiert wird.

Eine Datenübertragung an den Server findet nur in einem – gegebenenfalls ärztlich oder amtlich bestätigten – Infektionsfall statt. Dann wird jedoch nur der persönliche Schlüssel der „infizierten“ App auf den Server übertragen, von wo ihn alle anderen Apps abholen können. Anschließend erfolgt ein lokaler Abgleich auf dem Smartphone, indem alle dort gespeicherten Zeitstempel mittels des fremden Schlüssels in Prüfsummen umgerechnet und mit den ebenfalls gespeicherten fremden Prüfsummen verglichen werden. Bei einem Treffer hatte man Kontakt mit einer infizierten Person.

Die Trennung von DP3T und PEPP-PT
DP3T sah sich ursprünglich als eines der Projekte „unter dem weiten Schirm“ der grundlegenden PEPP-PT-Architektur, welches sich eben im Hinblick auf die Dezentralität des Abgleichs festgelegt hatte [19]. Auch auf der offiziellen Website von PEPP-PT (https://www.pepp-pt.org) findet sich ein Passus, nach welchem diese Plattform sowohl einen zentralen als auch einen dezentralen Ansatz berücksichtigt oder zumindest erwägt (das verwendete englische Verb „consider“ ist hier nicht eindeutig).

Aus dem Kontext heraus, nämlich dass PEPP-PT zwar internationale Interoperabilität anstrebt, aber auch im Detail verschiedene länderspezifische Implementierungen der App und der Infrastrukturen um diese herum unterstützen möchte, konnte man sich seitens DP3T durchaus Hoffnungen machen, dass auch der – in Bezug auf den Abgleich der anonymen oder zumindest pseudonymen Kontakthistorie auf dem Smartphone – dezentrale Ansatz dieses Projektes hierbei berücksichtigt würde. Dies gilt zumal auf der PEPP-PT-Website einige Zeit das DP3T-Protokoll ausdrücklich als dezentralisierte Umsetzung be-zeichnet wurde, welche vom PEPP-PT-Team begutachtet werde [19]. Dieser Satz wurde in der Woche nach Ostern jedoch von der Website gestrichen – nach Aussage von Mitglie-dern des DP3T-Teams ohne Rücksprache mit diesem, was dort Irritationen auslöste. Man befürchtete eine verstärkte oder gar ausschließliche Hinwendung zu einem zentralen Modell.

Im Hinblick auf ein solches Modell, insbesondere so wie es von vom PEPP-PT-Lead in Deutschland verfolgt wurde, werden von Mitgliedern des DP3T-Teams aber erhebliche Bedenken angemeldet, die teils auch in diesem Beitrag bereits angesprochen wurden. Denn diese Modelle erfordern u. a. ein höheres Vertrauen in die zentralen Services, welches missbraucht werden könne. So bestehe das Risiko des „function creep“, also einer schleichenden Ausweitung der Zweckbestimmung, gerade angesichts der zentralen Verfolgbarkeit zunächst anonymer Kontakte [20]. Diese könnten aber zur Anlage sozialer Graphen (Kontaktgeflechte) genutzt werden und bis hin zur De-Anonymisierung führen.

Allgemein wurde eine mangelnde Transparenz der Arbeiten der PEPP-PT-Kerngruppe kritisiert [19]. So begründete Marcel Salathé, Professor für „Digitale Epidemiologie“ an der ETH Lausanne und prominenter Vertreter des DP3T-Projektes, seine Abkehr von der Zusammenarbeit mit PEPP-PT damit, dass er sich nicht hinter etwas stellen können, vom dem er nicht wisse, wofür es steht. Sein Kollege Kenneth Paterson, Leiter der „Applied Cryptography Group" an der ETH Zürich, führte aus, dass das PEPP-PT-System von externen Experten nicht begutachtet werden könne, weil keine Spezifikation, geschweige denn Code vorgelegt würde.

Erst seit 19.04.2020 wird über ein öffentliches Verzeichnis auf GitHub Code für eine Android-Implementierung des zentralen Need-To-Know-Ansatzes von PEPP-PT zur Verfügung gestellt (https://github.com/pepp-pt). DP3T stellt hier dagegen schon länger Software Development Kits (SDKs) für Android und iOS bereit (https://github.com/DP-3).

Mittlerweile haben sich alle Mitglieder der DP3T-Gruppe von PEPP-PT distanziert, u. a. auch das Helmholtz-Zentrum für Informationssicherheit (CISPA) in Saarbrücken. Und sie bekommen von außerhalb dieses Konsortiums Unterstützung in ihrer Kritik.

Neben den DP3T-Vertretern haben knapp 300 Wissenschaftler aus aller Welt am 19.04.2020 einen offenen Brief unterzeichnet, der auf große Risiken zentralisierter Systeme zur Kontaktverfolgung hinweist, die mit hochgradig dezentralen Lösungen vermieden werden könnten [21]. Letztlich wird gefordert, nur auf Systeme zu setzen, welche öffentlich überprüft werden können und die Privatsphäre durch ihr technisches Design wahren – und nicht lediglich durch Vertrauen in ihre Betreiber. Dieser Forderung schlossen sich der Sache nach am 24.04. auch der Chaos Computer Club, die Gesellschaft für Informatik sowie weitere Vereinigungen in einem offenen Brief an Kanzleramtsminister Braun und Bundesgesundheitsminister Spahn an [22].

Die gemeinsame Initiative von Apple und Google
Kurz vor Ostern haben auch Apple und Google gemeinsam die Initiative ergriffen und angekündigt, die Nutzung von Bluetooth für Zwecke der Kontaktverfolgung zu fördern [23]. Damit möchte sich diese Allianz ausdrücklich den Arbeiten anschließen, die eine Reihe von Gesundheitsbehörden, Universitäten und Nichtregierungsorganisationen diesbezüglich bereits vorangetrieben haben. Der Grundansatz der gemeinsamen Initiative ähnelt dem von PEPP-PT: Insbesondere sollen Privatheit und Sicherheit zentral für die gemeinsam zu entwickelnde Technologie sein und deren Einsatz auf der Einwilligung (dem „opt-in“) des Nutzers beruhen. In der Ausgestaltung verfolgt die Initiative jedoch eine Architektur des dezentralen Abgleichs von Kontaktkennungen, welche derjenigen von DP3T gleicht.

Im einem ersten Schritt planen die beiden Big Player für Mai in abgestimmter Weise Schnittstellen für die Anwendungsprogrammierung, sogenannte Application Programming Interfaces (APIs), speziell zur Kontaktverfolgung in die Betriebssysteme zu integrieren. So soll die Interoperabilität zwischen Android- und iOS-Geräten gewährleistet werden, wenn Kontaktverfolgungs-Apps auf diesen Schnittstellen aufsetzen. Die offiziellen Apps der Gesundheitsbehörden können in den jeweiligen App Stores den Nutzern zum Download bereitgestellt werden. Ein Ausrollen auch von Apps zusammen mit einem Betriebssystem-Update, wie teils politisch – wenn auch mit Widerspruchsrecht – gefordert wurde [24], ist derzeit aber nicht vorgesehen.

In einem zweiten Schritt wollen Apple und Google in den kommenden Monaten daran arbeiten, umfassendere Funktionalitäten der Bluetooth-basierten Kontaktverfolgung direkt in die „zugrundeliegenden Plattformen“, womit wahrscheinlich die Betriebssysteme gemeint sind, zu integrieren. Dies soll eine stabilere Lösung als APIs ermöglichen, welche mehr Menschen die Kontaktverfolgung erlaubt, vermutlich auch und gerade, wenn in ihrem Land entsprechenden Apps nicht verbreitet werden. Eine „Interaktion mit einem breiteren Ökosystem von Apps und staatlichen Gesundheitsbehörden“ soll gleichwohl möglich sein.

Dieser Schritt 2 ist noch nicht näher spezifiziert, jedenfalls nicht für die Öffentlichkeit. Die gemeinsame Initiative gelobt jedoch Transparenz, will mit anderen Entwicklern, Regie-rungen sowie Gesundheitsdiensten zusammenarbeiten und Informationen zur Analyse durch Dritte veröffentlichen. Bereits mit Ankündigung der gemeinsamen Initiative wurden Entwürfe der technischen Konzeption zu Schritt 1 online gestellt (Links unter [23]): eine Rahmen-Dokumentation für das API sowie Spezifikationen für den Einsatz von Bluetooth und Kryptografie. Alle Dokumente werden zwar als vorläufig bezeichnet und stehen unter dem Vorbehalt von Änderungen und Erweiterungen. Dennoch wurde die gemeinsame Initiative der Betriebssystem-Hersteller zu diesem Zeitpunkt für die Öffentlichkeit schon konkreter als beispielsweise PEPP-PT.

Dezentraler Kontakt-Abgleich nach Apple und Google
Aus diesen Dokumenten ergibt sich, dass Apple und Google bereits im ersten Schritt nicht nur eine Verbesserung der Abstandsmessung mittels Bluetooth anstreben, sondern auch einheitlichere Prozeduren für die eigentliche Kontaktverfolgung. Demnach werden die an einem Kontakt beteiligten Personen nicht offengelegt, und auch die „technische Identi-tät“ einer App wird mehrfach verschlüsselt und verschleiert. Zwar existiert eine eindeutige Nutzerkennung pro App (Tracing Key), welche aber nicht unmittelbar personenbezogen ist und das eigene Gerät nie verlässt. Auch die zwischen den Geräten ausgetauschten und bei jedem Kontakt wechselnden Kennungen (Rolling Proximity Identifier) werden nur dezentral auf den beteiligten Geräten gespeichert. Lediglich im Infektionsfall sollen von der App mit Zustimmung des Nutzers dessen Tageskennungen („Daily Tracing Keys“) der letzten zwei Wochen (nach Infektion auch „Diagnosis Keys“ genannt) auf einen Server hochgeladen werden. Vom Inhalt abgesehen werden für diesen Upload keine genauen Vorgaben gemacht, so dass der Server auch von den nationalen App-Herausgebern bestimmt werden kann. Alle anderen Apps können dort diese „infizierten“ Kennungen abholen und mit den beim Kontakt ausgetauschten Kennungen (Rolling Proximity Identifiers) über ein kryptografisches Verfahren abgleichen, um so festzustellen, ob Kontakt zu einer infizierten Person bestand.

Über in den „Rolling Proximity Identifiers“ gegebenenfalls gespeicherten „Metadaten“ wie die Dauer und die Nähe des Kontaktes kann zudem auch dezentral über einen entsprechend in der App implementierten Algorithmus annähernd die Höhe des Infektionsrisikos bestimmt werden. Diese „Rolling Proximity Identifier“ werden auch dezentral nur gespeichert, wenn ein Kontakt bestimmte Mindestkriterien wie eine Dauer von fünf Minuten erfüllt. Sind diese erfüllt, sollen lokal auch nähere Angaben wie die Kontaktdauer in Fünf-Minuten-Intervallen gespeichert werden können. Eine darauf aufbauende App kann eine Speicherung aber auch erst ab einer Kontaktdauer von z. B. 15 Minuten veranlassen.

Breitenwirkung, Interoperabilität und verbesserte Messungen
Die Initiative kann eine sehr große Breitenwirkung entfalten, denn Googles Smartphone-Betriebssystem Android und Apples iOS kommen zusammen auf einen Marktanteil von über 99 %, sowohl weltweit als auch in Deutschland [25]. Über diese Betriebssysteme könnte man weltweit Milliarden von Handys erreichen und in Deutschland Millionen [25], vorausgesetzt entsprechende Updates würden auch für ältere Smartphones bereitgestellt, was aber gerade bei Android in der Vergangenheit keineswegs immer für alle Modelle aller Hersteller gewährleistet war.

Bluetooth-Funkmodule sind zwar in praktisch allen Smartphones verbaut, können aber von Apps nur über das jeweilige Betriebssystem angesprochen werden. Wenn Apps basierend auf unterschiedlichen Betriebssystemen miteinander über Bluetooth kommunizieren, kann dies unter Umständen daher zu Interoperabilitätsproblemen führen. Typischerweise wollen Apps über Bluetooth nur Datenverbindungen zu anderen Geräten herstellen und eine möglichst hohe Signalstärke erhalten, was die Anforderungen an die Interoperabilität und die Fehleranfälligkeit in dieser Hinsicht geringer hält.

Bei Corona-Tracing-Apps ist dies aber nachvollziehbarerweise anders. Hier soll der Standard Bluetooth Low Energy nicht nur zur Übertagung von Dateninhalten, sondern auch zur Messung des Abstandes zwischen zwei Geräten bzw. der epidemiologischen Relevanz von Kontakten eingesetzt werden. Idealerweise werden hier z. B. auch Hindernisse wie Glasscheiben zwischen den Trägern der Smartphones berücksichtigt. Dies kann möglicherweise auch App-seitig über die Erfassung der Laufzeit von Bluetooth-Datenpaketen erfolgen, wohl aber genauer unter (ergänzender) Zuhilfenahme der vom Betriebssystem gemessenen Bluetooth-Feldstärke. Je länger die Laufzeit oder je geringer die Feldstärke, desto weiter entfernt sind üblicherweise die Geräte oder umso mehr Hindernisse befinden sich zwischen ihnen – jedenfalls wenn man von gleicher Sendeleistung ausgeht bzw. die Signalstärke zu dieser ins Verhältnis setzt. Damit die Betriebssysteme die hierfür erforderlichen Informationen genauer messen und/oder diese Daten in genauerer und einheitlicherer Form an die Corona-Tracing-Apps weitergeben, sind Anpassungen an den Betriebssystemen nötig oder zumindest hilfreich [22].

Schnittstellen zur Risikosteuerung für Behörden
Am 24.04.2020 haben Apple und Google nun ihre Spezifikationen insoweit erweitert, dass sie den Entwicklern bzw. Behörden mehr Spielraum bei der Ausgestaltung ihrer Corona-Tracing-Apps geben [26]. Über neue Schnittstellen sollen sie nicht nur Grenzwerte für die Kontaktdauer, sondern auch für die Signalstärke festlegen können.

Der Kontaktabgleich und die Risikobewertung sollen aber nach wie vor dezentral auf dem Smartphone erfolgen, wahrscheinlich auch nicht in der App selbst, also unter technischer „Hoheit“ der Entwickler, sondern direkt mittels der in das Betriebssystem integrierten Technologie. Der Staat bzw. seine Entwickler sollen wohl lediglich, aber immerhin, über ihre App die Parameter hierfür setzen und damit die medizinische Verantwortung übernehmen können.

iOS: Notwendige Bluetooth-Handshakes zeitnah möglich
Bei Apples iOS besteht bislang v. a. aber das Problem, dass bei allen Apps von Drittanbietern die Ausführung ständiger Bluetooth-Handshakes im Hintergrund verhindert wird, um eine ungewollte Ortung der Smartphones mittels Bluetooth z. B. für Werbezwecke (location-based advertising) zu verhindern [15]. Da die Kontakterfassung bei Corona-Apps aber gerade über solche „Handshakes“ zur laufenden Herstellung von neuen Verbindungen funktioniert, müssten diese ständig auf dem Smartphone aktiv sein, also im Vordergrund bei entsperrtem Gerät ausgeführt werden. Dies ist kein realistisches Einsatzszenario für diesen Zweck, denn häufig wird man gerade im öffentlichen Raum aus Gründen der Ak-kulaufzeit, Bequemlichkeit und Sicherheit sein Handy gesperrt im Standby-Modus z. B. in der Hosen- oder Handtasche bei sich tragen.

Vor diesem Hintergrund haben vor allem Deutschland, Frankreich und die EU Druck auf Apple ausgeübt, damit ein Kontaktverfolgungs-API zeitnah schon vor Mai bereitgestellt wird, auf welches dann die nationalen Apps aufsetzen und laufend die nötigen Bluetooth-Handshakes im Hintergrund ausführen können [27]. Apple-Chef Tim Cook soll nun EU-Binnenmarktkommissar Thierry Breton versichert haben, dass eine erste Version dieser Schnittstelle bereits am 28.04. bereitgesellt wird [27].

Wahrscheinlich ermöglicht diese neue Schnittstelle, jedenfalls in ihrer ersten Version, aber auch nur solche Bluetooth-Koppelungen im Hintergrund. Wenn Apple an seinem Grundkonzept festhält dürfte sie darüber hinaus keine Details zur Signalstärke und eventuell noch nicht einmal zur Kontaktdauer an die App herausgeben, sondern die App allenfalls umgekehrt Grenzwerte setzen lassen (wobei dies für die erste Version auch fraglich erscheint). Dann würde bei iPhones ohnehin das Modell eines zentralen Abgleichs mit Risikobewertung auf dem Server auch künftig nicht funktionieren. Das war möglicherweise mit ein Grund für die Kehrtwende der Bundesregierung hin zum dezentralen Modell.

Risiken personenbezogenen Trackings über den Server
Nicht nur in der zentraleren PEPP-PT-Architektur, auch in dezentraleren Modellen wie bei DP3T oder Apple und Google müssen die Apps jedoch mit einem Server kommunizieren und an diesen wohl zumindest ihre jeweils aktuelle IP-Adresse übertragen, was auch gewisse Datenschutzrisiken mit sich bringt [20]. Denn diese IP-Adresse kann jedenfalls vom vergebenden Internet-Access-Provider bis zu 10 Wochen lang auf Vorrat gespeichert und einem bestimmten Anschlussinhaber zugeordnet werden (z. B. der Arbeitsstelle oder Wohnung des Nutzers, wenn das Smartphone die Internetverbindung des dortigen WLANs nutzt).

Soweit der Bertreiber des Servers nun über rechtliche Mittel verfügt, die „vernünftigerweise“ eingesetzt werden können, um mit Hilfe Dritter den Nutzer anhand der gespeicherten IP-Adresse bestimmen zu lassen, wären die ihm auf dem Server zugeordneten Daten nach der Rechtsprechung von Europäischem Gerichtshof und Bundesgerichtshof auch für den Betreiber personenbezogen (BGH, Urteil v. 16.05.2017 – VI ZR 135/13). Als Dritte kommen hier der Internetzugangsanbieter und gegebenenfalls eingeschalteter Behörden in Betracht. Der Zugangsanbieter ist nach § 113 des Telekommunikationsgesetzes verpflichtet, die genannte Zuordnung u. a. an die zur Abwehr von Gefahren für die öffentliche Sicherheit oder Ordnung zuständigen Behörden herauszugeben, wenn sie zu diesem Zweck angefordert werden.

Eine solche Datenerhebung durch die Behörden bedarf zwar zusätzlich einer gesetzlichen Ermächtigung. Diese findet sich jedoch in vielen Fachgesetzen, v. a. in den Polizeigesetzen von Bund und Ländern, wenn auch oft mit Richtervorbehalt versehen. Zur öffentlichen Sicherheit zählt zudem die öffentliche Gesundheit. Fraglich ist allerdings, ob sich die allgemeinen Polizeibehörden einschließlich des Polizeivollzugsdienstes über die Sonderzuständigkeiten des Gesundheitsamtes und die hierfür geltenden Beschränkungen hinwegsetzen dürften. Und das Infektionsschutzgesetz (IfSG) berechtigt allenfalls sehr begrenzt zu einer Auskunft über die IP-Adress-Zuordnung. Die damit einhergehende Einschränkung des Fernmeldegeheimnisses (Art. 10 des Grundgesetzes) ist nach gegenwärtiger Rechtslage nur im Hinblick auf Schutzmaßnahmen gegen die Ausbereitung einer Erkrankung (§§ 28-32 IfSG), nicht jedoch für Ermittlungen über Art, Ursache, Ansteckungsquelle und Ausbreitung der Krankheit (§ 25 IfSG) erlaubt. Die Kontaktverfolgung durch das Gesundheitsamt wird aber auf die zuletzt genannte Vorschrift gestützt.

Wegen der zur Abwehr oder Aufklärung von Cyberangriffen bestehenden Rechtsbehelfe wird gleichwohl vom Bundesgerichtshof schon für einen „normalen“ Website-Anbieter angenommen, dass IP-Adressen für diesen personenbezogen sind. Dies wird man daher auch für den Betreiber des App-Servers kaum ausschließen können.

Um eine Identifizierung der Nutzer zu verhindern, ist daher darauf zu achten, dass deren IP-Adresse nicht oder nur kurzfristig über die Laufzeit der aktuellen Anfrage hinaus auf dem Server gespeichert bleibt. Zur Abwehr von Cyberangriffen kann es gerechtfertigt sein, die anfragenden IP-Adressen einige Stunden bis allenfalls wenige Tage über den Zugriff hinaus zu speichern, um zum Beispiel bestimmte IP-Adressen identifizieren und gegebenenfalls blocken zu können, von denen aus immer wieder Angriffe auf den Server erfolgen. Die IP-Adressen dürfen allerdings keinesfalls regelhaft mit den sonstigen Daten wie den IDs verknüpft werden, die über eine App auf den Server hochgeladen werden.

Auch dürfen – jedenfalls ohne gesonderte, aufgeklärte und optionale Einwilligung des Nutzers – keine weiteren, möglicherweise identifizierenden Daten wie die Mobiltelefonnummer, aber auch sonstige eindeutige Geräteinformationen wie die Adresse des Netzwerkadapters des Smartphones (sog. MAC-Adresse, kurz für „Media Access Control“), die IMEI-Nummer (International Mobile Equipment Identity), die SIM-Kartennummer (IMSI) sowie gegebenenfalls auch Fingerprints aus Geräteeinstellungen oder Cookie-Inhalte an den Server übertragen werden.

Das setzt gerade bei Smartphones, über die man als Nutzer in der Regel weniger administrative Kontrolle hat als bei klassischen PCs, ein höheres Vertrauen in die Hersteller der Betriebssysteme, die Herausgeber der Apps und die Betreiber der Server voraus. Zur Vertrauensbildung wie auch zur Qualitätssicherung bietet es sich daher an, die Server-Betreiber von unabhängiger Stelle zu zertifizieren und den (Quell-)Code der App als Open Source zur Verfügung zu stellen. Eine entsprechende Zertifizierung hatte auch PEPP-PT ins Spiel gebracht, wobei dieser Verbund insoweit für die dezentrale Lösung nicht in Betracht kommen dürfte. Zumindest sollte bei einer solchen App, die aktiv von der Politik empfohlen wird und möglichst nationale Reichweite erlangen soll, ein unabhängiges Review des Quellcodes durch unabhängige, nicht an der Entwicklung beteiligte Stellen erfolgen (vgl. [28]).

Wohl keine zuverlässigen Peer-to-Peer-Alternativen für die Warnung
Theoretisch mag es denkbar sein, dass die Apps nicht nur gegenseitig beim direkten Kontakt ohne zentrale Vermittlungsinstanz Informationen austauschen, sondern sich später im Infektionsfall dann auch mittels dieser Informationen über ein dezentrales Peer-to-Peer-Netzwerk warnen. Ein solches P2P-Modell könnte ohne zentralen Server auskommen, der immer ein besonderes Schadenspotenzial birgt, sollte er gehackt oder anderweitig missbraucht werden. Das Modell stünde jedoch vor anderen Herausforderungen, die dessen Nutzung für eine Corona-Kontaktverfolgung wenig praktikabel erscheinen lassen [29].

Zur Warnung im Infektionsfall kann man hier nicht auf eine lokale Koppelung der beteiligten Geräte wie beim Kontakt über Bluetooth setzen. Es wäre eine globalere Kommunikation nötig, die jedoch ohne Server implementiert werden müsste.

Auf physischer Ebene steht Smartphones aber nur Bluetooth und auf noch kürzere Distanz NFC (Near Field Communication) für eine P2P-Kommunikation zur Verfügung. Für eine Datenübertragung auf größere Distanz, wie zur Warnung erforderlich, müsste die Kommunikation letztlich doch über das Mobilfunknetz oder das Internet vermittelt werden, wobei auch dies grundsätzlich ohne Server denkbar wäre (logisches P2P-Netz auf höherer Ebene).

Diese könnte zeitübergreifend eindeutig adressiert erfolgen, also direkt zwischen den Geräten, die zuvor lokal in Kontakt miteinander standen, wofür man allerdings Identifier wie die (personenbezogene) Mobiltelefonnummer lokal hinterlegen müsste. Das ist aber eher untypisch für P2P-Netzwerke. Auch wenn man diese Daten nicht unmittelbar aus der App auslesen könnte, würde dies gleichwohl ein weit größeres Vertrauen allen Kontaktpersonen gegenüber erfordern als es bei den Server-basierten Lösungen, seien sie zentral oder dezentral, der Fall wäre. Außerdem würden auch im P2P-Modell zumindest Vermittlungsserver der Mobilfunkprovider eingesetzt, wobei diese die Kommunikation nicht ohne Weiteres einer Corona-App zuordnen könnten und die Inhalte nicht mitlesen dürften bzw. bei Verschlüsselung auch faktisch nicht könnten. Inwieweit man für diese dauerhaft eindeutige Adressierung der Warnungen andere Geräte- oder App-bezogene Identifier bzw. Push-Token einsetzen könnte, wäre gegebenenfalls zu prüfen. Ohne mehr oder weniger zentrale Administration des Adressraums (über einen oder mehrere Server) mit entsprechenden Gefahren für eine Identifizierung der Nutzer dürfte dies aber wahrscheinlich nicht funktionieren.

Möchte man auch die Peer-to-Peer-Kommunikation weitgehend anonym halten und verzichtet daher auf die individuelle Adressierung von Apps, müsste alle Apps fähig sein, sämtliche Informationen zumindest zu allen Infektionsfällen mit allen anderen Apps wie in einem Filesharing-Netzwerk zu teilen (P2P im typischen Sinn). Dafür müsste eine hinreichende Anzahl von Apps immer online sein und über genügend Speicher- und Rechenkapazitäten verfügen, was nicht als immer gegeben unterstellt werden und die technische Zuverlässigkeit von Warnungen negativ beeinträchtigen kann. Zwar wäre die geteilten Daten hier nicht so sensibel wie bei einer Adressierung über die Mobiltelefonnummer, dafür müsste man nicht nur seinen Kontakten, sondern allen anderen App-Nutzern dahingehend vertrauen, dass sie die bereitgestellten Daten nicht missbrauchen. Diese sind hier zwar reduziert, aber dennoch nicht ohne Aussagekraft.

Auch die Autorisierung einer Infektionswarnung durch einen vom diagnostizierenden Arzt dem Nutzer übermittelten Freigabecode wäre in den P2P-Modellen schwieriger zu implementieren, wenn nicht doch wieder Anfragen zur Prüfung der Echtheit (Authentifizierung) des vom Nutzer dann in die App eingegebenen Codes durch einen Server der Gesundheitsbehörden erfolgen sollen. Natürlich wäre es denkbar, in alle Apps schon bei Installation eine von vorn herein festgelegte Liste mit rund 80 Millionen Freigabecodes für die gesamte Bevölkerung Deutschlands herunterzuladen, gegen welche dann der gegebenenfalls später vom Nutzer eingegebenen Code geprüft würde. Dieses System würde aber wenig Flexibilität für Anpassungen aus technischen oder anderen Gründen bieten. Die Codes müssten in der App zwar besonders gesichert hinterlegt werden. Das Schadenspotential wäre aber enorm, falls die Liste doch gehackt würde, sei es durch Überwindung der Speicherschutzes, oder durch Abgreifen von echten Codes zur Laufzeit des Abgleichs mit einem willkürlich eingegeben Code.

Gleichwohl könnte der P2P-Ansatz noch näher untersucht werden. Nach dieser ersten Einschätzung dürfte er aber im Hinblick auf die Verfolgung von Corona-Kontakten wahrscheinlich weder im Hinblick auf technische Zuverlässigkeit, Datensicherheit und Datenschutz noch epidemiologische Auswertbarkeit überwiegende Vorteile mit sich bringen.

Richtungswechsel der Bundesregierung hin zum dezentralen Ansatz
Am 26.04. vollzog dann auch die Bundesregierung einen Richtungswechsel vom bislang verfolgten zentralen zum dezentralen Ansatz [3]. Kanzleramtsminister Braun und Bundesgesundheitsminister Spahn verkündeten die Entscheidung, konsequent „auf eine dezentrale Softwarearchitektur“ zu setzen [30], ohne dies offiziell jedoch als Abkehr vom bisheri-gen Kurs zu bezeichnen. Die „in Kürze zur Verfügung stehenden Programmierschnittstellen der wesentlichen Anbieter von mobilen Betriebssystemen“ sollen hierfür genutzt werden, womit auf die Initiative von Apple und Google Bezug genommen wird. Gleichzeitig soll in die dezentrale Architektur auch die Möglichkeit integriert werden, dass Bürgerin-nen und Bürger freiwillig in pseudonymisierter Form Daten zur epidemiologischen Forschung und Qualitätssicherung“ an das RKI übermitteln können.

Damit würde einerseits der in Bezug auf den Server datensparsame Ansatz der dezentralen Architektur beachtet, die – wenn sie wirklich konsequent umgesetzt wird – den Kontaktabgleich nur auf dem Smartphone durchführt. Wohl als Art Zusatzfunktion könnten die Nutzer andererseits jedoch weitere Daten, die für die Kontaktverfolgung nicht unbedingt nötig sind, auf Server des RKI übertragen und für die epidemiologische Forschung und Qualitätssicherung „spenden“, also in die Verarbeitung durch das RKI zu diesen Zwecken einwilligen.

Das HHI soll die App nicht weiter betreuen, sondern den ohnehin noch in Entwicklung befindlichen Projektstand an einen anderen Träger übergeben [3]. HHI-intern werden dem entsprechenden Pressebericht zufolge auch gravierende Fehler hinsichtlich der Kommunikation bei PEPP-PT eingeräumt.

Bewertung des zentralen gegenüber dem dezentralen Ansatz
Die Kehrtwende der Bundesregierung vom zentralen hin zu einem dezentralen Ansatz ist vor dem Hintergrund der Geschehnisse nachvollziehbar.

Denn eine Corona-Tracing-App ist auf eine hohe Akzeptanz in der Bevölkerung angewiesen, wenn sie wirksam sein soll. Die Wirkung solcher Apps beruht auf Netzwerkeffekten. Eine App kann Kontakte nur erfassen, wenn diese die App ebenfalls nutzen. Ein merklicher Effekt kommt nur zustande, wenn möglichst viele die App verwenden. Schätzungen zufolge müsste hier ein Schwellenwert von 60 % der Bevölkerung erreicht werden [31]. Die teils massive Kritik aus Wissenschaft und Zivilgesellschaft an der zentralen Lösung hätte daher die nötige Akzeptanz der App gefährdet, wenn sie weiter mit diesem Ansatz entwickelt worden wäre.

Hinzu kommt die bereits angesprochene Abhängigkeit von den beiden marktbeherrschenden Smartphone-Betriebssystemen. Während man bei dem relativ quelloffenen Android-System von Google als Entwickler bzw. Herausgeber einer App eher auch ohne aktive Kooperation von Google die für eine zentrale Lösung benötigten Daten auslesen kann, ist dies beim geschlossenen iOS-System von Apple aus (urheber-)rechtlichen und technischen Gründen kaum möglich. Apple scheint zudem im Hinblick auf eine zentrale Lösung zu keinem Entgegenkommen bereit gewesen zu sein und hätte aus rechtlichen sowie faktischen Gründen auch nicht oder nur schwer dazu gezwungen werden können. Ein Verzicht auf die iPhones würde aber in Deutschland einen Verlust von fast 30 % der Handynutzer bedeuten [25]. Ein Schwellwert von 60 % könnte theoretisch dennoch erreicht werden, praktisch würde aber die angesprochene Akzeptanzproblematik noch gravierender. Auch nicht jeder Android-Nutzer, der dies könnte, dürfte die App installieren – und so stünde die nötige Verbreitung umso mehr in Frage.

Auch wenn nun Fakten geschaffen wurden und die Bundesregierung kaum noch einmal eine Wende vollziehen dürfte, soll neben diesen rein faktischen Erwägungen hier aber auch eine kurze normative Einschätzung vorgenommen werden.

Im Hinblick auf Risiken für die Privatsphäre der Nutzer wäre hier die Wahrscheinlichkeit einer Re-Identifizierung und die hierdurch möglichen Nachteile zu evaluieren.

Wie bereits ausgeführt birgt die Kommunikation mit dem Server, vor allem wenn sie aus dem heimischen WLAN heraus erfolgt, jedenfalls über die IP-Adresse Re-Identifikationsmöglichkeiten. Diese Risiken existieren aber sowohl im zentralen, als auch im dezentralen Modell. Zudem wäre die Nutzung dieser Möglichkeiten hier nach geltendem Recht in der Regel nicht zulässig. Auch könnte man die IP-Adressen auf dem Server sofort nach dem Zugriff auf dem Server löschen und sie nur im Fall einer direkt nachgewiesenen Cyberattacke zu deren Aufklärung speichern. Auf die Ungewissheiten einer P2P-Implementierung wird man sich daher kaum einlassen müssen, wobei dieser Ansatz gleichwohl im Rahmen einer Vergleichsprüfung auch technisch noch etwas näher beleuchtet werden sollte.

Daneben kommt auch eine Re-Identifikation über den sozialen Graphen, also das Kontaktgeflecht, der Infizierten in Betracht, wenn sich hier ein besonderes Muster zeigt und ein Abgleich mit anderen Datenquellen erfolgt.

Teilweise wurden hierzu allerdings mit Aussagen wie der folgenden etwas übertriebene Befürchtungen geweckt [32]: „In einem zentralen System gibt es - verkürzt gesagt - einen ‚allwissenden‘ Server, dessen Betreiber letztlich alle Nutzer deanonymisieren kann.“ Auch der Server im zentralen PEPP-PT-Modell ist nicht „allwissend“ in dem Sinne, dass er ohne Weiteres alle Nutzer re-identifizieren könnte. Dies würde immer noch einiges an Aufwand erfordern, wäre wohl nur für einen kleineren Teil der – infizierten – Nutzer (und ihrer Kontakte) erfolgversprechend und ist überdies derzeit nicht geplant. Gleichwohl wäre die Wahrscheinlichkeit, eine gewisse Anzahl von Nutzern zu de-anonymisieren, und zwar gerade die Kontakte eines identifizierten Infizierten (wenn man es denn möchte), im zentralen Modell merklich größer als im dezentralen Modell.

Die Frage wäre dann, welche Nachteile diesen Nutzern durch die Re-Identifizierung drohen. Im Hinblick auf die informationelle Selbstbestimmung als Grundrecht wäre schon die bloße Re-Identifizierung ohne Einwilligung ein solcher Nachteil. Denn dieses Grundrecht dient dem Schutz der freien Persönlichkeitsentfaltung bereits im Vorfeld konkreter Benachteiligungen, soll diesen vorbeugen und auch einem zu Selbstbeschränkung führenden Überwachungsgefühl vorbeugen.

Zudem können durchaus konkrete Nachteile drohen. So ist der Quellenschutz für den investigativen Journalismus von besonderer Bedeutung. Journalisten dürfen auch von Dritten (ihren Quellen) illegal erhobenes Material bei öffentlichem Interesse verwerten. Wenn nun aber Quellen, z. B. Whistleblower aus dem Gesundheitswesen, die über eventuelle Missstände berichten, als Kontakte von Journalisten mit Re-Identifizierung durch einen staatlichen Gesundheitsdienst und die Ermittlungsbehörden rechnen müssten, wäre der aus gutem Grund ebenfalls grundrechtlich geschützte Journalismus beeinträchtigt (ein Beispiel aus Frankreich, das den zentralen Ansatz zumindest verfolgte, wenn nicht noch verfolgt, und in dem dies relevant werden könnte, liefert [33]).

Hier wird man einwenden können, dass man gegen die Re-Identifizierung sowohl technische als auch rechtliche Sicherungen treffen könnte. Ein Beispiel für letztere wären Beweisverwertungsverbote zur Verhinderung einer Benachteiligung nach erfolgter Re-Identifizierung . Angesichts solcher institutionellen Sicherungen in einem demokratischen Rechtsstaat wie der BRD mögen einem die beschriebenen Risiken gering erscheinen. Ganz leugnen kann man sie aber nicht. Und sie sind, v. a. durch das größere Re-Identifizierungspotenzial, im zentralen größer als im dezentralen Modell. Dieser Umstand unterwarf und unterwirft diejenigen einer besonderen Rechtfertigungslast, die auf das zentrale Modell setzen.

Die intensivere Verarbeitung von Daten im dezentralen Modell auf den Smartphones mag auch gewisse Risiken für Sicherheit und Datenschutz mit sich bringen, die in vergleichbarer Weise beim zentralen Ansatz nicht bestehen. Gleichwohl dürften diese Risiken begrenzter sein als jene die durch Kompromittierung eines zentralen Servers mit weit mehr Daten bestünden. Auch sind dezentrale Risikominimierungsmaßnahmen vorgesehen, wie die Verschlüsselung der Kennungen auch für den Nutzer selbst auf dem Smartphone. Auch bei Verlust könnten diese nicht ohne Weiteres ausgelesen werden. Außerdem wäre der Verlust eines Smartphones für den Nutzer offensichtlicher als die Kompromittierung des Servers.

Das Risiko des Datenmissbrauchs durch die Hersteller der Betriebssysteme von Smartphones, letztlich also vor allem Apple und Google, sollte natürlich auch betrachtet werden. Allerdings dürfte dieses Risiko im dezentralen Modell allenfalls geringfügig höher als im zentralen Modell sein und die erhöhten Risiken eines zentralen Modells im Hinblick auf die Privatheit nicht überwiegen. Denn auf den Smartphone-Betriebssystemen setzen letztlich beide Lösungen auf. Außerdem müssen auch dezentrale Systeme nicht unbedingt auf erweiterten Funktionalitäten des Betriebssystems aufsetzen, sondern könnten sich wie zentrale Systeme auch mit den Basisfunktionen begnügen und die eigentliche Kontaktverfolgung und Risikobewertung App-seitig bewerkstelligen.

Das bedeutet nicht, dass das zentrale Modell unter keinen Umständen datenschutzkonform implementiert hätte werden können. Im Hinblick auf die Datensparsamkeit hat aber das dezentrale Modell klar „die Nase vorn“. Und von diesem Grundprinzip der DSGVO kann auch mit Einwilligung der Nutzer als Rechtsgrundlage nicht ohne weiteres abgewichen werden. Dies gilt jedenfalls dann, wenn man als Staat eine solche Maßnahme fördert und jeden Smartphone-Besitzer zur Nutzung – wenn auch nicht rechtlich verpflichtend – auffordern möchte.

Die Befürworter des zentralen Modells müssten also Vorteile für andere legitime Zwecke wie den Gesundheitsschutz benennen und darlegen, warum diese Vorteile die Nachteile im Hinblick auf die Privatheit überwiegen. Entsprechende Rechtfertigungsansätze über unter Umständen bessere epidemiologische Auswertung und Steuerung von Infektionsrisiken zeigten sich in der Öffentlichkeit jedoch erst vergangene Woche als Reflex darauf, dass die Kritik am zentralen Modell massiv zugenommen hatte. Wenn man das zentrale Modell hätte weiter verfolgen wollen, hätte dieser epidemiologische Zusatznutzen des zentralen gegenüber dem dezentralen Modell noch näher beschrieben und bewertet werden müssen [34], wenn auch ohne in der akuten Situation gegenwärtig höchste Evidenzgrade zu verlangen.

Richtig wäre zudem gewesen, die verschiedenen Modelle und ihre jeweiligen Vor- und Nachteile zunächst in einer Datenschutz-Folgenabschätzung gegeneinander abzuwägen, bevor man eine Entscheidung trifft. Ob im deutschen PEPP-PT-Projekt eine solche DSFA stattgefunden hat, vermag der Autor nicht zu sagen. Aus dem zivilgesellschaftlichen Bereich hat der Informatiker-Vereinigung FIfF einen gut strukturierten, wenn auch im Ergebnis sehr kritischen Vorschlag hierzu unterbreitet [35]. Zur Stopp-Corona-App des ÖRK wurde eine solche DSFA durchgeführt und evaluiert, was nun mit dazu geführt hat, dass man dort von einem zentralen zu einem dezentralen Modell übergehen möchte [36].

Angesichts der intendierten Breitenwirkung, hätte eine solche DSFA – unabhängig von deren Ergebnis – nicht allein kleinen Expertenzirkeln aus Kanzleramt, Bundesgesundheitsministerium, RKI und HHI überlassen werde dürfen, sondern hätte einer breiteren Einbindung zumindest der Fachöffentlichkeit, wenn nicht gar einer gesamtgesellschaftlichen Debatte bedurft. So hätten Entwürfe bspw. veröffentlicht werden und Verbändekonsultationen stattfinden können, wie man es aus dem Gesetzgebungsverfahren kennt, wenn auch nachvollziehbarerweise mit kürzeren Fristen. Entsprechende politische Abwägungsentscheidungen hätten letztlich transparent verkündet und begründet werden sol-len.

Faktische Grenzen von Kontaktverfolgungs-Apps
Ohnehin ist auch die Frage aufgekommen, ob automatisierte Kontaktverfolgungs-Apps, gleich nach welchem technischen Konzept, überhaupt alle relevanten Kontakte in epidemiologisch sinnvoller Weise erfassen können. So stellte der Landesbeauftragte für den Datenschutz in Baden-Württemberg die Hypothese auf, dass entsprechendes „Handy-Tracking“ nicht funktioniere, solange es zum einen freiwillig sei und zum anderen (auch nach freiwilliger Aktivierung) bestimmte Situationen mit relevantem Infektionsrisiko nicht erfassen könne [37].

Jason Bay, Senior Director der Government Digital Services in Singapur und verantwortlich für die dort schon im Einsatz befindliche Bluetooth-basierte Corona-App „TraceTogether“, formuliert etwas weniger skeptisch, hebt aber doch prägnant die Grenzen eines solchen Systems hervor [38]: „If you ask me whether any Bluetooth contact tracing system deployed/under development, anywhere in the world, is ready to replace manual contact tracing, I will say without qualification that the answer is, No.“ Er plädiert für einen „human-in-the-loop“ und eine enge Anbindung solcher Apps an eine „manuelle“ bzw. menschliche Kontaktverfolgung.

Auch möchte er mit Apple und Google bei deren Bemühungen um eine Kontaktverfolgungs-Technologie zusammenarbeiten und Input zu gewünschten Schnittstellen (APIs) geben, ohne diesen konkret zu benennen. Zwar gibt es ihm zufolge kritische Faktoren wie die Belüftung eines Raums, die eine App nicht erfassen kann. Dennoch geht es ihm bei der Definition von Schnittstellen möglicherweise darum, dass auch dem öffentlichen Gesundheitsdienst mehr Daten zur Verfügung stehen. Hier könnte man an Daten zur Kontaktdauer, zur Signalstärke oder gegebenenfalls auch zu Standorten denken, um z. B. aus letzteren mit Hilfe von Bewegungsprofilen Infizierter Infektions-„Hotspots“ erkennen zu können, das vermutet nicht allzu fern liegend zumindest Marcel Salathé, Professor am „Digital Epidemiology Lab“ der ETH Lausanne [39]. Denn, so die Worte von Bay: „You cannot “big data” your way out of a “no data” situation.”

Zuzustimmen ist Bay jedenfalls insoweit, als dass automatisierte Kontaktverfolgung kein Allheilmittel gegen das Coronavirus ist. Dennoch können auch entsprechende Apps einen Beitrag leisten.

Kontaktverfolgung durch das Gesundheitsamt
Mit oder ohne App steht am Beginn der Nachverfolgung eine positive COVID19-Diagnose durch Fachpersonal, die dem Infizierten in der Regel durch dieses Personal mitgeteilt wird. Früher oder später erhält der Infizierte dann einen Anruf vom Gesundheitsamt samt Verhaltenshinweisen, er wird, falls erforderlich, beruhigt und in jedem Fall nach seinen Kontakten befragt – und zwar personenbezogen, worauf er grundsätzlich nach § 25, § 16 Ab-satz 2 IfSG auch antworten muss. Engere Kontakte bekommen dann irgendwann auch einen entsprechenden Anruf. So können neben Namen und Erreichbarkeit auch Art, Intensität und Ort der Kontakte erfragt werden. Diese Angaben können dann gegebenenfalls auch für Analysen über bislang unbekannte Infektionswege genutzt werden, sei es durch Big Data und/oder menschliches Denkvermögen.

Nun würde die App, weder im Modell von PEPP-PT noch von DP3T oder Apple und Google dazu führen, dass das Gesundheitsamt automatisch schneller an die Telefonnummern oder der näheren Umstände der Kontakte kommen würde, auch wenn sich der Landkreistag dies nun wünscht [14]. Dennoch kann die Warnung der Kontakte über die App schneller erfolgen, als wenn das Gesundheitsamt diese erst erfragen und dann abtelefonieren müsste – ohne dass Letzteres dem Gesundheitsamt erspart bliebe oder zumindest abgeschnitten wäre. Dies sollte, selbst bei einem schlimmstenfalls massiven (Wieder-)Anstieg der Infektionszahlen nach Lockerung der Kontaktrestriktionen, so weit wie möglich weiter erfolgen, wofür nach dem Bund-Länder-Beschluss vom 15.04. zusätzliche Kapazitäten geschaffen werden sollen.

Denn manche Kontakte mit Risiko würden überhaupt nicht von der App erfasst, z. B. sol-che unterhalb der üblichen Mindestdauer, aber einem Anniesen oder Anhusten. Auch soweit sich SARS-CoV-2 unabhängig von (größeren) Tröpfen als Aerosol-„Fallschirmspringer“ länger in der Luft hält und infektiös bzw. vorgelagert kontagiös sein kann („airborne transmission“), hilft das im vorgesehene, auf räumliche und zeitliche Nähe zu einer anderen Person abstellende „proximity tracing“ nicht oder nur begrenzt [38]. Hier könnten neben (mündlichen) Angaben zu den räumlichen Verhältnissen (z. B. geschlossener Raum oder Wiese im Park) auch (automatisch erfasste) GPS-Daten mit Zeitstempel weiterhelfen, wenngleich letztere wahrscheinlich auch nur begrenzt, aber immerhin. Auch GPS-Daten sollen beim Proximity Tracing jedoch nicht erfasst werden.

Auf der anderen Seite kann eine entsprechende App aber auch Kontakte erfassen, die anders praktisch nicht nachverfolgbar wären. So wird ein Infizierter in der Regel nicht über die Kontaktdaten jeder Person verfügen, die in öffentlichen Verkehrsmitteln mindestens 15 Minuten in weniger als 2 Meter Entfernung von ihm verbracht hat. Über eine App ließen sich aber auch solche Personen zumindest anonymisiert warnen.

Ausbau solcher Apps zur personenbezogenen Kontaktverfolgung?
Gleichwohl kann man sich vor dem Hintergrund der Angaben, die ein Infizierter ohnehin dem Gesundheitsamt gegenüber machen kann und muss, die folgende Frage stellen: Wieso nicht die App gleich alle Kontakte personenbezogen (mit Mobilnummer u. am bes-ten auch Kontaktort/GPS-Daten) erfassen und nach Bestätigung einer Infektion automatisch an das Gesundheitsamt übertragen lassen? Am besten indem der Arzt schon die Handynummer abfragt und dann an das Gesundheitsamt übermittelt, welches sich remote die Daten vom Handy holt, wenn die nicht ohnehin laufend schon auf Server übertragen werden. Das würde die Gesundheitsämter am besten unterstützen, auch wenn dann immer noch menschliche Arbeit erforderlich wäre.

Dies entspricht der vergangenes Wochenende vom Deutschen Landkreistag aufgestellten Forderung, dass die App auch „die Kontaktdaten der betroffenen Personen sowie die örtlichen und zeitlichen Gegebenheiten“ an die Gesundheitsämter übermitteln solle [14]. Auch wenn die Bundesregierung dies abgelehnt hat, sollen im Folgenden die rechtlichen Grenzen einer solchen Maßnahme kurz beleuchtet werden.

Rechtliche Grenzen eines solchen Ausbaus
Je automatisierter die Rechtsdurchsetzung durch Technik erfolgt, desto effizienter mag sie sein. Sie wird dadurch aber auch in skalierbarer Weise umso missbrauchsanfälliger und kann so leichter zu großem Unrecht werden. Das geht nicht so einfach, wenn das Handeln zahlreicher Individuen – sei es der Mitarbeiter im Gesundheitsamt oder der Infizierten – dazwischentreten muss. Hier gilt es einen Ausgleich zu finden, was klar gegen die Zwangsinstallation einer App mit Nachverfolgung von identifizierbaren Personen oder präzisen GPS-Daten spricht.

Zudem besteht selbst dem Gesundheitsamt gegenüber ein Aussage- bzw. Zeugnisverweigerungsrecht dahingehend, dass man sich selbst oder einen Angehörigen nicht einer Straftat oder Ordnungswidrigkeit bezichtigen muss (§ 16 Abs. 2 S. 4 IfSG in Verbindung mit § 383 Abs. 1 Nr. 1-3 der Zivilprozessordnung – ZPO). Dieses Recht würde unter anderem greifen, wenn man in gerader Linie verwandte Kontaktpersonen, z. B. die in einem eigenständigen Haushalt lebenden Eltern, unter Verstoß gegen die nach den Allgemeinverfügungen oder Rechtsverordnungen mancher Bundesländer insoweit bestehenden Kontaktverbote getroffen hätte und dies mit einem Bußgeld belegt werden kann. Ein solches Verweigerungsrecht spricht auch gegen eine zwingende und personenbezogene Voll-Automatisierung der Kontaktverfolgung durch eine App. Denn Automatismen können solche Ausnahmefälle oder neue Konstellationen meist nicht zuverlässig erkennen – das gilt für das Recht genauso wie für die Medizin.

Darüber hinausgehende Zeugnisverweigerungsrechte aus beruflichen Gründen wie die für Journalisten über ihre Quellen (§ 383 Abs. 1 Nr. 5 ZPO) finden sich im IfSG zwar nicht. Üblicherweise wird auch davon ausgegangen, dass dies verhältnismäßig sei, da man nur Kontakte, nicht aber etwa Inhalte der Kommunikation offenlegen müsse.

Diese Rechte könnten unter bestimmten Umständen aber vor verfassungsrechtlichem Hintergrund analog angewendet werden, gerade wenn Journalisten über mögliche Versäumnisse der Gesundheitsbehörden recherchieren. Denn hier könnte der bloße Kontakt zu einer benannten Quelle im Gesundheitswesen dem Gesundheitsamt schon ohne Kenntnis der Gesprächsinhalte Hinweise auf Whistleblower geben. Die rechtliche Bindung der Verarbeitung der erhobenen Daten an die Zwecke des IfSG dürfte als Schutzmaßnahme nicht ausreichen, wenn es um Recherchen von Journalisten über die Gesundheitsverwaltung geht. Auch die Reporter ohne Grenzen betonen im Kontext von Apps zur Verfolgung von Corona-Kontakten die Bedeutung der Anonymität für den Quellenschutz [40].

Denkbare freiwillige Optionen
Auf freiwilliger Basis könnte man jedoch erwägen, die App um optionale Funktionen zu ergänzen wie ein (dezentrales) Tracking von GPS-Daten oder gar die (dezentrale) Speicherung der Mobiltelefonnummer von Kontakten. Wobei für das Tracking der GPS-Daten die Zustimmung beider Kontaktpartner erforderlich sein sollte, während für die Speicherung der Telefonnummer folgende Abfrage durchgeführt werden könnte:

1. Meine Mobiltelefonnummer darf von der App meiner Kontakte gespeichert wer-den:
   ( ) Ja        ( ) Nein
2. Die Mobiltelefonnummer meiner Kontakte wird bei deren Einverständnis von mei-ner App gespeichert
   ( ) Ja        ( ) Nein

Nur wenn ein Ja bei Option 1 der einen an dem Kontakt beteiligten Person (Nutzer A) auf ein Ja bei Option 2 der anderen am Kontakt beteiligten Person (Nutzer B) trifft, findet ein Tracking auf dem Smartphone von Nutzer B statt und könnte bei deren (per TAN) bestätigter Infektion zur Offenlegung der Mobilfunknummer von Nutzer A an Nutzer B oder (besser) das für Nutzer B zuständige Gesundheitsamt führen.

Wichtig wäre, dass diese Zusatzfunktionalitäten wie die App an sich freiwillig und auch nicht an den Einsatz der App an sich gekoppelt wären, letztere also auch ohne die Zusatzfunktionen als weitestgehend anonymes Kontakt-Nachverfolgungssystem eingesetzt werden kann. Die Standardeinstellung (Default) sollte für alle Zusatzfunktionen „Nein“ sein, d.h. ohne eine aktive Umstellung auf „Ja“ durch den Nutzer blieben die Zusatzfunktionen deaktiviert. Freilich müssten bezüglich der zusätzlich erfassten Daten alle übrigen Voraus-setzungen der DSGVO erfüllt sein, wie insbesondere die Bindung an den Zweck des Infek-tionsschutzes im Rahmen der aktuellen Corona-Pandemie.

In eine ähnliche Richtung geht auch die jüngst von der Bundesregierung als optionale, aber integrale Ergänzung der (dezentralen) Tracing-App vorgesehene pseudonyme „Datenspende“ an das RKI [30]. Diese soll allerdings nicht der individuellen Kontaktverfolgung, sondern der epidemiologischen Forschung und Qualitätssicherung dienen und wird wohl eher Angaben wie Kontaktdauer, Nähe oder räumliches Umfeld umfassen. Dabei sollten allerdings die Kritik aufgenommen werden, die sich an der Ausgestaltung der bereits freigegebenen separaten Datenspende-App des RKI entzündete, wie bspw. ein unzureichender Schutz der Zugangsdaten, eine möglicherweise mangelhafte Pseudonymisierung sowie eine unklar formulierte Einwilligung [41].

Fazit: Sorgfältige Implementierung des dezentralen Modells
Wie allgemein im Hinblick auf die Corona-Pandemie, so gilt auch für den Datenschutz in diesem Kontext: Keine Panik verbreiten, aber Risiken offen benennen, realistisch einschät-zen und – in transparenter Abwägung mit anderen Schutzgütern – möglichst begrenzen. Im Hinblick auf die geplante Corona-Tracing-App sind der Bundesregierung und dem PEPP-PT-Verbund um HHI und RKI bei diesem „Risikomanagement“ Fehler unterlaufen. Mögliche epidemiologische Zielsetzungen über die Kontaktverfolgung hinaus wurde lange Zeit nicht öffentlich benannt, geschweige denn erläutert und konnten daher auch nicht vorausschauend in eine Abwägung durch Fachöffentlichkeit und Zivilgesellschaft eingehen.

Ob diese umfassendere Abwägung das PEPP-PT-Modell mit dem Abgleich der Kontaktkennungen und der Bestimmung des Risikos dieser anonymen oder zumindest pseudonymen Kontakte auf dem zentralen Server hätte rechtfertigen können, kann daher offenbleiben. Der Druck der Fachöffentlichkeit, die damit zusammenhängende Sorge um mangelnde Akzeptanz in der Bevölkerung sowie die Restriktionen vor allem des iOS-Betriebssystems von Apple haben die Bundesregierung letztlich auf den Kurs zu einer dezentralen Lösung gebracht.

Diese sollte nun möglichst schnell, aber mit der gebotenen Sorgfalt entwickelt werden. Optionale Erweiterung können angedacht werden, sollten derzeit aber nicht im Vordergrund stehen. Letztlich geht Sorgfalt hier auch bei der Kernfunktionalität vor Schnelligkeit. Eine App mit schweren Fehlern könnte selbst das dezentrale System vor größere Akzeptanzprobleme stellen. Das Coronavirus wird uns so schnell nicht davonlaufen. So wichtig eine Lockerung der Kontaktrestriktionen für das soziale und wirtschaftliche Miteinander auch sein mag – nur eine wirklich zuverlässige Kontaktverfolgungs-App wird einen nachhaltigen Beitrag dazu leisten können. Ob deren Einführung nun ein paar Wochen früher oder später erfolgt, sollte nicht ausschlaggebend sein.

Autor
Dr. Uwe K. Schneider
Fachanwalt für Medizin- und IT-Recht
Vogel & Partner Rechtsanwälte mbB
Kontakt: us(at)vogel-partner.eu

Der Autor dankt Herrn Dipl.-Wirtsch.-Ing. Christian Knupper für seine Unterstützung bei diesem Artikel, insbesondere für die Erstellung der Grafiken.