Transparenz, Datenschutz und Trolle in Digitalen Städten

Nachdem wir im letzten Blogpost ausführlich über funktionale Anforderungen („Was soll die Software tun“) an unseren Mängel- und Anliegenmelder berichtet hatten, soll es diesmal also vor allem um nicht-funktionale Anforderungen und damit um das „Wie soll die Software dies tun“ gehen.

Eine sehr bedeutsame nicht-funktionale Anforderung an jede Software ist zweifelsohne der Schutz der personenbezogenen Daten und Meta-Daten der NutzerInnen. Dies gilt um so mehr für Software mit der die demokratische Partizipation von BürgerInnen gestärkt werden soll, schließlich soll sich die erhoffte Wirkung nicht durch gegenteilige Seiteneffekte ad absurdum geführt werden. Seit dem 25. Mai wird die neue EU-Datenschutzgrundverordnung (DSGVO) in ganz Europa angewendet und während es für klassische zentrale IT-Dienste halbwegs klar zu sein scheint, welche Schritte hier angebracht und notwendig sind, ist es für offene, dezentrale und verteilte IT-Systeme wie unserem Mängel- und Anliegenmelder, dem alt bekannten Usenet News System (NNTP), oder auch verteilten Sozialen Netzen wie Mastodon oder GNU Social bislang eher unklar wie der Schutz personenbezogener Daten, Meta- und Logdaten (ePrivacy-Verordnung) und ein Recht auf Vergessen ohne jede Form einer einfachen zentralen Durchsetzbarkeit von Regeln funktionieren könnte.

Chris Bourg „Open as in dangerous“

Schon in der Beschlussvorlage der Piratenpartei zum Mängelmelder im Stadtrat war die Forderung nach einer möglichst niederschwelligen und anonymen Benutzbarkeit des städtischen Mängel- und Anliegenmelders aufgestellt worden. Dies wurde zwar von allen Seiten begrüßt, führte im Stadtentwicklungsausschuss aber auch zu der nachvollziehbaren Frage wie wir in diesem Fall eine missbräuchliche Verwendung des Mängelmelders durch „Internet-Trolle“ verhindern oder zumindest erschweren würden. Wie man sich unschwer vorstellen kann, war damals niemand so wirklich an einer technischen Erläuterung unseres Ansatzes interessiert 😉 Dennoch ist diese Frage natürlich richtig und wichtig!

Neben diesen gesetzlichen Vorgaben wird ein all zu „naiver“ Umgang mit Transparenz und Offenheit jedoch auch von anderen Seiten aus mehr und mehr kritisiert. Amira Dhalla (Mozilla) schreibt:

Open is great. Open can be the future. If, and only when, we prioritize structuring it as a movement where anyone can participate and protecting those who do. Until then open will be something that in unattainable by the masses and only open or abused by those in power.

Doch wir wollen hier ja keine philosophischen Grundsatzdiskussionen starten, sondern nur reflektieren, was diese beiden externen Anforderungen für unser Mängel- und Anliegenmeldeprojekt bedeutet.

Grundsätzlich kann das Melden eines Problems natürlich vollständig anonym erfolgen. In der Praxis scheint dies allerdings weniger das zu sein, was BürgerInnen, Städte und private Organisationen von einem sinnvollen Mängel- und Anliegenmelder erwarten würden.

  1. Gemeldete Mängel weißen häufig falsche oder fehlende Informationen auf. Eine Rückfragemöglichkeit beim mängelmeldenen Bürger wäre also wünschenswert. Dies kann aber auch indirekt über Pseudonyme etc.pp erfolgen. Eine Rechtfertigung personenbezogene Daten wie Telefonnummern, E-Mail-Adressen oder eine Verknüpfung mit einem Bürgerkonto zu verlangen ergibt sich hieraus nicht.
  2. Wie glaubwürdig sind gemeldete Mängel? Um Spam und Missbrauch des Mängel- und Anliegenmeldern zu vermeiden wäre es wünschenswert, wenn eine Mängelmeldung weitere Informationen beinhalten würde, welche helfen diese Frage zu beantworten. Dies könnten natürlich klassische personenbezogene Daten wie Telefonnummern, E-Mail-Adressen oder eine Verknüpfung mit einem Bürgerkonto sein.
  3. In Verbindung mit 2. steht natürlich auch der Identitätsdiebstahl. Auch wenn der Schaden ausgehend von falschen personenbezogenen Angaben bei einer (falschen) Mängelmeldung eher übersichtlich sein dürfte, so ist es für den/die betroffene BürgerIn doch eher unerfreulich bis hin zur Belästigung, wenn so etwas zu einfach möglich wäre. Dies bedeutet natürlich auch, dass der Mängelmelder nicht als indirektes Angriffswerkzeug missbraucht werden können darf, um z.B. das Handy nachts um 3:00 Uhr mit SMS-Bestätigungsanfragen für gemeldete Mängel zu bombardieren.
  4. Der/die mängelmeldende BürgerIn soll ja ermuntert werden möglichst einfach, möglichst viele Mängel zu melden und dies unter Umständen auch von verschiedensten Endgeräten aus zu erledigen. Gleichzeitig will die/der BürgerIn auch Informationen über die selbst gemeldeten und über andere aktuelle Mängel erfahren. Hierdurch ergibt sich die Anforderung für Benutzerkonten die gewisse Einstellungen und Informationen speichern können. Doch wo sind diese gespeichert? Auf den gleichen Servern? Auf anderen Servern? Nur auf den eigenen Geräten? Wie gelangt ein Benutzerkonto von einem Gerät auf ein neues Gerät? Was tun, wenn alle Geräte verloren gegangen sind?
  5. Prinzip bedingt werden alle Mängelmeldungen als OpenData veröffentlicht, an jeden weitergeleitet der sich hierfür interessiert und jeder kann und darf diese für eigene Analysezwecke weiter nutzen. In Verbindung mit 1. und 2. wäre es deshalb wichtig den/die BürgerIn selbst entscheiden zu lassen, wie viel personenbezogene Daten er/sie gegenüber wem offenbaren will. So könnte es ja sein, dass jemand seine Kontaktdaten, die genaue Uhrzeit und Geokoordinaten einer Mängelmeldung gegenüber der Stadtverwaltung oder dem Kommunalservice offenbaren will, nicht jedoch gegenüber der Allgemeinheit. Zu jeder Mängelmeldung könnte es also verschiedene „Sichten“ mit unterschiedlichen Datenschutzanforderungen geben.