Freifunk-Standorte in OSM

Mi Sep 11 13:50:43 CEST 2019

Hallo,

neben dem, was ich gerade nochmal separat zum Datenschutz geschrieben habe, folgendes:

> deswegen vielleicht eher Scenario 2: 

> Zwei Felder, 

> - eins für das Monitoring, wie bisher, als opt-out

> - ein neues als opt-in für Weiterleitung an $Dienste. Hier könnte man dann OSM, $Zukunftsmusik aufführen.

So funktioniert die Firmware nicht.

Effektiv bläst der nodewatcher alle Daten per alfred ins Layer-2-Netz, wo jeder (!) Teilnehmer dort die Daten mitschreiben kann.

Schon der erste Schritt nach dem Router macht also alle Daten effektiv öffentlich, die der nodewatcher sendet.

Wir haben also gar keine Kontrolle darüber, was danach damit passiert. Dass die Daten beim Monitoring landen, ist eine Dienstleistung des Gatewaybetreibers (bei normalem V2). Wenn jemand anderes im Netz die Daten für sein eigenes Monitoring mitloggt, können wir das nicht verhindern.

Das ist übrigens ein Feature im Sinne der Dezentralität, es muss ja niemand das zentrale Monitoring nutzen. So kann jeder ein eigenes/neues/besseres/schöneres Monitoring bauen, ohne überhaupt ein Gateway betreiben zu müssen etc. pp.

In der Konsequenz macht es also gar keinen Sinn, per Haken verschiedenen Nutzen vorzugeben, weil wir diesen nicht kontrollieren können. Wir können lediglich Felder definieren, die dann vom Nutzer ausgewertet werden, wenn er das will (wie die robots.txt für Suchmaschinen).

Was hingegen natürlich geht, wäre die entsprechenden Daten überhaupt nicht zu senden, also den nodewatcher zu modifizieren. Dann stehen sie auch nicht im Monitoring. Die gibt dann wieder Konflikte mit dem Thema Koordinaten vs. Datenschutz aus der anderen Mail.

Wer eine dezentrale Hood betreibt hat hier natürlich ungleich mehr Kontrolle, insbesondere wenn er seine Statistik-Daten nicht mit alfred im L2-Netz rumbläst. Diese fallen also teilweise aus der Diskussion heraus, allerdings wären sie auch betroffen, wenn jemand z.B. einfach die Monitoring-Daten an OSM schickt.

Grüße

Adrian

From: SebaBe [mailto:freifunk at beibecks.de] 
Sent: Mittwoch, 11. September 2019 13:34
To: Adrian Schmutzler <mail at adrianschmutzler.de>; franken at freifunk.net
Subject: RE: Freifunk-Standorte in OSM

Hallo,

Fall 1: Ein Feld für die generelle Übermittlung von Statistikdaten;

- ich finde ein Opt-In eigentlich besser, da man somit mehr Datenhoheit hat. Außerdem darf man davon ausgehen, dass es Leute, die sich nur "schnell durchklicken" und es weniger genau nehmen nicht anklicken.

- In der Praxis hätten wir mehr Probleme bei der Fehlersuche in Hoods, Hilfe bei Email-Support, Übersicht über das Netz.

deswegen vielleicht eher Scenario 2: 

Zwei Felder, 

- eins für das Monitoring, wie bisher, als opt-out

- ein neues als opt-in für Weiterleitung an $Dienste. Hier könnte man dann OSM, $Zukunftsmusik aufführen.

Grüße,
Sebastian

Am 11. September 2019 um 13:21:09 +02:00, hat Adrian Schmutzler <mail at adrianschmutzler.de <mailto:mail at adrianschmutzler.de> > geschrieben:

	Hallo,

	die technische Implementierung sehe ich hier als unproblematisch an.

	In der Firmware muss ein zusätzliches Feld hinzugefügt werden, und im Monitoring ein zusätzliches DB-Feld. Das kann man dann mit dem Alle Router-Json rausblasen, und wer eine Schnittstelle zu OSM bauen will, kann dieses einfach gelegentlich parsen.

	Zudem fliegen die Alfred-Daten ja ohnehin frei zugänglich im Netzwerk rum, ich sehe hier zunächst also keine zusätzlichen Datenschutz-Probleme für die Firmware, weil wir ohnehin dort sagen, dass die Daten frei zugänglich sind.

	Probleme macht sich wohl lediglich der, der die Daten dann auswertet und an OSM weiterschickt.

	Die spannendere Frage ist, was man mit dem Feld setzen will. Grundsätzlich gibt es zwei Möglichkeiten:

	1. Opt-in

	Ein boolean-Feld wird integriert, dieses ist standardmäßig aus. Wer das Feld setzt, sagt damit, dass seine Koordinaten verlässlich sind.

	Vorteil: Es werden so nur Daten weitergegeben, die zuverlässig sind.

	Nachteil: Die meisten Standorte tauchen nicht auf.

	2. Opt-out

	Ein boolean-Feld wird integriert, dieses ist standardmäßig an. Wer das Feld abwählt, markiert seinen Router als Test-Router/verborgenen Router ohne korrekte Position.

	Vorteil: Wir geben alle relevanten Standorte weiter.

	Nachteil: Wir nehmen die ganzen Leute mit, die schnell irgendetwas einstellen und sich nicht weiter kümmern. Zudem besteht ja eigentlich die Policy, dass die Koordinaten korrekt sein sollen. Mit der Opt-out-Lösung suggeriert man, dass falsche oder Fake-Koordinaten akzeptabel sind.

	Generell:

	Es ist davon auszugehen, dass bei einem Wechsel von Produktiv-Router zu Test-Router und umgekehrt das Setzen des Flags vergessen wird (in beiden Fällen). Das ist aber wahrscheinlich größenordnungsmäßig irrelevant.

	Weiterhin ist die Frage, wie man ein solches schaltbares Feld benennen will. Eine Möglichkeit wäre, zwischen "korrekten" und "inkorrekten"/"Fake-" Koordinaten zu unterscheiden. Das würde aber das oben beschriebene Problem befeuern, dass man suggeriert, nicht korrekt gesetzte Koordinaten wären akzeptabel.

	Noch weniger gefällt mir aber die Alternative, hier direkt Bezug auf eine Weiterleitung an Dritte wie OSM zu nehmen. Denn dann stimmt die Geschichte nicht mehr, dass die Firmware nur Daten sammelt und diese per Alfred ins Netzwerk bläst; sie würde dann explizit eine Nutzung der Daten implizieren. Das würde ich unbedingt vermeiden.

	Im Falle der "Opt-out" Lösung könnte man den Haken auch einfach "Test-Router" nennen, das könnte man dann auch im Monitoring anzeigen. Das würde dann aber wieder diejenigen nicht treffen, die ihren Router in einen See setzen, weil sie die tatsächliche Position wirklich einfach nur verschleiern wollen.

	Hier fehlt mir also noch eine "schöne" Lösung für den Namen dieses Feldes.

	Beste Grüße

	Adrian

		-----Original Message-----

		From: franken [mailto:franken-bounces at freifunk.net <mailto:franken-bounces at freifunk.net> ] On Behalf Of Tim Niemeyer

		Sent: Mittwoch, 11. September 2019 07:37

		To: fff at mm.franken <mailto:fff at mm.franken> .de; franken at freifunk.net <mailto:franken at freifunk.net> 

		Subject: Re: Freifunk-Standorte in OSM

		Moin

		Am 11. September 2019 02:03:02 MESZ schrieb fff at mm.franken <mailto:fff at mm.franken> .de:

			Hallo Sebastian,

			bitte nutze diese Attribute für Freifunk:

			internet_access=wlan

			internet_access:fee=no

			internet_access:ssid=*

			internet_access:operator=Freifunk

			https://wiki.openstreetmap.org/wiki/Key:internet_access

			Mit JOSM kannst Du die Attribute alle zusammen it <Strg-c> kopieren

			und mit <Shift-Strg-v> auf einen neuen Punkt kopieren.

			Oder Du duplizierst einen vorhandenen Punkt mit <Strg-d>

			und verschiebst das Duplikat an die passende Stelle.

			Bitte die Standorte nicht von unserer FFF-Karte nehmen!

			(dort sitzen einige mitten im See oder auf der Wiese :-( )

			Sondern nur korrekte Standorte eintragen.

		Alles was da manuell von ein paar einzelnen gemacht wird, wird eher früher als später veralten. Eigentlich hat das also nur Zukunft,

		wenn man eben dich einen Sync von unserem Monitoring zum OSM baut.

		Eventuell könnte man als kleinen schritt dahin in der Firmware ein Flag integrieren, womit man die korrekten Daten deklariert und

		ggfs den OSM Export einwilligt. Ins OSM werden dann nur die als gültig markierten übernommen.

		Tim

			internet_access=wlan gibt es bisher 140'495 mal in OSM.

			internet_access:fee=no gibt es bisher 49'782 mal in OSM.

			internet_access:operator=Freifunk gibt es bisher 513 mal in OSM.

			Mit herzlichem Gruss,

			Markus

				Am einfachsten mit einem Editor wie zB JOSM

				(https://wiki.openstreetmap.org/wiki/Editors).

			Tutorial:

			https://www.youtube.com/watch?v=ENTN0EGGNKU

			https://www.youtube.com/watch?v=sokqVwAaL4M

			(abonnieren erwünscht :-) )

			Allg. Infos zu Kartografieren in OSM:

			https://einklich.net/osm/osm-tutorial.pdf

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://lists.freifunk.net/pipermail/franken-freifunk.net/attachments/20190911/9c7c79c2/attachment-0001.html>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : openpgp-digital-signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 834 bytes
Beschreibung: nicht verfügbar
URL         : <https://lists.freifunk.net/pipermail/franken-freifunk.net/attachments/20190911/9c7c79c2/attachment-0001.sig>