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. Thomas sagt:

    Bei dem Party-Beispiel mit der dez. App müssten doch dann eigentlich ca. 33 Menschen informiert werden, statt nur 9, oder? Also, wenn man von 30% Installationsrate unter den Besuchern der Party ausgeht und vermutlich werden alle 100 anwesenden Menschen dem Erkrankten nah genug gekommen sein. Darunter ist dann evtl. genau ein Drittel der angesteckten. Oder hab ich hier einen statischen Denkfehler?
    Bin ich beim Lesen drüber gestolpert, ändert ja aber nichts an der Aussage. Danke für den Artikel. Hab die Diskussion bisher eher gemeidet, aber du fasst das hier sehr ansprechend zusammen :)

    • mspro sagt:

      9 Leute sind 30% der 30 Angesteckten. Wenn man, wie du davon ausgeht, dass alle der 100 von App als Kontakte registriert wurden (was ich für unwahrscheinlich aber nicht ausgeschlossen halte) würden halt noch 21 weitere Leute als Kontakte alarmiert, die sich als Falschpositive herausstellen.

      • Thomas sagt:

        100 Partybesucher – 30 davon haben die App – 10 (also 9 + Superspreader) sind infiziert. Also ja, 21 mehr Benachrichtigungen. Ja, das meinte ich.

        Schönes anschauliches Beispiel.

  2. Fabio sagt:

    Ich verstehe das Beispiel nicht wirklich. Wenn ich die App nutze und ich mich an der Party «richtig» bewege, dann erhalte ich entweder mehrere Treffer an einem bestimmten Zeitpunkt (dezentral) oder ich werde von der Behörde über ein Superspreading-Event informiert. Bei beiden Fällen weiss ich, dass ich zuhause bleiben sollte.

    Wenn ich die App nicht nutze, werde ich mit geringer Wahrscheinlichkeit von einem Kollegen*in (dezentral oder zentral) oder von der Behörde über den Event informiert (zentral). Ich denke nicht, dass ich auf Social Media des Clubs lesen werde: Am 6. Juni Superspread-Event! Bleiben Sie zuhause!

    Übersehe ich Vorteile?

    • mspro sagt:

      Dein Fehler ist, das aus einer individuellen Perspektive zu betrachten. Bei der Pandemiebekämpfung geht es aber nicht um dich. Dass du als App-Benutzer in Quarantäne gehst ist schön, aber wenn 21 andere Leute, die sich infiziert haben, es nicht tun, reicht aus, um die Pandemie anzuheizen. Man muss also den gesamten Cluster isolieren.

  3. Mtt sagt:

    Kann nicht auch die dezentrale App zur Clustererkennung genutzt werden? Wenn jemand positiv getestest wurde: Historie des Telefons nach einem relevanten Zeitpunkt durchsuchen, an dem es gleichzeitig relativ viele Kontakte hatte. Dann die Person fragen, welches Clusterevent das war.

    Auch der zentrale Ansatz bietet nicht zwingend eine zielführende Clustererkennung. Wenn auf dem zentralen Server die Personen nicht bekannt sind, können diese nicht befragt werden, um welches Clusterevent es sich gehandelt hat. Wenn die Personen nicht bekannt sind, müssten also Bewegungsprofile zentral gespeichert werden, um Ort und Zeitpunkt des Events festzustellen.

    PS: Sind es wirklich Sicherheitsgründe, die unter ios die Unterstützung von Apple nötig machen? Ist es nicht eher so, dass Apps einfach nicht im Hintergrund laufen können und somit nicht senden/empfangen können?

    • mspro sagt:

      Hinterher kann man immer alles rausbekommen. Auch einfach durch Befragung der Erkrankten. So passiert das ja auch schon und ist, so weit ich beurteilen kann, auch recht effektiv. Wahrscheinlich braucht es daher die zentrale App auch gar nicht, weil Clustererkennung fast genau so gut und effektiv durch manuelles Contact Tracing geleistet wird.

      Der Zentrale Ansatz würde hier nur einen gewissen Zeitvorteil bringen, weil, man direkt Auf die Telefone einen Clusteralarm senden kann, mit der Anordnung sich sofort beim Gesundheitsamt zu melden.

      Zum PS: Ja, es sind Sicherheitsgründe. Apple erlaubt Apps sogar über BTLE auch im Hintergrund zu lauschen, aber aus Sicherheitsgründen nur auf vorher festgelegte Beacons. Die Tracing App verwendet aber aus Datenschutzgründen Randombeacons.

      • Mtt sagt:

        Der Zentrale Ansatz würde hier nur einen gewissen Zeitvorteil bringen, weil, man direkt Auf die Telefone einen Clusteralarm senden kann, mit der Anordnung sich sofort beim Gesundheitsamt zu melden.

        Würde man bei diesem Ansatz bereits eine Warnung verschicken, wenn noch gar kein Anhaltspunkt für eine Infektion vorliegt (also niemand Symptome hat, sondern nur eine Menschenansammlung vorhanden war)?

        Wenn ja: Würde dies doch vermutlich durch einen Algorithmus erfolgen, der die Erkennung eines potenziellen Clusters automatisch durchführt. Diesen Algorithmus könnte man doch auch in der lokalen dezentralen App auf dem Telefon ausführen. Unabhängig vom Ansatz, wie würde man potenzielle Cluster erkennen und welche Daten bräuchte man dafür? Einfach nur die Anzahl der Personen an einem Ort zu zählen, erscheint mir nicht ausreichend zu sein.

        Wenn nein: Gewonnen hätte man doch nur die Zeitspanne zwischen dem Zeitpunkt, an dem das Lobor den positiven Test im „Corona-IT-System“ erfasst und dem Zeitpunkt der Freigabe auf dem Mobiltelefon der betroffenen Person. Die App könnte während der Freigabe prüfen, ob ein Cluster vorhanden war und eine entsprechende Clusterwarnung verschicken.

        Oder sitze ich hier grundlegend auf dem Schlauch?

  4. kasimon sagt:

    Die App und manuelles Contact Tracing direkt zu vergleichen ist glaube ich der zentrale Fehler deiner Argumentation. Contact Tracing ist ein massiver Eingriff in die Privatsphäre, der nur zu rechtfertigen ist, wenn es einen direkten Bezug zu einer nachgewiesenen Infektion gibt. Was eine App, wie du sie dir vorstellst, machen würde wäre Vorrats-Contact-Tracing für alle, die die App installiert haben. Und das wäre allerhöchstens dann zu rechtfertigen, wenn es das einzige Mittel wäre, um diese Pandemie in den Griff zu bekommen. Das ist es aber glücklicherweise nicht, wie wir sehen können wir auch mit den anderen Maßnahmen die Fallzahlen senken, und da kann man dann überlegen, wie eine App sonst noch helfen kann. Und das ist bei Kontakten, an die man sich vielleicht gar nicht erinnert, weil man z.B. im öffentlichen Raum unterwegs war und nicht genau darauf geachtet hat, wer sich um einen herum befunden hat. Dafür ist die App im Gegensatz zum Contact Tracing aber prinzipiell blind bei allen, die gar kein Smartphone haben (können), wie kleinere Kinder oder ältere Senioren. Da würde auch eine Installationsrate von 100% nichts helfen.

  5. Mtt sagt:

    Ein Cluster ist ein Bereich in einem Netzwerk, der enger vernetzt ist, als der Rest.

    Auch dezentrale Apps dürften das erkennen können: Wenn ich lokal Codes und Uhrzeit speichere, kann meine App erkennen, ob meine App zusammen mit dem „infizierten Code“ in einem Cluster war, weil zum selben Zeitpunkt viele andere Codes gesammelt wurden.

    Unabhängig davon: Vermutlich wollen wir bei einem Clusterevent nicht darauf warten, dass mehrere positive Testergebnisse eingehen (insb. wenn die Appdurchdringung suboptimal ist). Wir wollen wahrscheinlich schon warnen, wenn ein positiver Test im Cluster auftaucht.

    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.

    Zunächst müsste man untersuchen, ob das überhaupt ein relevanter Sonderfall ist. Vereinfacht stellt sich die Frage, ob die Reichweite des Virus die BTLE-Reichweite übersteigt. Wenn ja: Evtl. könnte man dieses Problem zumindest etwas beheben, indem man bei positivem Test nicht die eigenen Codes veröffentlicht sondern die empfangenen. Meine App könnte dann prüfen, ob irgendeiner dieser Codes auch in meiner eigenen Historie vorhanden ist. Zumindest bei Events, bei denen die Teilnehmenden nicht starr an einem Ort verharren, dürfte sich damit schon sehr viel gewonnen sein, weil die Wahrscheinlichkeit einer Schnittmenge steigt.

    • mspro sagt:

      Das Telefon mag zwar erkennen, dass es zu dem Zeitpunkt der Infektion „unter Leuten“ war, aber erstens hat es nur einen sehr unvollständigen Ausschnitt des Clusters und es ist halt auf dem Telefon. Das RKI weiß dann immer noch nix.

      Dass Abstandsmessungen innerhalb von geschlossenen Räumen obsolet sind, dürfte mittlerweile als gesichert gelten. (Das ist auch ein valider Kritikpunkt an der App, den ich hier der Übersicht halber komplett rausgelassen habe)

      • Mtt sagt:

        Ob der Ausschnitt groß genug ist, müsste man natürlich untersuchen. Ich würde mal unqualifiziert tippen: In der Regel dürfte er groß genug sein.

        Wenn das gilt, wäre noch die Frage, welche Informationen das RKI benötigt und ob diese im zentralen Modell vorhanden wären. Das RKI könnte von der dezentralen App z. B. in dem Moment benachrichtig werden, in dem die App die Codes nach positivem Test veröffentlicht (einfach ein zusätzlicher Upload, der besagt, dass das Telefon ein Clusterevent vermutet).

        Wenn man statt der eigenen Codes nach Infektion die fremden Codes inkl. Zeitpunkt des Empfangs hochlädt, könnte das RKI auch selbst auswerten. Das Bild würde sich dann auch mit Zunahme der Tests verbessern. Und wie bereits beschrieben, wäre die Abdeckung um einen Hop vergrößert, was die Warnung von indirekten Kontakten ermöglicht.

      • Mtt sagt:

        Was ggf. zusätzlich einführen sollten: VeranstalterInnen von öffentlichen „Clusterevents“ sollten ggf. auf der kompletten Veranstaltungsfläche eigene Veranstaltertoken aussenden, die von jeder/m Teilnehmenden empfangen werden. Dann könnte man im Fall der Fälle diese Veranstaltertoken als Clusterwarnung veröffentlichen. Diese Token hätte dann auch jede(r) Teilnehmende empfangen.

        Ggf. wäre es auch sinnvoll, dass die lokale App neben den empfangenen Token zusätzlich den Standort speichert. Wenn dann etwas auftritt, könnte dieser Standort ausgelesen werden. In schlimmen Fällen könnte man den Standort eines vermuteten Clusterevents dann auch veröffentlichen. Andere könnten diesen Standort inkl. Uhrzeit abrufen und wären ggf. gewarnt.

        • mspro sagt:

          DAS halte ich für eine super Idee. Ich finde, sogar alle Restaurants, Kneipen und Shoppingmalls sollten sowas betreiben. DANN wäre das wirklich effektiv, denn eine weitere Schwäche der App ist ja auch die Konzentration auf Entfernungen. Wir wissen ja aber, dass Entfernungen eine viel geringere Rolle spielt als gedacht. Wichtiger ist indoors und outdoors.

    • Sven Türpe sagt:

      Was dezentrale Apps theoretisch respektive praktisch können, sind zwei Paar Schuhe. Zwei eigentlich unabhängige Fragen fallen hier zusammen, nämlich (1) „Zentral oder dezentral?“, und (2) „Mit Gapples Exposure Notification Framework oder unabhängig davon?” Theoretisch ist jede Kombination denkbar, praktisch die bereitgestellte Plattform aus Entwicklersicht der sinnvollste Weg. Die Entscheidung für das Exposure Notification Framework impliziert die Architekturentscheidung. Darüber hinaus folgen aus dieser Entscheidung weitere Beschränkungen, die Teil des Frameworks und nicht der zugrundeliegenden Architektur sind. Insbesondere gibt das Framework nicht alle Daten über seine API an die App weiter.

  6. Ortwin Pinke sagt:

    Guter Artikel, danke dafür. Doch liegt da nicht ein Denkfehler vor? Zur Erkennung eines Clusterevents benötigt auch ein zentraler Ansatz mehr Informationen als eine anonyme ID. Nur mit entsprechenden Standortdaten ist eine solche Erkennung machbar. Zu denen kommen dann noch die Standardinfos bei der Übertragung vom Smartphone, womit dann sowohl die Anonymität gefährdet sein kann, als auch ein Tracing des einzelnen Smartphones, also ein Bewegungsprofil, möglich wäre.

  7. Sven Türpe sagt:

    Zu einem gewissen Grad war der Fehler der frühen Festlegung durchaus absehbar, zumindest auf der Metaebene. Unabhängig davon, ob sich die eigentliche Entscheidung als richtig oder falsch erweist, ist die Anforderungsanalyse verunglückt und hat dem technischen Datenschutz zu früh – schon mit den ersten Auftritten von DP-3T und PEPP-PT – zu hohe Priorität eingeräumt. Unter die Räder kamen zugunsten dieses Sekundärziels die Funktionalität und organisatorischen Integration, die Flexibilität hinsichtlich späterer Anpassungen an neue Erkenntnisse sowie die rechtliche und institutionelle Ausgestaltung des App-Einsatzes.

    Die anfangs in den Raum gestellten und nie korrigierten Prioritäten schlagen sich nun im Ergebnis nieder: Wichtigstes Entwicklungsziel war technischer Datenschutz auch über das durch Risikoanalysen zu rechtfertigende Maß hinaus. Deshalb haben wir jetzt eine Corona-Warn-App, die in erster Linie Daten schützt – und gesondert entwickelte Apps, um die Zettelwirtschaft zum Beispiel in Restaurants zu digitalisieren.

  8. David sagt:

    Es wäre übrigens (in Bezug auf deine Anforderungen) auch ein Hybrid möglich, bei dem die zunächst dezentralen Apps nach einer Exposure Notification Daten über andere im Umfeld der Exposition gesammelte Kontakte wahlweise manuell oder automatisch zurückfunken, um die Clusteridentifikation zu ermöglichen.

  9. bgp sagt:

    Ich habe deinen Blogpost heute Abend erneut gelesen. Man soll ja immer mit dem Positiven starten, ich finde es prinzipiell gut, dass du dich mit dem Thema beschäftigst und bis zu einem gewissen Grade auch gut, dass du deine Reichweite nutzt, um auf das Thema aufmerksam zu machen. Nun aber zu meinem Kritikpunkt. Der Artikel kommt zu spät und er verwirrt. Du hättest dich aktiv mit diesen Informationen schon lange in den Entwicklungsprozess der App einschalten können. Jetzt hier an dieser Stelle mit einem solch reißerischen Titel „Warum… ein Fehler war…“ aufzukreuzen… Das finde ich gelinde gesagt nicht so toll. Ich (persönlich) würde solch einen Artikel nicht posten bzw. ich würde ihn als Diskussionsanregung stehen lassen, oder ich würde ihn löschen.
    Aber ja… Jeder hat andere Ansprüche an seine Außenwirkung und eigentlich will ich dich nicht „persönlich ansprechen“ sondern dir deine Wirkung aufzeigen. Kommen wir zum Kern meines Kommentars. Der zentrale Ansatz war technisch nicht machbar. (Ich denke du kennst die Bluetooth Problematik, die im Vorfeld gelöst werden musste) Und das ist schon das Argument, dass deinen kompletten Post kaputt macht. Zentrale App wäre technisch nicht gegangen! Klar wäre es schön gewesen, weil dann XYZ… Aber sie wäre nicht gegangen!
    Was denkt nun aber ein Leser aus deinen Followern, der sich diesen Artikel durchliest? Ich habe heute Morgen irgendwann den Link gefunden, den Post überflogen und das Beispiel grob für plausibel gehalten. Wenn ich mir das heute Abend jetzt nicht nochmal angesehen hätte, dann hätte ich diesen falschen Stand gehabt… Das an meine Leute weitergegeben und das hätte der dezentralen App einen „Zacken aus der Krone“ gebrochen. Falls das deine Intention ist und du mit solchen „schwubbeligen“ Thesen in Verbindung gebracht werden willst, dann ist dir das wohl gelungen. Im Endeffekt wird aber jede „durch deinen schwubbelArtikel nicht installierte App“ aber Menschenleben gefährden. Und genau aus diesem Grund schreibe ich dir diese Zeilen hier und hoffe, dass du zumindest die reißerischen Überschriften etwas entschärfst, wenn nicht sogar den Artikel änderst / entfernst. MFG ein Dipl. Inf. und sonst sehr stiller Follower deiner Twitternachrichten.

    • mspro sagt:

      Dein Kommentar klingt ein bisschen so, als seist du in einer Glaubensmission unterwegs. Ich glaube, du überschätzt den Impact meines Artikels. Niemand wird sterben deswegen, da bin ich ganz sicher. ;)

      Zu deinen Argumenten: dass die zentrale App nicht machbar war, ist natürlich eine Definitionsfrage. Es gibt viele zentrale Apps da draußen (Frankreich, UK…) aber ich gebe dir recht, dass sie einen an Unbenutzbarkeit grenzende Einschränkung mitbringen, nämlich, dass sie auf iOS immer im Vordergrund laufen müssen. Mein Argument wäre aber, dass der Diskurs bereits vorher entgleist ist. Apple und Google konnten sich mit der dezentralen Variante ja nur deswegen durchsetzen, weil die IT-Crowd und Datenschutzaktivisten so früh auf den dezentralen Ansatz gepocht haben. Sonst wäre das vermutlich anders verlaufen.

      Was ich bemängele (übrigens auch damals schon öffentlich bemängelt habe), ist, dass es keine vernünftige Debatte gab. Das lag (wie ich im Artikel ja auch ausführe) vor allem auch an den Zentralisierungsbefürworter, die die Debatte quasi verweigerten. Ich finde es wichtig, aus solchen Fehlern zu lernen. Deswegen schrieb ich den Text. Ich habe daran nichts zurückzuziehen.

      • bgp sagt:

        I agree to disagree. Ich hätte auch nicht gedacht, dass du meinen Kommentar veröffentlichst. (Ein bisschen Respekt zolle ich dir dafür) Ansonsten… IMHO – Dein Artikel bleibt in vielerlei Hinsicht für mich einfach „falsch“. Die „Restaurant + Cluster“ Überlegung ist sogar berechtigt. Dies der App als Fehler anzukreiden aber nicht. Missionieren will ich dich nicht ;-) Ich konnte mir aber echt nicht vorstellen, dass du das alles ernst meinst. Deine Meinung darfst du haben… Und (meine) Toleranz beginnt genau hier.

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

Schreibe einen Kommentar zu David Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.