Handreichung: Was an und rund um die CoronaWarnApp zu kritisieren ist
20% Fehlerquote (false positive + false negative)
- Berichterstattung
- Datenschutz, Open Source, Forschungsdaten
- Fehlerquote
- Kosten
- Onboarding und Usabilty
- Datensouveränität und -portabilität
Berichterstattung
„Ich kenne keine Parteien mehr, sonder nur noch App-Nutzer“. So ließe sich die Berichterstattung in vielen dt. Medien über die CoronaWarnApp zusammenfassen, die am 16. Juni 2020 startete und nunmehr einige Millionen mal heruntergeladen wurde. Das Eigenlob der Bundesregierung und der beteiligten Dax-Konzerne wurde meist eins zu eins unhinterfragt wiedergeben.
Etwa bei heise.de, das die lachhafte Formel „Alles ist Made in Germany“ des Telekom-Chefs für schlagzeilenwürdig hielt. Hier wäre der Redaktion empfohlen sich die Methode des „Truth Sandwichs“ anzueignen, um die journalistische Einordnung für solch Falschaussagen gleich mitzuliefern. Richtig wäre gewesen: “Obwohl die zugrundeliegende DP3T-Methodik ein internationales Forscherteam entwickelte, behauptet der Telekom-Chef über die App ‘Alles ist Made in Germany’. Doch die Technologie stammt maßgeblich aus USA und China.”
Über die hohe Fehlerquote, Intransparenz bei den enormen Kosten und die schlechte Nutzer*innenführung war bislang wenig zu vernehmen. Das gilt auch für den exklusiven Charakter der ganzen Veranstaltung. Dass die verwendete Technologie nur auf neueren Smartphones laufen wird, ist seit Monaten bekannt. Und dass wahrscheinlich so eher ältere Personen und wirtschaftlich schlecht gestellte Milieus von der Teilnahme ausgeschlossen werden, ist auch keine Überraschung.
Laut dem Journalismusforscher Uwe Krüger ist diese Art der affirmativen Berichterstattung allerdings typisch: “Ich beobachte aber, dass die Medien hierzulande im Prinzip immer ‘dafür’ sind. Denn auch außerhalb von Ausnahmezuständen wie der Corona-Krise ist es die Regel, dass der Journalismus in weiten Teilen eben nicht alles kritisch hinterfragt.”
Datenschutz, Open Source, Forschungsdaten
Viel Gejubel rief die Open Source-Entwicklung hervor. Dass diese auch durch zivilgesellschaftlichen Druck (und Apple und Google) erzwungenen worden war, wurde während der Selbstbeweihräucherung von der Regierung vergessen.
Der Hauptaugenmerk auf dem Datenschutzaspekt vernebelte dabei offenbar einigen digitalpolitischen Gruppen den Blick auf eine Reihe von Unzulänglichkeiten, die sehr wohl zu kritisieren sind. Ohne dabei die Sinnhaftigkeit des Tracings in Frage stellen zu müssen. Hinsichtlich der hierzulande eigentlich hohen Datenschutzsensiblität ist es bemerkenswert, dass eine Studie der TU Darmstadt über Mängel an der Tracing-Technologie von Google und Apple kaum Widerhall fand.
Zahlreiche Epidemiologen zeigten sich trotz hoher Arbeitsbelastungen in den letzten Monaten in der Lage, Pre-Print Studien ihrer laufenden Forschung zu veröffentlichen. Dies war den Dax-Konzernen und beteiligten (para-)staatlichen Einrichtungen (Fraunhofer, RKI) nicht möglich. Daten zu ihren Qualitätsmessungen der verwenden Bluetooth-Technologie fehlen bislang (siehe nächster Abschnitt). Bei den eingesetzten Geldmitteln kann das zumindest nicht an den Ressourcen gescheitert sein. Die Dokumentation des epideomiologischen Modells zur Berechnung des Risikobewertung liegt immerhin bei Github vor. Hier zeigt sich, dass in so einem Fall die Qualität von Open Source immer auch im Zusammenhang mit entsprechendem Open Data und Open Access bewertet werden sollte.
Fehlerquote
Die Fehlerquote ist der zentrale Faktor dafür, wie hilfreich die App als technisches Mittel zum Nachvollziehen von Infektionsketten ist. Doch wird ihr in der Berichterstattung wenig Aufmerksamkeit geschenkt. Dabei wäre alleine aus Glaubwürdigkeitsgründen der Bundesregierung angeraten, von selbst über die Grenzen der App zu berichten. Etwa sollten offen Szenarien wie dieses diskutiert werden: Wie wird damit umgegangen, wenn in einer möglichen 2. Welle durch die App plötzlich zehntausende falsch erfasste Kontakte Gesundheitsämter überlasten könnten?
20 Prozent Fehlerquote räumte der CTO von SAP ein. Diese sei auf der Basis zahlreicher Simulationen von Situationen mit verschiedenen Geräten (wievielen?) ermittelt worden. Kernstück der CoronaWarnApp ist die Funktechnologie Bluetooth-Low-Energy (BLE). Um auf diese überhaupt sinnvoll zugreifen zu können, gab es die Kooperation mit Apple (iOS) und Google (Android). Bei der verlässlichen Messung per BLE spielen etwa die Position des Smartphones am Körper bzw. in der Hand eine Rolle. Aber auch die Qualität der verbauten BLE-Module, die wohl auch innerhalb einer Baureihe voneinander abweichen kann.
Gemeint ist mit der Fehlerquote, wie oft bei einem „kritischen Kontakt“ (gemeinsamer Aufenthalt für 15 Minuten innerhalb eines 2 Meter Radius) fälschlicherweise ein Zustandekommen -false positive- in der App der Nutzer*in registriert wird . Oder wie oft ein eigentlich „kritischer Kontakt“ nicht registriert wird -false negative (siehe Grafik ganz oben).
Diese Fehlerquote genau einzuschätzen, bleibt ohne mehr über die Vorgehensweise bei den Messungen zu wissen, schwer möglich. Fraglich wäre etwa wie hoch ist der Schwankungsbereich. Also könnte beispielsweise ein signifikanter Teil der Kontaktmessungen sogar eine Fehlerquote von bis zu 50 Prozent aufweisen? Wir wissen es nicht (eine Veröffentlichung zur Messung wurde offenbar angekündigt). Es sind bislang nur unüberprüfbare Aussagen einer Quelle. Journalistische Stücke zur App sollten das deutlich machen.
Kosten
Nachdem vor einigen Tagen erst die Rede von 20 Millionen Euro Kosten war, kam laut Aussagen eines Linkspartei-Bundestagabgeordneten durch seine parlamentarische Anfrage ans Licht, dass fast 70 Millionen Euro Kosten bis Ende 2021 eingeplant sind (ein Teil davon dürfte als Mehrwertsteuer zurück an den Staat fließen). Rund 45 Millionen sind für den Betrieb vorgesehen. Ob darin die Kosten für die Anbindung der Gesundheitsämter an das App-System enthalten sind, ist unklar.
Abgesehen von der Salamitaktik des Ministers Spahn, der diese Zahlen nicht proaktiv herausgibt, wird in der medialen Öffentlichkeit diese Summe kaum hinterfragt. Ohne die Details zu wissen, lassen sich die Kosten nur per Schätzungen bewerten. Doch erscheinen die Entwicklungskosten beindruckend hoch. Selbst wenn man Elemente wie den Einkauf von Datenschutzexpertise und umfassenden Bluetooth-Tests einbezieht. Immerhin konnte kostenfrei auf wesentliche Arbeit der DP3T-Initiative zurückgegriffen werden und möglicherweise Vorarbeiten (BLE-Messung) des gescheiterten PEPP-PT. Selbst bei einer Gewinnerwartung der Firmen von 100 Prozent und Tagessätzen von 2000 Euro käme man bei 20 Mio. Euro auf 5000 Personenarbeitstage.
Ähnliches gilt für die laufenden Kosten von monatlich drei Millionen Euro. Die werden wohl u.a. mit der Bereitstellung von 24h-Telefonhotlines begründet. Abgesehen davon, dass die Notwendigkeit von 24h Hotlines zu hinterfragen wäre, weil 12 Stunden es auch täten: Um auch nur begründet auf eine Million Euro Kosten dafür im Monat zu kommen, müssten hunderte Personen dafür in drei Schichten arbeiten. Monatliche Millionenkosten für Serverinfrastruktur und Wartung eines überschaubaren IT-Projekts wirken eher nach Mondpreisen.
Entgegen der ersten Corona-Forschungs-App vom RKI ist die Direktvergabe für die CoronaWarnApp offenbar noch nicht im europäischen Ausschreibungsportal TED zu finden.
Onboarding und Usability
Nun zur App selbst. Startet man die App zum ersten Mal, kommt im zweiten Schritt eine 26.000 Zeichen lange Erklärung der Datenschutzaspekte. Das sind etwa 10 Seiten bedruckte Din A4-Blätter Text, die man beim „an Bord kommen“ (Onboarding) vorgesetzt bekommt. Überhaupt gibt es einigen Text, drapiert mit ein paar aussagelosen Symbolgrafiken. Und das war es. Eine prägnante Zusammenfassung der wichtigsten Funktionsweisen (inkl. Fehlerquotenaspekt) und Datenschutzfragen zum Einstieg, möglicherweise per Erklärvideo/-animationen oder wenigsten begleitet von Erklärgrafiken: Fehlanzeige.
Dabei hat selbst das RKI eine solche Grafik auf ihrer Website. Wieder gilt: Angesichts des absurd hohen Budgets ist es unverständlich, dass kein Geld dafür ausgegeben wurde, um die App zugänglicher zu machen. Es gibt darauf spezialisierte Berufe: Stichwort Usability (quasi eine Nutzungs-Didaktik). Das rächt sich offenbar bereits: Statt bei der speziell eingerichteten Telefonhotline rufen Nutzer*innen die Gesundheitsämter an, weil sie mit der App nicht klar kommen.
So wundert es auch nicht mehr, dass es mit einem 20 Millionen Budget nicht möglich war zum Launch der App eine Übersetzung für in Dtl. verbreitete Sprachen zu organisieren. Dies soll wohl noch erfolgen. Eine Version in Einfacher Sprache fehlt ebenfalls.
Datensouveränität und -portabilität
Innerhalb der App selbst gibt es keine Information darüber, wieviele „kritische Kontakte“ man in den letzten 14 Tagen hatte. Es wird nur das Risiko (erhöht, niedrig, unbekannt) angegeben. Die Möglichkeiten, Anzahl und Zeitpunkt der registrierten Kontakte in einer Liste etc. einzusehen, fehlt. Im Sinne der Datensouveränität, Freiwilligkeit und Stärkung von Privatsphäre sollte es ermöglicht werden, bestimmte Zeiträume im Nachhinein zu löschen (möglicherweise erlauben Apple/Google nicht den Zugriff).
Eine Funktion zur Datenportabilität (Export im Tabellenformat, z.B. csv) wäre sinnvoll, um etwa Daten an unabhängige Forschungs- und Rechercheprojekte spenden zu können. Und ggf. um zu alternativen Angeboten wechseln zu können, sollten diese in den nächsten Monaten entstehen.
