FSFE
/
fsfe-website
29
30
Fork 85
Code Issues 62 Pull Requests 14 Wiki Activity

News about cell broadcasts / emergency apps in Germany #1685

Merged
max.mehl merged 8 commits from news/20201105-emergency into master 2020-11-12 06:27:50 +00:00
Conversation 3 Commits 8 Files Changed 3 +492
3 changed files with 492 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

206
news/2020/news-20201112-01.de.xhtml Normal file
View File

@ -0,0 +1,206 @@
<?xml version="1.0" encoding="UTF-8"?>
<html newsdate="2020-11-12">
<version>2</version>
<head>
<title>Wie man ein öffentliches Warnsystem (nicht) aufbauen sollte</title>
</head>
<body>
<h1>Wie man ein öffentliches Warnsystem (nicht) aufbauen sollte</h1>
<p>
Wie kann man Menschen am besten vor Katastrophen warnen? Deutschland
setzt auf proprietäre Apps, wodurch der jüngste "Warntag" zu einem
offiziellen Misserfolg wurde. Wir haben die Situation analysiert und
robustere Lösungen gefunden, die Nutzerrechte respektieren.
</p>
<p>
Die Grundidee des Testens von Notfallsystemen besteht darin,
potenzielle oder tatsächliche Probleme zu finden. Es ist jedoch
bemerkenswert, wie viel beim offiziellen deutschen Warntag im
September schief gelaufen ist. Insbesondere die <a
href="https://www.tagesschau.de/inland/warntag-115.html">Unzuverlässigkeit</a>
der offiziell beworbenen, unfreien und nicht standardisierten Apps
zwang das zuständige Bundesinnenministerium (BMI), welches dem
zuständigen Bundesamt für Bevölkerungsschutz und Katastrophenhilfe
(BBK) übergeordnet ist, den Testtag als gescheitert zu kennzeichnen.
</p>
<p>
Die FSFE analysierte die Ergebnisse zusammen mit Experten aus
Katastrophenschutz und mobilen Netzwerken, um herauszufinden, warum
die Apps fehlschlugen und wie ein belastbareres und offeneres System
aussehen kann.
</p>
<figure>
<img
src="https://pics.fsfe.org/uploads/medium/8a77a3fbd5eb790cf94b2f115f6f94f3.jpg"
alt="Ein rotes Notfalltelefon" />
</figure>
<h2>Digitale Warnsysteme in Deutschland</h2>
<p>
Es gibt drei prominente, öffentlich finanzierte Apps, die offizielle
Notfallwarnungen an ihre Benutzer weiterleiten können: Katwarn, Nina
und Biwapp. Alle drei sind proprietär, also unfreie Software, die es
ihren Benutzern nicht erlaubt, die Software zu benutzen, zu
studieren, zu teilen und zu verbessern. Darüber hinaus basieren sie
darauf, Notfallwarnungen vom zentralen <em>MoWaS</em> ("modulares
Warnsystem") abzurufen und diese über die WLAN- oder mobile
Internetverbindung an die Mobiltelefone der App-Nutzer
weiterzuleiten.
</p>
<p>
Eine Überlastung dieses zentralen Systems war der Hauptgrund dafür,
dass viele Alarme die Nutzer der App nicht oder nicht rechtzeitig
erreichten. Das kam jedoch nicht überraschend. In einem Szenario, in
dem Millionen von Geräten gleichzeitig von einer zentralen Instanz
mit Eins-zu-eins-Verbindungen (<em>unicast</em>) erreicht werden
müssen, sind solche Engpässe fast unvermeidlich.
</p>
<p>
Die zugrunde liegenden Probleme sind jedoch unnötige Komplexität und
Mehrfachstrukturen. Anstatt große Mengen öffentlicher Gelder in
zentralisierte Systeme und drei proprietäre Anwendungen zu
investieren, betreiben andere Staaten eine widerstandsfähigere und
gut getestete Infrastruktur für die Verteilung von
Notfallnachrichten: SMSCB, häufiger auch <em>Cell Broadcast</em>
genannt, also Eins-zu-viele-Nachrichten.
</p>
<h2>Cell Broadcasts</h2>
<p>
Um 1990 standardisiert, sind Cell Broadcasts eine etablierte Methode,
um Nachrichten an alle Benutzer von Mobilfunknetzen zu senden,
entweder in einem ganzen Land oder begrenzt auf bestimmte Gebiete –
und zwar in weniger als ein paar Sekunden. Die Telefone müssen nicht
einmal in einem bestimmten Netz registriert sein, um diese
Nachrichten zu empfangen, und Alarme mit der höchsten Priorität lösen
sogar einen Alarm aus, wenn das Telefon stumm geschaltet ist. Außerdem
haben solche Broadcasts im Gegensatz zu SMS und mobilem Internet einen
reservierten Kanal, der auch dann funktioniert, wenn die
Telefonzellen mit vielen eingewählten Geräten und Nachrichten
überlastet sind.
</p>
<p>
Darüber hinaus können Cell Broadcasts von jedem Telefon empfangen
werden, unabhängig davon, ob Notfall-Apps, ein aktuelles
Betriebssystem oder proprietäre Google/Apple-Dienste installiert
sind. Da es sich um eine Eins-zu-viele-Kommunikation handelt, gibt es
auch keine Datenschutzbedenken. Diese klaren Vorteile veranlassten
die Europäische Union zu der Entscheidung, das zukünftige <a
href="https://de.wikipedia.org/wiki/EU-Alert">EU-Alert-System</a>
Cell Broadcats basieren zu lassen. Als Richtlinie muss dies von allen
EU-Mitgliedsstaaten bis Juni 2022 umgesetzt werden, es sei denn, ein
Staat kann einen Dienst mit einer ähnlich zuverlässigen Leistung
anbieten - was eine sehr hohe Schwelle ist.
</p>
<p>
Ungeachtet dieser Vorteile hat sich Deutschland im Gegensatz zu
anderen Ländern wie den Niederlanden, Griechenland, Rumänien, Italien
oder den USA dafür entschieden, sein Notfallwarnsystem nicht auf dem
SMSBC-Standard aufzubauen. Da es keine offizielle Verpflichtung dazu
gibt, haben die meisten Mobilfunknetzbetreiber diese Funktion aus
Kostengründen deaktiviert. Stattdessen fallen für den Steuerzahler
wesentlich höhere Kosten an, um ein isoliertes System und
dazugehörige proprietäre Anwendungen zu finanzieren.
</p>
<figure>
<img
src="https://pics.fsfe.org/uploads/big/f790c7602451468f95091e50dc7988d1.jpg"
alt="EU-Alert/NL-Alert Cell Broadcast message" />
<figcaption>EU-Alert/NL-Alert Cell Broadcast-Nachricht aus dem Jahr 2018.
CC-BY-SA-4.0 von WarningMessageDelivery</figcaption>
</figure>
<h2>Warn-Apps</h2>
<p>
Trotz der klaren Vorteile von Cell Broadcasts haben separate
Warn-Apps ihre Berechtigung. Benutzer können verschiedene
Informationen über andere Regionen und vergangene Geschehnisse
einsehen. Einen großen Teil der Notfallkommunikation auf diese Apps
zu stützen, hat sich jedoch als zu anfällig dafür erwiesen, beim
Ausfall einer Komponente komplett zu versagen.
</p>
<p>
Darüber hinaus müssen sie aufgrund ihrer kritischen Rolle für die
Öffentlichkeit <a href="/freesoftware/">Freie Software</a> sein und
auf <a href="/freesoftware/standards/">Offenen Standards</a>
aufbauen. Nur mit den Freiheiten, Software frei benutzen, studieren,
teilen und verbessern zu können, können sie von Bürgern und
unabhängigen Sicherheitsforscherinnen analysiert werden. Das
wiederum erhöht das Vertrauen und die Bereitschaft, eine ergänzende
Warn-App zu installieren, wie die praktischen Erfahrungen mit den
Corona-Tracing-Apps zeigen.
</p>
<h2>Fazit</h2>
<p>
Unsere Analyse schließt mit drei zentralen Ergebnissen, die nicht nur
die verantwortlichen Verwaltungen, sondern auch andere Akteure im
Auge behalten sollten.
</p>
<ul>
<li>
Die Grundlage der Notfallkommunikation von Behörden zu Bürgern
sollte ein standardisiertes, belastbares System bilden, das in der
Lage ist, Millionen von Nachrichten an möglichst viele Geräte zu
senden. Das muss dabei unabhängig von deren Betriebssystem oder installierter
Software sein. Gegenwärtig scheinen SMSBC, also Cell Broadcasts, die
bestmögliche Umsetzung zu sein, die in zahlreichen Staaten gut
funktioniert. Daher begrüßen wir, dass die EU sich dafür
entschieden hat, EU-Alert auf Cell Broadcasts basieren zu lassen.
</li>
<li>
Warn-Apps können eine nützliche Ergänzung sein. Besonders für
öffentlich finanzierte Anwendungen ist es entscheidend, die
Software unter einer Freie-Software-Lizenz zu entwickeln und zu
veröffentlichen, getreu dem Prinzip <a
href="https://publiccode.eu/de">Public Money? Public Code!</a>.
</li>
<li>
Das Testen von Warnsystemen ist wichtig, und die geplanten regelmäßigen Warntage
sollten auch in Zukunft beibehalten werden. Es ist normal, dass bei
diesen Tests Fehler auftreten, aber sie dürfen nicht beschönigt
werden, sondern erfordern eine gründliche Analyse und Verbesserung.
</li>
</ul>
<p>
In diesem Sinne haben die zuständigen Verwaltungen, BBK und BMI, viel Arbeit vor
sich. Aber es ist machbar, sowohl aus praktischer als auch aus
finanzieller Sicht.
</p>
</body>
<tags>
<tag key="front-page"/>
<tag key="de">Deutschlamd</tag>
<tag key="fya">Android</tag>
<tag key="pmpc">Öffentlicher Code</tag>
</tags>
<discussion href="https://community.fsfe.org/t/538"/>
<image url="https://pics.fsfe.org/uploads/medium/7a0203c58e6e11e841072693a1a91eeb.jpg"/>
</html>

193
news/2020/news-20201112-01.en.xhtml Normal file
View File

@ -0,0 +1,193 @@
<?xml version="1.0" encoding="UTF-8"?>
<html newsdate="2020-11-12">
<version>2</version>
<head>
<title>How (not) to set up a public warning system</title>
</head>
<body>
<h1>How (not) to set up a public warning system</h1>
<p>
What is the best way to alert people about catastrophes? Germany went
with proprietary apps which caused the recent warning day ("Warntag")
to become an official failure. We analysed the situation and found
more robust solutions that respect user rights.
</p>
<p>
The basic idea of testing emergency systems is to find potential or
real problems. However, it is remarkable how much went wrong in
Germany's official warning day in September. Especially the <a
href="https://www.dw.com/en/germanys-nationwide-emergency-warning-day-sees-bumpy-rollout/a-54877137">unreliability</a>
of the officially advertised non-free and non-standard apps forced
the Federal Ministry of the Interior (BMI), that is in charge of the
responsible Federal Office of Civil Protection and Disaster
Assistance (BBK), to label the test day as a failure.
</p>
<p>
The FSFE analysed the findings together with experts in civil
protection and mobile networking to figure out why the apps failed,
and what a more resilient and open system can look like.
</p>
<figure>
<img
src="https://pics.fsfe.org/uploads/medium/8a77a3fbd5eb790cf94b2f115f6f94f3.jpg"
alt="A red emergency phone" />
</figure>
<h2>Digital Warning Systems in Germany</h2>
<p>
There are three popular publicly financed apps that can carry
official emergency alerts to their users: Katwarn, Nina, and Biwapp.
All three are proprietary, so non-free
software that does not allow their users to use, study, share, and
improve the software. Moreover, they rely on fetching emergency alerts
from the central <em>MoWaS</em> ("modular warning system"), and forwarding
these to the app users using their phones' WiFi or mobile internet
connection.
</p>
<p>
An overload of this central system was the main reason why many
alerts did not reach the app users in time or at all. This did not
come as a surprise, though. In a scenario where millions of devices
are reached at the same time from a central instance with
one-to-one (<em>unicast</em>) connections, network bottlenecks are
almost inevitable.
</p>
<p>
The underlying problem, however, is unnecessary complexity and duplicated
structures. Instead of investing large amounts of public money into
centralised systems and three proprietary apps, other states run a
more resilient and well-tested infrastructure for distributing
emergency messages: SMSCB, more commonly called <em>cell
broadcasts</em>, to provide one-to-many messages.
</p>
<h2>Cell Broadcasts</h2>
<p>
Standardised around 1990, cell broadcasts are an established method to
send messages to all mobile network users, either in a whole country
or limited to specific areas, in no more than a few seconds. Phones do
not have to be registered in a specific network to receive these
messages, and alerts with the highest priority will ring an
alarm even if the phone is muted. And unlike SMS and mobile internet, cell
broadcasts have a reserved channel that works even if phone cells are
overloaded with users and messages.
</p>
<p>
Furthermore, cell broadcasts can be received by every phone, no
matter whether emergency apps, an up-to-date operating system, or
proprietary Google/Apple services are installed. Because the
communication is one-to-many, there are no privacy concerns either.
These clear benefits made the European Union decide to base the <a
href="https://en.wikipedia.org/wiki/EU-Alert">EU-Alert</a> system on
cell broadcasts. As a directive, this has to be implemented by all EU
member states before June 2022, unless a state can provide a service
with a similarily reliable performance – which is a very high
threshold.
</p>
<p>
Regardless of these advantages, Germany chose to not base its
emergency alert system on the SMSBC standard, unlike other countries
such as the Netherlands, Greece, Romania, Italy, or the USA. Because
there is no official obligation to do so, most mobile network
providers deactivated this feature to save costs. Instead, much
higher costs are incurred by the taxpayers to finance an isolated
system and accompanying proprietary apps.
</p>
<figure>
<img
src="https://pics.fsfe.org/uploads/big/f790c7602451468f95091e50dc7988d1.jpg"
alt="EU-Alert/NL-Alert Cell Broadcast message" />
<figcaption>EU-Alert/NL-Alert Cell Broadcast message in 2018.
CC-BY-SA-4.0 by WarningMessageDelivery</figcaption>
</figure>
<h2>Warning Apps</h2>
<p>
Despite the clear advantages of cell broadcasts, warning apps have
their justification. Users can request various information about
other regions and past events. However, basing a
large part of the emergency communication system on warning apps has proven to be
too prone to single points of failure.
</p>
<p>
Furthermore, because of the critical role of emergency communication systems for the public, they have
to be <a href="/freesoftware/">Free Software</a>, and built upon <a
href="/freesoftware/standards/">Open Standards</a>. Only with the
freedoms to use, study, share, and improve software, can they be
analysed by citizens and independent security researchers. This in
turn increases trust and willingness to install a complementary
warning app, as the practical experience with the Corona tracing apps
shows.
</p>
<h2>Conclusion</h2>
<p>
Our analysis concludes with three key findings that not only the
responsible administrations but also other actors should keep in
mind.
</p>
<ul>
<li>
The foundation of emergency communication from authorities
should be a standardised, resilient system that
is capable of sending millions of messages to as many devices as
possible, regardless of their operating system or installed
software. Currently, SMSBC, or cell broadcasts, seem to be the best
possible implementation that works well in numerous states.
Therefore, we appreciate that the EU chose to base EU-Alert on cell
broadcasts.
</li>
<li>
Warning apps can be a useful complement. Especially for publicly
funded apps, it is crucial to develop and release the software under a
Free Software license, following the principle of <a
href="https://publiccode.eu">Public Money? Public Code!</a>.
</li>
<li>
Testing warning systems is important, and the planned regular warning days
should be maintained in the future. It is normal that errors occur
during these tests, but they must not be glossed over. Instead
errors must be addressed thoroughly.
</li>
</ul>
<p>
In this sense, the responsible administrations, BBK and BMI, have a lot of work
ahead. But it is doable, both from the practical and financial
perspectives.
</p>
</body>
<tags>
<tag key="front-page"/>
<tag key="de">Germany</tag>
<tag key="fya">Android</tag>
<tag key="pmpc">Public Code</tag>
</tags>
<discussion href="https://community.fsfe.org/t/538"/>
<image url="https://pics.fsfe.org/uploads/medium/7a0203c58e6e11e841072693a1a91eeb.jpg"/>
</html>

93
news/2020/news-20201112-01.it.xhtml Normal file
View File

@ -0,0 +1,93 @@
<?xml version="1.0" encoding="UTF-8"?>
<html newsdate="2020-11-12">
<version>2</version>
<head>
<title>Come (non) impostare un sistema di allerta pubblico</title>
</head>
<body>
<h1>Come (non) impostare un sistema di allerta pubblico</h1>
<p>Qual è il miglior modo per allertare la popolazione sulle catastrofi? La Germania ha utilizzato App proprietarie che hanno di fatto reso il recente giorno d'allerta ("Warntag")
un fallimento ufficiale. Abbiamo analizzato la situazione e trovato soluzioni più forti che rispettino i diritti degli utenti.
</p>
<p>L'idea che sta alla base delle prove dei sistemi di emergenza è quella di trovare problemi potenziali o reali. È però degno di nota quanto sia andata male in Germania la giornata ufficiale di prova tenutasi in settembre. Specialmente l'<a href="https://www.dw.com/en/germanys-nationwide-emergency-warning-day-sees-bumpy-rollout/a-54877137">inaffidabilità</a>
delle App non libere e non standard ufficialmente sponsorizzate, ha imposto al Ministro degli Interni (BMI), che è il referente dell'Ufficio responsabile della Protezione Civile e Assistenza ai Disastri (BBK), di etichettare questa giornata di test come un completo fallimento.
</p>
<p>La FSFE ha analizzato i risultati insieme ad esperti della protezione civile e della rete mobile per capire perché le App hanno fallito e da come si potrebbe costituire un sistema più flessibile e aperto.</p>
<figure>
<img
src="https://pics.fsfe.org/uploads/medium/8a77a3fbd5eb790cf94b2f115f6f94f3.jpg"
alt="Un telefono rosso per le emergenze" />
</figure>
<h2>Sistemi di allerta digitali in Germania</h2>
<p>Ci sono tre App finanziate pubblicamente che possono inviare le allerte di emergenza ufficiali agli utenti: Katwarn, Nina e Biwapp. Tutte e tre sono proprietarie, quindi software non-libero che non permette ai propri utenti di studiare, condividere e migliorare il software. Comunque, esse si basano sul prendere i messaggi di emergenza dal sistema centrale <em>MoWaS</em> ("modular warn system", sistema di allerta modulare) e inoltrarli all'App degli utenti utilizzando la connessione Internet WiFi o mobile dei loro smartphone.
</p>
<p>Il motivo principale del perché molti messaggi non sono stati notificati in tempo dall'App o non sono proprio arrivati, è stato il sovraccarico di questo sistema centrale. Non si può di certo esserne sorpresi. In uno scenario dove milioni di dispositivi devono essere raggiunti nel medesimo istante da un singolo sistema centrale con connessioni uno-a-uno (<em>unicast</em>), la rete diventa inevitabilmente un collo di bottiglia.
</p>
<p>Il problema di base è dato da una eccessiva complessità e da strutture duplicate. Invece di investire un'ingente quantità di denaro pubblico in sistemi centralizzati e in tre App proprietarie, altri stati hanno scelto una infrastruttura flessibile e ben testata per distribuire messaggi di emergenza: SMSCB, più comunemente chiamata <em>broadcast di cella</em>, quindi messaggi uno-a-molti.
</p>
<h2>Broadcast di cella</h2>
<p>Reso standard intorno al 1990, i broadcast di cella sono un metodo per inviare messaggi a tutte le utenze mobili, globalmente in tutto il paese o limitatamente a specifiche aree, solo in pochi secondi. I cellulari non devono essere registrati in una rete specifica per ricevere questi messaggi, e i messaggi di allerta con priorità massima fanno squillare il telefono anche quando è in silenzioso. E, a differenza degli SMS e la navigazione Internet mobile, i broadcast di cella utilizzano un canale riservato che funziona anche se le celle sono sovraccariche di utenze e traffico.</p>
<p>Inoltre, i broadcast di cella possono essere ricevuti da qualsiasi telefono, non importa se ci siano o meno installate App di emergenza, o se il sistema operativo è aggiornato, o se sono installati servizi proprietari di Google/Apple. Dal momento che la comunicazione è uno-a-molti, non ci sono nemmeno preoccupazioni a riguardo della privacy. Questi chiari benefici hanno portato l'Unione Europea a decidere di basare il sistema <a href="https://en.wikipedia.org/wiki/EU-Alert">EU-Alert</a> sui broadcast di cella. Come direttiva, questo sistema dovrà essere implementato da tutti gli stati membri UE prima del giugno 2022, a meno che lo stato sia in grado di fornire un servizio con prestazioni simili e affidabili - che però è una soglia molto elevata.</p>
<p>Nonostante questi vantaggi, la Germania ha scelto di non basare il suo sistema di allerta per le emergenze sullo standard SMSBC, come hanno invece fatto altri paesi quali i Paesi Bassi, la Grecia, la Romania, l'Italia o gli Stati Uniti. Siccome non c'è alcun obbligo ufficiale per tenere attivo SMSBC, molti provider di reti mobili disabilitano questa funzionalità per risparmiare denaro. Invece, costi molto più alti sono pagati dai contribuenti per finanziare un sistema isolato e le relative App proprietarie.</p>
<figure>
<img
src="https://pics.fsfe.org/uploads/big/f790c7602451468f95091e50dc7988d1.jpg"
alt="Messaggio di allerta broadcast EU-Alert/NL-Alert" />
<figcaption>Messaggio di broadcast da EU-Alert/NL-Alert del 2018.
CC-BY-SA-4.0 di WarningMessageDelivery</figcaption>
</figure>
<h2>App di allerta</h2>
<p>Al di là degli evidenti vantaggi dei broadcast di cella, le App di allerta hanno comunque motivo di esistere. Gli utenti possono richiedere varie informazioni su altre regioni e sugli eventi passati. Comunque, è stato dimostrato che un sistema di comunicazione di emergenza basato in gran parte sulle App è eccessivamente predisposto a fallire per la fragilità del singolo punto di rottura.</p>
<p>Inoltre, visto il ruolo critico che hanno questi sistemi per le persone, le App devono essere <a href="/freesoftware/">Software Libero</a>, e costruite sugli <a href="/freesoftware/standards/">Standard Aperti</a>. Solo con la libertà di utilizzare, studiare, condividere e migliorare il software, è possibile un'analisi da parte dei cittadini e da parte di ricercatori della sicurezza indipendenti. Questa analisi a sua volta incrementa la fiducia e la volontà di installare un'App di allerta complementare, come ci insegna l'esperienza pratica con le App di tracciamento del coronavirus.</p>
<h2>Conclusione</h2>
<p>
La nostra analisi si conclude con tre punti chiave che non solo le amministrazioni responsabili ma anche altri esponenti dovrebbero tenere a mente.</p>
<ul>
<li><div>Le basi delle comunicazioni di emergenza da parte delle autorità ai cittadini dovrebbero essere formate da sistemi standardizzati e flessibili capaci di inviare milioni di messaggi a quanti più dispositivi possibile, indipendentemente dal loro sistema operativo o dal software installato. Attualmente, SMSBC, o broadcast di cella, sembrano essere la migliore implementazione praticabile che funziona correttamente in numerosi stati. Apprezziamo quindi che l'UE abbia scelto di basare EU-Alert sui broadcast di cella.<br/></div></li>
<li><div>Le App di allerta sono uno strumento complementare utile. Specialmente per le App finanziate pubblicamente, è però cruciale sviluppare e rilasciare il software con una licenza di Software Libero, seguendo il principio di <a href="https://publiccode.eu">Denaro pubblico? Codice pubblico!</a></div></li>
<li><div>È importante testare i sistemi di allerta, ed è bene che la pianificazione di giornate ordinarie di allerta venga mantenuta in futuro. È normale che capitino degli errori durante questi test, ma non devono essere ignorati ed occorre invece che vengano attentamente esaminati.</div></li>
</ul>
<p>In questa direzione, le amministrazioni responsabili, BBK e BMI, hanno molto lavoro da fare. Ma è una cosa fattibile, sia dal punto di vista pratico che finanziario.
</p>
</body>
<tags>
<tag key="front-page"/>
<tag key="de">Germania</tag>
<tag key="fya">Android</tag>
<tag key="pmpc">Codice Pubblico</tag>
</tags>
<discussion href="https://community.fsfe.org/t/538"/>
<image url="https://pics.fsfe.org/uploads/medium/7a0203c58e6e11e841072693a1a91eeb.jpg"/>
<translator>Francesca Indorato e Luca Bonissi</translator>
</html>