blog.schildbach.de

Seit Version 3.5 kennt Firefox ja “Location Aware Browsing”. Eine Web-Applikation - etwa eine Restaurant-Empfehlungsseite - fordert den Aufenthaltsort des Nutzers vom User Agent an. Dieser ermittelt nach einer dem Datenschutz dienlichen Rückfrage unter Zuhilfenahme eines sogenanten “Geolocation Service Provider” die Geo-Koordinaten und liefert sie an die Web-Applikation zurück. Firefox nutzt als Geolocation Service Provider, nachdem i.d.R. kein GPS-Empfänger vorhanden sein dürfte, “Google Location Services”.

Eine zeitlang hat das bei mir auch recht zuverlässig funktioniert: Mein Wohnort in Berlin wurde z.B. bei Google Maps mit unheimlich anmutender Genauigkeit auf den Meter bestimmt. Seit einigen Wochen jedoch liefert jede Anfrage meinen alten, seit mindestens 9 Monaten nicht mehr gültigen Wohnort in München zurück. Was passiert da?

Laut Google nutzt “Google Location Services” die IP-Adresse des Nutzers sowie in dessen Umgebung befindliche WLAN-SSIDs zur Bestimmung der Geo-Koordinaten. Die IP-Adresse wird von Alice, meinem Internet-Provider, jeden Tag aufs neue dynamisch vergeben. Selbst wenn man bei Alice IP-Adressbereiche Städten oder gar Stadtteilen zuordnen könnte, gibt es keinen Grund wieso ich noch mit einer Münchner IP-Adresse im Internet surfen sollte.

Meine eigene WLAN-SSID habe ich kurz nach dem Umzug gewechselt. Die SSIDs meiner damaligen Nachbarn habe ich natürlich auch nicht mitgenommen.

Bleibt noch die Möglichkeit, daß irgendwo undokumentierter State im Browser gehalten wird. Jedoch tritt das Problem auch nach kompletter Ubuntu-Neuinstallation (und übrigens ebenfalls unter Windows) auf.

Mir ist das irgendwie umheimlich… Hat jemand eine Idee, wo ich suchen kann?

Vor vielen Jahren wurden die Grundlagen der jetzt allgegenwärtigen DSL-Anschlüsse geschaffen. Auf die Bitübertragungsschicht (die nicht Teil dieses Beitrags sein soll) legte man ATM (Asynchronous Transfer Mode), bei dem die Daten in Pakete unterteilt werden. Das war die ideale Grundlage für alle damals gängigen Netzwerk-Protokolle - neben dem heute üblichen IP (von TCP/IP) auch IPX/SPX (Novell) oder ISDN. Eine DSL-Leitung entspräche als fast der Verbindung über ein LAN-Kabel; die Datenverbindung steht, wenn auf beiden Seiten der Stecker drin ist.

Doch man hatte die Rechnung nicht ohne die Deutsche Telekom gemacht. Diese vermisste nämlich die Möglichkeit, die Verbindung softwaremäßig zu unterbrechen bzw. wiederherzustellen (die sogenannte “DSL-Einwahl”). Man war von ISDN- und Analogtelefonie gewöhnt, erst ab Einwahl bis zur Unterbrechung der Verbindung zu zahlen. Diese zeitbasierte Abrechnung sollte so lange wie möglich beibehalten werden. Das ist natürlich nicht möglich, wenn die Verbindung 24 Stunden am Tag besteht. Also suchte man nach einer Möglichkeit, eine virtuelle Verbindung über die DSL-Leitung aufzubauen. Die Wahl fiel auf PPP (Point-to-Point Protocol), und nachdem wir es nicht mit einer seriellen Verbindung zu tun haben, auf die spezielle Variante PPPoE (PPP over Ethernet). Und die klaffende Lücke zwischen ATM und Ethernet-Frames schloß man mit einem entsprechenden Adapter. Auf PPP thront dann wieder IP. Mit zwei zusätzlichen Schichten war man also nun in der Lage, die Kunden pro Minute zu schröpfen.

Fast forward, 10 Jahre. Alle deutschen DSL-Anbieter sind in dieselbe Falle getappt und tun es der Telekom gleich. In Österreich, Polen und vielen anderen europäischen Ländern verzichtete man immerhin auf den Ethernet-ATM-Adapter und entschied sich für die PPPoA (over ATM)-Variante. Der durch den Wegfall eines Protokolladapters erzielte Geschwindigkeitsvorteil beträgt immerhin knapp 1%.

Inzwischen dürfte 99% der DSL-Kundschaft auf eine volumenbasierte Abrechnung migriert sein. Viele davon haben sogar eine Flatrate. Einige DSL-Anbieter bieten gar keine zeitbasierte Abrechnung mehr an. Die Erfassung einer Nutzungsdauer ist also nicht mehr wirklich relevant.

Zeit, die Nutzung von PPPoE/PPPoA zu überdenken. Denn neben dem Protokoll-Overhead bringt es nämlich viele andere Probleme mit sich. Allen voran die Authentifizierung. Ursprünglich dafür gedacht, den Nutzer zu ermitteln, der sich über die Telefonleitung zum Zugangspunkt einwählt, ist das bei DSL weniger sinnvoll: Jeder Nutzer hat ohnehin eine dedizierte Leitung. Folgerichtig nehmens die Provider mit der Authentifizierung auch nicht so ernst und lassen einfach beliebige Passwörter zu. Trotzdem steckt hier eine riesige Fehlerquelle: Alle 4 Ausfälle, die ich bei meiner Alice-DSL-Leitung seit 8 Jahren zu beklagen hatte, sind darauf zurückzuführen. Mal wird aus unbekanntem Grund der PPP-Username geändert, mal trennt ein Bagger die Verbindung zwischen Zugangspunkt und Authentifizierungs-Server. Wohlgemerkt: In allen Fällen war die ATM-Verbindung intakt, es hätten also Daten fließen können.

Man muß auch bedenken, daß viele User schon damit überfordert sind, überhaupt eine Username/Passwort-Kombination in ihren Router einzutragen. Nebenbei erwähnt: Es gibt inzwischen weitergehende Protokolle, die die Konfiguration des Routers in die Hand des Providers legen. Warum tun die DSL-Provider sich und ihren Kunden den Aufwand für diese Vielzahl an Protokollen an?

PPP teilt dem Nutzer auch seine IP-Adresse zu. Dafür gibt es allerdings Alternativen, z.B. das via Ethernet und WLAN gebräuchliche DHCP. Ganz nebenbei kann man mit DHCP auch ganze Subnetze zuweisen, womit PPP versagt (daher geht man bei Firmen-DSL-Anschlüssen ohnehin schon einen anderen Weg). Und mit IPv6 wird sogar DHCP überflüssig, da dieses die Vergabe der IP-Adresse(n) bereits mitbringt.

PPP kann, wie schon erwähnt, die Verbindung trennen - auch anbieterseitig. Davon wird in Form der “Zwangstrennung”, die i.d.R. alle 24 Stunden erfolgt, auch Gebrauch gemacht. Doch wer will, verbindet sich nach einer Trennung direkt neu. Was bleibt, ist der Zwangs-Wechsel der IP-Adresse. Das ist aus Anbieter-Sicht nützlich, da es den Kunden erschwert, Serverdienste an DSL-Anschlüssen bereitzustellen. Der Zwangs-Wechsel einer IP-Adresse ist jedoch auch bei DHCP möglich, man müßte nur die “Lease Time” begrenzen.

PPP ermöglicht es, mehrere virtuelle Verbindungen gleichzeitig laufen zu lassen. Dies wird beispielsweise von Alice an manchen Anschlüssen genutzt, um Internet-Traffic von NGN (IP-Telefonie) zu trennen. So ist es unwahrscheinlicher, daß ein schneller Download das parallel laufende Telefongespräch beeinträchtigt. Doch das Feature paralleler Datenströme ist eines der Basisfeatures von ATM, ja eigentlich der Grund wieso man überhaupt Datenpakete eingeführt hat. Alternativ käme auch die QoS-Erweiterung für IP in Betracht.

Warum also nicht die Daten direkt über ATM fließen lassen? Mit “Multiprotocol Encapsulation over ATM” existiert seit über 15 Jahren ein Standard dafür.

Ich bin gerade ziemlich sauer auf o2.

Seit zwei Monaten nutze ich ja deren mobilen Internet-Zugang ausgiebig, natürlich auch für e-Mail. Vor einer Woche machte mich ein Gesprächspartner darauf aufmerksam, daß meine Mail bei ihm im Spam-Ordner landet, weil der einliefernde Mailserver angeblich für Spam-Auslieferung bekannt ist. What the fuck? Unser Mail-Server - liebevoll administriert - wird als Spam-Schleuder mißbraucht? Doch halt - die Adresse des Mail-Servers ist ja gar nicht die unseres Root-Servers, sondern eine von o2. Mein erster Gedanke war, daß Evolution die Mails versehentlich selbst an den für den Empfänger zuständigen Mailserver ausliefert, anstatt den dem Postfach zugeordneten Mailserver zu verwenden.

Doch Tage später finde ich heraus, daß Evolution gar keine Schuld trägt. Ein Test per telnet ergibt, daß ich gar nicht mit unserem Mailserver verbunden werde, wenn ich die Verbindung von meinem per UMTS verbundenen Client aus aufbaue. Stattdessen lande ich auf einem SMTP Proxy, und dieser bietet noch nichtmal STARTTLS (Verschlüsselung).

Ich frage mich, wieso o2 so einen Unsinn macht? Was für ein Sinn macht ein SMTP Proxy? Im Gegensatz zu HTTP kann man nichts cachen. Man kann auch keine Bilder kleinrechnen, da SMTP ja nur zum Verschicken von Mails dient und die Bilder bereits durch den Flaschenhals UMTS gewandert sind, wenn der Proxy zum Zuge käme. Also was? Etwa Mails mitlesen? Protokollieren? Ich will gar nicht weiterdenken.

Konsequenterweise habe ich jetzt auf unserem Mailserver SMTPS (SMTP via SSL) zusätzlich zu SMTP eingerichtet und empfehle jedem unserer User, die Mail-Clients auf SMTPS umzustellen. Wer sich auf SMTP/StartTLS verläßt, riskiert, daß seine Mails unverschlüsselt zum Mailserver übertragen werden.

Wie jeden Sommer veranstaltet McDonalds wieder ein Gewinnspiel. Das nicht nachvollziehbare Monopoly-Thema ist diesmal der EM gewichen, das Prinzip ist jedoch das selbe: Auf Cola oder Fritten befinden sich Rubbelfelder, die sogenannte Sofort- oder Sammelgewinne verbergen.

Sofortgewinne beschränken sich auf Werbegeschenke, daher betrachte ich sie nicht weiter. Ich hab’s auf die Sammelgewinne abgesehen. Um einen der höherpreisigen Gewinne zu erzielen, muß man nämlich zwei zueinander passende freigerubbelte Felder finden, also z.B. Teil 1 und Teil 2 des TFT-Fernsehers. Dieses Sammel-Konzept gibt es schon länger, ich finde es aber immer noch genial. Für den Gewinnspiel-Veranstalter hat das unglaubliche Vorteile:

1. Verzicht auf Nieten. Man kann alle herkömmlichen Lose mit der Aufschrift “leider kein Gewinn” einfach in “Hauptgewinn 1. Teil” umbenennen, ohne daß sich dadurch der Erwartungswert des Gewinnspiels ändert. Der Kunde hat dadurch ein viel besseres Gefühl als bei einer Niete, denn er hat ja schon die erste Hälfte für den Hauptgewinn gewonnen. Mehr noch, wahrscheinlich wird er angespornt sein, durch den Kauf weiterer Lose auch noch den zweiten Teil zu bekommen, obwohl er eigentlich nur eine Niete in der Hand hält.
2. Gewinne, die nicht abgeholt werden. Gehen wir mal davon aus, daß Teil 1 die verkappte Niete darstellt, und Teil 2 eigentlich der Gewinn, der entsprechend selten vorkommt. Die Wahrscheinlichkeit ist nicht schlecht, daß derjenige, der den wertvollen zweiten Teil freirubbelt, diesen nicht ernstnimmt und wegschmeißt, genau wie alle ersten Teile einzeln im Papierkorb landen. Ergo: McDonalds muß ein TFT weniger auszahlen.
3. Werbung im Portemonnaie. Ähnlich wie die ubiquitären Rabattgutscheine wirkt jede aufgehobene Rubbelkarte als ständige Erinnerung: Geh doch mal wieder zu McDonalds!

Als ich Kind war, gab es auf unserem lokalen Volksfest einmal eine Losbude mit A-, B- und C-Losen (und Jokern, die jedes Los ersetzen können). Nur, wer alle drei Lose vorweisen konnte, konnte einen Hauptgewinnen sein eigen nennen. Einzelne Lose berechtigten nur für einen wertlosen Preis (ich erinnere mich noch an Aufkleber, Kugelschreiber, usw.). Ich habe mein ganzes Taschengeld in diese Losbude versenkt, aber natürlich fehlte immer genau ein Los. Als das Volksfest abgebaut wurde, fragte ich den Besitzer, wieviele dieser seltenen Lose und Joker denn nun enthalten seien. Seine Antwort: 2 seltene, 3 Joker. Das war mein letztes Los, was ich jemals gekauft habe.