v4 ist endlich, und wir reden nicht über /24, sondern über das, was whois halt zurückgibt, also z. B. 20.192.0.0/10. Oder 2a03:4000::/32, die meisten fehlerhaften bzw. Crawler-Anfragen kommen hier aber noch aus v4-Ranges.
Schade, dass es dafür dann wohl keine Weg gibt, die Freifunk-Knoten auf die Map zu bekommen.
Ohne dass es irgendwo in der API gelistet ist oder dann irgendwie in einem der gelisteten meshviewer wird es schwierig. Oder gibt es eine extra API für diese Communities?
2 „Gefällt mir“
Das Problem ist die Berliner “Community”-Definition. (faktisch: “Community kann nur sein, wo es ein gelbes Ortseingangsschild gleichen Namens gibt”), was neue Dinge wie irgendwelche “$REGION-Funk”-Listungen verunmöglicht.
Die Berliner API ist daher voll mit Einträgen von FF-Communities, die nur auf dem Papier bestehen (“Haan”).
Warum? Weil das das Konzept von “Meta-Communities” beim Wechsel von Wiki zu Git (Github) grandfathered wurde.
Freifunk sollte offensichtlich dezentraler erscheinen als es wirklich ist. Mit dem Effekt Neulingen in der API irgendwelche Potemkinsche Dörfer zu präsentieren, statt Orientierung in Richtung real lebendiger Communities.
Und nicht alle Freifunkenden sind durch diesen Reifen gesprungen.
Aber zurück zur Frage: Bei der besagten freifunk-karte liessen sich solche Domains per Mail submitten. Aber ein separates Git wäre ja durchaus ein guter Plan. Also Hauptsache “ist Freifunk drin, mit allem was dazu gehört wie PPA etc.”
Meinst Du damit ein neues Repo wie z.B. freifunkMUC/freifunk.net-API: Freifunk.net API JSON File (siehe api.freifunk.net), welches dann aus den eingetragenen Domains ein valides JSON erstellt?
Also als Sammelbecken für all diese Meta-Communities. Frage ist da, ab wann fliegt eine Community raus, wer pflegt das?
genau!
Die Frage „wer pflegt das“ ist die gleiche wie bei dem Berliner-Repository: Da sind auch ca. 20% tote Communities drin. Gibt halt keinen KeepAlive-Mechanismus dafür.
Ja, die Knoten senden, wenn vorhanden, die Kontaktdaten ins Mesh — was erst einmal eine geschlossene Benutzergruppe darstellt. Diese Daten sammeln unsere Mapserver ein und erstellen daraus je Mesh eine JSON-Datei, auf die über die API verwiesen wird. Ist diese, im Kontext der Freifunk-API erstellte und bereitgestellte Datei nun vogelfrei?
Mit den gesammelten Daten können Anwendungen wie die Übersichtskarte über die Freifunk-Communities http://community.freifunk.net/ bzw. http://api-viewer.freifunk.net/ oder auch News-Aggregatoren wie http://weimarnetz.de/fffeed/feed.php umgesetzt werden.
Neben Dingen wie dem Datenbank-Leistungsschutzrecht greift hier meines Erachtens jedenfalls die DSGVO, denn ein berechtigtes Interesse an der Verarbeitung der personenbezogenen Daten in den über die Freifunk-API Dritten zur Verfügung gestellten Daten – namentlch zum Zwecke der Darstellung auf Übersichtskarten – muß regelmäßig verneint werden. Und ohne Recht der Verarbeitung fehlt es natürlich am Recht an der Veröffentlichung dieser personenbezogenen Daten.
Die Analogie sollte hinfahren aka Datei holen sein; egal. Heute Nacht wurde die Datensammlung umgebaut, um derlei Doxxing ein für allemal zu verunmöglichen; stand halt sehr weit unten auf der ToDo-Liste: Kontaktdaten werden durch eine Fake-Mailadresse ersetzt, die Rohdaten sind außerhalb des jeweiligen Meshes nicht mehr vorhanden.
Parallel laufen die Überlegungen, die Kontakdaten entweder aus dem respondd-Datensatz zu eliminieren und stattdessen uns über einen anderen Pfad zugänglich zu machen, oder aber die Mailadresse (wir lassen syntaktisch nur eMailadressen zu) auf dem Knoten zu verschlüsseln — was bei öffentlich zugänglichen Sourcen auch nur Security by Obscurity wäre.
Der Bann der Netcup-Netze wurde zurück-, dafür weitere IP-Bereiche von Cloudprovidern in die Droplist aufgenommen; bis auf den Datensammler der freifunk-karte.de verenden alle anderen Anfragen nach API-Dateien, jetzt auch per https, im 401, Authorization Required. Schade, das dies notwendig wurde.
Das ist technisch inkorrekt. Einerseits verlangen wir die Angabe einer Mailadresse bei Knoteneinrichtung, andererseits veröffentlichen wir diese Daten explizit nicht in unseren Kartenservern oder auf dem öffentlich erreichbaren Statusseiten und die fraglichen Daten stehen auch nicht in den API-Dateien (sondern Verweise darauf).
Aber, better safe than sorry, die API-Dateien sind nun hinter einer Whitelist – was das Ganze ad absurdum führt, aber so ist das, wenn Juristen involviert werden –, an unsere Mapserver-URLs kommt Mensch nun per API-json nicht mehr heran, ohne sein Begehr vorher erklärt und seine Zugriffs-IP bekanntgemacht zu haben. (Was zwar nix am Problem der Mapserverdaten ändert, aber who cares?)
Vollkommener Dünnsinn. Auf unseren Statusseiten stehen die Kontaktdaten seit Jahren nicht mehr im Klartext, sondern nur als dysfunktionaler Alias:
<dt>Kontakt</dt><dd> <a href="mailto:744401748e8b@gut.nospam.4830.org">email</a></dd>
Wem wirklich an der Kontaktaufnahme gelegen ist, wird irgendwann jemanden bei 4830.org erreichen … und dann sähen wir weiter.
Und von außerhalb des Meshes kommt man an die korrekten Daten nicht heran – Abgriff der Kartenserver-jsons ausgenommen –, was eine Umgehung eines Zugangsschutzes realisierte. Die vom Kartenserver abrufbaren Daten wiederum können wir schwerlich einschränken; selbst wenn wir in der API-json sie nicht listeten, die browserbasierten Lösungen HopGlass und Meshviewer basieren darauf, daß der Client die Daten vom Mapserver liest und präsentiert.
Um der DSGVO gerecht zu werden bleibt also nur die Entfernung der Kontaktadresse, entweder vor der Datensammlung des Karten- oder Statistikservers, sprich: in der Firmware, oder vor der Veröffentlichung auch durch den eigenen Kartenserver.
Denn keine Communitiy wird eine gerichtsverwertbare explizite Einwilligung der uneingeschränkten Veröffentlichung der Kontaktdaten für jeden einzelnen Knoten vorweisen können — Gluons »Bitte hinterlege hier einen Hinweis, um anderen zu ermöglichen, Kontakt mit dir aufzunehmen. Beachte, dass dieser Hinweis auch öffentlich im Internet, zusammen mit den Koordinaten deines Knotens, einsehbar sein wird. Das bedeutet, dass diese Informationen von jedem heruntergeladen und verarbeitet werden können. Für den Betrieb sind diese Informationen nicht erforderlich. Eine Speicherung erfolgt auf diesem Knoten. Die Daten können durch dich in diesem Menü eigenständig gelöscht werden.« reicht hierfür AFAICS nicht aus, vgl. »zahlungspflichtig bestellen«.
Das PPA hat hiermit nichts zu tun.
Nice try. »The owner agrees to publish the information necessary for peering to take place.« — dies gilt im Binnenverhältnis knotenbetreibende Person <> Mesh, hat aber keine, insbesondere keine erlaubende, Wirkung auf einen Gatewaybetreiber ins Internet, diese Daten ins Internet zu pusten.
Uns als betreibender Verein gegenüber fordern wir eine Kontaktadresse in der Firmware — ohne syntaktisch korrekte Angabe keine Teilnahme. Da sind wir auf PPA-Level, z. Zt. kursiert diese Kontaktadresse auch noch im jeweiligen Mesh — aber das wird sich wie gesagt ändern. Dir oder FFMUC schuldet unser Knotenbetreiber diese Daten nicht. Und insofern werden seine Kontaktdaten DSGVO-konform auch nicht mehr unser Netz verlassen. Case closed.
Ja, das würde (auch) ich gerne (in einem neuen Thread) mal diskutieren; wir haben aufgrund ›aktuell notwendiger Maßnahmen‹ uns auch dieses offensichtlichen Problems angenommen: unsere out-of-area-Knoten haben keine Community, Communities mit >1 Map-Eintrag tauchen zumindest auf freifunk-karte.de nicht auf, …
Die naheliegende Lösung ist es, die nicht repräsentierten Knoten einer Community zuzuschlagen und dafür ein ›künstliches‹ JSON zu erzeugen. Und leider funktioniert dies so gut wie erwartet.
Ich habe insofern einn Würgarounde Lösung für mich gefunden …
Ich glaube, wusel, dass du hier zwei Ebenen vermischst. Wenn die Daten im respondd-Datensatz im Mesh kursieren, von euren Mapservern automatisiert eingesammelt und anschließend über HTTP abrufbar bereitgestellt werden, dann verlassen sie faktisch bereits den geschlossenen Benutzerkreis. Ob sie direkt im API-JSON stehen oder dort “nur” referenziert werden, ist technisch kein wesentlicher Unterschied. Sie sind maschinell abrufbar. Ob Du sie bei euch auf der Karte dann im Nachhinein anonymisierst, ist eine andere und vor allem deine Sache. Eine nachgelagerte Aggregation greift also eben NICHT!!! in einen geschützten Bereich ein, sondern nutzt eine bestehende Veröffentlichungskette.
Auch das Argument mit dem “Umgehen eines Zugangsschutzes” überzeugt mich nicht wirlich. Wenn die Mapserver-Daten clientseitig von einem Meshviewer oder HopGlass geladen werden, sind sie per Definition öffentlich abrufbar. Das macht ja awlnx mit der Federation Map ebenfalls. Dass sie nicht prominent verlinkt sind oder nicht indexiert werden sollen, ist eher ein Fall von intendierter Nichtbeachtung, aber kein technischer Zugriffsschutz im engeren Sinne. Dass Ihr jetzt die Whitelist aktiviert habt, ist jedoch in der Freifunk Community mal wieder ein Alleingang. Ich bin jetzt erst seit knapp 2 Jahren bei einer Community aktiv, aber sowas wie du/ihr es macht, hab ich bisher noch nicht miterlebt. Auch das Darstellen aller anderer Betreiber, die die Adressen veröffentlichen als “die ultimativ Bösen und Inkompetenten Datensammler, die nichts anderes im Sinn haben, als Nutzerdaten zu veröffentlichen” finde ich schwach und das vergiftet diese Diskussion.
Ich bin kein Anwalt, wie vmtl niemand von uns hier in dieser Diskussion. Jedoch ist doch bei den Kontaktdaten doch entscheindend, ob eine Rechtsgrundlage für die Verarbeitung besteht. Wenn Betreiber beim Einrichten des Knotens ausdrücklich darauf hingewiesen werden, dass die hinterlegten Kontaktdaten öffentlich einsehbar und maschinell verarbeitbar sind (was Sie mit dem Standard-Gluon-Paket werden), spricht zumindest einiges für eine informierte Bereitstellung. Es existiert ja sogar der Hinweis, dass diese Daten ÖFFENTLICH im Netz einsehbar sind. Ob das einer gerichtsfesten Einwilligung gleichkommt, kann man diskutieren, aber die Verantwortung für die Veröffentlichung liegt zunächst bei der Stelle, die die Daten einsammelt und öffentlich ausliefert, nicht bei einem Dritten, der diese offen abrufbaren Daten weiterverarbeitet. Die Federation Map bzw @awlnx dann als “ohne Fingerspitzengefühl” zu framen, weil Ihr es nicht gebacken bekommen habt, das aus der API zu filtern, finde ich sehr sehr fragwürdig. Das verschiebt das Problem von euch auf @awlnx.
Wenn ihr euch nun entscheidet, die Daten firmwareseitig zu entfernen oder serverseitig zu filtern, ist das natürlich euer gutes Recht. Das ändert aber nichts daran, dass die bisherige Bereitstellung technisch öffentlich war und eine darauf aufbauende Verarbeitung nicht automatisch “Doxxing” darstellt. Das ändert jedoch nichts daran, dass die bisherige Bereitstellung technisch öffentlich war und eine Nutzung dieser öffentlich abrufbaren Daten nicht per se rechtswidrig ist.
Eben. Für uns ist das Thema erledigt, unbekannte Dritte kommen ersteinmal weder an die API-Daten direkt dran noch an die Kontaktdaten der Knotenbetreibenden, die bekannten Dienste (Community Map auf freifunk.net und die Freifunk-Karte) sind freigeschaltet, FW-Änderungen für v2021 und v2025 für die endgültige Lösung stehen auf der To-do-Liste. Über UA-Filterung/IP-Einschränkungen bei den Mapservern wird zu einem späteren Zeitpunkt entschieden.
'nuff said, schönes Wochenende!
Ich weiß, dass hier ein Platzhalter rein muss, aber muss der Tritt in unsere Richtung wirklich sein? none-of-your-business.ffmuc@mail.google
Wir sollten doch als Freifunk Gemeinschaft zusammenarbeiten. Das bringt doch nichts, da jetzt noch mehr Öl ins Feuer zu gießen. Wir alle wollen doch, dass Freifunk gedeiht und wächst. Das machen wir in Müchen so, das macht Ihr bei 4380 so. Wir haben nur diese Karte gebaut, um das Gesamtfreifunk besser abzubilden und zu visualisieren. Da bist du @wusel ein Teil davon, wir auch. Wir wollen alle das gleiche. Wäre es daher möglich, den Platzhalter in etwas neutrales wie redacted@example.org zu ändern? Und können wir uns irgendwie auf einen Kooperativen ansatz einigen, sodass wir mehr zusammenarbeiten und weniger streiten? Am Ende profitieren doch alle Communities davon, wenn wir zusammenwachsen und gemeinsam an Lösungen arbeiten.
Und was ich auch noch sagen möchte: Ich finde es gut, dass ihr bei 4830 Verantwortung übernehmt und euch Gedanken um den Schutz eurer Betreiber macht. Das zeigt ja, dass euch eure Community nicht egal ist. Eine lebendige Community (wie hier im Forum) besteht auch aus Diskussionen, selbst wenn sie mal hitziger werden. Ohne Reibung gibt es keine Weiterentwicklung 
Mir ist nur wichtig, dass sich hier keine zwei Fronten bilden. Bei den Kontaktdaten haben wir offenbar unterschiedliche Auffassungen, das kann man sachlich diskutieren. Aber im Kern verfolgen wir doch dasselbe Ziel.
Gerade weil wir ähnliche Herausforderungen haben, etwa beim Umgang mit kleinen oder sterbenden Communities, die integriert werden müssen könnten wir voneinander profitieren (München nimmt Communities auf, ihr auch, siehe Winterberg, bei uns z.B. Ulm). Vielleicht ergeben sich daraus Synergien oder zumindest ein konstruktiver Austausch^^
Ich würde mich jedenfalls freuen, wenn wir den Fokus wieder stärker auf Zusammenarbeit legen können. Am Ende sitzen wir alle im selben Boot.
Damit bin ich jetzt auch erstmal fertig.
Herzlichen Glückwunsch, den Thread zu derailed zu haben.
1 „Gefällt mir“
Eigentlich sind der Worte aus meiner Sicht genug gewechselt, aber einmal dann noch:
Hmm, rekapitulieren wir. Wir finden es nicht opportun, Kontaktadressen aus einer anderen Community zu veröffentlichen, jedenfalls nicht aus unserer. Eure Antwort: wenn Ihr’s nicht auf 'ner Karte lesen wollt, dann packt’s halt nicht in den Datensatz. Okay, dann ersetzen wir also jenes Datum durch einen für uns angemessenen Platzhalter, Schlaf wird ja auch überbewertet. Insofern: wenn Ihr auf Euer Karte nicht lesen wollt, was andere so in die Datensätze schreiben, dann filtert’s halt.
Oder kurz und knackig: Ich wolltet das unbedingt veröffentlichen, das könnt Ihr gerne veröffentlichen …
Ich könnte viel schreiben, aber dies ist mir wichtig: Ich sehe bis heute nicht, daß Ihr auch nur einen einzigen Gedanken darauf verwendet habt, ob das vielleicht eine ganz dumme Idee sein könnte, diese Daten zu veröffentlichen. Wie gesagt, fehlendes Fingerspitzengefühl aus meiner Sicht, aber hey, wenn Ihr unbedingt alle Daten veröffentlichen wollt, die wir senden, dann macht halt; you got what you asked for — auf ganzer Linie.
Wir gießen nix, wir haben nur getan, was Ihr wolltet: dafür gesorgt, daß die Daten, die wir nicht durch Dritte neben unseren Knoten sehen wollten, nicht mehr durch Dritte neben unseren Knoten ausgegeben werden können. Was können wir dafür, daß Teile der Daten Euch nicht gefallen? Wir zwingen Euch ja nicht, die auszugeben, das ist allein Eure Entscheidung — ja, die wir für falsch halten, aber das ist nicht mehr unser Bier.
Und wie gesagt, danke für den Ansatz, die Idee als auch die Umsetzug ist schon nice — ansonsten s. o. Nicht alles, was technisch möglich ist, ist auch zielführend, IMHO. Aber der Drops ist gelutscht, wir werden zukünftig bestimmte Informationen nicht mehr weitergeben, weitergehende Einschränkungen – zwei bis drei Nachkommastellen für die Position reicht für externe Datensatzkonsumenten ja auch, Knotenname kann auch eine reine Nummer sein – nicht ausgeschlossen. (Knotennamen bestehen per Default aus PLZ+Straßenaddresse.)
Feel free. Nochmal: Wir haben kein Interesse an der Sichtbarkeit dieses Datums auf einer Karte. Das durch Euch bei uns entstandene Problem ist für uns gelöst, falls Ihr jetzt ein Problem habt, müßt Ihr es wohl für und bei Euch lösen. Es gab nie einen Versuch, auf uns zuzugehen, und nun ist es eben, wie es ist.
(Ja, da ist noch viel Unverständnis und Ärger über Euren Stunt. Frag’ in fünf bis sieben Jahren nochmal …)
Um das klarzustellen: rein technisch stimme ich @awlnx vollkommen zu: Eure Veröffentlichung unserer Kontaktdaten auf Eurer Karte hat das Problem der viel zu großzügigen Verbreitung eben jener ›nur‹ ins Rampenlicht gestellt.
Wir haben bislang daran festgehalten unter der Prämisse, daß diese JSON-Dateien überwiegend von Freifunkern für Freifunkzwecke verwendet werden — so wie wir in der Vergangenheit sehr froh darüber waren, Kontaktadressen aus den Netzdaten entnehmen zu können statt bei zu übernehmenden Communities mit 4 von 3 verlustig gegangenen Know-How-Trägern und/oder Technikern hoffen zu müssen, daß irgendwelche Kontakte.xls gefunden werden. Kann auch mal $hier geschehen, also lassen wir die Daten as-is drin, auch wenn wir nicht wirklich kontrollieren können, wer die nodes.jsons sich zieht.
Die unbeschwerten Tage der Promiskuität sind aber nun ein für alle Mal vorbei. Ihr habt – undankenswerter Weise, sorry – der Welt gezeigt, was mit den json-Daten möglich ist, also müssen wir handeln. Aus meiner Sicht – Ihr seht das anders, so ist das nun einmal – habt Ihr dem (unverschlüsselten; aber ohne öffentlich zugänglichen Schlüssel ist es auch wertlos und mit diesem nicht mehr als verschlüsselt anzusehen) Kontaktdatenfeld in außerhalb des Meshes publizierten Datensätzen den Todesstoß versetzt.
It was bound to happen, aber die Ecke des Internets, aus der das jetzt kam, ärgert mich. Das war einfach vollkommen unbedacht und unverzeihlich aus meiner Sicht.
Well, life goes on.
Also an sich ist das nicht unser »Kerngeschäft«, sterbende Communities weiterzubeatmen; bei Lüneburg und Uelzen waren das eher bestehende Kontakte aus grauer Vorzeit und einer an sich weiter existierenden lokalen Community, bei Bielefeld das Interesse, in der Nachbargroßstadt Freifunk nicht sterben zu lassen und mit Lippe arbeiten wir seit Jahren zusammen, haben deren AS aufzubauen geholfen und mit dem Wegfall ihres gemieteten v4-Netzes war der Parallelbetrieb zweier ASe, eines nur noch v6-only, auf gemeinsam betreuter HW irgendwie double the trouble, half the fun. Eigentlich geht der Spruch doch aber genau anders rum
Was Winterberg angeht, ich sehe nicht, daß da ein Plan existiert. Wir haben das intern abgehakt; die Vorkehrungen sind da, falls man da wollen würde, aber die Karawane zieht weiter.
Ich sehe da kein Problem; Ihr seid nicht auf unsere Zustimmung bzgl. Eures Tuns angewiesen, wir nicht auf Eure Jeder greift mal ins Klo, Ihr müßt die hiesige Sicht ja nicht teilen (wenngleich ich mir wünschen würde, Ihr gucktet da mit zeitlichem Abstand nochmal drauf).
Ihr operiert IIRC in MUC & VIE, wir in FRA, BER, HAM, latent werden wir jeweils die technischen Herausforderungen gestemmt haben, aber wo’s Sinn ergibt, kann man ja auch zusammenarbeiten
Post 1: https://federated-map.ffmuc.net/
Post 2: „wie habt Ihr da FFM reinbekommen?“
Post 3: „Daten raten“
Post 4: „Äh, Arsch offen? (Unsere) Kontaktdaten gehören nicht veröffentlicht!“
Nur, weil Du als 2. postetest, ist das nicht Dein Thread über fehlende Neanderfunk-Einträge
That said, …
… wo diskutieren wir dieses weiter?
Um hier vielleicht mal die Sicht aus Aachen zu geben:
Wir hatten schon länger als ich Freifunk mache den Knotenbetreibern kommuniziert, dass die Owner Info nicht veröffentlicht wird und lediglich der Kontaktaufnahme durch das FFAC-Freifunk-Team dient.
Das hat natürlich zur Folge, dass wir das im Meshviewer nicht anzeigen, aber vor allem auch im Yanic einfach no_owner = true gesetzt haben um es auch nicht aggregiert anzuzeigen.
Der Lookup aus Admin-Zwecken erfolgt dann auf die Datei /var/lib/yanic/state.json.
So kann man auch gut mit der Lösung schlafen.
Konsequenterweise haben wir dann auch einen Patch, der das Owner field von der status-page entfernt:
Hier jetzt reaktiv seitenweise sich als Geschädigten zu präsentieren und FFMUC wegen ihrer neuen Karte nen Vorwurf zu machen kann ich nicht nachvollziehen.
Jede Community, die die Daten aggregiert veröffentlicht sollte das an die Nutzenden auch kommunizieren und sich da im vorhinein Gedanken gemacht haben.
Post 4: „Äh, Arsch offen? (Unsere) Kontaktdaten gehören nicht veröffentlicht!“
Ja dann veröffentlich sie halt nicht.
1 „Gefällt mir“
Muss der Knotenbetreibene dann machen. „Ihr“ / der Supernode-Betreiber veröffentlicht es ja in der API. Auch wenn da was anderes bei einigen behauptet wurde.
@jenell95 die Aggregation der knoteninfos findet auf dem monitoring server mittels yanic statt. In der daraus erstellten öffentlichen meshviewer.json wird die kontaktinformation bei FFAC jedoch nicht reingeschrieben (no_owner = true in yanic.conf).
Man muss als supernode/monitoring betreiber einfach diese config anpassen. Das müssen die Community-Admins halt machen.
Dann wird es auch in keiner API (du meinst wohl die meshviewer.json) veröffentlicht.
2 „Gefällt mir“