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 indiskutabel, dass sich Freifunker auf diese Weise 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. Es muss klar erkennbar sein:

• Was ist die Konsequenz: 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 zeigen.

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 kann dies aus der Dokumentation hervorgehen?

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.