Hinweis: Dieser Artikel ist älter als 3 Jahre
Inhalte, Quelltexte oder Links können zwischenzeitlich überholt sein.

Blog-Serie in drei Teilen

Die Corona Warning App will helfen, sich wieder frei im öffentlichen Raum zu bewegen. Gleichzeitig ist diese Technologie die Büchse der Pandora, bietet Sie eine bislang noch nie dagewesenen Möglichkeit der staatlichen Überwachung. Der CCC bezeichnet diese in seinen 10 Prüfsteinen nicht ohne Grund als Risikotechnologie¹.

Die ersten Ergebnisse der isländischen App, die von 38% der Bevölkerung genutzt und daher bislang als erfolgreichste App gehandelt wird, sind ernüchternd. Verantwortliche berichten, diese sei keine Hilfe oder gar ein Gamechanger².

Auch die erste Auswertung der RKI Datenspende-App scheint einem netzpolitik.org Beitrag nach ernüchternd zu sein³. Die veröffentlichten Karten und Ergebnisse lassen Zweifel an der Sinnhaftigkeit aufkommen, zumal die Auftraggeber keine Ahnung von der zweifelhaften Arbeitsweise der App gehabt hatten und mit Fehlinformationen viel Vertrauen zerstört haben⁴.

Ein Blick in andere Länder, zum Beispiel nach Argentinien, offenbart Datenschutz-Alpträume und offenkundigen Dilettantismus⁵.

Wo stehen wir mit der Corona-Warning-App? Wohin weisen die heute bekannten Informationen? Dieser mehrteilige Beitrag möchte eine Momentaufnahme und Einschätzung geben. Weitere Teile werden in den kommenden Tagen folgen.

Vorab aber ein Disclaimer:
Im Grunde versuche ich ein sich schnell bewegendes Ziel zu treffen. Bereits Geschriebenes muß bei Erscheinen einer neuen Dokumentation neu überarbeitet werden. Zuvor nicht berücksichtigte Aspekte neu bedacht werden. Ich kann nur “auf Sicht” schreiben, was nach aktueller Quellenlage als gesichert gilt. Und ich bin als IT-affiner Mensch natürlich nicht ganz Unvoreingenommen und schaue mit einer ganz bestimmten Brille auf die Dinge.

Wer sich auf eigene Faust einen Überblick in den Repositories der Corona Warning App verschaffen und die Entwicklung mitverfolgen möchte, dem empfehle ich dieses am besten ohne Verhaltensdatenweitergabe an Microsoft/GitHub mit einem Mirror zu tun. Wie das datensparsam geht, kann in meinem Blog-Beitrag “Gitea Mirror Spiegel - Die eigene Gitea Instanz Teil III” gelesen werden.

Warum Telekom und SAP nicht in der Lage sind, ein eigenes VCM zu betreiben, bleibt leider unbeantwortet⁶. Eine eigene GitLab Instanz bietet mindestens genauso gute CI/CD Möglichkeiten.

Eine Frage der Prioritäten

Die Bundesregierung, das RKI als gemeinsame Auftraggeber und die mit der Entwicklung beauftragten Unternehmen Deutsche Telekom und SAP werden im Microsoft/ GitHub Eröffnungsdokument als Stakeholder genannt⁷.

Andere wie zum Beispiel die Gesundheitsämter, die vielen Testeinrichtungen und die Ärzte spielen zwar im Gesamtkonzept eine wichtige Rolle, fehlen aber als Stakeholder. Folglich bleiben Ihre User-Stories und Sichtweisen, die mögliche Anforderungen spezifizieren, unbekannt. Als wenn es da gar keine Anforderungen oder Bedürfnisse zu berücksichtigen gäbe oder diese vollkommen vergessen wurden. Im entsprechenden Issue wird (Nach-)Besserung versprochen⁸.

Ein Datenschutzbeauftragter und eine Datenschutzerklärung sind nicht bekannt. Weder was den Einsatz von Microsoft/ GitHub als zentrale Plattform anbetrifft noch in Form von User-Stories. Eine Projektwebsite existiert nicht, soll aber in Kürze kommen. Wir müssen uns demnach noch gedulden.

Ein Gefahren- oder Threat Modell fehlt bislang ebenso und wird nicht nur von mir vermisst⁹.

Immerhin, für ein App-Logo war hinreichend Muse, Zeit und Geld vorhanden, die Werbeagentur “Zum goldenen Hirschen” zu beauftragen¹⁰. Auch Layouts und Farben sollen bereits fest stehen. Von Blau und Rot ist die Rede, umrahmt von Claims wie “Kleine App, große Wirkung”, “Die App-traktion des Jahres” oder auch “Diese App kann nichts, außer Leben retten”¹¹.

Wenden wir uns von diesen vorzeitigen, kreativen Ergüssen ab und berücksichtigen den Umstand, dass alles noch “im Werden” ist.

Nun sag, wie hast Du’s mit Open Source?

In einer bemerkenswerten Entscheidung hat die Bundesregierung die Vorgabe gemacht, einen dezentralen Ansatz zu verfolgen und die Quelltexte offen zu legen. Die hier vorgestellten Problemfelder und Inkonsistenzen sollen diese vorbildliche Entscheidung nicht schmälern. Vor einigen Wochen las sich alles noch anders an und liess Schlimmes befürchten¹².

Diese Transparenz wünschte ich mir gerne auch bei anderen IT Großprojekten, als Stichworte nur Begriffe wie “Anwaltspostfach”, “Herkules” oder “TollCollect” in den Raum geworfen. Vielleicht ist es Zeit, so manche Standards für Großprojektemanagement um die Punkte “Open Source” und “Public Money - Public Code” als Voraussetzungen in die Köpfe zu bringen.

Bei aller Begeisterung bitte im Hinterkopf behalten, dass die Open Source Corona-Warn-App auf einer mehr oder minder Closed Source Blackbox von Google und Apple aufsetzt, die ihrerseits sich die Hardware mit einer noch größeren Blackbox mit dem Namen Baseband teilt. Die Unterstützung anderer Systeme oder gar eine F-Droid Version wird ausgeschlossen¹³.

Die Gretchenfrage “Nun sag, wie hast Du’s mit Open Source?” entstand zwischen Ankündigung und der ersten Veröffentlichung von Quellcode. Die große Sorge und Frage im Raum war, ob der Quellcode “am Stück” vor die Füsse geworfen wird. Wer zurück an den Mathematikunterricht in der Schulzeit denkt, weiß, wie wichtig nicht nur das Ergebnis sondern auch der Lösungsweg ist. Ich erinnere mich noch sehr gut daran, wie es häufig trotz eines blöden Zahlendrehers am Ende einer seitenlangen Auflösung noch die volle Punktzahl gab. Bei Software verhält es sich ähnlich.

Diese Sorge hat sich nicht bestätigt. Die erste Quellcode-Veröffentlichung ist augenscheinlich vollständig mit Ihren Commits, Branches und Pull Requests. Sogar so vollständig, dass mit einem Schmunzeln gesehen werden kann, wie der cwa-server zuvor ein ena-server war¹⁴.

Die Gretechenfrage ist beantwortet. Volle Punktzahl trotz Copy & Paste eines Projekt-Templates.

Grundannahmen

Zur Ermittlung, ob jemand exponiert und möglicherweise erkrankt ist werden folgende Faktoren herangezogen:

• vergangene Tage seit einer Exposition
• Dauer der Exposition (in 5 Minuten Schritten)
• BT Signalstärke
• Mitglied in Risikogruppe (optional)

Mit Ausnahme der optionalen Angabe zur Risikogruppe birgt jeder Faktor so seine Probleme.

Abstandsmessung

An der Abstandsmessung mit BT LE scheiden sich die Geister¹⁵. Es handelt sich dabei um keine direkte Messung wo ein Wert X eine Distanz Y ergibt sondern um eine interpretierte Messung, wo zahlreiche Störfaktoren beseitigt und mit Gauss- oder Sigmoid-Funktionen mathematische Schwellenwerte und Stufen erst ermittelt werden müssen.

Obwohl mehrere PEPP-PT Testreihen stattgefunden haben, geben diese alle mehr oder minder Laborumgebungen wieder ohne besondere Berücksichtigung von Hindernissen, Reflektionen oder Interferenzen. Der Aussage eines Issues nach soll das Umarmen einer Person mit beiden Smartphones in der Tasche sich kaum von dem Signalmuster von in der Hand gehaltenen Geräten im Sicherheitsabstand von 2 Metern unterscheiden¹⁶.

Die Aufzeichnungen der verlinkten PEPP-PT Testreihe “Distance Measurements and Classification Test Report” von Dipl-Inf Steffen Meyer, Fraunhofer IIS scheint dieses zu bestätigen¹⁷. Auch schreibt dieser:

Estimating proximity by measuring RSS can be influenced by a number of parameters, including phone model (antennas, BLE chip), usage pattern (in hand, at ear, in pocket), environment (indoor/outdoor, open space / crowded rooms), phone orientation and others. However, RSS-based positioning is widely spread and has to cope with the same effects.

In einem deutlich aufwändigeren Test mit mehreren Geräten, 48 Bundeswehrsoldaten, Indoor- und Outdoor-Messungen liefert das Paper “Report from the Measurement Campaign 2020-04-09” der Forscher Jackie Ma, David Neumann, Felix Sattler, Ralf Schafer, Patrick Wagner, Thomas Wiegand bessere Resultate¹⁸.

Based on the values (..) the actual distances (ground truth) of all the mobile phones involved in the test can be determined.

Im gleichen Paper steht in einem Nebensatz vermutlich der beste Hinweis, was die App wirklich messen soll:

(…) according to the Robert Koch Institute, for the flu, a physical proximity between two people of less than 2 meters over a time period of 900 seconds (15minutes), results in a high risk of being infected.

Im Paper wird eine Erkennungsrate (True Positive Rate) zwischen 67% und 76% detektiert.

Den ersten Prüfstein¹⁹ des CCC als Maß angesetzt:

Grundvoraussetzung ist, dass „Contact Tracing“ tatsächlich realistisch dabei helfen kann, die Infektionszahlen signifikant und nachweisbar zu senken. Diese Beurteilung obliegt der Epidemiologie. Sollte sich herausstellen, dass „Contact Tracing“ per App nicht sinnvoll und zielführend ist, muss das Experiment beendet werden.

komme ich persönlich als Laie zu dem Schluss, dass eine Abstandsmessung möglich und sinnvoll sein kann. Auch wenn diese unpräzise und fehlerbehaftet ist, so ergibt die Kombination aus Zeit und Dauer möglicherweise ein plausibles Modell.

Messung der Dauer

Ein Smartphone soll zwar konstant alle 250 ms seine RPIs (Rolling Proximity Identifier) an die Umgebung aussenden, umgekehrt jedoch nur einmal alle 5 Minuten für die Dauer von 2 Sekunden lesen können²⁰.

Angenommen jemand geht mit 6 km/h durch eine Innenstadt. Dann legt er in 5 Minuten eine Strecke von ca. 500 Metern zurück. Das ist grob die Strecke vom Kölner Hauptbahnhof vorbei am Dom über die Domplatte zum Römisch-Germanischen Museum ohne dass die App etwas von der Menschenmenge links und rechts mitbekommen würde. Ein COVID-19 Infizierter, der einen in dieser Zeit angerempelt, angehustet oder die Hand geschüttelt und innig umarmt hat, bleibt unerkannt.

Statistisch betrachtet: Wenn die App wirklich nur alle 5 Minuten für 2 Sekunden lauscht, ergibt das über einen Tag mit 24 Stunden und 86.400 Sekunden ein Zeitfenster von 576 Sekunden oder 0,67% der Zeit.

Der technischen Einschränkungen ist man sich bei den Stakeholdern bewusst:

(…) only exposures of longer duration within a certain proximity range are considered relevant for the intended purpose of this app, most of them will be covered.

Passen die grundlegenden Annahmen? Was ist von einem Instrument zu halten, das nur 0,67% der verfügbaren Zeit misst? Einerseits bin ich als IT-Mensch von der Möglichkeit fasziniert, wie mit minimalinvasiven 0,67% der Zeit alle Kontakte und Interaktionen > 5 Minuten abbildbar werden. Anderseits aus einer datenschutzrechtlichen Sicht bin ich tief erschüttert.

Differenzen und Unsicherheiten

Wo die Grundannahmen zwischen den Stakeholdern zu 100% auseinander klaffen wird in der Bandbreitenberechnung deutlich. Das RKI geht von einem “best case” von 60 Mio Anwendern aus, SAP und Telekom von 30 Mio²¹.

Darüber hinaus will das RKI sich die Möglichkeit offen halten, die Gewichtung der einzelnen Faktoren mit einem zusätzlichen “Weight Factor” justieren zu können. Dieses soll vorbei an den App-Stores zusammen mit der Übermittlung von Diagnosedaten erfolgen. Wie genau ist noch nicht bekannt²².

Aufbau der Gesamtlösung

Betrachten wir die angedachte Funktionsweise der Gesamtlösung, bestehend aus den nativen iOS- und Android-Apps sowie den Serverdiensten. Der Onboarding-Prozess, wie eine App sich auf einem Gerät initialisiert und wie die anonyme Übermittlung von Diagnosedaten Infizierter ausgestaltet ist, lässt sich noch nicht sagen.

Was sich bereits jetzt sagen lässt ist, dass keine Push Notification Services von Google und Apple zum Einsatz kommen werden. Diese könnten Hinweise und zusätzliche Mißbrauchsmöglichkeiten für Dritte bieten, dazu später mehr im letzten Teil der Blog-Serie.

Kommuniziert wird direkt mit den Servern der Telekom, die in der Open Telekom Cloud (OTC) betrieben werden. Damit die App das auch sicher kann, spendieren Apple und Google systemseitig mehr “background time”²³.

Wir dürfen uns auf einen erhöhten Strombedarf und somit deutlich kürzere Laufzeit von teilnehmenden Endgeräten einstellen. Immerhin nirgends steht etwas von Cloudflare oder US-CDNs, das ist soweit gut.

Die bereits bekannte Zahl aus der “Bandwidth Estimation” geht von ca. 30 Mio Anwendern aus, die ein Datenvolumen von 43 TB und 720 Mio Requests am Tag erzeugen sollen²⁴.

Gemäß dieser Zahlen leitet sich ab, dass die App vermutlich einmal stündlich Kontakt mit Ihren Gegenstellen aufnimmt. Ausgehend von 2.000 täglichen Neuinfektionen wird der Umfang der übermittelten Diagnosedaten auf ca. 1,5 MB geschätzt. Das ergibt für jedes Endgerät:

• 36 MB/ Tag
• 252 MB/ Woche
• ca. 1 GB/ Monat

Ich befürchte das Thema Netzneutralität wird in der einen oder anderen Form wieder auf den Tisch kommen. Hat doch ausgerechnet die Telekom in der Vergangenheit mit Ihren StreamOn- und Zero-Rating Produkten eine nicht als legal zu bezeichnende Auffassung vertreten²⁵.