Wie im Artikel über unsere CWA-Messungen in Berliner U-Bahnen versprochen, veröffentlichen wir nun die Daten aus unseren Messungen. Um weitere Auswertungen mit den Daten möglichst einfach zu machen, haben wir ein paar Vorverarbeitungsschritte gemacht. Dabei haben wir außerdem alle nicht benötigten Daten, die als persönliche Daten gewertet werden könnten, entfernt. Keine dieser Veränderungen sollte die Auswertbarkeit der Daten beeinträchtigen. Eine genaue Beschreibung, welche Änderungen wir vorgenommen haben und eine Beschreibung des Datenformats befindet sich im Readme des Repositories.

Das GitHub repo mit den Daten und Doku ist unter https://github.com/zerforschung/Covid32Data zu finden

In Bussen und Bahnen steckt man sich nicht mit Corona an, behaupten die Verkehrsunternehmen immer wieder¹ und starten Werbekampagnen zum “wieder einsteigen”. Das erscheint auf den ersten Blick irrational, da ÖPNV-Umgebungen viele Merkmale aufweisen, die laut RKI das Infektionsrisiko erhöhen: viele Menschen, geringe Abstände, geschlossene Räume.

Die Verbünde begründen ihr Vertrauen in die Sicherheit des ÖPNV damit, dass nur ein Bruchteil der ans RKI gemeldeten Infektionsorte Bus und Bahn betreffen.

Allerdings konnten die Gesundheitsämter mehr als 75% der Übertragungsorte gar nicht ermitteln.

Das @rki_de-Diagramm zum "Infektionsumfeld" ist noch immer gefährlich missverständlich.
Ich habe das mal repariert: https://t.co/cCNwlmHb6S pic.twitter.com/iGHMgNpHDj

— Michael Kreil (@MichaelKreil) January 18, 2021

Der ÖPNV ist ein idealer “versteckter” Übertragungsort: Viele Zufallsbegegnungen mit ständig wechselnden, unbekannten Menschen. Es ist damit unmöglich, ein Kontakttagebuch zu führen und diese Kontakte dem Gesundheitsamt mitzuteilen.

Um die tatsächliche Gefahr einschätzen zu können, überlegten wir uns also, wie wir bessere Daten über Coronafälle im ÖPNV erfassen können.

Nach kurzer Überlegung, uns selbst in die Bahn zu stellen und die Leute zu fragen, ob sie Corona haben und dabei unsere Gesundheit zu gefährden, hatten wir eine sehr viel bessere Idee…

Wie ihr alle mitbekommen habt (oder vielleicht eben auch nicht) fand am 10. September der erste bundesweite Warntag statt. Neben Sirenen und Rundfunkunterbrechungen sollten auch die Warn-Apps getestet werden. Aus nicht wirklich nachvollziehbaren Gründen gibt es in Deutschland nicht die eine Warnapp™, nein, es steigen gleich drei wichtige Apps in den Ring:

• NINA: Die vom Bundesamt für Bevölkerungsschutz und Katastrophenhilfe bereitgestellte App, in deren Fokus die Auslieferung von Katastrophenmeldungen, die in den Zuständigkeitsbereich des Bundes fallen.
• Katwarn: Ursprünglich im Auftrag des Verbandes Öffentlicher Versicherer von Fraunhofer FOKUS entwickelt, wird aber mittlerweile von vielen Gemeinden, Kreisen und Ländern als offizieller Kanal zum Ausspielen von Katastrophenwarnungen in deren jeweiliger Zuständigkeit genutzt. Zusätzlich existiert nur für Hessen noch eine eigene, weitere App HessenWARN, deren zusätzliche Existenzberechtigung mir komplett schleierhaft ist.
• BIWAPP: Als weitere regionale Warnapp, die von der Marktplatz GmbH entwickelt und betrieben wird, und für manche Kreise, Städte und Gemeinden als deren offizielle Warnapp fungiert.

Bis vor kurzem mussten sich BürgerInnen selbst informieren, welche App denn jetzt für ihre Region zuständig ist - um sicher zu gehen aber jedoch alle drei Apps installiert und aktiviert haben, da man sich nicht zwingenderweise immer im gleichen Landkreis aufhält. (okay, dieses Jahr vielleicht schon). Seit Februar 2019 tauschen die Apps ihre Meldungen mit NINA aus (wobei es wohl keinen Austausch zwischen BIWAPP und Katwarn gibt). Das macht doch Lust auf mehr!

Jedenfalls sollten diese Apps jetzt im Rahmen des Warntags im großen Stile getestet werden, was bei uns doch etwas Interesse hervorrief. So entstand im vorhinein des Warntages die Idee, die Verfügbarkeit der hinter den Warnapps stehenden Serverinfrastruktur von außen zu monitoren. Kurz vor knapp haben wir das ganze am Abend vor dem Warntag dann auch tatsächlich noch schnell eingerichtet.

Da Monitoring der Verfügbarkeit von Infrastruktur ein normales Vorgehen für den Betrieb von IT ist, gibt es dafür auch eine Menge an fertigen Tools. Die Tools sind in der Regel dafür ausgelegt, Infrastruktur “von außen” (aus dem Internet) zu beobachten, da bei einem Komplettausfall ein internes Monitoring (im selben Netz, Rechenzentrum, …) auch weg sein könnte. Zudem ist es einfach sinnvoller von Außen zu testen, wenn der normale Anwendungsfall auch von außen passiert.

Wir haben dafür den Service UptimeRobot auf sämtliche uns bekannte Schnittstellen der Apps angesetzt. Dieses Tool misst minütlich, ob der entsprechende Server verfügbar ist und wie lange dieser zum Antworten braucht. Ist die Antwortzeit ungewöhnlich lange, ist das ein Indiz dafür, das der entsprechende Server überlastet ist. Die Infrastruktur für das Ausliefern von Push-Notifications lässt sich von außen leider nicht ohne weitere Informationen über das System monitoren.

Um an die Information zu kommen, mit welchen Servern und Schnittstellen die Apps sprechen, musste wir die Apps auseinander nehmen - denn die Schnittstellen sind nicht öffentlich dokumentiert und wurden bislang auch nicht auf Anfragen nach dem Informationsfreiheitsgesetz herausgegeben.

Leider ist es uns in der knappen Zeit nicht gelungen, die Schnittstellen aller Apps heraus zu finden. So konnten wir bei Katwarn nur die ping Zeiten der Server, jedoch nicht die wirkliche Reaktionszeit des Dienstes überwachen.

Außerdem haben wir noch die Info-Webseiten der Apps mit ins Monitoring aufgenommen.

Und dann kam alles anders schlimm.

Donnerstag, 10. September 2020, 11 Uhr. Die Sirenen heulen leise am Horizont, aber die Apps pushen nicht.