Warum die Festlegung auf die dezentrale Variante der Corona-Warn-App ein Fehler war

Nächste Woche soll die Corona-Warn-App herauskommen. Es gab die letzten Wochen viele Diskussionen über technische Hintergründe, vermeintlichen Gefahren für die Privatsphäre und den Sinn und Unsinn dieser App. Ich habe mich lange Zeit eher auf der Befürworterseite der App wiedergefunden. Nun sind aber Erkenntnisse über das Virus bekannt geworden, die die ganzen Dikussionen in einem neuen Licht erscheinen lassen. Ich bin mittlerweile überzeugt, dass insbesondere das Beharren auf dem dezentralen Ansatz ein entscheidender Fehler war, der das ganze Unterfangen jetzt nahezu sinnlos gemacht hat. Aber von vorn.

Kontaktverfolgung

Contact Tracing – oder Kontaktverfolgung – ist grundsätzlich erstmal eine sehr sinnvolle und effektive Maßnahme zur Pandemiebekämpfung. Dabei wird die Kontakthistorie von erkrankten Menschen erfragt und diese Kontakte werden dann ihrerseits gebeten sich zu isolieren. Es geht darum, Infektionsketten zu durchbrechen, also dafür zu sorgen, dass Leute, die in Gefahr sind, sich angesteckt zu haben, ihrerseits niemanden mehr anstecken. Gerade bei Covid19, bei dem Ansteckungen oft symptomfrei passieren, ist ein solches Vorgehen besonders wichtig.

In der Praxis geschieht das erstmal manuell, mit speziell geschultem Personal. Sie interviewen die kranke Person und sie telefonieren hinter den Kontakten hinterher. Diese Praxis hat mehrere Probleme: 1. Sie ist sehr personalaufwändig, die Gesundheitsämter mussten dafür bereits sehr viele zusätzliche Leute anstellen. 2. Die Methode ist ist lückenhaft. Man erinnert sich vielleicht noch an jeden einzelnen Kollegen und jedes Familienmitglied mit dem man interagiert hat, aber nicht, neben wem man eine viertel Stunde in der Bahn gesessen hat. 3. Die Methode ist sehr zeitaufwändig. Das ist wahrscheinlich das größte Problem, denn Zeit ist hier der kritische Faktor. Jede zusätzliche Stunde, die ein potentiell Angesteckter nicht gewarnt wird, bedeutet, dass er oder sie weitere Personen anstecken kann.

Auf alle drei dieser Probleme scheint die Corona-Warn-App die Lösung zu sein. Statt, dass sich die Leute selbst merken, mit wem sie wann in Kontakt standen, merkt sich einfach das Telefon, welche anderen Telefone es in der Nähe gesehen hat. „Gesehen“ meint hier, Identifikationscodes anderer Telefone per Bluetooth LE empfangen zu haben. Die Technologie erlaubt sogar eine Abstandsmessung mit einer gewissen Präzision.

Schon im März kam man auf den Gedanken, dass eine solche Methode relativ datenschutzfreundlich umsetzbar ist. Durch Bluetooth kann man getrost auf jede Lokalisierung verzichten. Es geht schließlich nicht um Orte, sondern um relative Entfernungen der Personen zueinander. Obendrein haben findige Sicherheitsforscher ein Konzept entwickelt, wie der Austausch der Identifikationscodes komplett anonymisierbar ist. Es wurde schnell eine europäische Initiative aus Wissenschaftlerinnen, NGOs und Unternehmen gegründet: PEPP-PT (Pan European Privacy Preserving – Proximity Tracing). Es wurde vieles richtig gemacht: Es wurde früh eine breite Debatte angestoßen und es wurden viele zivilgesellschaftliche Akteure und Spezialistinnen eingebunden.

Der Streit

Eine Frage aber schien die Initiative schon früh zu spalten: Nämlich, ob die App zentral oder dezentral funktionieren soll. Zentral würde bedeuten, dass die Daten von den Telefonen gesammelt, aber gleich an einen zentralen Server weitergesendet werden, der dann die Auswertung der Kontakte unternimmt und die Warnungen verschickt. Dezentral bedeutet, dass die Daten vorerst auf den Telefonen bleiben und dort ausgewertet werden. Nur im Infektionsfall würden Daten zentral verarbeitet und an alle Telefone weitergeleitet werden, die dann anhand der jeweilig lokalen Kontakthistorien überprüfen können, ob sie mit dem Identifikationscode des Erkrankten in Berührung gekommen sind.

Die Verfechter der dezentralen Lösung legten als erste eine eigene Spezifikation genau für diese Methodik vor: DP-3T (Decentralized Privacy-Preserving Proximity Tracing). Sie hatten alle Argumente auf ihrer Seite: Eine Zusammenführung der Daten auf dem zentralen Server war schlicht nicht notwendig und aus Datenschutzsicht sogar potentiell gefährlich. Statt die zentrale Variante aber argumentativ zu verteidigen, entschied man sich bei PEPP-PT, DP-3T kommentarlos aus der Initiative zu werfen und ansonsten die Bundesregierung um Unterstützung zu ersuchen. Die stellte sich zwar daraufhin auf Seiten der zentralen Lösung von PEPP-PT, doch das brachte wenig.

Am Ende entschieden nämlich Apple und Google über die Umsetzung. Vor allem die Zusammenarbeit mit Apple war für die Umsetzung egal welcher Lösung absolut notwendig, weil sie aus Sicherheitsgründen den Zugriff auf das Bluetooth ihrer Geräte begrenzen. Apple und Google favorisierten ganz klar die dezentrale Lösung und setzten sie auch noch in Windeseile in Form einer API auf Betriebssystemebene um. Deutschland und Frankreich versuchten das Ganze noch ansatzweise zu eskalieren, um die zentrale Variante doch noch möglich zu machen, doch all das aber brachte nichts. Zumindest Deutschland lenkte bald ein. PEPP-PT verlor.

Das was nun nächste Woche veröffentlicht wird, ist also die dezentrale Variante der App. Ein Sieg der Datenschützer*innen und von Apple und Google.1 Doch es ist ein Pyrrhussieg, denn die grundlegende Designentscheidung, sich auf Dezentralität festzulegen, wird der App nun zum Verhängnis.

Der Paradigmenwechsel

Über die Effektivität der App wird bereits seit langem gestritten. Zwei wesentliche Punkte tauchen dabei immer wieder auf: Zum einen gibt es die Sorge, dass die App in erster Linie Falschpositive Ergebnisse produzieren wird, also Warnungen, die aufgrund von Messfehlern oder falschen Einschätzungen von Kontaktereignissen entstanden sind und die Leute nur verwirren. Zum Anderen und entscheidender: Es braucht es eine enorm hohe Installationsrate, damit die App wirklich effektiv sein kann. (Edit: allerdings bringt auch ein bisschen auch schon was2) Bei 70% Installationsrate würden überhaupt nur 50% der Kontakte registriert. Doch 70% sind ansich schon völlig illusorisch. Selbst die erfolgreichsten Apps überhaupt schaffen gerade mal 60% Abdeckung. Die meistgenutzte Contacttracing-App gibt es auf Island und sie schafft gerade mal 40%. Immer noch ein Traumwert. Wenn wir in Deutschland auf 20% kämen, wäre das bereits ein enormer Erfolg. Ich persönlich fand allerdings keines dieser Argumente so stark, dass es den Versuch nicht wenigstens Wert gemacht hätte.

Meine Meinung änderte sich erst mit dem Auftreten neuer Erkenntnisse zum Virus selbst. Wir wissen zwar schon lange, dass die Reproduktionzahl (R0) des Virus zwischen 2 und 3 liegt (ein Kranker steckt im Normalfall und im Schnitt 2 bis 3 Leute an), wir wussten aber wenig, wie sich diese Ansteckungen verteilen. Bisher sind wir implizit davon ausgegangen, dass sich die Ansteckungen statistisch zufällig verteilen, dass also der eine mal eine Person, die andere vier, die nächste wieder zwei, auch mal jemand niemand und so weiter ansteckt. So ist das zum Beispiel bei der Grippe, mit der wir die meiste Erfahrung haben. Wir wissen aber heute aus mehreren Studien, dass SARS2 – ähnlich wie sein naher Verwandter SARS – eine sehr hohe Dispersion hat. Eine hohe Dispersion heißt, dass die allermeisten Kranken kaum irgendwelche Leute anstecken, aber ein sehr geringer Teil der Kranken gleich sehr viele Leute anstecken. Die sogenannten Superspreader. Wie hoch die Dispersion genau ist, ist noch strittig. Nicht strittig ist jedoch, dass dieses Ungleichgewicht existiert und dass es vergleichsweise hoch ist.3

Was bedeutet das für die Corona-Warn-App? Es bedeutet eine grundlegende Verschiebung der Aufgabenstellung beim Contact Tracing. Kurz: das Verfolgen von Einzelkontakten wird weniger wichtig, das Aufspüren von Clustern rückt ins Zentrum. Der Reihe nach:

Erstens: der Einzelkontakt wird weniger wichtig, weil die Wahrscheinlichkeit der Ansteckung bei Einzelkontakten sinkt. Bei einer normalverteilten Dispersion würde sich die Ansteckungswahrscheinlichkeit auf alle Einzelkontakte gleichmäßig verteilen. Da wir jetzt aber wissen, dass sich ein Großteil der Gesamtwahrscheinlichkeit der Ansteckung auf Superspreading-Events konzentriert, verteilt sich nur noch wenig Restwahrscheinlichkeit für Ansteckungen auf die Einzelkontaktereignisse. Anders: Die Chance, dass ich mich bei dem Typen, der neben mir in der Ubahn gesessen hat, anstecke, ist geringer als wir dachten. Mich davor zu warnen, ist deswegen zwar nicht völlig sinnlos, aber wesentlich wirkungsloser, als wenn wir es mit einer Normalverteilung des Ansteckungsgeschehens zu tun hätten.

Was dagegen jetzt ins Zentrum rückt, sind damit die Superspreading-Events, denn sie haben offensichtlich eine entscheidende Bedeutung für das Ansteckungsgeschehen. Wenn wir jemanden als krank identifizieren, ist es sehr wahrscheinlich, dass diese Person sich in einem Cluster angesteckt hat. Die Priorität verschiebt sich jetzt dahin, das eventuelle Cluster, in dem sich der Patient angesteckt hat, zu identifizieren und alle Menschen des Clusters zu isolieren. Die manuellen Contact Tracer der Gesundheitsbehörden können ein solches „Clusterbusting“ leisten und tun das auch bereits. Doch die Corona-Warn-App kann das nicht. Und zwar grundsätzlich nicht, wegen ihres dezentralen Designs.

Das dezentrale Design eignet sich nur und ausschließlich, um Einzelkontakthistorien zu sammeln und zu analysieren. Wenn es aber darum geht, herauszufinden, wo und unter welchen Umständen man sich angesteckt hat, zu überprüfen, ob es sich dabei um einen Cluster handeln könnte und alle weiteren Leute, die sich in diesem Cluster aufhielten zu warnen, dann ist das mit der dezentralen Variante schlicht nicht umsetzbar.

Rechnen wir uns einen konkreten Fall mal durch: Bei einer Party mit 100 Leuten steckt ein infizierter Gast 30 andere Gäste an. Um die Wirkung der App auf dieses Ereignis zu beurteilen, müssen wir zunächst eine grundlegende Unterscheidung machen: in Fall 1 nutzt der Kranke die App, in Fall 2 nutzt der Kranke die App nicht. Fall 1 ist genau so wahrscheinlich, wie hoch die allgemeine Installationssrate der App ist. Bei 30% Installationsrate (was enorm hoch gegriffen ist), wäre die Chance eben 30%, dass Ansteckungsereignisse überhaupt registriert werden. Die Chance, dass es gar nichts registriert wird liegt also bei phänomenalen 70%. Von den anderen Gästen haben aber auch wiederum nur 30% die App installiert. Also selbst für dem unwahrscheinlich glücklichen Fall, dass der Krankte die App hatte, würden nur 9 der 30 angesteckten gewarnt und könnten sich isolieren.

Und wie ist mit den sekundären Fällen, also die 30 Leute, die sich dort angesteckt haben? Die werden ja vielleicht auch getestet und hatten unter Umständen eine App. Zwar ist es möglich, in ihrer Kontakthistorie entsprechend weit zurückzugehen und alle Leute auf der Party zu warnen, die sich länger mit ihnen unterhalten haben. Aber das bringt genau nichts, weil sie ja zu dem Zeitpunkt gar nicht ansteckend waren. Würden in diesem Fall tatsächlich Leute gewarnt, die sich angesteckt haben, wäre das reiner Zufall. Wie man es dreht und wendet, die dezentrale App ist zum Clusterbusting weitestgehend nutzlos.

Der Zentrale Ansatz hätte es gebracht

Mit der zentralen Variante wäre das Clusterbusting dagegen sogar ziemlich leicht umsetzbar. Würden alle Kontaktgeschehnisse auf einem zentralen Server zusammengeführt, wären solche Cluster-Ereignisse recht leicht und automatisch erkennbar. Es müssten sogar nur vergleichsweise wenige Leute die App nutzen, damit der Verdacht eines Clusters aufscheinen kann.

Rechnen wir das nochmal durch. Bei 30% Installationsrate würden neun der 30 auf der Party infizierten in der Datenbank zusammen als Cluster aufleuchten. Das Signal wäre eindeutig, das RKI und oder die Gesundheitsbehörden könnten entsprechend handeln, den Cluster aufspüren und alle Personen isolieren. Sogar bei nur 10% Installationsrate würden drei Ereignisse in einem vernetzten Zusammenhang auftauchen, was zumindest für einen Verdacht auf einen Cluster völlig ausreicht. Mit anderen Worten: Die zentrale App wäre sogar bei vergleichsweise geringer Nutzung sehr nützlich, um Cluster aufzuspüren.

[EDIT: Es scheinen sich an dieser Stelle einige Mißverständnisse zu ergeben, die es nötig machen, hier noch mal sehr viel weiter ins Detail zu gehen: konzeptionell unterscheiden sich zentrale und dezentrale App zunächst erstmal gar nicht so sehr, insbesondere in Fall 1, also wenn der Erkrankte die App hat. Es werden egal ob zentral oder dezentral 9 Menschen benachrichtigt (und wohl noch ein paar mehr Falsepositives). Auch bei Fall 2 scheint es erstmal ganz ähnlich zu laufen. 30 Leute haben sich sekundär angesteckt, davon werden ein paar symptomatisch, einige davon lassen sich testen, von denen haben einige die App und werden jeweils einige der Leute auf der Party benachrichtigen (jedenfalls, wenn die App so eingestellt ist, dass sie zeitlich weit genug zurückgeht).

Der Unterschied liegt aber in dem, was serverseitig passiert. Bei der dezentralen App kommen nach den Tests nur die Identifikationscodes der Erkrankten an, die dann an die Telefone weitergereicht werden. Die Identifikationscodes sagen aber nichts über Kontaktereignisse aus. Der Server bleibt in der Hinsicht dumm. Nur die Telefone können jeweils lokal abgleichen, ob die Identifikationscodes zu Kontakteignissen passen.

In der zentralen App werden dagegen nicht nur die Identifikationscodes der Erkrankten gesammelt, sondern alle Identifikationscodes. Auf dem Server wird dann überprüft, ob Kontakte stattgefunden haben. So entsteht ein Gesamtgraph aller Kontaktereignisse, egal ob hier Infektionen stattgefunden haben oder nicht. Das heißt, wenn die Sekundärerkrankten ihre Testergebnisse bekommen, ist auf dem Server automatisch nachvollziehbar, dass

  1. die Erkrankten eine gemeinsame Kontakthistorie hatten und wann das der Fall war. Mit anderen Worten: Das Cluster wird erkannt. Ein Cluster ist ein Bereich in einem Netzwerk, der enger vernetzt ist, als der Rest. Das Cluster ist serverseitig schon vorher als solches sichtbar, mit den Testergebnissen wird aber klar, dass dort mehre Ansteckungen passierten. Alarm.
  2. innerhalb des Cluster lassen sich dann alle Personen mit App identifizieren, die ebenfalls beim Ereignis dabei waren, unabhängig davon, ob sie eine primäre Kontakthistorie mit den Getesteten hatten. Das heißt, auch die Cousine, die auf der Party war, aber gar nicht mit einem Erkrankten interagiert hat, kann dem Cluster zugerechnet werden.
  3. Das heißt: Alle diese Clusterkontakte können nun auch benachrichtigt werden, nicht nur die Primärkontakte der Erkrankten.
  4. Sie können zudem anders kontaktiert werden. Mit höherer Dringlichkeit und mit der Bitte, sich sofort zu melden, alle Leute, die auch auf dem Event waren, zu benachrichtigen (auch die ohne App) und sich einer behördlichen Quarantäneanordnung zu unterziehen.

All das ginge mit der dezentralen App halt nicht, weil weder das Wissen um das Cluster an irgendeiner Stelle existiert, noch die Möglichkeit das Cluster direkt als solches zu adressieren. Das Gesundheitsamt würde dann wahrscheinlich im Nachhinein bei der Befragung trotzdem drauf kommen, dass es ein Cluster ist, würde sich die entsprechenden Kontakte erfragen und würde entsprechende Maßnahmen treffen. Das ist dann aber alles wieder manuell und zeitlich und personell aufwändig. Mit der zentralen App ginge das im Nu.]

Fazit

Das frühe Festlegen auf die Dezentralität war ein Fehler. Ein Fehler, den man vorher nicht absehen konnte. Ich selbst habe den dezentralen Ansatz favorisiert mit der einfachen Überlegung, dass ein etwas datengeschützterer Ansatz vielleicht zu einer höheren Akzeptanz führen würde. (Was sich angesichts der tatsächlich stattfindenden Debatte ebenfalls als fraglich herausgestellt hat.)

Es ist hier niemanden ein Vorwurf zu machen. So ist das mit Entscheidungen unter unsicherer Informationslage. Die Chance, das man falsch liegt, ist da nun mal hoch und die dezentrale App schien wie eine gute Idee.

Ok, vielleicht ist doch jemandem ein Vorwurf zu machen. PEPP-PT hätte solche Eventualitäten als Argumente in ihrem öffentlichen Auftreten nutzen können. Sie hätten den „Case“ für die zentrale Lösung sehr viel überzeugender machen können. Stattdessen hat man sich eingemauert und geglaubt mit der Macht der Regierung die eigenen Vorstellungen durchdrücken zu können. Das ging vorhersehbar schief. Schade, das war eine verpasste Chance.

Ich bin aber deswegen aber nicht besorgt oder traurig. Ein weiterer Effekt der Überdispersion ist nämlich, dass wir Covid19 wahrscheinlich auch ganz prima ohne App in den Griff bekommen. So lange wir Superspreading-Events weiterhin vergleichsweise unwahrscheinlich machen und nebenher auf Gesundheitsamtsebene wachsam das Infektionsgeschehen im Blick behalten, ist die Gefahr gering, dass uns die Krankheit noch mal außer Kontrolle gerät.

EDIT: Mtt hat in den Kommentaren auf eine Möglichkeit hingewiesen, wie sich das Problem lösen ließe.

Das würde nicht nur den zentralen Ansatz dazu befähigen, Cluster erkennbar zu machen (Alle, die zu der Zeit diese Innenraum-Id empfangen haben gehören zum Cluster), sondern würde auch ein zweites grundlegendes Problem der App lösen (das ich aus Übersichtsgründen hier nicht mitbehandelt habe). Nämlich die Fokussierung auf Entfernungen. Wir wissen heute, dass Entfernungen fast immer egal sind. Sie sind draußen egal, weil draußen kaum Ansteckungsereignisse passieren. Sie sind aber auch drinnen egal, weil ein Großteil der Ansteckungen durch Aerosole passieren, denen Entfernung mehr oder weniger egal ist. Es braucht also eigentlich eine App, die versteht, wann und mit wem man sich in Innenräumen aufhält und wie lange.

Der genannte Ansatz würde das möglich machen. Sobald die App eine Innenraum-Id empfängt, würde sie alle IDs im Raum aufsammeln – Entfernungen sind dabei egal. Wenn jemand nun positiv testet, würde er nicht nur seine eignen Ids, sondern auch alle Innenraum-Ids mit auf den Server senden. Alle leute des Clusters werden dann gewarnt.

Die Innenraum-IDs wären am besten von normalen IDs unterscheidbar, so dass auch der Server (also das RKI) von dem Cluster sofort unterrichtet wird. (Mehrere positive Testergebnisse mit der Innenraum-ID zu einem gemeinsamen Zeitpunkt sind ein Superspreading-Event.) Innenraum-Ids wären zudem nicht-anonym (Restaurants haben keine Persönlichkeitsrechte), so dass die Behörden auch erfahren, welcher Ort betroffen ist.

Meines Erachtens wäre das eine um ein vielfaches effektivere App und sogar der Datenschutz wäre damit wenig bis kaum angetastet.

Wie ich aber lese, sind solche Ansätze sogar vorgeschlagen worden. Mir ist völlig unverständlich, warum sie nicht umgesetzt wurden.

  1. Allein dazu gibt es noch eine Menge zu sagen, was ich hier getan habe, https://www.youtube.com/watch?v=kwQ6VIDVKQo&list=PLLpGyoDLvP2TH3Avi9d4Q0x31txQrO-gr&index=1
  2. Patrick Howell O’Neill: No, coronavirus apps don’t need 60% adoption to be effective, https://www.technologyreview.com/2020/06/05/1002775/covid-apps-effective-at-less-than-60-percent-download/
  3. Vgl. Lars Fischer: Wie Sars-CoV-2 in Deutschland aussterben kann, https://www.spektrum.de/news/wie-sars-cov-2-in-deutschland-aussterben-kann/1741310
Dieser Beitrag wurde unter Algorithmenkritik, Postprivacy, Queryology veröffentlicht. Setze ein Lesezeichen auf den Permalink.

23 Kommentare zu Warum die Festlegung auf die dezentrale Variante der Corona-Warn-App ein Fehler war

  1. Pingback: Eine neue Netzpolitik ist verfügbar? › Regierungsforschung

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.