Fortsetzung der Diskussion von Langzeitstatistiken aus den Alfred Daten:
Dazu ergänzend hier mal die aktuellen Batman Daten: Freifunk.net Pad
Vielleicht mag das ja mal jemand mit der Realität abgleichen.
Zumindestens meine Node liegt hier richtig.
1 „Gefällt mir“
Naja, aber wie willst du denn sonst ein Layer-2-Routing-Protokoll implementieren, wenn du keine MAC-Adressen austauschst, um die entsprechenden Nachbarschaftstabellen aufzubauen?
Ja, aber von denn verbundenen Clients? Ist das denn wirklich nötig?
Die sind am Mesh doch gar nicht beteiligt.
Ja, dann kannst du halt nur senden, aber nicht empfangen, weil die Router nicht wissen, wo die Daten hinsollen 
Hmpf, da hast du recht 
Dann gehts wohl nicht anders ohne sich periodisch ne neue MAC zu klauen.
Wurde das denn noch nie hier diskutiert?
Finde das so Datenschutztechnisch eigentlich nicht hinnehmbar.
Da gibt es halt eben nicht viel zu diskutieren, weil man da nicht wirklich was dran ändern kann auf technischer Ebene.
Entweder man sorgt dafür, dass die einzelnen Clients ihre MAC einfach wechseln können, sodass man etwas vergleichbares zu den IPv6 Privacy Extensions dann wirklich auf MAC-Ebene hat. Der Client kümmert sich also aktiv um seine Nicht-Identifizierbarkeit. Darum können wir uns aber halt nicht kümmern, da wir diese Geräte nicht herstellen, und MACs sollen nunmal eigentlich auch nicht ständig geändert werden, daher die Hersteller wohl kaum darauf hören werden.
Oder man opfert Roaming dafür, dass man sich fest an einen Router bindet, und dieser dann ggf. eine „geheime“ 1:1 Zuordnung zwischen echter MAC und öffentlicher MAC hat, die nur er kennt. Freifunk ohne Roaming kann man aber knicken, das würde schon den Fall ausschließen dass man zwischen zwei APs mit ähnlich guter Signalqualität sitzt, und öfters mal zwischen beiden hin- und herflippt. Da würden dann natürlich jedes mal alle Verbindungen gekappt werden.
Vielleicht mag ja jemand mal ne Anbindung an das vorgestellte Snoopy Framework umsetzen ;D
Wenn du das nüchtern betrachtest hast du die Entscheidung zwischen einem sicheren Datennetz, oder eben einem Freifunk.
Da wir ja darauf aus sind, dass möglichst viele Leute mitmachen, können wir nie ausschließen, dass sich unter den Leuten eine faule Node befindet, die periodisch Daten aus dem Mesh absaugt.
Was man allerdings machen kann, ist eine kleine Hürde einzubauen, die Daten nicht 1:1 in der nodes.json wiederzuspiegeln, ein potentieller Angreifer auf den Datenschutz müsste dann schon aktiv an der Community teilnehmen, die sie/er abschnorcheln möchte.
Bisweilen reicht ein wget in der dauerschleife, um ziemlich viel Metadaten aus fremden Communities einzusammeln.
Ein erster Schritt wäre schon mal nur die Verwendung einer Hashsumme der Mac-Adresse, anstatt die Adresse im Plaintext, innerhalb der Karte…
Ich finde man muss hier auch differenzieren zwischen dem Flooden der Daten innerhalb des Freifunk Netzes (Mesh) und dem exponieren dieser Daten im Internet.
Dass die Alfred Daten innerhalb des Meshes gemulticast werden ist momentan halt nötig. Viel schlimmer ist es diese Daten im Internet zu veröffentlichen, wie es manche Communities mit dem Alfred Tab der Karte machen. Hier muss man zuerst ansetzen …
1 „Gefällt mir“
Hi @stv0g,
das wurde vor einiger Zeit einmal in einem Workshop im Rahmen des Freifunk Nord treffens diskutiert:
viele Grüße
Thomas
Die Sicherheit muss immer Ende-zu-Ende stattfinden. Oder das Endgerät absichern.
Wenn man die Sicherheit ins Netz verlagert, dann ist man der Verdammnis anheim gefallen.
- Das war bei der der Deutschen Bundespost mit ISDN-GBGs (Geschlossenen Benutzergruppen als Zugangskontroll für Datendienste)
- Das ist bei „Mailverschlüsselung auf dem Server bei DeMail“ so.
- Das ist bei Verwendung von unverschlüsselter Mail in WPA2-Netzen so, frei nach dem Motto „Der Provider hört ja nicht ab“.
- Das ist der Verzicht auf sinnvolle Firewalleinstellungen in mittelständischen Firmennetzen, nach dem Motto „Wir vertrauen jedem Praktikanten und jedem Druckerhersteller, dass er nix böses treibt“.
Wir als Freifunk sagen wenigstens: Du liebeR UserIn musst Dich selbst schützen. Rechne stets mit dem Schlimmsten! Denn diese BubInnen sind sowieso da, auch bei anderen Providern, auch gegen deren Willen. Aus Gründen der Staatsraison.
Danke Thomas,
einen Leitfaden halte ich auch für den richtigen Weg.
Wenn wir es technisch nicht vermeiden können, sollten die Nutzer zumindestens darüber bescheid wissen.
Naja, für mich macht das keinen Unterschied. Ob nun als öffentliche Angabe auf der Karte, in nodes.json oder als Broadcast im Netz.
Jeder technische versierte Nutzer bekommt das hin.
Wenn wir die Infos verstecken und sie quasi klein reden hat das doch gerade die flasche Wirkung…
Ja, aber mir gings ja um den Datenschutz. Sodass das nicht jeder nachvollziehen kann wo ich gerade so herumlaufe.
Ja aber sagen wir ihnen auch, dass sie trotz Verschlüsselung verfolgbar sind?
Könnte Batman nicht gehashte MAC Adressen fürs Routing nutzen?
(Das ist jetzt aber nich der richtige Ort hier)
Das hat rein gar nichts mit klein reden oder verstecken zu tun. Es ist ein großer Unterschied, ob jeder X-Beliebige Internet User auf der Welt „einfach nur so, weil er IP technich hinkommt“ diese Daten herunterladen kann oder ob er Teilnehmer im Freifunknetz sein muss, damit er da ran kommt. Es geht mir hier um Datensparsamkeit. Wenn man Daten aus dem Freifunk Netz in einem weltweiten Netz veröffentlich sollte man vorher gründlich überlegen, welche Daten man veröffentlich und ob das überhaupt nötig ist. Freifunk ist ja auch dezentral und hat das Ziel autark, also auch unabhängig vom Internet zu sein.
Alle Daten, die z.B. in der Karte nicht benötigt werden, kommen einfach nicht in die nodes.json, fertig aus. Wir in Mainz, Wiesbaden haben das Karten Backend entsprechend gepatcht, dass wir nur die wichtigen und unkritischen Daten mit in die Karte aufnehmen. Vor ein paar Monaten gabs ja auch noch einen Patch, der alle Clients (+ deren MACs) aus der Karte entfernt hat, super!
1 „Gefällt mir“
Ja, auch die muss am Ende stattfinden.
Sogar Apple hat das verstanden.
Müsste man wenn dann mit einem eingehashten Timestamp (Datum, ohne Uhrzeit) kombinieren. Dann hätte man eben nur einmal alle 24h Konnektivitätsprobleme (wär ja nicht so schlimm, kommt uns ja von irgendwoher bekannt vor 
)
Dann wäre man nur über einen Tag lang verfolgbar, aber nicht z.B. über Jahre.
Wenn man nur hasht hätte man ja das selbe Problem. Eine MAC ist genauso eine erstmal nicht personenbezogene Zahl wie der Hash einer MAC, die aber (praktisch gesehen) immer noch eineindeutig/bijektiv aufeinander abzubilden sind.
Apple hat den Macshuffler mit dem derzeitigen IOS eingeführt.
Ich bin ziemlich zuversichtlich, dass Google mit Android da nicht lange hinterherschauen wird.
Von daher dürfte sich das mit „den Jahren“ bald erledigt haben.