VDS as a Public Service 

"Was soll das?" 

Es ist der 17 Mai 2017 in Münster. Es ist warm. Freifunk Treffen. Wir sind im Biergarten mit vielen netten Menschen. 
VDS frustriert uns. Wir wissen nicht was wir in unserer speziellen Konfiguration tun "müssten". Natürlich halten wir das alles eher a) einen Fehler und b) in der Ausführung für phänomenal blöde. "Schnell, Schnell" Gesetzgebung halt. #sad

Das die Freifunk "Daten" für die Ziele der VDS sinnfrei sind ist eine weitere Komplikation.   

Also was machen wir?

Von der BNetzA haben wir keine Auskunft, ob wir in unserer speziellen Situation überhaupt "VDS pflichtig" sind (wir haben gefragt).
Und dabei wäre dies auch erstmal ne Auskunft, da kann man auch anderer Meinung sein. Sprich: Rechtsprechung steht ja eh noch aus.

Also wir sind frustriert (und im Biergarten). Was macht der Nerd dann? Quertreiben. D. h. die Idee ist grundsätzlich die "Daten die bei uns anfallen " ∩ die Daten "die VDS möchte" zu Open Data zu erklären und als #VDSULTRAS für alle bereitzustellen.

Für uns ist das eine Form des Protestes!

Vielleicht ist es auch ein Ansatz um mit Nutzern mehr über VDS zu reden (VDS Gesetzeslage 2015: Schwerste Verbrechen z. B. Mord & Totschlag, Diskussion 2017: Auch für Wohnungseinbruch, 2019: Falsch Parken, ach was sage ich "jederzeit und online" - weil man dann "so schön rastern kann").

Die Essenz ist das der Chilling Effect hier vermutlich deutlich geringer ist als Abschaltung - und wir versenken nicht 3000 Routeraufsteller und 10k Nutzer in einem Schlag und "ohne Wirkung".

Wer seinen Routern abschaltet, was jeder Mensch natürlich jederzeit tun kann, müsste diese Entscheidung dann selbst treffen (statt von "uns" das Netz abgedreht zu bekommen).
Und wenn nichts bleibt, dann bleibt vielleicht eine Auseinandersetzung mit dem Thema.


So jetzt Inhalt: (und noch'n Bier bitte)

Daten die wir 'hätten' vs Katalog VDS

"Hättten wir" (bzw kommen wir dran)
Möchte VDS (lt FAQ BNetzA)

MAC Adresse d. Clients

(Fehler)Nicht benötigt → "Die MAC-Adresse eines Endgerätes kann nicht als zusätzliche Anschlusskennung gespeichert werden"
Gemeinsam genutzte Public IP des Clients (NAT)(Haken)Benötigt → "... eine Internetnutzung zugewiesene IP-Adresse zu speichern ... "

Private IPv4 d. Clients

(Fehler)Nicht benötigt "Hierunter ist – ausschließlich – die öffentliche IP-Adresse zu verstehen"

Verbindungen des Clients

  • src IP d. Clients
  • dest IP d. Clients
  • Zustand der Verbindung
(Frage)Keine Quelle
  • src Port d. Verbindung
  • dest Port d. Verbindung
(Fehler)Nicht benötigt "Nein, weitere Verkehrsdaten wie die Portadressen dürfen nicht gespeichert werden"

Hostname d. Clients (wenn mittels DHCP übermittelt)

(question)

Knoten an dem der Client hängt (Public-IP?)

(Haken)Benötigt → "Die Anschlusskennung ist in öffentlichen WLANs im Allgemeinen die netzseitige Kennung des HotSpot"

IPv6 Adresse des Clients (wenn aktive Kommunikation)



(Fehler)(Fehler)

Nicht benötigt Benutzerkennung

FAQ: "Wird dem Endnutzer keine Benutzerkennung zugeteilt, wie dies beispielsweise in registrierungsfreien HotSpots der Fall ist, entfällt diese Speicherpflicht"

 

Öffentlich 

Essenz: Schnittmenge zwischen VDS Forderung und Daten die wir haben. vdsutltras.freifunk-muensterland.de

Online, Public & Realtime. (Technik: Elasticsearch)


Über Zeit:

Client (v4 via NAT, v6) zugewiesene Public IPIP des Freifunk Routers

Wem müssen wir das erklären? 

Müssen wir die bekannten Kontaktdaten der Routerbetreiber (da wo wir sie haben) löschen?
Abgesehen von generellen Überlegungen dazu: Nein, deren Identität ist via VDS Abfrage eh zugänglich.