CommunityDay2019

Draft!

Details

Wann?

In 2019? https://dudle.inf.tu-dresden.de/FFKBUCommunityDay2019/

Wo?

C4?

Programm

FFRL Werbeblock

??????????

Mesh ./. Ad-Hoc (802.11s ./. IBSS)

• Was sind die genauen Gründe, für den Wechsel auf 802.11s in Bonn v2?
• Welche Hinweis geben wir Freifunkern, deren Hardware kein 802.11s kann? (z.B. RaPis)
• Warum zieht Bonn auf 802.11s um - Köln und Umland jedoch nicht? Gibt es Argumente dafür?

yanosz denkt, es wäre gut, wenn wir:

• den gleichen Modus überall verwenden (also 802.11s default überall)
• den Modus konfigurierbar halten (soweit möglich)
• auf der Karte anzeigen, welcher Modus verwendet wird, damit pico-Peering möglich ist.

Dokumentation Auto-Updater

Situation

• Seit Firmware 1.4 (2016??) ist der Auto-Updater per default aktiv (Opt-Out). Einige Freifunkker haben damit indirekt Zugriff auf private Router und Netze, um Software zu installieren.
• Bis 01/2018 wurden die Benutzerinnen und Benutzer im unklaren gelassen - die Dokumentation sagte aus, dass es keine Update-Funktion gibt und keine Updates verteilt werden können.
• Seit 01/2018 gibt es einen Hinweis in der Wiki, dass die Firmware über einen Auto-Updater verfügt. Benutzerinnen und Benutzer werden informiert und darauf hingewiesen, dass der Auto-Updater bei Interesse deaktiveren werden kann. Falls überlesen, werden Benutzer/innen nicht erneut aktiv mit der Entscheidung (automatische Updates ja / nein) aktiv konfrontiert. Bislang wurden keine Updates automatisch installiert.

Probleme / Issues

1. Hintertür-Problem

Freifunker haben aktuell noch ohne Zustimmung und ggf. Kenntnis des Aufsteller/innen Zugriff auf private Netze & Daten. Bis 01/2018 wurden Aufsteller(innen) über die Zugriffsmöglichkeit in die Irre geführt.

yanosz findet es kafkaesk, dass sich Freifunker verdeckt Zugriff auf private Daten und Netze verschaffen können: Falls jmd. denkt, dass es cool ist, unter falschen Angaben Zugang zu privaten Netze & Daten zu erlangen gibt es Diskussionsbedarf. Es steht für yanosz außer Frage, dass die Benutzer dem Autoupdater aktiv zustimmen müssen. Aus der Dokumentation muss klar erkennbar sein:

• Was ist die Konsequenz eines aktiven Auto-Updaters: Wer hat Zugang zu den privaten Netzen der Nutzer?
• Wer hat wann welches Update ausgerollt (audit history)?
• Welche Infos gibt es bei einem Update (changelog)?
• Welche Policy gibt es für automatische Updates (Key-Management, 4-Augen-Prinzip, etc.)

Diskussionspunkte:

• Wie soll die/der Benutzer/in Updates zustimmen (Radio-Button / Feld im Config-Mode? / Hinweis)?
• ToDos für die Key-Inhaber
  • Re-keying, löschen aktueller Keys: Ernsthafte Zusicherung, dass geschaffene Zugänge gelöscht wurden, sofern Aufsteller/innen nicht explizit zugestimmt haben.
  • Nachvollziehbare Dokumentation der Ownership (PGP / Web-Of-Trust?)
  • Soll die Zustimmung der Nutzer dokumentiert werden? Falls ja, wie?
• Wie werden ausgerollte Updates dokumentiert?
  • Wiki-Seite mit changelog
  • E-Mail über spezielle Liste?
  • Kontrolle / Auditing in der Community?
• Haftung für Freizeit-Admins bei Fehlern?
• Wie können Benutzer einzelene Updates zurückhalten?

2. Es-gibt-keine-Updates-Problem - es gibt keine Auto-Updater ja/nein Entscheidung.

Die Dokumenation suggiert aktuell, dass es einen Auto-Updater bzw. automatische Updates gibt. Benutzer/innen gehen z.T. gutgläubig davon aus. Die / der Benutzer/in kann sich für oder gegen automatische Updates entscheiden.

Diskussionspunkte:

• Welche Dokumentation macht Stand jetzt Sinn? Wie soll die aktuelle Firmware beschrieben werden? Evtl. klarer herausstellen: Es geht nicht um automatische Updates, sondern um Zugriffsrechte auf private Devices.
• Auto-Updater ist keine ja / nein - dafür / dagegen Frage. Es wird immer Leute geben, die "Ihre"-Firmware bauen. Das ist der Sinn des Projekts! Wie soll dies aus der Dokumentation hervorgehen?
• Passt es zum Projekt, Nutzern zu empfehlen (bzw. vor die Wahl zu stellen) uns Zugang zu Ihrem Netz zu geben, ohne dass tatsächlich Updates gibt? Warum sollte das jmd. tun wollen, d.h. welche Argumente sprechen dafür?

Ideen / Arbeitspunkte / Anregungen

1. Wir branchen jetzt eine neue Firmware für neue Devices. Was tun?
2. Auto-Update klar als Projekt einzelner Freifunker herausstellen: Es gibt auch Leute, die auch eine Firmware bauen, wo ihre Keys hinterlegt, damit sie ggf. Updates einspielen können. Wer macht genau was?
3. Netzstabilität ohne Auto-Updater (Notfall-Plan für fastd-Port Rotation)?
4. Das Scharf-Schalten (d.h. verlinken als Download in der Installationsanleitung) sollte der letzte Schritt sein - d.h. die Doku-Todos müssen erledigt sein, bevor entsprechende Software zum Download angeboten wird.
5. Vorschlag zur Auto-Updater Umsetzung
   1. 2 Branches: Mit / ohne Auto-Updater (2018.x) asap für alle Hoods
   2. Zunächst nur Firmware ohne Auto-Updater in der Anleitung verlinken
   3. Wenn die Doku fertig ist und es regelmäßige Updates gibt: Hinweise in Installationsanleitung aufnehmen.