Am Samstagmorgen, dem 13. Januar 2018 um 8:09 Uhr Hawaiischer Zeit, ging ein Mitarbeiter des State Warning Points der Hawaii Emergency Management Agency HIEMA seine Routine-Checkliste zum Schichtwechsel durch. Er ging diese Checkliste jeden Tag durch, wenn er seine Schicht begann. Es war reine Routine. Nichts daran war interessant.
Schließlich öffnete er die IPAWS-Alarm-Software, sah sich einer Liste mit gespeicherten Vorlagen gegenüber und wählte eine aus einer Liste von neun. Die, die er auswählte, trug den Namen PACOM (CDW)—STATE ONLY.
Nur war das nicht die Vorlagendatei, die er hatte öffnen wollen. Die Vorlage, die er eigentlich öffnen wollte, war DRILL—PACOM (CDW)—STATE ONLY benannt. Abgesehen vom Wort DRILL (Übung), waren die beiden Dateien nahezu identisch. Ich sage "nahezu", denn es gab noch einen Unterschied: Die Übungsversion sendet nur eine Nachricht an Testgeräte, während die Nicht-Übungsversion dieselbe Mitteilung an jedes Mobiltelefon in Hawaii schickt.
Die Nachricht war unheilvoll: Ballistische Rakete bedroht Hawaii. Sofort Schutzraum aufsuchen. Das ist keine Übung.
Der Mitarbeiter im State Warning Point bemerkte nicht sofort, dass er die falsche Datei gewählt hatte. Nichts im System sagte ihm, dass es so war. Die Klicks und Bestätigungen waren für alle Dateien gleich. Er bekam von seinem Fehler nichts mit, bis ein paar Augenblicke später sein eigenes Handy mit dem Alarm vibrierte - wie bei allen anderen in der Notfall-Einsatzzentrale des State Warning Points. Huch!
Wenn jemand drauf und dran ist, eine Mitteilung über eine nahende ballistische Rakete an Millionen von Telefonen zu senden, sollte es eine Bestätigungsnachricht geben, könnte man meinen. Gab es. Gab es aber auch für die Testnachricht. Sie verlangte sogar ein spezielles Passwort vom Nutzer, um sicherzustellen, dass er die Absicht hatte, eine Mitteilung an jeden Empfänger zu schicken. Aber genau so war es auch bei der Testnachricht.
Die Crux an diesem Fehler war die Auswahl der falschen Datei aus einer Liste, die wie diese aussah:
Es ist unschwer zu erkennen, wie es zur Auswahl der falschen Datei kam. Sie scheinen in chronologischer Reihenfolge aufgelistet zu sein, von der neuesten bis zur ältesten. (Die erste Datei BMD False Alarm wurde hinzugefügt, unmittelbar nachdem der falsche Alarm rausgegangen war und der Gouverneur eine Stellungnahme abgegeben hatte. Sie enthält die Nachricht, die dann allen mitteilte, dass die Keine-Übung-Nachricht in Wirklichkeit eine Übung gewesen war.)
Es schwirrt eine alternative Vorlagenliste herum:
In beiden Fällen sehen wir klar, dass der Übungs-Dateiname fast identisch mit dem eigentlichen Dateinamen ist. (CDW ist Civil Defense Warning, Zivilschutzwarnung.) Diese Liste ist alphabetisch, was nicht viel besser ist als eine Sortierung nach Datum.
Planung für solche Fehler
Dies war kein sorgsam designtes Menü - wie jede willkürliche Sammlung von nutzerbenannten Objekten. Doch um bis zu diesem Punkt zu gelangen, war eine Menge sorgfältiger Planung nötig.
Das System, das zum Einsatz kam, um die Alarmierungen zu versenden, heißt IPAWS – Integrated Public Alert & Warning System –, verwaltet von der US Government’s Federal Emergency Management Agency (FEMA) in Zusammenarbeit mit der Federal Communications Commission (FCC). Der Mobiltelefon-Anteil von IPAWS ist bekannt als Wireless Emergency Alert (WEA) System.
Staaten und Counties können Zugang zum IPAWS-System bekommen, um Notfallnachrichten zu posten - von Straßensperrungen bis zu AMBER-Alarmen (Alarme im Fall von Kindesentführungen).
Hawaii hatte sein System schon eine Weile in Betrieb; sie nutzten es für wettertechnische Probleme wie Erdrutsche, die Straßen unpassierbar machen, und Tsunami-Warnungen. Im November gab HIEMA - besorgt über die zunehmenden Spannungen mit Nordkorea - einen neuen Notfall-Bereitschaftsplan heraus, der auch WEA-Benachrichtigungen im Falle ballistischer Raketenangriffe umfasste.
Hier ist eine Folie aus dem Notfallbereitschafts-Slidedeck von HIEMA, die die Reaktion auf einen Raketenstart beschreibt:
Hier sind die Benachrichtigungen, die HIEMA empfohlen hat:
Wie wir sehen, kam die tatsächlich herausgeschickte Nachricht den Nachrichten des HIEMA-Plans sehr nahe. (WEA hat ein 90-Zeichen-Limit, sodass die empfohlene 138-Zeichen-Nachricht gekürzt werden musste.)
Ich schätze, dass der State Warning Point seine gespeicherten Nachrichten im Zuge der neuen Richtlinien aktualisiert und dabei zunächst die Übung als reguläre Praxis hinzugefügt hat, anschließend die eigentliche Nachricht.
(Es sieht so aus, als hätten sie bei dieser Gelegenheit auch eine Vorlage für Tsunami-Warnungen hinzugefügt, da diese zwischen den beiden PACOM-Nachrichten zu finden ist. PACOM steht für United States Pacific Command, das gemeinsame militärische Koordinierungsbüro, das die Pazifikregion überwacht.)
FEMA listet 23 zugelassene Anbieter für IPAWS-Alarmveranlassungs-Software auf. Die meisten sind entweder Software as a Service oder iOS-Apps. (Ja, jemand kann den gesamten Staat von seinem Telefon aus alarmieren.)
HIEMA hat nicht offengelegt, welchen Anbieter sie zurzeit nutzen. Es ist unwahrscheinlich, dass die HIEMA-Implementierung auf irgendeine Weise individualisiert war. Es kostet einige Arbeit, um die FEMA-Zertifizierung zu bekommen. Die überlässt man besser den Anbietern.
Wenn wir die Websites diverser zugelassener Hersteller besuchen, sehen wir ein paar hübsch designte Systeme. Hier ist eines von einem Unternehmen namens Alertsense:
Das ist offenbar ein säuberlich designtes System. Allerdings gibt es einen Vorgänger und es ist möglich, dass bei HIEMA etwas im Einsatz ist, das eher so aussieht:
Behörden sind häufig bestrebt, das Geld der Steuerzahler zu sparen, und geben nichts für Upgrades aus. Speziell nicht für Systeme, die nicht kaputt sind. Hoffentlich erfahren wir bald mehr über das spezifische System, das Hawaii verwendet.
Dieser Fehler ist wahrscheinlich auch schon früher passiert
Meine Reaktion, als ich das involvierte System gesehen habe, war: Warum ist das nicht schon früher passiert? Schließlich ist das Auswählen einer falschen Datei ein verbreiteter Fehler. Wenn die Art und Weise, eine IPAWS-Nachricht zu versenden, darin besteht, eine vordefinierte Vorlage aus einer Liste zu wählen, ist es wahrscheinlich, dass früher schon jemand die falsche genommen hat.
Doch das wäre kein Thema für die Abendnachrichten. Bei den meisten IPAWS-Alarmen geht es um AMBER-Alarme und lokale Wetterprobleme. Würde die falsche Nachricht rausgeschickt, sagen wir wegen einer überfluteten und gesperrten Straße, wüssten die meisten Leute nicht, dass es ein Problem gegeben hat. Wenn sie nicht gerade in der Nähe dieser bestimmten Straße gewesen wären, hätten sie die Mitteilung wahrscheinlich gar nicht beachtet, selbst wenn es ein Fehler war.
IPAWS-Nachrichten sind normalerweise lokale Angelegenheiten. Staatsweite Nachrichten ist selten. Das hat dazu geführt, dass dieser Vorfall so öffentlichkeitswirksam war.
Dateinamen sind die Übeltäter
Kennen Sie auch jemanden, der mal eine alte Version einer Datei geschickt hat, obwohl er dachte, es wäre die neueste, nur hatte er beim Speichern versehentlich die alten über die neuen Daten geschrieben? Das ist im Wesentlichen das Problem, mit dem wir es hier zu tun haben.
Es ist ein klassisches User-Experience-Problem mit Konventionen für Dateinamen. User wählen Dateinamen oft nicht mit dem Gedanken Werde ich später einen Fehler machen und die falsche Datei auswählen? Wir machen die ganze Zeit Fehler mit unseren Dateien und nehmen die falsche Version, wenn zwei Dateien ähnlich benannt sind.
Wenn wir uns fragen, wie wir vermeiden könnten, dass uns das passiert, sollten wir uns ansehen, wie die IPAWS-Nachrichten für die spätere Nutzung gespeichert werden. So wie das System heute funktioniert, vertraut es darauf, dass die Nutzer die Nachrichtenvorlagen mit sinnvollen Namen versehen. Wenn sie einen Namen vergeben, der einem anderen ziemlich ähnlich ist, wird dieser Fehler erneut geschehen.
Es gibt hier kein System, das Namenskonventionen erzwingt - so wenig, wie es Namenskonventionen für irgendwelche anderen Dateien in irgendwelchen anderen Dateisystemen gibt. Unsere Systeme zwingen den Nutzern kein bestimmtes Naming-Regime auf, um sicherzustellen, dass jeder Name klar und eindeutig ist, damit künftige Namenskonfusion vermieden wird.
Eine mögliche Lösung: Dateinamen loswerden
In mancherlei Hinsicht sind Dateinamen ein Anachronismus aus jenen alten Tagen, in denen das Lesen von Daten langsam war und Platz kostbar. Wir konnten sie in vielen Fällen eliminieren, und daher kommt das.
Für eine IPAWS-WEA-Nachricht gibt es zwei eindeutige Identifikatoren, die wir stattdessen für einen Dateinamen nutzen könnten: die Nachricht selbst und die Adressaten, an die ausgestrahlt wird. Die Nachricht (Bedrohung durch ballistische Rakete) ist die wichtigste Sache und unterscheidet sie von anderen Nachrichten. Das UX-Design könnte die Nachricht als Primärindikator verwenden.
Das Design könnte auch Übungen von tatsächlichen Notfall-Alarmen unterscheiden. Es könnte getrennte Listen für die Übungen geben, die durch den Ort und andere Indikatoren wie eine klare visuelle Kodierung (etwa durch Farbstufen) separiert sind.
Die Nachricht als Identifikator zu nutzen und die Übungen von den echten Alarmen zu trennen, würde eine Menge dazu beitragen, dieses Problem zu vermeiden. Kurz: Es ist ein klassisches Mikrointeraktions-Problem. Gutes Design könnte eine große Hilfe sein, um zu gewährleisten, dass das Problem niemals wieder auftritt.
Natürlich würde das in der Hand des Software-Anbieters liegen. Und in diesem Fall gibt es 23 davon. Liegt es in der Verantwortlichkeit von FEMA, diese Art von UX-Änderung anzuordnen? Oder sollten die Anbieter es tun, einfach um Peinlichkeiten zu vermeiden?
Wir wollen wahrscheinlich nicht, dass unsere Gesetzgeber Sicherheitsstandards für Dateinamen-Methodologien erstellen. Oder wollen wir?
Wie hätten wir dieses Problem vorhersehen können?
Nun ist man hinterher immer klüger und sieht das Problem klar vor sich. Aber hätten wir es eine Woche vorher ahnen können?
Wir investieren nicht genug Arbeit, um unsere eigenen Designs Stresstests zu unterziehen. Wir fragen nicht, ob Leute Dateien verwechseln werden, die sie selbst erstellt haben, weil die Namen zu ähnlich sind. Wir fragen nicht, wie wir vermeiden können, dass die Bevölkerung eines ganzen Staates aufgeschreckt wird und den Notruf verstopft - was womöglich jemanden, der wirklich einen Notfall hat, in Gefahr bringt.
In der Notfallbereitschaft sind Übungen gängige Praxis. FEMA, staatliche Einsatzorganisationen und lokale Einsatzkräfte üben regelmäßig für den Ernstfall. In diesen Übungen versuchen sie zu antizipieren, was schiefgehen könnte. Sie entwickeln Szenarien, die alle möglichen Extreme abdecken (Was ist, wenn ein Terrorangriff während der Rettungsarbeiten nach einem Erdbeben passiert?). Dann halten sie Retrospektiven ab, um auseinanderzunehmen, was passiert ist und wo das System nicht standgehalten hat.
Produkt- und Dienstleistungsanbieter sind oft eingeladen, diesen Übungen beizuwohnen. Sie beobachten, wie ihre Produkte und Dienste unter dem Stress simulierter Situationen standhalten. Kluge Hersteller halten zudem eigene Übungen und Simulationen ab und setzen ihre eigenen Produkte und Dienste Extremsituationen aus. Diese Stresstests an ihren Lösungen eröffnen ihnen die Chance, sie robuster und effektiver zu machen.
Solche Arten von Abläufen sind bei digitalen Produkten nicht die Regel, außer im Bereich der Informationssicherheit, in dem beispielsweise Hacking-Events üblich sind. (Letztes Jahr hat der Defense Digital Service die Öffentlichkeit dazu eingeladen, in die DOD-Systeme einzubrechen, und eine Belohnung für jeden erfolgreichen Versuch ausgelobt, um seine Systemsicherheit stresszutesten.)
Was hätte ein simulierter Raketenangriff über die Funktionsweise des Systems enthüllt? Hätten wir genau das Gegenteil des Problems erlebt, dem wir am 13. Januar begegnet sind? Hätten wir gesehen, wie ein Operator die Übungsvorlage nutzt in der Meinung, er gäbe eine offizielle Warnung heraus?
Dem HIEMA-Notfallaktionsplan zufolge müssen WEA-Nachrichten fünf Minuten nach der Detektion rausgehen, weil der Einschlag 15 Minuten später erfolgt. Wie viele Leben könnten verloren sein, wenn es zu einer Verzögerung käme, weil es fünf Minuten dauert, um zu merken, dass keine offizielle Warnung gesendet wurde?
Wir brauchen mehr Lernerfahrungen solcher Art, bei denen Hersteller und Operative daran arbeiten, unsere Systeme zu stressen. Wir müssen die Barrieren von Organisationen niederbrechen und direkt mit den Nutzern zusammenarbeiten, denn sie haben uns vielerlei Perspektiven anzubieten. Dann müssen wir etwas Besseres designen, etwas, das mehr Sicherheit für diese Menschen bietet.
Dieser Artikel wurde im Original am 17. Januar 2018 unter dem Titel The Hawaii Missile Alert Culprit: Poorly Chosen File Names von Jared M. Spool veröffentlicht. Jared M. Spool gehört zu den führenden User-Experience-Experten unserer Zeit. Seine Website erreichen Sie unter http://www.uie.com. Weitere Artikel von Jared M. Spool finden Sie im UX-Special von //SEIBERT/MEDIA.
