Neues Kapitel zum Thema Datenschutz

[lu-j]

Auf dem Workshop haben wir beschlossen, dass es in der Spezifikation ein neues Kapitel zum Thema Datenschutz geben soll. In diesem Kapitel sollen Empfehlungen an Server-Betreiber und API-Nutzer gegeben werden. Es soll überlegt werden, welche Empfehlungen sinnvoll sind.

Über folgende Empfehlungen haben wir bereits nachgedacht: Als Server-Betreiber sollte man keine Kontaktinformationen der Ratsmitglieder und keine Anwesenheitslisten über die OParl-Schnittstelle ausgeben, es sei denn es liegt eine explizite Erlaubnis vor. Die Erlaubnis könnte über eine Einstellungsmöglichkeit im RIS-System gegeben werden. Als API-Nutzer sollte man Emailadressen aus OParl-Daten nur so in Webanwendungen ausgeben, dass sie nicht leicht von Spambots gesammelt werden können.

Wir freuen uns über weitere Anregungen und Vorschläge für das Datenschutzkapitel.

[akuckartz]

Als Server-Betreiber sollte man keine Kontaktinformationen der Ratsmitglieder und keine Anwesenheitslisten über die OParl-Schnittstelle ausgeben, es sei denn es liegt eine explizite Erlaubnis vor.

Die Öffentlichkeit hat grundsätzlich ein berechtigtes Interesse daran zu erfahren, ob ein Mandatsträger in einer Sitzung anwesend war oder nicht. Wenn diese Information pro Tagesordnungspunkt vorhanden ist, dann hat sie auch daran ein berechtigtes Interesse. Daran würde auch ein Widerspruch eines Mandatsträgers nichts ändern.

EDIT: Allerdings kann aus Anwesenheitsinformationen auch abgeleitet werden, wann jemand in Zukunft wahrscheinlich an anderem Ort abwesend ist. Und das kann problematisch sein.

Als API-Nutzer sollte man Emailadressen aus OParl-Daten nur so in Webanwendungen ausgeben, dass sie nicht leicht von Spambots gesammelt werden können.

EDIT2: Ich habe meine ursprüngliche Einschätzung hierzu revidiert. In einem anderen Issue wurde entschieden, dass auch Web-Browser bei Anforderung der URL das JSON-Dokument und nicht eine HTML-Darstellung ausgeliefert bekommen sollen (was ich nicht gut finde, aber nicht Gegenstand dieses Issue ist). Dann werden auch SPAM-Spider diese JSON-Dokumente erhalten, selbst wenn sie gar nicht nach application/json fragen. Die Wahrscheinlichkeit, dass die Spider diese Texte dann nach mail-Adressen und weiteren URLs durchsuchen halte ich für hoch. Ob die mail-Adressen dann auch unter anderen URLs in HTML-Code auftauchen halte ich dann nicht mehr für entscheidend. Eine wirklich gute technische Lösung gibt es aus meiner Sicht nicht - und es ist ein Problem, was in keiner Weise OParl-spezifisch ist. Deshalb kann es sein, dass dazu bereits in anderen Communities Lösungsansätze erarbeitet wurden.

[akuckartz]

Siehe auch #39 und #271

[the-infinity]

Vorschlag in https://github.com/OParl/spec/commit/185adb2ee45e79260f4b396225d213d6e45cc77f . OK so? Bei den Mailadressen tu ich mir schwer, das geht nicht so richtig sinnig: sobald man ein Cloaking der Mailadressen fest definiert, haben Spammer wieder leichtes Spiel.

[konstin]

Sieht gut aus.

[akuckartz]

Ich kann hier nur noch einmal stark davon abraten, als juristische Laien verbindliche rechtliche Ausführungen in eine technische Spezifikation aufnehmen. Das geht regelmäßig schief.

Über das Deutsche Datenschutzgesetz hinaus sind folgende Punkte zu beachten ... Beim Zugriff auf die Weboberfläche des Ratsinformationssystem ohne OParl-Schnittstelle dürfen nur die personenbezogenen Daten ausgegeben werden, zu denen eine explizite Einveständniserklärung der betreffenden Person vorliegt.

Ein "Deutsches Datenschutzgesetz" gibt es nicht. Es gibt ein Bundesdatenschutzgesetz und eine Reihe von Datenschutzgesetzen von Bundesländern.

Was ist mit "dürfen" gemeint? Dass die OParl-Spezifikation das untersagt? Falls ja: warum?

Jedenfalls verbietet kein Datenschutzgesetz für alle personenbezogenen Daten deren Veröffentlichung auf Webseiten. Triviales Beispiel: die Namen von Mandatsträgern sind ohne jeden Zweifel personenbezogen. Ich nehme an, dass die OParl-Autoren deren Veröffentlichung trotzdem nicht von einer Einwilligung der jeweiligen Personen abhängig machen wollen.

Eine rechtliche Erfordernis für "explizite" Einverständniserklärungen mag es zwar im Einzelfall geben, woher eine solche generelle Erfordernis kommen soll sehe ich aber nicht.

Dasselbe hilt für OParl: Private Daten (Kontaktdaten, Photos, Anwesenheitslisten, ...) dürfen nur dann ausgegeben werden, wenn eine explizite Zustimmung der betreffenden Person vorliegt.

Was sind denn "private" Daten? Sind das andere Daten als "personenbezogene" Daten? Worin besteht gegebenenfalls der Unterschied?

Was bedeutet "dürfen"? Verbietet die OParl-Spezifikation das? Falls nein, wodurch wird dies verboten? Das "Deutsche Datenschutzgesetz" kann es jedenfalls nicht sein, denn die Ausführungen sollen ja darüber hinaus beachtet werden.

Es mag verständliche Gründe geben, warum jemand z.B. nicht auf einer Anwesenheitsliste erwähnt werden möchte. Es gibt aber zweifellos auch gute Gründe, warum die Öffentlichkeit ein berechtigtes Interesse an solchen Informationen hat - auch und gerade in maschinenlesbarer Form. Möchten die OParl-Autoren wirklich entscheiden, wessen Interessen hier vorgehen? Was passiert, wenn z.B. ein Stadtrat entscheidet, dass das für sein Gremium anders gemacht wird, wird dann gegen die Spezifikation verstossen?

Zusammenfassung: Ein allgemeiner Hinweis auf Datenschutzaspekte mit Beispielen für möglicherweise datenschutzrelevanten Fragestellungen ist hilfreicher. Auch nicht fehlen sollte die Empfehlung, dass der zuständige Datenschutzbeauftragte möglichst frühzeitig beteiligt wird.

[konstin]

Zusammenfassung: Ein allgemeiner Hinweis auf Datenschutzaspekte mit Beispielen für möglicherweise datenschutzrelevanten Fragestellungen ist hilfreicher.

Nach meiner Lesart ist der Text überhaupt nicht als genaue juristische Ausführung zu sehen, sondern als Hinweis, was wegen des Datenaschutzes beachtet werden muss. Dabei mag einiges unpräzise formuliert sein, aber der Text erfüllt seinen Zweck, nämlich auf die rechtlichen Probleme bei der Verwendung personenbezogener Daten hinzuweisen.

Auch nicht fehlen sollte die Empfehlung, dass der zuständige Datenschutzbeauftragte möglichst frühzeitig beteiligt wird.

Das könnte wirklich noch ergänzt werden. Auch sollte der Satz "Über das Deutsche Datenschutzgesetz hinaus sind folgende Punkte zu beachten:" entfernt werden, da der nächste Abschnitt nicht über den gesetzlichen Datenschutz hinausgeht, sondern sich auf diesen bezieht.

[the-infinity]

@konstin hat Recht: Das soll keine juristische Abhandlung sein. Das soll einfach ein Hinweis sein, dass man bei einigen Punkten datenschutzrelevante Themen streift, und diese grob benennen. Einen Hinweis auf den Datenschutzbeauftragten werde ich morgen noch einbauen, das ist eine gute Idee. Und ich werde eine leichte Reformulierung vornehmen, um die Verpflichtung da rauszunehmen, sondern den klaren Hinweischarakter herauszustreichen.

[the-infinity]

So. Neuformulierung: https://github.com/OParl/spec/commit/3588b321e88aec7da082cd25abe47b54a337147c

• Datenschutzbeauftragter drin
• Indirekte Formulierung, welche mehr den Hinweischarakter herausstreicht

Besser? :)

[eFrane]

Sollten wir das Kapitel vielleicht nicht eher "Anmerkungen zum Datenschutz" nennen? Das würde von vornherein klarstellen, dass wir keinerlei Anspruch auf Vollständigkeit und aktueller juristischer Korrektheit der Information in diesem Kapitel erheben.

[the-infinity]

Im Titel fänd ich das komisch, aber als Klammer durchaus sehr sinnvoll. Siehe https://github.com/OParl/spec/commit/9cece7bfa1d60b1ae69f8a3662307e5da30f9026 .

[akuckartz]

Keine Einwände von mir zu den Änderungen.

[the-infinity]

Dann wohl mal eine & closed. :)