Für Nutzungs- und/oder Datenschutzvereinbarung: Welche Daten erfasst der OBS?

Hilfe / Support Portal & Datenverarbeitung
#1

Zu unserer Communinty-Diskussion heute mit u.a. @zoe @gluap @thomaso @boldt @SubOptimal: Hier aus dem Entwurf einer viel zu umfangreichen Datenschutzvereinbarung (die u.a. alle Datenverarbeitungen beschreibt) die Daten, die der OpenBikeSensor in Reinform erfasst.

Das Gerät „OpenBikeSensor“ erfasst die folgende Daten:

  1. Zurückgelegte Fahrtrouten:
    • Der Fahrtverlauf enthält die GPS-Position, Geschwindigkeit und Bewegungsrichtung des Geräts
    • die aktuelle Zeit in regelmäßigen Abständen während der Fahrt, üblicherweise ein Datenpunkt pro Sekunde.
  2. Abstandswerte: So oft wie technisch möglich misst das Aufzeichnungsgerät mit den verbauten Ultraschallsensoren die Abstände nach links und rechts zu anderen Objekten.
  3. Metadaten des Gerätes:
    • Akkuspannung
    • GPS-Status (Anzahl Satelliten, Empfangsqualität)
    • Geräte-ID
    • technische Ereignisse
    • ID der Aufzeichnung
  4. Die (per Knopfdruck) bestätigten Überholvorgänge (Einzelner Datensatz aus den o.g. Daten mit Metadatum „Dies ist ein Überholvorgang“)
  5. Am Gerät vorgenommene Einstellungen, z. B.
    • Lenkerbreite
    • aktiviertes Bluetooth
    • Fahrradtyp oder andere durch die:den Nutzer:in vorgenommen Einstellungen aus der Konfiguration des Sensors

Der letzte Punkt ist allgemein gehalten, da er ggf. auch künftige Firmware-Anpassungen der Konfiguration abdecken sollte.

Der Nutzer kann am Gerät „Privatsfphärezonen“ erstellen und auswählen, ob in diesen überhaupt daten erfasst werden sollen und wenn ja welche (z.b: Keine Position, Position nur bei Überholvorgängen, keine Daten).

edit by @gluap: Ergänzt: Fahrtrichtung, Geschwindigkeit, Formatting, Privacy zones

3 „Gefällt mir“
#2

Die Datensammlungssfotware „Portal“ speichert folgende Daten:

  • Alle vom OpenBikeSensor übermittelten erfassten Daten - Die rohen Trackinformationen sind standardmäßig nur und für den Nutzer selbst nach Login zugänglich.
  • E-Mail Adresse des Nutzers, Nutzername des Nutzers.

Die Datensammlungssfotware „Portal“ Ermöglicht öffentlichen Zugang zu folgenden Daten:

  • Datum, Uhrzeit, Position und Abstandsdaten von markierten Überholvorgängen
  • Verschiedene Visualisierungen der Überholvorgänge
  • Analyse aggregierter Daten aus den Tracks aller Nutzer, z.b. der Befahrungshäufigkeit von Strecken (Zeitunabhängig und ohne Nutzerbezug).

Technisch hat der Betreiber (wie bei den meisten Datenerfassungssystemen) Zugriff auf die Rohdaten („Tracks“) der Nutzer, und kann diese im Rahmen der Nutzungsrechtsabtretung weiter nutzen oder in anderen Formen veröffentlichen. Er sollte im Rahmen der Datenschutzerklärung erklären, in wie fern er von dieser technischen Möglichkeit gebraucht macht und welcher Personenkreis Zugang hat.

Das OpenBikeSensor Projekt strebt eine Veröffentlichung anonymisierter Daten unter der OpenDatabaseLicense an.

#3

Auch wichtig: Die Angaben werden in „lesbarem Format“ (hier: CSV, comma separated values) gespeichert.
Außerdem wird die verwendete Firmwareversion in der Headerzeile gezeigt.

#4

Hallo zusammen,

ich nehme gerade unser Portal in Betrieb und versuche dieses möglichst so zu konfigurieren, dass es möglichst Datenschutzkonform ist. Dabei stellen sich einige Fragen, die nach meinem aktuellen Verstädnis im Widerspruch zu den bisherigen Aussagen stehen.

Änderung des Usernamen: Wir hatten für die ersten Tests noch nicht die Option den Usernamen frei zu wählen, so dass die Mailadresse der Nutzername war. Nun wurden die ersten Tracks hochgeladen und tauchen als Erstellt von john.doe@mailing.com auf.
Mittlerweise haben wir die Loginnamen geändert, bei den bisherigen Tracks bleiben diese gleich.
Wie können wir dieses ändern, so dass keine Mailadressen mehr erscheinen.

Blockzitat
Die rohen Trackinformationen sind standardmäßig nur und für den Nutzer selbst nach Login zugänglich.

Im Portal stehen die bisherigen Testfahrten unter Fahrten>Öffentliche Fahrten bereit. Das ist einigen Nutzern nicht so wirklich lieb.
Wie muss das Portal oder der OBS konfiguriert werden, damit

  • Überholvorgänge mit Abstand und Uhrzeit verfügbar sind
  • Nur der Nutzer seine Fahrten sehen kann
  • Analysen aggregierter Daten ohne Nutzerbezug möglich sind?

Wie kann dies nachträglich noch geändert werden?

Können die Rohdaten durch die Admins eingesehen und ggf. geändert/gelöscht werden? Oder muss das jeder Nutzer selbst? @gluap schreibt der Betreiber hat Zugriff darauf.

Wie kann ein Backup der Daten erfolgen?

Wie können die Daten anonymisiert veröffentlicht werden? Gibt es hierzu schon ein Verfahren? Ein reiner Datenbank-Dump dürfte nicht anonymisiert sein.

Danke und viele Grüße
Markus

#5

@markus um die Tracks nur für den Nutzer sichtbar zu machen, darf das Häkchen „track veröffentlichen“ nicht gesetzt werden. (Default ist nicht öffentlich)

Screenshot_20220907-071023~2
Screenshot_20220907-071023~21080×353 24.7 KB

Überholvorgänge mit Abstand und Uhrzeit sind immer anonymisiert verfügbar, z. B. Über den json Export. Sie werden auch auf der öffentlichen Karte angezeigt. Unabhängig von Sichtbarkeitseinstellung des tracks.

Es gibt keinen sinnvollen Weg zu verhindern dass ein serveradmin auf die Daten auf seinem Server zugreifen kann. Er kann die Daten deshalb immer einsehen und verändern. Ein Admininterface dafür gibt es derzeit nicht.

Die Nutzernamen werden nur von Nutzern öffentlich angezeigt, die Tracks veröffentlichen. Wenn das ein Problem ist müsste der admin vermutlich den nutzernamen in der Datenbank anpassen.

Zu backup gibt es einen Abschnitt in der deployment doku:

#6

Moin,
Danke für die Info.
Dass immer einer den God-Mode hat ist soweit klar und ist denke ich kein Problem.
Mit ist noch unklar wie der Admin die Daten einsehen und ändern kann. Muss er dafür in die Datenbank?

Nutzernamen von Tracks werden demnach nicht als Referenz auf den Usernamen, sondern „hart“ bei Upload in den Track kopiert und statisch gespeichert?
Könnte man dafür nen Change Request stellen um es zu ändern?

Danke und Grüße
Markus

#7

Hat denn der Nutzer unter seinem neuen Namen noch Zugriff auf die alten tracks und kann z. B. Die Sichtbarkeitseinstellung ändern? Ich vermute nein, da ich annehme dass beim Ändern des Namens ein neuer Nutzer erstellt wurde, also jetzt ein verwaister Nutzereintrag mit dem alten Namen in der Datenbank liegt. Grund: die track Tabelle speichert den nutzernamen gar nicht sondern verweist auf die nutzerzeile in der nutzertabelle.

Um das Problem zu lösen, müssten dann die Tracks dem neuen Nutzer zugeschrieben werden. Ehrlich gesagt ist das Problem selten genug dass ich empfehlen würde es in der Datenbank zu lösen. Es würde reichen die author_id aller tracks und ggf. comments des Betroffenen usernamens auf die id seines neuen äquivalents zu ändern. Falls der admin schwer zu greifen ist und es nur um ein paar tracks geht wäre auch folgender weg möglicherweise gangbar um das Ziel „mailadresse aus trackliste putzen“ zu erreichen:

  • neuen user mit dem alten unerwünschten namen im keycloak erstellen
  • in portal einloggen, tracks runterladen und löschen (=>mailadresse verschwindet von Webseite)
  • als neuer Nutzer einloggen und die gerade herunter geladenen nun fehlenden tracks wieder hich laden.
    Ausloggen

Und möglichst nur bei tracks „veröffentlichen“ bei denen es um den track als solches geht.

Ein feature was ich mir für euer Problem vorstellen könnte was man vorschlagen könnte wäre ein „do not display my username publicly“ flag.

#8

In unserem Portal ist kein Track automatisch public.

Technisch hat ein User nach dem Ändern des Usernamens in KeyCloak die gleiche UUID, d.h. er ist weiterhin eindeutig zu identifizieren. Vielleicht sollten wir bei den Tracks nur die UUID speichern und sie Userdaten separat halten. So könnte man bei einem Login einfach den aktuellen Username aus dem JWT-Token lesen und ersetzen.

@opatut wie läuft das derzeit?

#9

Die Dateien liegen im Dateisystem unter tracks/${username}/${trackId}/original.csv. Das ist so, damit Admins es leichter haben am Ende, falls z. B. die Datenbank futsch ist oder man damit als Forschungsprojekt arbeiten will, die Tracks wieder jemandem zuzuordnen. Username ändern ist nicht unterstützt im Moment. Der Username wird vom Keycloak übernommen und beim ersten Anmelden in die Datenbank geschrieben. Dort, bei der Anmeldung, ist theoretisch auch ein Wechsel des Username möglich, weil über die UUID der gleiche Account gefunden werden kann. Aufgrund der Implikation im Dateisystem (Dateien würden nicht mehr gefunden werden) ist das aber im Moment auskommentiert:

image

Siehe api/obs/api/routes/login.py.

Um im Keycloak keine Emails als Nutzernamen zu übernehmen sollte diese entsprechende Option deaktiviert sein:

image
image901×630 31.2 KB

1 „Gefällt mir“
#10

Hallo zusammen,

wir hatten zunächst die Option „e-Mail as username“ aktiviert. Daher der Änderungsbedarf.
Mittlerweile sind die Einstellungen wie im Screenshot.
Bedeutet:

Der Username wird vom Keycloak übernommen und beim ersten Anmelden in die Datenbank geschrieben.

dass die Änderung bei neuen Tracks gar nicht durchschlägt, weil der Username einmal „hart“ übernommen wurde und nie ein Update vorgesehen ist?
Dann wäre der einzige Workaround der von @gluap?

Ich kann trotz der Einstellung in Keycloak meinen Usernamen nicht editieren. Ist das bei Euch auch so?

Grüße
Markus

#11

Eine Frage noch zu den erfassten Daten:
Wie können die bereits hochgeladenen Daten nachträglich noch verändert werden?
Ich habe zwei Szenarien, warum ich frage:
Szenario 1: Ich habe bei der Inbetriebnahme und den ersten Tests auf der Knopf gedrückt, und so einen sehr engen Überholvorgang dokumentiert.
Dieser Test ist beim ersten Track-Upload ins Portal verarbeitet worden und taucht im Portal auf. Ich habe die Test-Tracks dann bei mir im Profil gelöscht. Leider verschwindet dieser nicht aus den öffentlich erreichbaren Daten.

Welche Verarbeitungsschritte nimmt das Portal beim Upload vor? Werden die hochgeladenen Tracks und Überholvorgänge anonymisiert separat eingetragen und können vom Nutzer nicht mehr geändert werden?

Wie können Tracks (u.a. wg. notwendiger Anpassung der Privacy Zone oder Fehlern) nachträglich korrigiert werden? Die Funktion „Fahrtdaten ersetzen“ kann das, allerdings macht diese nur Sinn, wenn diese dann auch im öffentlichen Portal verschwinden.

Szenario 2: Dies steht zunächst im Widerspruch zu Szenario 1. Wir wollen ja Daten sammeln und auswerten können. Sollte sich jemand irgendwann gegen die weitere Sammlung entscheiden, kann er seinen Account löschen. Wir möchten die vom User erfassten Überholvorgänge natürlich nicht verlieren,. Nach DSGVO dürfen Daten anonymisiert werden. Damit wäre eine Kopie der Überholungen, ihres Zeitpunktes, GPS Koordinaten und Abstand sowie die Anzahl der Fahrten auf einem Abschnitt zulässig.

Natürlich ist es am besten saubere Daten hochzuladen, aber eine Fehlerkorrektur solllte auch möglich sein.

Gibt es für die nachträgliche Löschung einzelner Überholvorgänge im Portal eine Lösung?

Ich danke Euch!

Grüße
Markus

#12

Hallo markus,

1.) Wenn mit der Löschung eines Tracks die dazu gehörenden Daten nicht verschwinden, ist das ein Bug - welche Portalversion benutzt ihr denn? Mit 0.7.x wurde da glaube ich etwas gefixt.

2.) Redigieren von Überholvorgängen ist ein noch nicht implementiertes Feature

3.) Verarbeitungsschritte: im Grunde liest das Portal den track ein, schreibt Track Metadaten, Überholvorgänge und Road Usage in Tabellen. Die Rohdaten werden als Datei im Urzustand separat abgelegt um nach Feature Updates / bugfixes die Daten neu einlesen zu können. Beim einlesen der sonstigen Daten wird eine Referenz auf die track id gespeichert, in einer weise, dass mit der Löschung des tracks im user interface die Löschung auf die Daten des tracks kaskadiert wird (oder zumindest soll).

4.) Wenn ein User in der Datenbank gelöscht wird, wird die Löschung auf seine Events etc… Übertragen. Es gibt derzeit aber keine Möglichkeit, User in der portal Datenbank zu löschen außer direkt per sql. Grund ist, dass die personenbezogenen Daten (email, password) in außerhalb des Portals im keycloak leben und dort auch gelöscht werden können. In der portal Datenbank ist das einzige personenbezogene Datum der nutzername - ein möglicher weg zur anonymisierung wäre also, den nutzer per sql umzubenennen - z. B. Auf deleted_user1234.

#13

Hallo Paul,

Danke!

  1. Wo sehe ich die Portalversion? Wir haben das erst vor kurzem eingerichtet.
  2. Prima, dass es in der Pipeline ist.
  3. Heißt das, dass bei Löschung eines Tracks auch Überholvorgänge und Road Usage verschwinden (sollen)?
    Aber was passiert, wenn ich einen Track herunterlade und ersetze? Ich habe den Bereich mit dem Überholvorgang gelöscht, dennoch ist er immer noch da. Könnte mit 1. zusammenhängen, da prüfe ich die Version.
  4. Heißt: User löschen geht derzeit nur per SQL. Löscht man einen User, werden alle seine Daten gelöscht?
    Die Trennung von Userdaten im KeyCloak (personenbezogen) und in der anonymisiert in der Datenbank macht Sinn und erfüllt die Datenschutzanforderungen.

Ich finde folgendes Design sinnvoll:
zu 3) Die Daten sollen durch die OBS Sammlung dauerhaft und unwiderrruflich gespendet werden. Damit sollte zwar die Korrektur einzelner Tracks möglich sein, aber nicht die komplette Löschung aller Tracks.
Wenn jemand eine Fahrt ersetzen möchte, wäre eine Löschung aller Daten der alten Fahrt sinnvoll, also komplett über die DB. Dann wird diese neu hochgeladen und erneut die Daten ausgewertet und in die Tabellen geschrieben. Die ID der Fahrt ist ja eindeutig in der DB, oder?
Damit keine spätere Löschung möglich ist, könnte man die Fahrt-ID zusammen mit dem Upload-Datum speichern und für einen definierten oder definierbaren Zeitraum in Tagen, das Ersetzen von Fahrten möglich. z.B. innerhalb von 30 Tagen. Fahrten müssen ja halbwegs zeitnah geprüft werden, sonst dürften die meisten sich nicht mehr korrekt erinnern.

zu 4) Usernamen im Portal (Datenbank) werden als eindeutige Referenz-ID auf Keycloak gespeichert. Wenn dieser angezeigt werden soll, für die Datenbank einen Lookup auf Keycloak durch und liest den aktuellen Username. Damit würde immer der jeweil aktuell gewählte Username im Portal angezeigt. Möchte ein User gelöscht werden, würde der Lookup nicht mehr funktionieren und einfach „deleted user“, ggf.mit einer Nummer angezeigt werden. Wobei die Nummer irrelevant ist denke ich.

Viele Grüße
Markus

#14

0.6.2. wir updaten mal. Melde mich wieder

#15

Zu 1) Unten im Footer wird das angezegit.

Zu 3) Evtl lädt deine Map einfach nciht neu, weil der Browser die Karte ziemlich agressiv im Cache hält, um den Server zu entlasten. Den Browser Cache zu löschen könnte das Problem der nicht verschwindenden Daten lösen, oder 7 Tage warten. Falls nicht, und du auf 0.7.x bist, dann schreib nochmal.

Zu 4) Löschen von Nutzern ist nicht implementiert. Wenn du einen User in der SQL löscht, bleiben die Dateien im Dateisystem. Es wird nicht automatisch syncrhonisiert. Du kannst die Dateien auch löschen, wenn du willst. Das sollte alles sein, was das Portal von einem Useraccount kennt. Weil der Username im Dateipfad vorkommt, ist das einfach zu machen als Admin. Dafür darfst du aber nicht stumpf den Username in SQL ändern und erwarten, dass die Tracks noch korrekt funktioneiren, weil die Dateien eben nicht verschoben werden dadurch. Du kannst beides von Hand tun, das sollte ™ funktionieren.

Die Daten sollen durch die OBS Sammlung dauerhaft und unwiderrruflich gespendet werden. Damit sollte zwar die Korrektur einzelner Tracks möglich sein, aber nicht die komplette Löschung aller Tracks.

Entspricht nicht DSGVO. Die Rohdaten bleiben auf dem Server erhalten (um spätere Probleme korrigieren zu können, wenn die Software reifer wird, siehe Kommentar von @gluap). Diese sind aber nicht veröffentlicht und fallen unter personenbezogene Daten laut DSGVO, unterliegen also „Recht auf Vergessen“ und so weiter. Ein zurückziehen der hochgeladenen Daten und die Entfernung dieser aus der Karte ist ebenfalls gewünscht und funktioniert ja soweit auch ganz gut.

Wenn dieser angezeigt werden soll, für die Datenbank einen Lookup auf Keycloak durch und liest den aktuellen Username.

Das ist zu langsam, aber wir könnten die Änderung des Username bei Login implementieren, dann ist es schnell genug. Hat halt einfach niemand gemacht, da es nicht nur eine Änderung in der SQL ist, sondern auch im Dateisystem, und das ist nichttrivial syncrhon zu halten. Darum ist der entsprechende Teil bis jemand das richtig implementiert auskommentiert, siehe mein Screenshot oben. User-Löschung muss dann im Portal stattfinden – aber das muss sie eh, denn der Keycloak wird auch hier nicht dafür sorgen dass das Dateisystem aufgeräumt wird.

Ergo: Es braucht in der Anwendung einfach die 2 Routinen für a) Username wurde in Keycloak geändert und b) User soll gelöscht werden. Letzteres gibt es als Issue schon, a) fehlt noch.

#16
1 „Gefällt mir“
#17

Hi @opatut,

danke fürs Issue erstellen :slight_smile: Aktuell ist mein Workaround, dass ich empfehle keine Fahrten zu veröffentlichen, wenn dadurch unerwünschte Informationen öffentlich werden. Ist also nicht zeitkritisch.

Ich hab geschaut: Der falsche Überholpunkt ist weg. Das Update scheint das erledigt zu haben. Ich hatte es mit 3 Browsern auf 2 Geräten versucht. Läuft :slight_smile:

Grüße
Markus

1 „Gefällt mir“
#18

Das ist ein Pull Request, das hab ich schon fertig implementiert :stuck_out_tongue: Warte da auf review von @gluap oder so, dann gibt’s das für alle.

1 „Gefällt mir“
#19

Wie sage ich als IT-ler dass ich von Programmierung keine Ahnung habe :sunglasses: