Projekte/Datenschutz

Muster-Entwürfe

Hier sind Entwürfe zu datenschutzrechtlichen Dokumenten, die auf den Mustern der WKO basieren:

• Datei:Datenschutzerklärung Entwurf.pdf

• Datei:Auftragsdatenverarbeitungsvertrag Muster.pdf

• Datei:Datenschutzerklärung Entwurf 01.pdf

• Datei:EU-DSGVO-MUSTER-Verarbeitungsverzeichnis-Verantwortlicher.pdf

Grundsätzlich

• Werden Dienste auf Servern außerhalb des Funkfeuer-Servers gehostet? Wenn ja, wir brauchen Datenauftragsverarbeitungsverträge.
• Eine Liste der Personen, welche die unterschiedlichen Dienste/Funktionen betreuen, Admin-Rechte haben und Zugriff auf personenbezogene Daten (Name, E-Mailadresse, IP-Adresse, GPS-Daten etc.) – Zwar spricht § 6 DSG nur von „Mitarbeitern“, aber darunter fallen auch ehrenamtliche Mitarbeiter eines Vereins -> Verpflichtungserklärung zum Datengeheimnis wird benötigt (Anm.: Wir sollten das mit der Aufnahme als ao/o Mitglied mit abfragen

• Gibt es ein Verarbeitungsverzeichnis?

(Anm.: Ich glaube wir erstellen das hier gerade neu, so ausführlich wie das hier zugeht)

Social Media

• Facebook
• Twitter
  • Wir brauchen da auch Datenschutzhinweise, wer betreut das?
  • Gibt es nochmehr Social media Auftritte? Youtube?

Kategorien von Knoten-Inhabern

• Name, Adresse, Telefonnummer/Handy, E-Mail, Fax, IP-Adresse (von Geräten am Standort, nicht Endgerät)
• SSID (WLAN-Name) als optionale Angabe zu einem Device

Mitglieder

• Name, Adresse, E-Mail, Telefonnummer, Nickname = Nutzername, Passwort

Bildergalerie im Wiki

• https://gallery.funkfeuer.at/
• PROBLEM: Recht am eigenen Bild (verfassungsrechtlich und europarechtlich geschützt & Datenschutz)
  • 1. Warum kann ich nicht-eingeloggt Fotos von Personen sehen?
  • 2. Gibt es Einwilligungserklärungen der Personen, die dort sichtbar sind?

Wir haben/hatten eine Einwilligungsseite beim Hochladen/Registrieren, (Anm. stratuscumulus: Hoffe die Einwilligungen wurden gespeichert, wenn selber hochgeladen umso besser) und die meisten Fotos sind von den abgebildeten selber hochgeladen worden, bzw. sind die abgebildeten Personen Gründer/Vorstandsmitglieder des Vereins. Das hiervon ausgehende Risiko einer Rechtsverletzung ist also sehr überschaubar. Auf explizite, schriftliche Einwilligungserklärungen haben wir bisher (bewusst) verzichtet. (Anm. stratuscumulus: Wenn Bilder angefertigt werden, am besten gleich solch eine Einwilligungserklärung unterzeichnen lassen, bewusst würde ich keinesfalls darauf verzichten, das ist sehr problematisch)

Map 1 "BaseMap"

• Fragen:
  • Worauf basieren die Maps? Google/Open Street Maps? [Pocki: Google-Maps]
  • Wie sind diese damit verbunden? [Pocki: Map-Javascript API lädt Google-Map]
  • Wer hat einen Google-Account der die Maps damit verbindet? [Pocki: API-Key wurde dankenswerter Weise von wnagele zur Verfügung gestellt]
  • Werden die Daten, die den Nodes zugeordnet werden auch an Google o.ä. weitergeleitet? [Pocki: Nein]
  • Wie funktioniert die Map an sich? Wie werden die Verbindungen/Nodes darauf angezeigt? [Pocki: Node-Daten werden von Redeemer geladen, IP-Adressen aus der Topologie damit verschnitten, dann mittels Javascript Geomarker und Linien als Overlay beim Client auf die Map gelegt.]
• Wem der Node gehört
• GPS-Daten
• Geräte / IP-Adressen

• Node:
  • Name: (Smokeping-Link)
  • NodeId:
  • Typ: normal
  • Lat.:
  • Lon.:
  • User:
  • Adresse:
  • E-Mail:
  • Technischer Kontakt:

Map 2 "NodeMap"

• Map 2:
  • Node Information
  • Node ID:
  • Hex Node ID:
  • Node Prefix v642:
  • Node Name:
  • Coordinates:
  • Node Status:
  • Node Type:
  • Node Technical Contact:
  • Owner:
  • Address:
  • E-Mail:
  • Amount of Links:
  • local device partner device other node distance ETX
  • Amount of Devices:
  • Devices:

Map 3 "IPv6@OLSRv2"

https://ff.cybercomm.at/monitor/olsr.php -> Was ist das? [Pocki: Kann unter https://wiki.funkfeuer.at/wiki/Benutzer:Pocki#OLSRv2_Status genauer nachgelesen werden. Zusammengefasst: Informationen aus der Map1-API (IP-Adressen, Knotenname und Geolocations *ohne* Kontaktdaten, erfordert einen User-Login) werden mit der OLSRv2-Topologie verschnitten und (wo möglich) die Zugehörigkeit der IPv6-Adressen zu Knoten versucht. Das Ergebnis wird (ähnlich der Map1-BaseMap) mittels Javascript auf einer Google-Map dargestellt.]

Smokeping?

Hier könnte man sagen, dass man aus den Auslastungsdaten von Links Benutzungsmuster ablesen kann. Allerdings sind die wenigsten Knoten klar nur einer Person, oder auch nur einem Haushalt zuzuordnen.

Das ist wohl der Punkt für die spannendste Diskussion von allen, da hier die Entwicklung des Netzes direkt einem etwaigen Schutz gegenübersteht. Ohne diese Daten kann man ein Netz nicht planen, weiterbauen. Mit diesen Daten (wenn erweitert um einzelne Interfaces) kann ich den Datenverbrauch der einzelnen Personen versuchen zu rekonstruieren.

Bankdaten

• Evtl. Housing? Braucht was eigenes, da ja etwas anderes als der eigentliche Vereinszweck (<Housing ist Bestandteil und Hilfsbetrieb des Vereinszwecks).
• Nur Firmen oder auch Privatpersonen, die dort ihren Server haben?

Forum

• Bild – warum auch sichtbar, wenn man dort nicht eingeloggt ist? – Bedarf einer Information
• Nickname, Name, Standort (Woher), Website, Mitglied seit wann, letzter Beitrag, Aufrufe, wann zuletzt eingeloggt
• Statistik: Wie oft vorbeigekommen, wie lange, welche Themen betrachtet/gelesen/erstellt/bester Beitrag, häufigste Antworten an, likes für/von/Abzeichen

Allgemein

Wir nutzen Riot für die Nah-Zeit-Kommunikation, wie in der Vor-Mobile-Ära IRC. Hierbei betreiben wir keinen eigenen Server, sondern nutzen ein föderiertes System, ähnlich e-Mail. D.h. Jeder Teilnehmer wählt selber seinen "home-Server" aus, und verbindet sich mit diesem. Die Kommunikation kann auf Wunsch der Beteiligten E2E verschlüsselt werden, und ist dann nach dem derzeitigen Erkenntnisstand wirklich das, was man von E2E erwartet.

Hierbei werden von der Gemeinschaft keine Daten bereitgestellt, und auch der Verein tritt nicht förmlich auf. Wir nutzen den Service quasi wie ein Gasthaus, bei dem wir keine Visitenkarte hinterlassen, aber einen Tisch auf den Namen Funkfeuer bestellt haben (Anmerkung: So, genug Metaphern).

Fragen

• Chatraum
• Bilder, Nickname, welche Endgeräte
• ?
• Verifikation?
• Über welchen Server läuft Riot
• Wer hat Zugriff?

Interne Datenbank

• Mitgliederdaten: Nur die vom Formular und den Nodes oder mehr?

• Werden E-Mails dort gespeichert?

• Was und wie lange speichert ein evtl. Mailserver?

• Was ist mit dem Redeemer? Was wird dort außer die angezeigten Felder noch gespeichert? [Pocki: nachstehend die Datenfelder der Redeemer-Tabellen (zwecks Lesbarkeit/Verständnis teilweise vereinfacht)]
  • MEMBERS: nickname, hash-of-password, firstname, lastname, street, housenumber, zip, town, email, (optional: telephone, mobilephone, fax, homepage), (depricated/empty: mentor_id, instant_messenger_nick), created, changed, last_login, Mitgliedsstatus, Adminstatus
  • VERIFY: hash-of-email, status-code-of-mailserver, catch_all-status, debug-text-last-mailserverresponse, last_checked
  • NODES: owner, tech_c, (optional:gps), [_]map, [_]smokeping, created, changed, last_seen
  • DEVICES: Node, Name, (optional: Antenne, Hardware, Ssid, Mac), [_]Smokeping, created, changed, last_seen
  • IP: Node/Device, IPv4, [_]Dns, last_seen
  • IP6: Node/Device, Name, IPv6, (optional: Antenne, Hardware, Ssid, Mac), [_]Smokeping, [_]Dns, created, changed, last_seen

• Ist das LDAP damit verbunden? [Pocki: ja, das LDAP-Verzeichnis wird täglich aus einem Teil der Redeemer-Memberdaten erstellt]

• Welche Dienste werden mittels LDAP verifiziert? [Pocki: voip. Auf Userwunsch: Forum]

Mailinglisten

Allgemein

Wir betreiben einen eigenen Mailing-Listen-Server, auch um hier selber Sicherheit für die Archivierung zu sorgen. Viele Geschehen der Vereinsgeschichte sind fast nur hier abgebildet. Hierbei gibt es öffentliche Listen, wie discuss, wien (und ggf. andere geographische Listen), und geschlossene, die der Koordination in der Gemeinschaft dienen. Hierbei werden aber auch über diese Archive angelegt, zwecks der Transparenz der Arbeit in der Zukunft.

• Wer hat Zugriff auf E-Mails, Namen?

Die Archive sind für die jeweiligen Mitglieder einsehbar.

• Was wird dort alles bearbeitet?

Wir versuchen dort eine sachliche Diskussion für das jeweilige Listethema einzuhalten.

• Wieso ist die Wien-Liste öffentlich und die Vorstandsliste nicht? Ich halte das aus datenschutzrechtlicher Sicht für problematisch, da dort über Nodes und Leute diskutiert wird, was evtl. auch schädigend sein kann.

(Anmerkung: Wieso öffentlich, oder wieso nicht öffentlich?)

Website

Allgemein

AFAIK wurde das Logging der Webseite beendet. Das ist insofern problematisch, als wenn wir eine mehr dynamischere Webseite bauen würden, wir Fehlermeldungen nicht mehr sinnvoll verarbeiten können. D.h. in der Folge eines Beschlusses für eine dynamische Webseite, müssen wir festlegen welche Felder wir wie lange speichern können wollen. Vielleicht sollten wir auch bei öffentlichkeitswirksamen Maßnahmen eine sinnvolle on-premise Speicherung von pseudonymisierten Statistikdaten (wie piwik) überlegen, um unsere Maßnahmen bewerten zu können.

Eine Kontrolle des Status Quo steht aus.

Fragen

• IP-Adresse
• User Agent
• besuchte Webseite
• verwendeter Browsertyp/Browserversion
• verwendetes Betriebssystem
• die zuvor besuchte Seite
• Hostname des zugreifenden Rechners
• Uhrzeit der Serveranfrage
• Menge der gesendeten Daten

Wiki-Account

• E-Mail, Username, Passwort
• Wer wann was eingetragen(geändert hat
• Wie findet die Verifikation statt?

Findet nicht allgemein statt. Es wurde nur ein Zugangssystem aktiviert, um den um sich greifenden Wiki-SPAM Herr zu werden, weil CAPTCHAs mühsamer, und nicht barrierefrei sind.

• Problem: Warum gibt es ein neues und ein „OldWiki“?

Hier wurde ein anstehender Neustart bei Softwareversion und Inhaltskoordination genutzt, um neu zu starten.

• • Gleiche Fragen wie oben

Cookies

• Nur beim Einloggen - > Hinweis beim Einloggen erforderlich, eigentlich bräuchte man ein Cookie-Banner, da aktive Einwilligung erforderlich
• Bei welchen Diensten finden sich Cookies?

GitHub

• Wie wird das genutzt?

GitLab

• Wie wird das genutzt?

Hinweis zur Stellung von Datenschutzbeauftragten/-koordinatoren

Artikel 37 DSGVO

(1) Der Verantwortliche und der Auftragsverarbeiter benennen auf jeden Fall einen Datenschutzbeauftragten, wenn

[...]

b) die Kerntätigkeit des Verantwortlichen oder des Auftragsverarbeiters in der Durchführung von Verarbeitungsvorgängen besteht, welche aufgrund ihrer Art, ihres Umfangs und/oder ihrer Zwecke eine umfangreiche regelmäßige und systematische Überwachung von betroffenen Personen erforderlich machen, oder

c) die Kerntätigkeit des Verantwortlichen oder des Auftragsverarbeiters in der umfangreichen Verarbeitung besonderer Kategorien von Daten gemäß Artikel 9 oder von personenbezogenen Daten über strafrechtliche Verurteilungen und Straftaten gemäß Artikel 10 besteht.

[...]

(4) In anderen als den in Absatz 1 genannten Fällen können der Verantwortliche oder der Auftragsverarbeiter oder Verbände und andere Vereinigungen, die Kategorien von Verantwortlichen oder Auftragsverarbeitern vertreten, einen Datenschutzbeauftragten benennen; falls dies nach dem Recht der Union oder der Mitgliedstaaten vorgeschrieben ist, müssen sie einen solchen benennen. Der Datenschutzbeauftragte kann für derartige Verbände und andere Vereinigungen, die Verantwortliche oder Auftragsverarbeiter vertreten, handeln.

[...]

Artikel 38 DSGVO

(1) Der Verantwortliche und der Auftragsverarbeiter stellen sicher, dass der Datenschutzbeauftragte ordnungsgemäß und frühzeitig in alle mit dem Schutz personenbezogener Daten zusammenhängenden Fragen eingebunden wird.

(2) Der Verantwortliche und der Auftragsverarbeiter unterstützen den Datenschutzbeauftragten bei der Erfüllung seiner Aufgaben gemäß Artikel 39, indem sie die 'für die Erfüllung dieser Aufgaben erforderlichen Ressourcen und den Zugang zu personenbezogenen Daten und Verarbeitungsvorgängen' sowie die zur Erhaltung seines Fachwissens erforderlichen Ressourcen zur Verfügung stellen.

(3) Der Verantwortliche und der Auftragsverarbeiter stellen sicher, dass der Datenschutzbeauftragte bei der Erfüllung seiner Aufgaben 'keine Anweisungen bezüglich der Ausübung dieser Aufgaben erhält'. Der Datenschutzbeauftragte darf von dem Verantwortlichen oder dem Auftragsverarbeiter wegen der Erfüllung seiner Aufgaben nicht abberufen oder benachteiligt werden. Der Datenschutzbeauftragte berichtet unmittelbar der höchsten Managementebene des Verantwortlichen oder des Auftragsverarbeiters.

[...]

(6) Der Datenschutzbeauftragte kann andere Aufgaben und Pflichten wahrnehmen. Der Verantwortliche oder der Auftragsverarbeiter stellt sicher, dass derartige Aufgaben und Pflichten nicht zu einem Interessenkonflikt führen.

Siehe dazu auch [1]