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.

Ein Blick in unser Monitoring zeigt… nichts. Die Vermutung, dass die Telefone keine Nachrichten bekommen, weil die Infrastruktur der Apps zusammen gebrochen ist, konnten wir aus dem Monitoring nicht ablesen. Unsere Vermutung: Entweder hatte jemand verschlafen, die Apps komplett vergessen, oder das Backend zum Einstellen der Meldungen musste abgeraucht sein.

Eine Vermutung, die sich leider später bestätigte:

Info 1/3
Die bundesweite MoWaS-Meldung konnte nur verspätet zugestellt werden. Grund dafür war eine nicht vorgesehene zeitgleiche Auslösung einer Vielzahl von Warnmeldungen über MoWaS. ^nps

— BBK (@BBK_Bund) September 10, 2020

Das Traurige daran ist jedoch, dass dies leider keine neue Erkenntnis ist, wie dieser Tweet von 2018 zeigt:

Die zeitgleiche Nutzung von #NINA durch das Innenministerium NRW sowie einiger Großstädte hat aber zu einer außergewöhnlichen Belastung der technischen Infrastruktur geführt. Die Schwachstellen konnten zwischenzeitlich identifiziert werden. 2/3 ^uf

— BBK (@BBK_Bund) September 11, 2018

MoWaS ist hierbei die bundeseigene Infrastruktur, über die Warnmeldungen eingegeben werden und dann an entsprechende Empfänger, wie Medienbetreiber (Radio, TV, …) aber z.B. auch die Warn-Apps, ausgespielt werden.

Erst eine halbe Stunde später tauchte im Fall von NINA eine Warnmeldung auf den meisten Geräten auf. Bei KatWarn dauerte es jedoch (auf unseren Testgeräten) noch zwanzig weitere Minuten bis zur Warnung:

Eine Entwarnung erfolgte nicht.

Dabei muss man dazu sagen, dass, jedenfalls auf iOS und Android, die Server der Warnapps die Nachrichten gar nicht selbst direkt an das jeweilige Gerät ausliefern, sondern diese an Apple bzw. Google übermitteln, deren Infrastruktur sich dann um die Auslieferung an die Endgeräte kümmert. Da diese im Normalbetrieb minütlich mehrere Millionen¹ Nachrichten ausliefern, lag die Verzögerung mit hoher Wahrscheinlichkeit nicht auf der Seite von Apple und Google.

Positiv anzumerken ist, dass die Server nach der Auslieferung der Push-Nachricht relativ stabil blieben. An der Stelle lag unsere größte Befürchtung, weil wir davon ausgingen, dass die Benutzenden die Apps über die Mitteilung öffnen werden, was wiederum eine Vielzahl an Anfragen an die Server der Apps bedeutet. Es kann natürlich sein, dass ein angekündigter Probealarm dieses Verhalten nicht so stark auslöst, wie in einem realen Katastrophenszenario. Die Stabilität ist im Ernstfall deswegen wichtig, da die ausführliche Erklärung der Notfalllage erst in der App selbst passiert, da in den Push-Notifications nur sehr begrenzt Platz für Text ist. Die Hälfte dieses Textes wird ja manchmal schon für die teilweise sehr langen Behördennamen verbraucht. Extrem lange Einführungen wie »Sachsen, Lagezentrum der Landesregierung meldet: Der Freistaat Sachsen Informiert:« sind hier auch nicht hilfreich.

Weitere Seiten, die wir nicht im Monitoring mit erfasst hatten, waren aber zeitweilig auch nicht erreichbar. Zeitweilig klingt hier erst mal nicht tragisch, für eine kritische Infrastruktur, wie Bevölkerungswarnung im Ernstfall, ist aber genau dies wichtig. Eine 99,99% Verfügbarkeit hilft eben genau nichts, wenn die 0,01% zum einzigen Zeitpunkt liegen, bei dem die Verfügbarkeit wichtig ist.

I did create an uptime check for some official websites. So if we're ever going to die, German websites ain't gonna help us 🥺 4/6 locations reported downtime for bbk (dot) bund (dot) de #Warntag2020 pic.twitter.com/m5uLMARjc1

— Daniel Freytag (@FRYTG) September 10, 2020

Wir waren nicht die einzigen, welche die BBK Seite gemonitored haben. Auch die Infoseite zu NINA war zeitweilig überlastet. (Möglicherweise durch Menschen, die sich wunderten warum keine Meldung kam?)

---

Einen Totalausfall haben wir auch noch zu vermelden: BIWAPP. Obwohl die Dienste der App per Akamai ausgeliefert werden, waren diese pünktlich um 11:02 nicht mehr erreichbar, und brauchten selbst danach mehrere Stunden um sich wieder zu erholen.

Die App war in dem Zeitraum komplett unbenutzbar, und stürzte an einigen Stellen sogar ab, weil sie ihre Server nicht erreichte. An Apps, die von sich behaupten, Katastrophenwarnungen vorzunehmen, ist der Anspruch an Verfügbarkeit und vorallem Stabilität in Fehlerfällen doch um einiges höher.

Wie oben beschreiben ließ sich die Infrastruktur von Katwarn von uns nicht komplett monitoren, da die Schnittstellen nirgends öffentlich dokumentiert sind. So sah das reine Ping Monitoring für Katwarn eigentlich ganz gut aus, die Realität war allerdings, dass zeitweise selbst ausgelöste Test-Pushmeldungen nicht funktionierten.

Stefan hatte schon 2012 aufgeschrieben, warum offene Schnittstellen im Katastrophenschutz wichtig wären, und wir glauben die Problematik hat sich mit der starken Verbreitung unterschiedlicher Arten von Endgeräten und Plattformen nur noch verstärkt.

Also, wir haben nix gehört.

— Deutscher Gehörlosen-Bund e.V. (@gehoerlosenbund) September 10, 2020

Das klingt erst mal witzig, zeigt aber, dass allein akustisches Warnen ganze Menschengruppen einfach ausschließt. Und Menschen mit anderen Einschränkungen haben ganz andere Anforderungen an eine Warnmeldung. Auch um diese verschiedenen Anforderungen zu erfüllen, könnten offene Schnittstellen weiterhelfen.

---

Ungeklärte Auffälligkeiten im Monitoring

Etwas unklar ist uns, warum hessenwarn.de nach 12:00 teilweise sehr langsame Antwortzeiten generierte, obwohl dies eigentlich nur eine Weiterleitung auf die Webseite des hessischen Innenministeriums sind.

Das gleiche Verhalten zeigte auch das österreischische katwarn.at, obwohl da der Warntag erst am 3. Oktober stattfindet. katwarn.at hatten wir versucht zu monitoren, um zu schauen, ob ein Warntag in Deutschland das System in Österreich beeinflusst.

Auch in den Monitoringdaten von NINA gibt es von ca. 17:00 bis 21:00 Uhr eine starke Erhöhung der Antwortzeiten an allen Schnittstellen. Auch hier ist uns die Ursache des Problems unklar.

---

Cell Broadcast

Warnung: Die folgenden Abschnitte wurden unter Einfluss von gefährlichem Halbwissen über Cell-Broadcast geschrieben.

Die Frage warum im deutschen Katastrophenschutz nicht auf Cell Broadcast gesetzt wird, wurde in den letzten Tagen schon öfter zu Recht gestellt. Während CB-Meldungen von allen Telefonen unterstützt werden, haben Apps den Nachteil, dass sie nicht für alle Telefone verfügbar sind. Außerdem werden Push-Notifications von Nutzenden im stummgeschalteten Modus oder Nachtmodus nicht bemerkt, während Cell Broadcast Nachrichten von den Telefonen priorisiert behandelt werden können. Außerdem können sich die Warnapp Notifications zwischen tausenden Benachrichtigungen anderer Apps, die wir täglich von Messengern bekommen, visuell nicht abheben, was bei CB-Nachrichten möglich ist. Der enorme Nachteil, dass die App auch noch aktiv installiert werden muss, und eigentlich nicht nur eine App, sondern mindestens drei ist gegenüber CB überhaupt nicht vertretbar. Außerdem können CB-Nachrichten auch bei stark überlasteten Netz in vielen Fällen noch zugestellt werden. Für weitere Infos, wie Karten und längere Texte sind die Apps vielleicht brauchbar, für die eigentliche Benachrichtigung allerdings nicht. Ein Link in der CB-Nachricht würde die Aufgabe weitere Infos bereitzustellen, aber genauso gut erledigen.

Kurz: Die Vorteile von CB überwiegen die einer App eigentlich in fast allen Punkte, was damit zusammen hängen dürfte, dass diese Technologie genau für diesen Anwendungszweck entwickelt wurde.

Dass CB in Deutschland von den Mobilfunkanbietern nicht angeboten wird, mag zwar bedingt stimmen, aber als Gesetzgeber wäre man sicher in der Lage, die Anbieter zu verpflichten dies anzubieten. Es ist ja so, dass alle Mobilfunkanbieter in Deutschland auch Schwesterunternehmen im Ausland haben, in denen CB genutzt wird. Am fehlenden Know-How in den Konzernen sollte es also nicht scheitern.

O₂/Telefónica hat in Deutschland bereits einmal Cell Broadcast unterstützt, da sie damals als VIAG Interkom (später O₂, später Telefónica) diese Technik benutzt haben um “Homezones” umzusetzen - und hat die Infrastruktur daher möglicherweise noch in Betrieb. Auch Vodafone nutzte Cell Broadcast um z.B. lokale Vorwahlen zu übermitteln.

NINA hat 20 Millionen Euro (1 Corona-Warn-App, 3 Saarland) gekostet – mit dem Geld hätten sich die Anbieter vielleicht auch überreden lassen, zukünftig Cell Broadcast Nachrichten auszuliefern.

Allerdings hätte im aktuellen Fall wahrscheinlich auch CB genauso verspätet ausgelöst, da die Verzögerung ja im davor gelagerten System MoWas entstanden ist. MoWas hätte also auch die CB-Systeme verspätet informiert.

---

Disclaimer: Dies ist eine reine Außenansicht der Systeme. Wir weisen außerdem daraufhin, dass Katastrophenschutz ganz weit außerhalb unserer Kompetenz liegt. Dementsprechend würden wir uns über Berichtigungen und Aufklärungen über Fehlannahmen sehr freuen.

---

Für weitere Analysen stellen wir die gemessenen Monitoring-Daten als JSON und als CSV bereit.

Ebenso werden wir in den nächsten Tagen ein GitHub Repo veröffentlichen, das alle uns bekannten Warnapp Schnittstellen enthält und den Beginn der Dokumentation dieser darstellen soll.

Update (Dezember 2021)

Inzwischen hat die Bundesstelle für Open Data eine inoffizielle Dokumentation der NINA API veröffentlicht.