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

Remote-Access

Diskussionspunkte:

• Wie soll die/der Benutzer/in Updates zustimmen (Radio-Button / Feld im Config-Mode? / Hinweis)?
• ToDos für die Key-Inhaber
  • 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?
• 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.
  • Praktisch eine Hintertür
  • Was machen wir mit dem Schlamassel?
  • Re-keying, löschen aktueller Keys: Ernsthafte Zusicherung, dass geschaffene Zugänge gelöscht wurden, sofern Aufsteller/innen nicht explizit zugestimmt haben?

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

• Benutzer/in kann sich für oder gegen automatische Updates entscheiden.
• So wird z.T. wahrgenommen, dass es automatische Updates geben könnte. Benutzer/innen gehen z.T. gutgläubig davon aus.

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?
• Die Doku sollte weder den Eindruck erwecken, dass es üblich ist, dass Freifunker Zugriff auf fremde Devices nehmen noch sollte der Download eine implizite Zustimmung ausdrücken (d.h. aktuelles Opt-Out verfahren).

Ideen / Arbeitspunkte / Anregungen

1. Wir branchen jetzt eine neue Firmware für neue Devices. Was tun?
2. Auto-Update klar als Projekt der Freifunker herausstellen, die Access bekommen : Es gibt Leute, die eine Firmware bauen, wo ihre Keys hinterlegt, damit sie ggf. Updates einspielen können. Autoren dokumentieren.
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 Weiteres Vorgehen
   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.