Egal wie ich versuche das zu interpretieren, ist es zunächst so formuliert das jede Art und Richtung von Traffic erfasst ist.
Es sind eine Reihe dreckiger technischer Tricks notwendig um dem User einen Splashscreen aufzuzwingen. Deswegen haben sich viele Communities (es gibt übrigens nicht „DIE“ Community, alle haben eine andere Ansicht) davon verabschiedet.
Verabschiedet im Sinne von - Ja, das gab es mal, aber es hat sich nicht bewährt. Die Begehrlichkeiten sind immer wieder da, damit sich z.B. Unternehmen dort platzieren können oder Spielregeln angezeigt werden können, die der User bestätigen muss. Und immer wieder entscheidet man sich wieder dagegen, weil es den Zugang behindert.
Strohmann - bitte beim Thema bleiben.
Und noch ein Strohmann. Was hat denn der Splash Screen mit einer regelmäßigen Deaktivierung zu tun?
Vielleicht würde deine Community deswegen sogar tolerieren, dass die von dir verwalteten Router Splashscreens ausliefern. Suchbegriffe wären „openwrt“ und „captive portal“.
Wenn alle anderen Meinungen falsch sind, ja.
Um dies anzuzeigen muss der DNS Eintrag von allen Domains geändert werden. Du kaperst also Domains wie Google.de oder Sparkasse.de und leitest diese auf deinen eigenen Server um und gibst dich als diese aus.
Für alle Domains wurde Geld bezahlt um diese nutzen zu dürfen. Wenn du also zu einer Domain falsche IP-Adressen auslieferst gibt es mehre Probleme:
Du bestiehlst den rechtmäßigen Nutzer der Domain.
Du bekommst Daten die der User eigentlich an diese Domain weiterleiten wollte.
Es erscheinen eine Menge Fehlermeldungen auf dem Endgerät weil hoffentlich alle Domains nur mit einer Verschlüsselung funktionieren und du keine Zertifikate dafür ausstellen kannst.
Hat eigentlich schon jemand versucht den Rechtsweg deswegen mit einen Hotspotanbieter zu bestreiten?
4 Likes
Gibt ja grundsätzlich unterschiedliche Implementierungen, aber egal welche man nutzt wird eben manipuliert, um auf die Portalseite zu gelangen, statt dorthin, wo die IP-Pakete eigentlich hin sollten / von kommen sollten.
Ich frag mich ganz ehrlich auch, wieso es da noch kein Industriegremium für eine Standardisierung gibt. Ich meine, die HTTPS-Problematik existiert bereits und wird sich nur noch weiter verschlimmern.
Es gibt ja IEEE 802.11u für den Informationsaustausch von AP und Client direkt bei der Verbindung, aber das ist auch keine Nachricht spezifiziert mit der der AP dem Client sagen kann „Hier ist ein Splashscreen, zeig bitte mal folgendes an“ ohne irgendwas umzuleiten?
Nun ja, das Thema Befreiung von der Störerhaftung
gemäß des Gesetzentwurfes würde auch eine solche Seite erfordern.
Wenn es denn in der Form Ende September durch geht.
Neben der angemessenen Sicherung muss sich der Betreiber wie bisher vom Nutzer zusichern lassen, dass dieser keine Rechtsverletzungen über den WLAN-Anschluss begehen wird. Nach wie vor kann er so mit nur einem Klick ins Internet gelangen.Erfüllt der WLAN-Betreiber beide Voraussetzungen, haftet er nicht als Störer für die von anderen über seinen Anschluss begangenen Rechtsverletzungen, kann also Abmahnungen und Unterlassungsklagen verhindern.
Wenn es nur die Privatleute trifft, dann nur die Communities die nicht zentral arbeiten…
Ich gehe mal davon aus, das Freifunk ganz neue Wege geht 2018 wegen dem VDS Gesetz.
Praktisch kein VPN mehr, dafür die Daten und Freigaben in einer Cloud basierenden Captive Portal verarbeitet.
Aber wer weiß was kommt…
Gerne alles machbar aber dann bitte auf eigene Faust mit irgendeinem Schweden VPN und ohne FFRL Backbone Infrastruktur.
Weiterführende Informationen dazu finden sich hier:
4 Likes
Wir haben scheinbar das MEMO nicht erhalten.
Quelle für die Aussage?
Captive Portals dürfen nicht als Eingangstür für den Netzwerk-Zugriff verwendet werden
Ob das allerdings am Ende auch alles so in „Gesetzte“ gegossen wurde kann ich nicht sagen (finde die Endfassung nicht).
Hier aber noch mal in jüngerer Vergangenheit 07/15 referenziert:
Hallo,
die Policy Documentation in dem veröffentlichten Status bildet die Grundlage für die Nutzung des FFRL Backbone.
Das haben bis zum jetztigen Stand alle angebundenen Communities so akzeptiert.
Grüße
Thomas
Ich fürchte fast, die meisten haben sie auch deswegen akzeptiert, weil sie so derartig vielseitig auslegbar ist (wer ist denn nun der User? Und was ist die Infrastruktur der lokalen Community?), dass man nicht fürchten muss, dass das jemals „konkret“ werden könnte.
Man verstehe mich bite nicht falsch. Ich teile die Intention und denke auch nicht, dass z.B. Captive Portals irgendwelche Probleme lösen könnten. Nur kann ich weder aus dem PPA noch aus der Backbone-Policy ein CP-Verbot durch „Router, die nicht in Vereinsbesitz sind“ herleiten.
(Wenn man das wollte und das könnte man für sinnvoll erachten, dann sollte man das schlicht auch so schreiben und nicht so verklausuliert, dass man es erst umständlich herleitet aus mehreren Paragraphen).
Oder um es anders zu beschreiben: Ich halte es mit dem derzeitigen Regularium für wesentlich einfacher alle Knoten auszusperren, die keine funktionsfähige E-Mail-Adresse propagieren. und im zweiten Schritt sogar alle, bei denen auf Mail binnen angemessner Frist und Nachfrist keine Kontaktaufnahme möglich ist.
(Nein, das wäre nicht sinnvoll, aber so einen Ausschluss würden die Regularen zumindest hergeben. Router „mit Splashpage“ auszuschließen, dafür sehe ich keine Handhabe.)
Ich verstehe garnicht was es da zu diskutieren gibt.
Ich habe das von Anfang an so rausgehört das der FFRL keine CP duldet wenn der Traffic über das FFRL Backbone ausgeleitet wird.
Wer sich da nicht dran hält bekommt halt den Tunnel zum Backbone abgenommen.
Selbst wenn das nicht zu 100% klar irgendwo steht muss das eigentlich jeder der ein bisschen hier liest sofort rausgehört haben.
Wer das CP gerne machen möchte kann das ja ohne Probleme machen (außer der Kritik der Community), dann aber ohne FFRL und dafür mit Schweden VPN
3 Likes
Siehe mein Posting.
Aber ich erkläre es gern nochmal, falls die Frage ernst gemeint war.
1.: Das Problem ist wirklich, man es nur indirekt aus den existierenden Dokumenten ableiten kann. Man kann diese Testpassagen aber eben auch anders lesen.
Das soltle meiner Meinung nach schlicht klar gestellt werden.
2: Darüber hinaus gibt es (siehe Flüchtlingsthread) Leute, die behaupten, ihnen sei gar nicht bewusst, welche Dinge sie anerkennen oder wie sie solches lösen sollten, wenn seitens ihrer Domain-Nutzenden z.B. mit selbstgebrauter Firmware Dinge getan werden.
3: steht die Behauptung im Raum, der Freifunk Rheinland würde selbst eine Captive-Portal-Lösung betreiben nm Freifunk-Knoten in einem NRW-Ministerium. Da gibt es aus Q2/2015 so eine „good point, we will check“ Aussage, und ein paar wochen später auf die Rückfrage ein „ist gerade Urlaubzeit, please stand by“.
Da würde schlicht eine klare Aussage helfen in der Art: „Nein, da ist kein CP im Einsatz hinter einem FFRL-Uplink und war auch nicht“ Sollte eigentlich machbar sein und bösen Speklulation um „Gleichheit vor Regeln“ den Saft entziehen.
Bin auf deine Auslegung mal gespannt. Denke der Satz ist eindeutig.
3 Likes
Es bieten sich auch „Niederlande VPNs“ (oder heißt es „Niederländer VPN“?) an. Ich wundere mich immer wieder über die Versteifung.
Ich glaube das ist einfach ein Begriff der sich eingebrannt hat. 
Ich hatte auch gerade den Fall mit einem Splash-Screen. Meiner Meinung nach sollte man sich fragen, was man damit bewirken möchte. Freifunk sollte im technischen Teil gänzlich auf Werbung verzichten. Es gilt zwar für das Projekt an sich Werbung zu machen, aber nicht, wenn man die Technik nutzt. Das ist für mich etwas, was ich absolut ablehne. Wir sind auch kein Internetanbieter im klassischen Sinne. Mir kommt immer die Galle hoch, wenn die Abgeordneten im Bundestag in einer Diskussion Werbung für ihre Partei einbauen, was die Diskussion niemals voranbringt, sondern verzögert. Das ist hier ähnlich und wir sollten mit gutem Beispiel vorangehen. Immerhin wissen wohl alle, dass Freifunk niemals kommerziell betrieben werden kann. Wenn ich durch die Innenstadt gehe, dann will ich immer Netz haben und nicht irgendeinen Button im Browser drücken müssen. Das würde bei mir nur Unmut erzeugen. Deshalb die Frage, was überhaupt der Nutzen von der Spash-Seite sein soll.
2 Likes
Wie du selbst schriebst:
Technischer Nutzen einer Splashpage: keinen
Werbenutzen einer Splashpage: Die Leute freuen sich, wenn sie ihr Logo sehen
Rechtlicher Nutzen: Man kann ein paar Kritiker beruhigen
Praktischer Nutzen: Mehr Leute die man dabei auslachen kann, wie sie auf einer für Desktop-PCs skalierten Seite einen winzigen Button zu drücken versuchen und dabei lauthals fluchen.
Meine persönliche Meinung:
Wenn ich eine technische Anwendung entwickle, dann soll diese dem Anwender helfen und nicht stören. Es soll also höchstens ein Schritt weg fallen oder ein Schritt geändert werden, aber auf gar keinen Fall ein neuer hinzukommen. (Darauf reagieren Anwender allergisch). Captive Portale machen aber genau das. Statt einfach nur das WLAN anzuklicken, muss ich nun
- einen Browser öffen
- (optional) irgendeinen Haken suchen
- (optional) diesen Haken treffen
- irgendwo akzeptieren klicken und dabei meine Seele verkaufen.
- Zurück zur Anwendung wechseln, die ich eigentlich nutzen wollte
Das sind 3-5 Schritte die Hinzukommen und somit den eigentlich ablauf verkomplizieren statt ihn zu vereinfachen. Das würde vielleicht einmalig auch noch gehen, aber es würde ja regelmäßig stattfinden. Folglich -> NoGo
3 Likes