Unser kommunaler Schadensmelder - was haben wir aus dem Beta Test gelernt?

3 März, 2021 von Kristina Juse

Nachfolgend beschreiben wir sieben Erkenntnisse aus unserem Beta Test für unseren digitalen Schadensmelder.

Was ist ein Schadensmelder?

Bitte hier entlang zur Erklärung oder hier für das Video: https://youtu.be/WwWrN0-0o3A

Was haben wir aus dem Beta Test gelernt?

Ein Beta Test von einem Monat ist für Kommunen zu kurz, denn es sind der Stadtrat, die Bürgermeisterin, die rechte Hand der Bürgermeisterin, die Bauhofmitarbeiter:innen und die städtischen Angestellten involviert. Das will koordiniert werden.

Die UI ist der erste Eindruck. Die normalen Anwender:innen können nur das beurteilen. Alle Erklärungen mit "ja, ignorieren Sie die Optik mal", wird nur Menschen überzeugen, die sich mit der Entwicklung von Software auseinandersetzen.

Die Anwender:innen bringen sinnvolle Funktionalitäten in die Planung der App mit ein. (Zum Beispiel: GPS Karte für Bauhofmitarbeiter:innen, so dass sie sich einblenden lassen können, wo welcher Schaden liegt und auf dieser Grundlage die Anfahrtsroute optimieren können).

Es ist sehr schwer vermittelbar, Funktionalitätswünsche und essentielle Funktionalitäten getrennt zu betrachten. Die Nutzer:innen wollen ein fertiges Produkt, denn so sind sie das von Ihren B2C Produkten gewohnt. Agile Produktentwicklung funktioniert so aber gerade nicht. In der Auseinandersetzung und Beobachtung in der Interaktion mit dem Produkt und den Nutzer:innen soll geklärt werden, was es braucht. Das verstehen wir unter einem Beta Test. Das heißt, die Nutzerinnen interagieren mit einem Work-in-Progress Produkt. Das ist meist unangenehm, weil wir anstatt einer Aussage “Produktfunktionalität überzeugt nicht” genau wissen müssen, was hätte passieren sollen, damit die Benutzer:innen eine gute Nutzererfahrung gehabt hätten. Das erfordert Zeit und Auseinandersetzung mit dem Produkt - ist also anstrengend. Wir muten den Nutzer:innen viel zu. Findet das nicht ausreichend statt, sind die Nutzer:innen enttäuscht vom Produkt.

Beispiel Schaden melden: Die Gemeinde will die Bürger:innen kategorisieren lassen. Die Bürger:innen melden: “Hallo Gemeinde, hier liegt ein Vandalismuschaden (Licht geht nicht mehr) vor”.

Wir dachten, lasst das nicht die Bürger:innen entscheiden, denn einerseits ist das ein Schritt mehr für die Bürger:innen bei der Meldung eines Schadens und andererseits kann ja ein Vandalismusschaden vom Bauhof als Lampenschaden vermerkt werden. Die Kategorisierung der Schäden überschneidet sich sicher mit der der Bürger, ist aber eben nicht 100% deckungsgleich. Wir hätten die Kategorien erst freigegeben, wenn wir aus der Anwendungsnutzung gesehen hätten, welche Kategorien tatsächlich passen.

Die Bürger:innen wünschen sich Schadensmelder, die Städte sind zurückhaltender, weil sie eine Übernutzung und Schindluder bei einer solchen Anwendung wittern. Ein Schadensmelder muss zudem dementsprechend seitens der Stadt betreut werden.

Außerdem haften die Städte, wenn ein akuter Schaden zu einem Unfall führt. Das heißt, in der Anwendung braucht es einen Hinweis, dass bei schwerwiegenden Schäden (tiefes Loch in der Fahrbahn) gleich die Feuerwehr etc. zu verständigen ist oder der Schadensmelder braucht tatsächlich so etwas wie Öffnungszeiten.

Generell sollten wir uns noch mehr Gedanken über die Verschlüsselung von Daten machen. Auch wenn die Applikation in der Stadt gehostet werden würde - so hatten wir das anfangs geplant - könnten theoretisch Administrator:innen auf die Daten zugreifen. Möchte man dies vermeiden, ist eine End-to-End Verschlüsselung (E2EE) notwendig. Einhergehend damit müsste jedoch das gesamte Konzept darauf ausgelegt werden. Den Administrator:innen müsste trotzdem insoweit vertraut werden, da sie theoretisch Zugriff auf jeden der städtischen Arbeitsrechner haben.

Die weitaus größere Gefahr wäre eine in irgendeiner Form aufgebrochene Datenbank, durch die persönliche Daten in die Umwelt gelangen könnten, sofern sie nicht verschlüsselt sind. Wir gingen fälschlicherweise anfangs nur von der erstgenannten Möglichkeit aus, welche aufgrund der bereits notwendigen Vertrauensbasis mit einer einfachen Transportverschlüsselung erledigt werden würde. Daher sollten die Daten definitiv vor der Ablage verschlüsselt werden. Auch wenn die Datenbank auf dem gleichen Server wie der Webservice laufen würde, hätte es den Vorteil, die Daten bereits im anfragenden Browser zu verschlüsseln: Ein Angreifer mit Zugriff auf den Server müsste "nur" den Arbeitsspeicher lesen können und nicht den Webserver entsprechend anpassen, um den Schlüssel für die Datenbank zu extrahieren. Da mehrere Verwaltungsangestellte Zugriff auf die Datenbank benötigen, um Routen zu planen oder Meldungen an bestimmte Personen zuweisen sollen, müssten mehrere Personen die gleichen Schlüssel kennen. Je größer dieser Personenkreis wird, desto größer wird damit auch die eigentliche Angriffsoberfläche. An dieser Stelle sollten wir uns die Frage stellen, ob sich dieser Aufwand - auch für die Nutzer - lohnt: Ein Schadensmelder ist ein Tool, welches Daten sowieso nur bis zur fertigen Bearbeitung speichern sollte und dabei sollten auch die meldenden Personendaten nicht langfristig gespeichert werden.

Und E2EE ist ungleich HTTPS. Sollten wir auch im Marketing so schreiben...

TL; DR

1. Ein Beta Test von einem Monat ist für Kommunen zu kurz.
2. Die UI ist der erste Eindruck. Anwender:innen gewichten das am meisten.
3. Die Anwender:innen bringen sinnvolle Funktionalitäten in die Planung der App mit ein.
4. Wir haben unseren Betatester:innen viel zugemutet.
5. Bürger:innen wünschen sich Schadensmelder, die Städte sind zurückhaltender.
6. Schadensmelder brauchen Notfallnummern.
7. E2EE ist ein erstrebenswerter Sicherheitsstandard für das Aufheben von Nutzerdaten. Und E2EE ist ungleich HTTPS.