Gibt es Erfahrungswerte wie viele aktive FreifunkerInnen durch ein Captive Portal bisher gewonnen wurden?
Die Abwägung fällt da für mich gerade ganz klar aus…
4 „Gefällt mir“
keine Routing-Infrastruktur vom Freifunk Rheinland.
Grüße,
dictvm
2 „Gefällt mir“
Sofern das der Weg ist, dann haben wir wohl keinen gemeinsamen mehr. Wobei ich jetzt nicht beurteilen kann, ob Du den Verein repräsentierst oder normaler freifunker bist. Solltest Du den Verein repräsentieren wäre das allerdings schade, denn dann wäre meine Mühe in den letzten Jahren umsonst gewesen.
Über das Crowdfunding haben viele Leute gespendet und die Wolke hier ist ein Gemeinschafts-Projekt geworden. Luisenviertel.com is for sale | HugeDomains
Ich würde behaupten, dass der Charakter als Gemeinschaftsaktion die Wolke in Fernsehn und Zeitung gebracht hat, da es auch anderswo in Wuppertal Wolken gibt. Im Nachgang haben weitere Wolken Zuschüsse aus öffentlichen Quelle erhalten, wahrscheinlich auf weil in der Presse entsprechendes über die Gemeinschafts-Wolke zu lesen war. Sicherlich kann die Wolke nicht die Lorbeeren einstreichen, ist aber schon ganz klar ein Wegbereiter. Und jeder, der automatisch verbunden wird (wie das moderne Geräte halt machen), siet mit Splash-Screen, dass es sich um eine Gemeinschafts-Aktion handelt und nicht um Datensammel- oder Kommerz-Funk.
@GuidoG der gemeinsame Konsens von Freifunk besteht aus dem [Pico Peering Agreement][1]. Als Betreiber eines Knoten mit Captive Portal manipulierst Du Daten von Nutzern. Hier speziell HTTP-Datenverkehr indem du ihn umleitest und hijackst.
[1]: http://www.picopeer.net/PPA-de.html
2 „Gefällt mir“
Hi Guido,
Ich kann hier keine Antwort auf die Frage von takt erkennen, kann mir aber auch nicht vorstellen, dass eure Crowdfunding-Kampagne ohne ein Captive Portal ein anderes Ergebnis gehabt hätte, weil dieses dort auch keinerlei Erwähnung findet.
Grüße,
dictvm
Das wurde jahrelang von Freifunkern - aus guten Gründen - so gemacht. Die erste Erwähnung, die mir gerade über den Weg gelaufen ist, ist von 2007.
Bitte erklären, in wie fern ich Daten von Nutzern manipuliere. Ich sehe eine Verzögerung, aber keine Manipulation. Datenverkehr wird auch nicht „gehijackt“. Er verlässt den selben Router, durch den er eh gehen würde, nur etwas später. Der Splashscreen stammt schließlich von jener Queen, der der Client sowieso vertraut, um Freifunk zu nutzen. Es ist also etwas albern, hier von einer Entführung von Daten zu sprechen.
Hallo,
ich wurde bei uns in Essen-Burgaltendorf auch immer wieder auf ein Captive Portal angesprochen. Man erhoft sich davon mehr Identität und Eigenwerbung.
Allerdings gibt es nun einmal Vereinbarungen, wie z.B. das Pico Peering Agreement v1.0, an denen wir uns auch halten sollten. Sonst funktionieren Community-Netzwerke nämlich nicht mehr sauber.
Gruß Jörg
Hi dictvm,
ich kann hier auch keine Antwort auf meine Frage erkennen 
Vertrittst Du den Verein oder gibst Du Deine persönliche Meinung wieder?
Davon unabhängig: die Landingpage nach dem Akzeptieren der Nutzungsbedingungen ist die „Danke“-Seite gewesen - bis zum letzten Update jedenfalls. Meinst Du ich hätte besser die genaue URL der zukünftigen „Danke“-Landingpage erwähnen sollen? Das habe ich für unnötig gehalten, tut aber auch jetzt eigentlich nichts zur Sache.
Der Wegfall des Splashscreens ist jedenfalls eine große Veränderung auf der Seite der öffentlichen Wahrnehmung. Ich halte es für wichtig, dass die Leute wissen, dass es ein Gemeinschaftsnetz ist, dass es keine unendliche Bandbreite hat und dass irgendwelche Kellerkinder sich ehrenamtlich darum bemühen, dass es läuft.
Wenn Freifunk diese Möglichkeiten nun nicht mehr bietet, dann ist das schade.
Grüße,
Guido
[quote=„GuidoG, post:29, topic:116“]
ich kann hier auch keine Antwort auf meine Frage erkennen Vertrittst Du den Verein oder gibst Du Deine persönliche Meinung wieder?[/quote]
Ich äußere meine Meinung, berufe mich auf das Pico Peering Agreement und habe aufgrund meiner beruflichen Erfahrung und meiner Position als Abuse-Verantwortlicher an dem Entwurf für unsere Provider-Policy mitgearbeitet.
Du hast so argumentiert als sei das Captive Portal ein deutlich beim Crowdfunding betontes Feature gewesen, das ihr den Finanzierenden angepriesen habt.
Das lässt sich durch bessere Werbung in Form von guten, in den Freifunk anbietenden Läden ausliegenden Flyern besser und weniger invasiv lösen. Du bist gern eingeladen dein Engagement für ein Captive Portal stattdessen in Konzepte für bessere Öffentlichkeitsarbeit zu investieren. Da besteht nämlich tatsächlich jede Menge Optimierungsbedarf.
Ich habe zum Captive Portal alles gesagt und klinke mich nun aus der Diskussion aus.
Grüße,
dictvm
3 „Gefällt mir“
Ich habe dazu weiter nachgedacht und noch einmal recherchiert. Alle existierenden „Lösungen“ betreiben zur Einblendung eines Captive Portals sogenanntes Hijacking. Es gibt kein Protokoll, dass eine Übermittlung eines URL zu einem Dokument für den Benutzer spezifiziert. Wenn Geräte eine „Anmeldung“ als erforderlich anzeigen, dann alleinig auf der Basis, dass sie ein Hijacking erkannt haben.
Solche Zumutungen an der Benutzbarkeit sind für die Benutzer nur rechtzufertigen, wenn der angebotene Zugang zu einem Netzwerk einem bestimmten Zweck dienen soll. So ist das bei den meisten Gäste-WLANs, da hier nur ein bisschen Surfen und Mailen ermöglicht werden soll. Oft wird dabei jeder Traffic außer HTTP(S) blockiert.
Ein Freifunk-Netzwerk ist jedoch ein regulärer (universeller) Zugang zum Netz. Die Klasse des Endgeräts (Smartphone, Desktop-System, Webserver, Blumengießautomat…) kann nicht eingegrenzt werden. Auf jeden Fall werden explizit auch sogenannte bedienerlose Systeme unterstützt. Diese Systeme haben große Probleme mit Captive Portals. Eine Implementierung von Wegklick-Skripten auf solchen Geräten ist nicht zumutbar.
Das Captive Portal ist daher auch für mich endgültig vom Tisch.
7 „Gefällt mir“
Die Bediener losen Systeme können einen Internetzugang auf einer anderen, nicht von DHCP vergebenen IP-Adresse erhalten bekommen; vom aufgeklärtem Nutzer und nicht von jemanden, der meint hier gratis Internet zu erhalten, denn dafür ist Freifunk mMn nicht da. Die GWs ohne CP gibt es auch in der Wolke, werden vom DHCP nur nicht mitgeteilt, und die Anleitung dazu wird im CP verlinkt. Jemand, der unfähig ist sich eine statische Adresse zu vergeben, wird ab und zu mit einer Seite konfrontiert, die ihn über den lokalen Freifunk aufklärt.
Die Frage dieses Threads war doch „Brauchen wir ein Captive Portal?“ Und nun ja, einige brauchen den offensichtlich. PPA gilt nur für das weiterleiten der Nachrichten im Freifunk. Internet ist ein externer Dienst des Freifunks. DHCP ist ein interner Dienst der Wolke. Welche IPs der DHCP-Service den Nutzern mitteilt ist eine Sache, die eine Community selbst im Konsens trifft. FFRL ist IP geworden, um die Knotenbetreiber vor Abmahnungen zu schützen. Ich bin der Meinung das seine Mitglieder über die Policy entscheiden sollen und nicht Einzelne. Darüber hinaus war die Devise, das einzelne Funkzellen Autonomie in der Umsetzung des Freifunks in ihrer Umgebung genießen. Hat sich diesbezüglich etwas geändert?
Die Vorteile und Nachteile eines CPs wurden zu genüge erläutert. Ich habe hier eine Ganz einfache Lösung für das Dilemma: der DHCP-Dienst, als interner Dienst, einer Wolke vergibt vermurkste IP-Adressen: vermurkster Gateway, verkorkster DNS. Alle Anfragen werden nicht zum GW weitergeleitet und auch landen sie nicht auf einem CP sondern auf einer Informationsseite der Freifunk-Community. Alle Anfragen, denn Internet ist ja kein Interner Dienst des Freifunks. Irgendwo, tief versteckt, ist die Information, wie man sich selbst eine statische IP vergibt, und wie die IPs des GWs und der DNS-Server lauten, wenn man nicht unbedingt die 8.8.8.8 schon eingetragen hat. Außerdem sind noch die Informationen, wie man bei sich Zuhause sein eigenes GW – nur für sich – betreibt. Dann hat man einen eigenen, internen Dienst: ein GW nur für sich und man muss sich ja nicht mehr mit der Störerhaftung herum plagen, denn dann ist man ja als einziger Nutzer seines eigenen GWs der Verursacher. Diese zusätzliche Information braucht man, weil der ISP-FFRL die Anbindung der Community verweigert hat und es wohl keinen einzigen anonymen GW in der Wolke gibt. Und das ganze nur, weil eine fiktive Policy, die mir nicht ein mal mein eigener ISP vorschreibt, verbietet IPv4-Port 80 umzuleiten, damit sich ein Nutzer diese Fehlfunktion mit nur einem einzigen Klick oder nur einem Neuladen des CP ausschaltet.
Die Lage in Wuppertal sieht so aus: manche Knotenaufsteller, vor allem die Gewerblichen, verlangen einen CP, sonst stellen sie keinen Knoten auf. Deshalb lautet die SSID „Freifunk Wuppertal“ und nicht „Freifunk“.
Die Frage des Threads habe ich beantwortet, Nachfragen beantworte ich gern. Und es bringt mir nichts mehr weiter zu diskutieren ohne einen Mitgliederentscheid in darüber in Aussicht. Darüber hinaus bin ich enttäuscht, dass dies nur ein pro-forma Thread ist, wo die Meinung nicht des Vereins, sondern einzelner, von vorne herein fest stand. Ich hoffe, Ihr findet Ironie in der zuvor beschriebenen „Lösung“.
[quote=„phip, post:32, topic:116“]
Die Frage dieses Threads war doch „Brauchen wir ein Captive Portal?“ Und nun ja, einige brauchen den offensichtlich.[/quote]
Ich habe dafür noch kein tatsächliches Argument lesen können, dass diese Einschätzung stützt. Zwischen „ich will aber!“ und einem tatsächlichen Bedarf liegen schon noch Welten.
Wir sind nicht Internet(!) Service Provider geworden um „Internet“ als einen externen Nebenbeidienst anzubieten. Entweder fällt aus einer Freifunknode Internet oder am besten gar nichts.
[quote=„phip, post:32, topic:116“]
Ich bin der Meinung das seine Mitglieder über die Policy entscheiden sollen und nicht Einzelne.[/quote]
Diese „Einzelnen“ wurden vom Vorstand ausgewählt um beim Aufbau des Projekts „ISP werden“ zu assistieren. In diesem Zuge entsteht gerade eine Policy, die wir veröffentlichen werden, sobald wir geschlossene der Meinung sind, dass diese vollständig ist. Daraufhin lassen wir sie von einem Anwalt auf juristische Fallstricke abklopfen und stellen den Entwurf der Community vor. Ich sehe nicht viel Sinn darin, einzelne Punkte von allen abstimmen zu lassen, ohne zu überprüfen, ob der/die Abstimmende über irgendeine Erfahrung mit dem Betrieb und dem Alltag eines ISP verfügt.
[quote=„phip, post:32, topic:116“]
Darüber hinaus war die Devise, das einzelne Funkzellen Autonomie in der Umsetzung des Freifunks in ihrer Umgebung genießen. Hat sich diesbezüglich etwas geändert?[/quote]
Ihr wurdet von den derzeitigen Admins des Freifunk Rheinland-ISP aber doch nicht gezwungen die neue Routing-Infrastruktur zu nutzen. Mehr möchte ich dazu hier nicht sagen.
Das ist ein berechtigtes Interesse der Nodeaufsteller. Inwieweit ihr da in den sauren Apfel beisst ist euch überlassen. Wenn ihr über die Freifunk Rheinland-Infrastruktur routen wollt, müsst ihr euch an die Policy des ISP halten, wenn der ISP schon aus rechtlichen Gründen auf ein Captive Portal verzichten möchte, um nicht Gefahr zu laufen, irgendwie mit dem Label „gewerblich“ in Verbindung gebracht zu werden. Ab diesem Zeitpunkt verlieren wir nämlich den Vorteil, nach derzeitiger Gesetzeslage keine Daten vorhalten zu dürfen(!), die individuelle Nutzer identifizierbar machen.
Dieser Thread diente den Admins in meiner Wahrnehmung dem Zweck, für den ISP-Betrieb die Argumente für ein Captive Portal zu sammeln, um diese zu beleuchten, zu hinterfragen und und ggfs. Möglichkeiten genannt zu bekommen, ein solches Portal ohne Eingriff in die Netzneutralität zu implementieren.
Grüße,
dictvm
5 „Gefällt mir“
Deshalb gab es ja hier schon @adorfers Vorschlag,
eines „Noncaptive Portal“/„Softcaptive Portal“.
Unabhängig davon, om man es will, schätze ich das als technisch akzeptable Lösung ein.
Allerdings nicht auf unserer Backbone Infrastruktur, sowas gehört wenn dann auf die Nodes als optionales Softwarepaket was sich abschalten lässt (Welches am besten per default aus ist). Allerdings gibt es das noch nicht. Es gab für die alte Freifunk Firmware einen Patch damit auch ohne Routing ein Splash via Ebtables zu realisieren ist.
Allerdings ist dies eingeschlafen und bis jetzt gab es auch keinen Bedarf dafür, wer da was machen möchte kann dies gerne machen. Ich schlage aber vor dann direkt als Gluon Modul damit alle was davon haben 
2 „Gefällt mir“
Zu @CyrusFox Vorschlag fällt mir grad nur ein „Halleluja“ oder wahlweise „Amen“.
Solange die Provider Policy nicht vorliegt, können wir es eh nicht solide diskutieren.
Aber wir haben ja eine mehrschichtige Org und Technik - da kann dann (soweit verstehe Ich es im Moment) ein Softcapture vieleicht zur künftigen Policy passen und doch die Community auf ihrer Ebene (Ich sähe da auch rechtliche Probleme, Gewerblichkeit) für sich selber entscheiden, bauen und per Gluon Paket teilen.
1 „Gefällt mir“
Vielen Dank @dictvm, dass Du dir die Zeit genommen hast meinen Post zu beantworten.
[quote=„dictvm, post:33, topic:116“]
Ich habe dafür noch kein tatsächliches Argument lesen können, dass diese Einschätzung stützt. Zwischen „ich will aber!“ und einem tatsächlichen Bedarf liegen schon noch Welten.[/quote]
Der Vorteil ist, dass der Nutzer sofort über Freifunk in seiner Umgebung informiert wird; der Nachteil, dass sein Port 80 vermurkst ist. Vor dem Surfen wird ein Nutzer ungefragt mit dem Thema Freifunk konfrontiert. Andererseits kann ein Nutzer nichts über den Freifunk wissen und bekommt in seinen Augen gratis Internet und kein Freifunk.
Von „ich will aber“ kann keine Rede sein. Das ist meine Community, die gemeinsam entscheidet.
[quote=„dictvm, post:33, topic:116“]
Das ist ein berechtigtes Interesse der Nodeaufsteller. Inwieweit ihr da in den sauren Apfel beisst ist euch überlassen. Wenn ihr über die Freifunk Rheinland-Infrastruktur routen wollt, müsst ihr euch an die Policy des ISP halten, wenn der ISP schon aus rechtlichen Gründen auf ein Captive Portal verzichten möchte, um nicht Gefahr zu laufen, irgendwie mit dem Label „gewerblich“ in Verbindung gebracht zu werden. Ab diesem Zeitpunkt verlieren wir nämlich den Vorteil, nach derzeitiger Gesetzeslage keine Daten vorhalten zu dürfen(!), die individuelle Nutzer identifizierbar machen.[/quote]
Danke für die Klarstellung. Das Vorhalten von MAC-Adressen für die das Verhalten des Port 80 drückt den ISP-FFRL in die gewerbliche Ecke. Nachfrage: auch wenn eine Freifunk-Community selbst die MAC-Adressen vorhält (wie bisher mit der FF-Advanced geschehen) und nicht der ISP-FFRL?
[quote=„dictvm, post:33, topic:116“]
Ihr wurdet von den derzeitigen Admins des Freifunk Rheinland-ISP aber doch nicht gezwungen die neue Routing-Infrastruktur zu nutzen.[/quote]
Das stimmt. Und nun stehe ich vor der Hölle in meiner Community. Mehrere Gateways … Wobei interessanterweise die Queens schneller DHCP vergeben, als es der Server tut. Auch bei Nutzern, weit, weit weg. Die erhalten dank fastd (selbst dann, wenn die Batman-Route über die Gateway-Supernode erfolgt) auch zuerst eine Antwort von irgendeiner Queen. Das ist aber ein anderes Thema.
[quote=„dictvm, post:33, topic:116“]
Dieser Thread diente den Admins in meiner Wahrnehmung dem Zweck, für den ISP-Betrieb die Argumente für ein Captive Portal zu sammeln, um diese zu beleuchten, zu hinterfragen und und ggfs. Möglichkeiten genannt zu bekommen, ein solches Portal ohne Eingriff in die Netzneutralität zu implementieren.[/quote]
Eine Implementierung einer Freifunk-Wolke mit einem GW ohne CP, welcher manuell genutzt werden kann, und einem DHCP-GW mit CP kommt also auch nicht in Betracht? Bitte prüft das. Bitte prüft oder beantwortet bei Gelegenheit:
- wo die Grenze zwischen der Community und ISP-FFRL liegt,
- ob DHCP ein interner Dienst der FF-Wolke oder der des ISPs ist, analog dazu wer bei DHCP die Daten vorhält (ISP/Community)
- ob ein CP ein interner Dienst einer FF-Wolke ist oder zum ISP-FFRL gehören würde, analog dazu wer die zu DHCP fast identischen Daten (MAC, IP, TTL) vorhält (ISP/Community),
- ob das Vorhalten der MAC, IP und TTL personenbezogene Daten sind, die, falls beim ISP gelagert, den ISP in eine gewerbliche Ecke drücken.
- wie das Dilemma eines uninformierten FF-Nutzers, der die „AGBs“ der Community weder kennt, noch bestätigt hat, gelöst werden kann. Er weiß ja nicht mal, ob er sich in einem total freien Netzwerk aufhält oder in einem Honeypot eines fiesen Fieslings.
Ansonsten belaste ich Euch lieber nicht mit zeitaufwändigen Fragen und Diskussionen. Wenn eine Policy ausgearbeitet wurde, so hoffe ich, dass es eine Gelegenheit geben wird konkret über die einzelnen Punkte zu Reden. Vielen Dank und viel Spaß und Erfolg beim Aufbau der ISP-FFRL Infrastruktur.
1 „Gefällt mir“
[quote=„CyrusFox, post:35, topic:116“]
Allerdings nicht auf unserer Backbone Infrastruktur […] [/quote]
Die FFW-Community hat zusätzlich zu w0 und w1 eigene Server, die ein CP betreiben würden.
1 „Gefällt mir“
Ja, das wäre bestimmt eine gute Idee gewesen. Nachbarn und Kneipenbesuchern irgendwas über ein „Captive Portal“ zu erzählen, damit die am besten erstmal halb Studieren müssen und gar keinen Bock mehr auf den ersten Schritt haben. Ich hätte auch Ports, Routingstrecken und Nameserver erwähnen sollen. Batman-Protokoll ganz vorne weg. VPN-Tunnel und dergleichen. Ich sehe schon - Du bist ein Mann aus der Praxis 
Herzlich willkommen! Wann setzt DU DEINE Zeit dafür ein? Und sorgst dafür, dass alle Nutzer - auch die auf öffentlichen Plätzen und der Straße - über das Gemeinschaftsprojekt und -konzept bescheid wissen?
Wo würdest Du die neuerdings so strikte Auslegung des PicoPeeringPolicy einsortieren? Welchen konkreten Bedarf gibt es da? Ich bitte Beispiele aus der Praxis.
Siehst Du, da hast Du es ja doch eingesehen.
Ich möchte Euch dann aber ans Herz legen, eine Freifunk GmbH oder gGmbH mit eigener Firmware zu gründen statt im Bestand grundlegende Funktionen zu ändern und die Community vor vollendete Tatsachen zu stellen.
Grüße,
Guido
2 „Gefällt mir“
Wir haben uns dazu einige Gedanken gemacht und haben diese auf der Wuppertaler Mailingliste festgehalten. Wir würden uns darüber freuen, das Thema nun erstmal etwas abkühlen zu lassen, bis wir unsere FAQ veröffentlicht haben.