in einer Diskussion wurde die These aufgestellt, daß Freifunk-Exit-Anbieter mit den Freifunk-Exit-Nutzern eine Auftragsdatenvereinbarung gemäß DSGVO abschließen müßten.
Mir erschließt sich dies im typischen Exit-v4-Szenario nicht, wo die Exit-IP als Tunnel beim der nutzenden Community endet und letztere das NATing macht.
(v6 mit Routing mag etwas anders sein.)
Da mir beim Thema Routing die DSVGO noch nicht über den Weg gelaufen ist: ist das so? Gegenstimmen? Wie stehen der FFRL oder der FFNW und andere, die für anderen Communities IP-Exit umsetzen, dazu?
Die These stammt von einem Freifunk-Admin im Diskussionskontext Ausleitung direkt via Hosting-ISP oder via ‚großem Freifunk-Verein‘ (ließ: FFRL oder evtl. FFNW).
Die Dsgvo greift nur bei personenbezogenen und pseudonymisierten Daten.
Bei Anonymen Daten greift sie nicht.
Welche Kategorie von Daten haben wir? Meines Erachtens ist die einzige Konstellation beim Gluon Aufbau bei der man in die Richtung Auftragsverarbeitung gehen könnte zwischen Knotenbetreiber und VPN-Konzentrator Betreiber. Da eventuell die ISP IP personenbezogenen sein kann. Wobei dort die Frage ist: Mit welchem Aufwand wird aus der IP ein personenbezogenens Datenpaket? Der Backbone Betreiber erhält nur noch „anonymen Datenmüll“ und ist raus, muss höchstens sich Gedanken machen über seine Beziehung zum Betreiber des VPN-Konzentrator, wobei wenn dieser z.b. Mitglied des Vereins (z.b. RL e.v.) ist könnte das über eine zusätzliche Regelung etc. Aufgenommen werden und fällt auch flach.
Wenn andere Anbieter als Exit Partner genommen werden (ausländische von Anbieter) sieht’s etwas anderes aus.
Wie immer bei rechtlichen Dingen: nicht Techniker sondern Anwalt fragen. Und da gibt es dann leider auch wieder verschiedene Ansichten.
Eine Auftragsdatenverarbeitung kann nicht gefordert werden, sonst wäre das Internet schon verboten. Es geht hier um die Weiterleitung von Paketen zwischen zwei Organisationen. Ist bei BGP nicht anders. Mir wäre nicht bekannt, dass irgendwelche Internetaustauschknotenpunktteilnehmer untereinander Datenverarbeitungsverträge abschließen müssten. Sowas wie DECIX wäre dann auch einfach juristisch vernichtet.
Eine Datenschutzerklärung wird dagegen schon sein müssen.
Ne Datenschutz Erklärung für was? Es gibt auf Seiten des Exit/Backbone Betreibers keine verwertbaren Daten, auf Seiten des VPN-Konzentratorbetreibers höchstens die ISP IPs des Knotenbetreiber.
Der Knotenbetreiber ist ein Dienstanbieter und muss entsprechend (und auch nach ppa) Kontaktdaten zur Verfügung stellen.
Ich kann es nur als technisch versierter Dsgvoler Sicht betrachten, nicht als Anwalt.
Die hier mal ausgearbeitete Info Seite für die Firmware/Download Page ist meines Erachtens ausreichend um den Knotenbetreiber zu informieren was rechtlich wichtig ist.
Wie schon erwähnt:
Personenbezogene Daten sind relevant. Pseudonymisierte Daten sind laut Definition Daten die mit „Mehraufwand“ (den Aufwand Mal dahin gestellt) zu personenbezogenen Daten gemacht werden können.
ISP IP (egal ob v4 oder V6) kann ich als VPN-Konzentratorbetreiber nicht ohne richterliche Anordnung (Strafverfahren, Cooperaktion mit dem ISP) zu personenbezogenen Daten machen. Hat für mich die Folge es sind für mich in erster Linie anonyme Daten und damit fallen sie nicht in die Dsgvo.
Denn Knotenbetreiber und AS-Inhaber müssen ja nicht die gleiche Person sein.
‚Höchstens‘ reicht ja schon. Und die Erklärung kann auch einfach sein dass das Zeug da durch kommt aber nicht gespeichert wird, bzw. nur zu den technisch notwendigen Dingen aus berechtigtem Grund (Debugging, Angriffsabwehr) für einen kurzen Zeitraum. Das ganz Ding kann da recht kurz ausfallen, die Frage ist eher, so als ‚nur Exit Betreiber‘ wie diese Erklärung an die ‚Kunden‘ gebracht wird.
Der Knotenbetreiber ist potentiell privat und damit fällt dem seine IP schon da runter. Im Falle von NAT ist mit Connection Tracking mindestens eine kurzfristige Speicherung zur Erfüllung der Aufgabe notwendig.
Mir gefällt diese Ansicht sachlich und technisch, ich meine aber von Datenschutzbeauftragten schon Gegenteiliges gehört zu haben.
Der Knotenbetreiber ist ein Dienstanbieter rechtlich, pauschal zu 100% haftbar für alles was über seinen Anschluss passiert.
Der Provider (zb. RLe.v.) hat keinerlei Informationen über diesen Dienstanbieter, die hat „nur“ der VPN-Konzentratorbetreiber, die einzige Info die vorliegt ist die IP (außer in Instanzen die z.b. fastd mit Key zum Knoten nur mit Registrierung betreiben)
In der Version:
Firmware installieren, eine Email Adresse angeben und Knoten ans Netz hängen - Gibt es keinerlei relevante Daten für den Provider oder auch für den VPN-Konzentratorbetreiber die unter die dsgvo fallen.
Der Knotenbetreiber ist als Dienstanbieter verpflichtet seine Daten zu veröffentlichen → heißt das er das selbst mit seinem Knoten macht - und nicht der Systembetreibende, somit muss der sich um nichts kümmern, da er keinerlei Handhabe und Infos hat aus der IP auch einen Namen usw zu generieren.
Um den Verpflichtungen des Server Betreibers nach zu kommen reicht das hier:
Grundsätzlich ist zu beachten - es gibt weder im BDSG noch in der Eu-DSGVO auch nur den Ansatz an Konstrukt wie der Freifunk ist.
Zum abwägen ob man überhaupt in die Dsgvo fällt:
gibt es personenbezogene Daten => Name, Anschrift, IP etc?
Gibt es pseudonymisierte Daten => kann man daraus personenbezogene machen?
Gibt es anonyme Daten => Super brauche gar nichts machen.
Äh, nochmal, ich rede vom »FFRL-Setup«: auf meinem (Gluon-) Gateway wird auf eine FFRL-IP genattet, die ›per BGP über GRE-Tunnel‹ auf das Gateway kommt. D. h. wen ich darauf natte, weiß nur ich als Gatewaybetreiber*. Sprich: da ist kein »VPN-Kontentrator« dazwischen.
v6 läuft da etwas anders, aus dem Mesh-/64 (vom FFRL) picken sich die Endgeräte per SLAAC mehrere v6-Adressen. Eine Zuordnung von v6-Adressen zu einem Gerät ist AFAIK technisch nicht möglich (erst wieder aus höheren Schichten durch Fingerprinting u. dgl. — damit typischerweise nicht dem Transitprovider).
Kurzum sehe ich hier nicht, wo die DSGVO einen Hebel hätte bezogen auf mich als Gatewaybetreiber und $Organisation, die v6- und v4-Adressen auf genannte Art bereitstellt?
* JFTR: Also »wissen« ist da relativ: Aus der Zuordnung MAC<>IP des DHCP-Servers könnte man bei vorhandenen DHCP-Logfiles die interne IP zu einer Geräteadresse zurückmappen.
Mangels Logging der conntrack-Tabelle allerdings nicht das öffentliche Socket zum internen. Das ginge nur live und in Farbe (tcpdump auf das Zielsocket auf dem Meshinterface).
Ich behaupte da du als Gateway/VPN-Konzentrator Betreiber keinerlei Möglichkeit hast personenbezug mit irgendwelchen Datensätzen herzustellen hantierst du nur mit anonymen Daten und die fallen nicht unter das BDSG.
Folglich existieren keinerlei Pflichten nach BDSG/DSGVO meines Erachtens.
Alles klar, ich rede davon dass der ‚VPN-Konzentrator‘ dem ‚IP-Exit‘ entspricht und um etwaige Beziehungen VPN-Konzentrator/IP-Exit<->Node-Betreiber (potentiell Privatperson mit seiner privaten IP). Nur dafür könnte ich mir überhaupt irgend etwas mit DSGVO vorstellen. VPN-Konzentrator<->IP-Exit ist mE gleichzusetzen mit beliebigen anderen Routern im Internet.
Eine öffentliche IP stellt nach aktueller Rechtsprechung per se ein personenbezogenes Datum dar.
Dabei wird sich auf eine Formulierung in der Begriffsbestimmung „personenbezogene Daten“ (Art. 4 - 1.) berufen [… als identifizierbar wird eine natürliche Person angesehen, die direkt oder indirekt, insbesondere mittels Zuordnung zu einer Kennung … ] sowie auf das BGH Urteil vom 16.05.2017 (VI ZR 135/13).
Aufgeweicht wird das Ganze allerdings wieder durch die Begriffsbestimmung zu „Pseudonymisierung“ (Art. 4 - 2.) die vergleichsweise einfach zu erreichen ist.
Die Frage ist IMHO inwiefern nachweisbar ist, dass weder die v4 noch v6 Adressen noch die MAC Adressen, auch nicht indirekt einem Gerät oder einer Person zugeordnet werden können.
generelle Überlegung:
Weiterhin geht es hier ja konkret um eine ADV die IMHO überhaupt nicht relevant sein kann, da u.a. kein Auftrag besteht. Eine ADV wird abgeschlossen zwischen einem Dienstleister mit Datenschutzvereinbarung (DV) und einem Drittdienstleister (z.B. Zulieferer) um die Einhaltung der eigenen DV durchzusetzen bzw. rechtlich abzusichern.
Die in meinen Augen relevantere Frage ist also eher, wie folgende Aussage juristisch beurteilt würde: Wenn ich als Knotenbetreiber oder lokaler Verein keine DV habe, kann ich auch keine ADV zur Durchsetzung meiner DV mit einem Exit-Betreiber abschließen.
Schön, aber in der gegebenen Fallkonstellation kann „niemand“ ein öffentliches v4-Socket einer internen v4-IP (und damit einem Nutzer) zuordnen, da conntrack spurenlos agiert.
Ebenso kann, mit Ausnahme …ff:fe…, kein öffentliches v6-Socket einem Gerät (und damit einem Nutzer) zugeordnet werden, da SLAAC spurenlos agiert.
**Art. 2 Buchst. a der Richtlinie 95/46/EG des Europäischen Parlaments und des Rates vom 24. Oktober 1995 zum Schutz natürlicher Personen bei der Verarbeitung personenbezogener Daten und zum freien Datenverkehr ist dahin auszulegen, dass eine dynamische Internetprotokoll-Adresse, die von einem Anbieter von Online-Mediendiensten beim Zugriff einer Person auf eine Website, die dieser Anbieter allgemein zugänglich macht, gespeichert wird, für den Anbieter ein personenbezogenes Datum im Sinne der genannten Bestimmung darstellt, wenn er über rechtliche Mittel verfügt, die es ihm erlauben, die betreffende Person anhand der Zusatzinformationen, über die der Internetzugangsanbieter dieser Person verfügt, bestimmen zu lassen.**
Wo und wie hab ich als SN Betreiber die Möglichkeit jemanden zu identifizieren?
Es wird nicht gespeichert, höchstens auf Anordnung, daher kein personenbezogenens Datum.
Kann ich die Diskussion also insofern zusammenfassen, daß keine offensichtliche Notwendigkeit gesehen wird, im Falle des typischen »FFRL-Exits« datenschutzrechtliche Verträge zwischen Gatewaybetreiber und dem ›Exit-Verein‹ zu schließen?
: