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

Hintergrund: 01/2018 war dokumentiert, dass es keinen Auto-Updater gibt. Yanosz hat festgestellt, dass er doch aktiv ist und andere Freifunk damit Access in sein Netz hatten. Von der Wahrnehmung her eine Backdoor.

Ziel wäre, dass System so zu dokumentieren, wie es aktuell umgesetzt ist und sicherzustellen, dass sich die Benutzer(innen) bewusst sind, dass Sie Zugriff einräumen (user consent).

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?)
• 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 einfach 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.