PySkyWiFi: Kostenloses langsames WLAN auf Langstreckenflügen bauen

 (robertheaton.com)
1 Punkte von GN⁺ 2024-07-10 | 1 Kommentare | Auf WhatsApp teilen
  • PySkyWiFi ist ein Experiment, bei dem Profilfelder eines Airline-Meilenkontos, die schon vor der Bezahlung zugänglich sind, als temporärer Speicher genutzt werden, um während eines Langstreckenflugs HTTP-Anfragen und -Antworten extrem langsam hin- und herzuschicken
  • Ein früher Prototyp aktualisierte und pollte das Namensfeld des Kontos, um einen Chat zu bauen, und wurde dann so erweitert, dass ein Daemon am Boden Anfragen wie STOCKPRICE: APPL liest und Ergebnisse zurücksendet
  • Die endgültige Architektur ist in einen Sky-Proxy im Flugzeug und einen mit dem Internet verbundenen Ground-Daemon aufgeteilt; die Ziel-URL wird über den X-PySkyWiFi-Header eines lokalen curl-Requests übergeben
  • Die Übertragung zerlegt HTTP-Anfragen in kleine Chunks und hält sie mit DATA-, ACK- und END-Segmenten sowie 6-stelligen Sequenznummern in der richtigen Reihenfolge
  • Es wurde vermieden, dauerhaft automatisierte Requests an echte Airline-Konten zu senden; der Abschlusstest blieb dabei, über GitHub Gist per curl die Startseite eines Blogs aufzurufen und einige Minuten später die HTML-Antwort zu erhalten

Ein Umweg im WLAN-Portal vor der Bezahlung

  • Die WLAN-Loginseite im Flugzeug verlangte eine Bezahlung, erlaubte aber schon vorher kostenlos den Login in das Airline-Meilenkonto
  • Beim Bildschirm zur Profilbearbeitung fiel das Namensfeld auf, und es wurde als kleiner Kommunikationskanal zum Austausch mit der Außenwelt betrachtet
  • Als Programmiersprache war zunächst Go vorgesehen, aber mit Python ließ sich der Name PySkyWiFi verwenden, daher fiel die Wahl auf Python
  • Der Quellcode ist auf PySkyWiFi veröffentlicht

Prototyp 1: Instant Messaging über das Namensfeld

  • Nachdem sich zwei Clients in dasselbe Airline-Meilenkonto eingeloggt hatten, tauschten sie Nachrichten aus, indem sie das Namensfeld abwechselnd aktualisierten und auslasen
    • Wenn eine Seite den Namen auf Hello how are you änderte, las die andere Seite dies aus
    • Wenn er dann wieder auf Im fine how are you geändert wurde, konnte die erste Seite die Antwort sehen
  • Das direkte Ändern des Namens in der UI war umständlich, daher wurde es mit einem Kommandozeilen-Tool automatisiert
    • Das Tool loggt sich auf der Website ein und aktualisiert das Namensfeld eines Testkontos mit einer Nachricht
    • Es pollt alle paar Sekunden das Namensfeld und gibt bei einer Änderung die Antwort der Gegenseite aus
  • An echte Airline-Meilenkonten sollten danach keine automatisierten Daten mehr gesendet werden; es wurde nur noch geprüft, ob etwa 10 schnelle Aktualisierungen des Namens alle erfolgreich waren
    • Dieses Ergebnis deutet darauf hin, dass das betreffende Konto möglicherweise keine Begrenzung für Request-Rate oder Anzahl der Requests hatte
  • Die weitere Entwicklung reproduzierte dasselbe Prinzip dann mit GitHub Gists und lokalen Dateien
    • Denn damit war iteratives Entwickeln schneller und einfacher als mit dem Airline-Meilenkonto

Prototyp 2: Externe Informationen mit einem Ground-Daemon abrufen

  • Im nächsten Schritt läuft ein Daemon auf einem internetverbundenen Computer am Boden oder in der Cloud
  • Der Daemon pollt fortlaufend das Namensfeld des Airline-Meilenkontos und sucht nach strukturierten Anfragen aus dem Flugzeug
    • Beispiel: STOCKPRICE: APPL
    • Beispiel: SCORE: MANUNITED
  • Wenn er eine neue Anfrage findet, parst der Daemon sie, ruft die Informationen über eine passende API ab und sendet sie über das Airline-Meilenkonto zurück ins Flugzeug
  • Ab diesem Punkt war über einfachen Chat hinaus auch die Abfrage von Echtzeitinformationen wie Aktienkursen oder Sportergebnissen möglich

Die Gesamtarchitektur mit Sky-Proxy und Ground-Daemon

  • PySkyWiFi ist ein TCP/IP-ähnliches Protokoll, das komplette HTTP-Anfragen in ein Airline-Meilenkonto hineinschreibt; ein Computer am Boden führt dann die eigentliche HTTP-Anfrage aus und sendet die Antwort auf dieselbe Weise zurück
  • Es gibt zwei Komponenten
    • Sky-Proxy: ein Proxy, der auf einem Laptop im Flugzeug läuft
    • Ground-Daemon: ein Daemon, der auf einem internetverbundenen Computer zu Hause oder in der Cloud läuft
  • Vor der Nutzung wird zuerst der Ground-Daemon gestartet, dann verbindet man sich im Flugzeug mit dem WLAN und startet den Sky-Proxy auf dem Laptop
  • Der Nutzer sendet mit Tools wie curl eine HTTP-Anfrage an den lokalen Proxy
    • Beispiel: curl localhost:1234 -H "X-PySkyWiFi: example.com"
    • Die eigentliche Ziel-URL steckt im benutzerdefinierten Header X-PySkyWiFi
  • Der Ground-Daemon entfernt den X-PySkyWiFi-Header und verwendet ihn für das Routing zur Ziel-Website
    • Request-Body und andere Header werden unverändert weitergeleitet
  • Wenn alles abgeschlossen ist, kommt eine HTTP-Antwort wie bei einem normalen Internet-Request zurück, aber abhängig vom Netzwerkzustand im Flugzeug kann eine Anfrage mehrere Minuten hängen und nur mit wenigen Bytes pro Sekunde laufen

HTTP hin und zurück mit Chunks, ACKs und einem zweiten Konto

  • Der Sky-Proxy nimmt einen curl-Request entgegen und zerlegt die komplette HTTP-Anfrage in Chunks
    • Denn die Menge, die auf einmal in das Namensfeld eines Airline-Meilenkontos passt, ist klein
  • Jeder Chunk wird der Reihe nach in das Namensfeld des ersten Airline-Meilenkontos geschrieben
  • Der Ground-Daemon pollt das Konto, liest neue Chunks und hinterlässt eine Empfangsbestätigung, dass der nächste Chunk gesendet werden kann
  • Sobald die komplette HTTP-Anfrage wieder zusammengesetzt ist, schickt der Ground-Daemon die echte Anfrage ins Internet
  • Die HTTP-Antwort durchläuft denselben Ablauf in die Gegenrichtung
    • Der Ground-Daemon zerlegt die Antwort in Chunks und sendet sie zurück
    • Um die Implementierung einfach zu halten, verwenden die Antwort-Chunks ein zweites Airline-Meilenkonto
    • Der Sky-Proxy liest die Chunks, setzt die HTTP-Antwort wieder zusammen und gibt sie an den ursprünglichen curl-Aufruf zurück

Getrennte Rollen von Transport- und Netzwerkschicht

  • Die Kommunikationslogik von PySkyWiFi ist in Transportschicht und Netzwerkschicht aufgeteilt
  • Die Transportschicht entscheidet, welche Daten in welcher Reihenfolge gesendet werden
    • Wie lange Nachrichten in kleine Chunks aufgeteilt werden
    • Wie signalisiert wird, dass der Empfänger für den nächsten Chunk bereit ist
    • Eine sehr lose Parallele zu TCP
  • Die Netzwerkschicht schreibt und liest die von der Transportschicht festgelegten Daten in den eigentlichen Speicher
    • Das kann ein Airline-Meilenkonto, eine lokale Datei oder ein Discord-Profil sein
  • Diese Trennung macht es einfacher, neue Airline-Meilenplattformen anzubinden
    • Es muss nur eine neue Netzwerkschicht implementiert werden; die Transportschicht bleibt unverändert
    • Eine Netzwerkschicht für Tests kann lokale Dateien lesen und schreiben statt eines Airline-Meilenkontos

Übertragungsregeln mit DATA, ACK und END

  • Eine PySkyWiFi-Transportverbindung besteht aus zwei Pipes
    • Jeder Client hat eine SEND-Pipe zum Schreiben und eine RECV-Pipe zum Lesen
    • Ein Airline-Meilenkonto kann als Pipe verwendet werden
  • Ein PSWF-Client kann zu einem bestimmten Zeitpunkt nur senden oder empfangen
    • Im Sendemodus sieht er keine vom Gegenüber gesendeten Daten
    • Im Empfangsmodus sieht das Gegenüber gesendete Daten nicht
    • Es ist also nicht wie bei TCP jederzeit bidirektional
  • Lange Nachrichten werden mit DATA-, ACK- und END-Segmenten übertragen
    • DATA: besteht aus dem Zeichen D, einer auf 6 Stellen aufgefüllten Sequenznummer und den eigentlichen Chunk-Daten
    • Beispiel: D000451adline": "Mudslide in Wigan causes m
    • ACK: besteht aus dem Zeichen A und der zu bestätigenden 6-stelligen Sequenznummer
    • Beispiel: A000451
    • END: ein einzelnes Zeichen E, das das Ende einer Nachricht markiert
  • Der Sender schickt DATA und wartet dann, bis ein ACK mit derselben Sequenznummer empfangen wird
    • Wenn A000451 eintrifft, gilt Chunk 000451 als verarbeitet und Chunk 000452 wird gesendet
  • Sieht der Empfänger END, behandelt er die Nachricht als abgeschlossen, und Sender und Empfänger tauschen die Rollen

Schnittstelle der Netzwerkschicht-Implementierung

  • Die Netzwerkschicht stellt eine einfache Schnittstelle bereit, die Daten in einen Speicher schreibt und daraus liest
  • Es gibt zwei verpflichtende Operationen
    • send(msg: str): schreibt msg in den Speicher
    • recv() -> str: liest eine Nachricht aus dem Speicher
  • In einer auf Airline-Meilenkonten basierenden Implementierung entsprechen diese beiden Operationen dem Schreiben und Lesen des Namensfelds des Kontos
  • Es gibt außerdem zwei verpflichtende Eigenschaften
    • sleep_for: die Wartezeit in Sekunden, die die Transportschicht zwischen Polling-Vorgängen der RECV-Pipe einlegt
    • segment_data_size: die Anzahl der Zeichen, die in ein Segment passen
  • sleep_for kann bei Testimplementierungen wie Dateien niedrig sein, sollte aber bei einer Airline-Meilenkonto-Implementierung mindestens einige Sekunden betragen, damit nicht zu viele Requests an den Remote-Server gesendet werden
  • segment_data_size muss der maximalen Größe des verwendeten Felds im Airline-Meilenkonto entsprechen; im Beispiel sind das etwa 20 Zeichen
  • Es gibt zwei optionale Hooks
    • connect_send(): wird bei der Initialisierung der SEND-Pipe aufgerufen und kann in einer Airline-Implementierung verwendet werden, um sich mit Benutzername und Passwort einzuloggen und Cookies zu erhalten
    • connect_recv(): wird bei der Initialisierung der RECV-Pipe aufgerufen

Base26-Codierung und Ideen zur Bandbreitenverbesserung

  • Das HTML-Formular des Airline-Meilenkontos erlaubt im Namen möglicherweise keine anderen Zeichen als Buchstaben
    • Stephen könnte akzeptiert werden
    • GET /data?id=5 könnte abgewiesen werden
  • Um das zu umgehen, kann die Netzwerkschicht Segmente in Base26 codieren, bevor sie in das Airline-Meilenkonto geschrieben werden
    • Base26 stellt einen String nur mit den Buchstaben A bis Z dar
    • Dafür wird ein Byte-String in eine große Zahl umgewandelt und dann wie eine Zahl im 26er-System mit den Zeichen A bis Z dargestellt
    • Beispiel: b26_encode("Hello world") gibt CZEZINADXFFTZEIDPKM zurück
  • Die Transportschicht muss diese Codierung nicht kennen
    • Die Netzwerkschicht wandelt die Bytes in Base26 um, speichert sie und stellt beim Lesen wieder die ursprünglichen Bytes her
  • Base26 macht Strings deutlich länger und reduziert damit die Bandbreite
    • Eine Base52 mit Groß- und Kleinbuchstaben könnte kürzer sein, bleibt aber als Verbesserung für Version 2 offen
  • Die Bandbreite lässt sich erhöhen, indem man die Segmentgröße vergrößert
    • Selbst wenn ein Feld nur 20 Zeichen speichern kann, könnten mit fünf 20-Zeichen-Feldern parallel 100-Zeichen-Segmente in einem Request gesendet werden
    • Der Empfänger könnte alle fünf Felder in einem Request lesen und wieder zusammensetzen

Verbesserungspotenzial durch HTTP CONNECT und der Abschlusstest

  • PySkyWiFi könnte einen besseren Tunnel bauen, wenn statt manuell ausgetauschter HTTP-Anfragen HTTP CONNECT requests verwendet würden
  • CONNECT ist der Mechanismus, den die meisten HTTP-Proxys verwenden; damit könnte PySkyWiFi wie ein Proxy auf Systemebene arbeiten und auch Browser-Anfragen verarbeiten
  • Mit CONNECT würde PySkyWiFi direkt eine TLS-Verbindung mit der Ziel-Website aushandeln, sodass der Datenverkehr durch das Airline-Meilenkonto verschlüsselt wäre
  • Der Nachteil ist ein deutlich höherer Implementierungsaufwand
  • Im finalen Test wurden Daten über GitHub Gist getunnelt, per curl die Startseite des Blogs geladen und einige Minuten später die HTML-Antwort empfangen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-07-10
Meinungen auf Hacker News

  • Vor Jahrzehnten nutzte meine Partnerin Google-Voice-SMS so, dass sie sie direkt im Gmail-Posteingang las und beantwortete. Sie mochte Handys nicht und trug deshalb ein altes Kindle Keyboard mit unbegrenztem 3G mit sich herum.
    Mit dem einfachen Browser des Kindle konnte man die schlanke Gmail-Ansicht öffnen, sodass es sich wie ein SMS-Gerät ohne monatliche Gebühren nutzen ließ; das einzige Problem waren Benachrichtigungen über neue Nachrichten.
    Also wollte ich nach einem Jailbreak einen Zähler auf dem Homescreen anbringen, kam dann aber auf die Idee, den Zähler neben den Kindle-Gerätenamen zu setzen, den man im Amazon-Konto ändern kann.
    Auf meinem Heimserver ließ ich per Browser-Automatisierung Amazon einloggen und den Gerätenamen in My Kindle (x) ändern; x war die Zahl der ungelesenen Google-Voice-SMS, und der Kindle aktualisierte den Namen auf dem Homescreen innerhalb einer Minute. Das funktionierte jahrelang gut.

    • Ich erinnere mich, dass die AT&T-Rechnung für die 3G-Kindles gewaltig war.
      Ich meine, schon das Einsparen von ein paar Byte hätte ungefähr eine Million Dollar gespart.
    • Ich hatte einem Kollegen, der verreiste, mein Kindle Keyboard geliehen, und in Mexiko wurde es gestohlen.
      Damals dürfte es fast der älteste noch funktionierende Kindle gewesen sein, also hat der Dieb wohl einfach genommen, was in der Tasche lag.
      Später fand ich auf einem Flohmarkt noch ein Kindle Keyboard für 20 Dollar, aber nach sechs Monaten war der Akku tot; das Gerät habe ich noch, und ich frage mich, was ein Ersatzakku kostet.
    • Dieses kostenlose 3G war wirklich großartig.
      Über den Browser konnte man Gmail gerade so benutzen, und ich baute auch eine Kindle-freundliche Zork-Website, auf der man aus mehreren zmachine-ROMs wählen und Textadventures spielen konnte.
      Nachdem ein paar Nachrichtenseiten darüber berichtet hatten, gab es auch eine gewisse Resonanz.
    • Ich habe das auch gemacht.
      Zwar ohne die clevere Integration, den Kindle-Namen zu ändern, aber ich habe eine Zeit lang mit einem Keyboard Kindle mit unbegrenztem 3G SMS verschickt.
    • Bevor ich ein Smartphone kaufte, nutzte ich auf langen Autofahrten Wegbeschreibungen auf dem Kindle Keyboard.
      Die Google-Maps-Website lief gerade so.

  • Vor einiger Zeit nahm ich eine rund 20-stündige Fähre von Italien nach Griechenland. Es gab kostenpflichtiges Wi-Fi über Satelliteninternet, aber ich wollte nicht bezahlen.
    Für die Zahlung war der Zugriff auf Stripe freigegeben, und wie sich herausstellte, waren alle Seiten von stripe.com erreichbar, einschließlich der Entwicklerdokumentation. Also begann ich, wiederholt Bilder herunterzuladen und Bandbreite zu verschwenden.
    Dann fiel mir ein, dass Stripe für den Betrieb Zugriff auf das Fastly-CDN braucht und dass auch Reddit Fastly nutzt. Nachdem ich mich mit Stripe verbunden hatte und den HTTP-Host-Header auf reddit.com änderte, konnte ich Reddit ansehen.
    Bilder funktionierten nicht, weil i.redd.it nicht Fastly nutzt, aber nachdem ich in /etc/hosts old.reddit.com auf die Fastly-IP von Stripe gelegt und die gruseligen TLS-Warnungen ignoriert hatte, konnte ich mich sogar einloggen.

    • Wenn man auf diese Weise mehrere Gigabyte Dokumentation herunterlädt, sind die Geschädigten wahrscheinlich die Passagiere im Flugzeug, die für diesen Dienst bezahlen.
      Wenn sie ihn wegen der langsameren Verbindung nie wieder kaufen, schadet das auch dem Anbieter, und es kann Stripes Kosten für Upload-Bandbreite erhöhen.
      Ich vermeide selbst im Mobilfunknetz Downloads, weil ich keine negativen Auswirkungen auf die Leute um mich herum haben möchte.
    • Ich weiß nicht, was man durch so ein Verhalten genau gewinnt.
      Als gedankliches Experiment zu erkunden, wie weit man über eine gesperrte Verbindung kommt, verstehe ich; aber absichtlich Bandbreite zu verschwenden ist ähnlich, als würde man in einer öffentlichen Toilette den Wasserhahn aufdrehen und Wasser verschwenden oder die Toilette verstopfen, bis sie überläuft.
    • Das ist Domain Fronting (domain fronting), und inzwischen wird es von allen großen CDNs blockiert.
      https://en.wikipedia.org/wiki/Domain_fronting
    • Beim nächsten Mal hast du wahrscheinlich im Hotel das Wasser laufen lassen, um ihnen eine Lektion dafür zu erteilen, dass sie es wagen, einen kostenpflichtigen Dienst anzubieten.
    • Ich frage mich, warum dein erster Instinkt bei einem Dienst, für den du nicht bezahlen wolltest, darin bestand, Funktionen zu missbrauchen oder zu verschlechtern.

  • Vor ein paar Wochen brachte ich die Kinder zu einem Kurs im Einkaufszentrum und wollte das kostenlose Wi-Fi nutzen. Die Anmeldung am Laptop klappte, aber es hieß, das Internet funktioniere nicht.
    Als ich das Standard-Gateway prüfte, landete ich auf einem Cisco-Modem; ich sah Diagnosetools und eine Liste verbundener Geräte, aber die Internetverbindung war ausgeschaltet.
    Auf dem Handy suchte ich nach dem Modell und fand heraus, dass der Admin-Benutzername die Seriennummer ist und das Passwort leer bleibt; es gab auch ein Beispielmuster, und der Name eines der verbundenen Geräte sah genau nach diesem Muster aus.
    Damit loggte ich mich ein, schaltete den Internet-Button ein, und 15 Sekunden später war er grün; außerdem setzte ich ein neues Gerätepasswort.

    • Ich war einmal bei der Familie zu Besuch und verband mich mit dem ungesicherten Wi-Fi eines Nachbarn, um ins Firmen-VPN zu kommen.
      Das VPN ließ sich nicht verbinden, und da ich leicht in den Router kam, änderte ich die MTU-Einstellung; danach funktionierte es sofort normal.

  • Solche Hacks sind im ursprünglichen Sinn cool, und ich mag sie.
    Allerdings habe ich kürzlich nachgesehen: Bei skywifi scheint globales DNS auch ohne Bezahlung korrekt aufgelöst zu werden, und auf meinem Flug hätte vermutlich einfach ein gewöhnlicher iodine-Tunnel funktioniert.
    https://github.com/yarrick/iodine

    • Vor ein paar Jahren betrieb ich einen öffentlichen iodine-Dienst, auf den jeder zugreifen konnte.
      Um Abuse-Meldungen zu vermeiden, leitete ich den ausgehenden Traffic des Servers über Tor, sammelte Logs darüber, in welchen Zug-, Hotel- und Flughafennetzen es funktionierte, und bot auch andere Tunneling-Protokolle an.
      Es war eine Zeit lang ein interessantes Projekt; ich hätte es weiterlaufen lassen sollen.
      Heutzutage ist DNS-Tunneling etwas schwieriger geworden, weil einige DNS-Server, insbesondere Google, die Groß- und Kleinschreibung in DNS-Anfragen randomisieren und damit bestimmte Encodings stark kaputtmachen.
    • Vor sechs Jahren funktionierte iodine im Wi-Fi einer anderen Airline.
      Die Idee und das Prinzip sind interessant, aber wegen der Geschwindigkeit ist es in der Praxis fast nutzlos; höchstens vielleicht, wenn man einen Messenger über UDP daraufsetzt ;-)
    • Wenn DNS in der Firewall erlaubt ist, könnte man dann nicht einfach WireGuard über UDP/53 verwenden, statt am DNS-Protokoll selbst herumzubasteln?

  • „Ich habe vergessen, meine Kopfhörer aufzuladen, also fing Limp Bizkit an, aus den Laptop-Lautsprechern zu laufen. Zum Glück schienen sich die anderen im Flugzeug nicht daran zu stören, also hatten wir alle zusammen Spaß.“
    Solchen Leuten fehlt es an grundlegender Etikette in der Öffentlichkeit.
    Viele Menschen in der Umgebung hat es sicher gestört, aber wahrscheinlich waren sie einfach zu höflich, um zu sagen, dass man ihnen keinen unnötigen Lärm aufzwingen soll.

    • Wenn der Autor „Das ist Satire“ dazuschreibt, macht das die Satire kaputt.
    • Ich habe es als Witz gelesen.
      Weil es so viele Menschen ohne solche grundlegenden Manieren gibt, fand ich den Witz lustig, und ich glaube zumindest nicht, dass der Autor wirklich so jemand ist.
    • Der Witz war nicht lustig, passte aber zum Thema des Textes.
      Er zeigt das Bild eines Hackers, der die Möglichkeit auf kostenloses Internet als machbare Gelegenheit sieht, und distanziert sich später davon, als wäre er nicht wirklich jemand, der Airline-Systeme missbrauchen würde. Daher wirkt der Ton am Anfang wie ein stilistisches Mittel.
    • Ich glaube, Menschen nennen das „Humor“.
    • Ich hoffe, es war, wie andere sagen, ein Witz.
      Wenn nicht, wäre das extrem unhöflich und rücksichtslos.

  • Ich frage mich, ob ich der Einzige bin, der im Flugzeug immer so müde wird, dass er außer Augen schließen und bis zum Ende warten nichts machen kann.
    Schon der Gedanke, einen Laptop oder ein Buch herauszuholen, erschöpft mich, es ist laut, und ohne Noise-Cancelling-Kopfhörer kann ich mich kaum konzentrieren.
    Wenn ich im Flugzeug sitze, habe ich schon mindestens zwei Stunden damit verbracht, von zu Hause loszugehen, Zug, Tram und Sicherheitskontrolle hinter mich zu bringen, und das ungesunde Essen am Flughafen hilft auch nicht.
    Das Wetter ist ein halbes Jahr lang entweder zu heiß oder zu kalt, und mit einem 10-kg-Rucksack schwitze ich ständig, sodass ich am Ende im Flugzeug zu nichts mehr Lust habe.

    • Ich habe ADHS als Erwachsener, und bei der Arbeit fällt mir Konzentration schwerer, aber im Flugzeug oder an anderen hektischen Orten kann ich mich im Gegenteil wie ein Laser fokussieren.
      Das ist kontraintuitiv, aber ich habe gehört, dass viele ADHS-Gehirne so funktionieren, und die Zeit im Flugzeug ist für mich die produktivste.
    • Früher habe ich versucht, den Laptop herauszuholen und etwas zu machen, aber seit der Sitzabstand kleiner geworden ist, ist es wirklich schwierig, etwas Größeres als ein Tablet herauszunehmen.
      Man muss es auf den Schoß legen, oder wenn die Person vor einem den Sitz zurücklehnt, besteht die Gefahr, dass der Bildschirm bricht; einem Kollegen ist das vor ein paar Jahren tatsächlich passiert.
      Heutzutage hole ich einfach iPad und Noise-Cancelling-Kopfhörer heraus und schaue Filme oder Serien.
    • Das geht nicht nur mir so.
      Mein Körper reagiert genauso, und ich vermute, es hängt mit der geringeren Sauerstoffmenge in der Luft zusammen.
      Es ist kein Lärmproblem, sondern ein Luftproblem, wobei Noise-Cancelling-Kopfhörer wirklich gut funktionieren.
      Es gibt aber auch Leute, die davon gar nicht beeinflusst werden und im Flugzeug nützliche Dinge erledigen.
    • Bei mir ist es genau umgekehrt.
      Egal wie müde ich bin oder wie wenig Schlaf ich hatte, im Flugzeug kann ich weder einschlafen noch werde ich müde, deshalb sind Transatlantikflüge noch quälender, und wenn meine Begleitung acht Stunden lang schläft, fühlt es sich fast so an, als würde ich verhöhnt.
    • Das geht nicht nur mir so.
      Während des Flugs wird mein Kopf völlig benebelt, ich schließe bis zur Landung die Augen, und selbst wenn ich versuche zu lesen oder zu arbeiten, schaltet mein Gehirn nach 5 bis 10 Minuten ab.
      Seltsamerweise verursacht mir das Bordessen jedes Mal Blähungen, sodass ich direkt nach der Landung Medikamente brauche.
      Interessanterweise konnte ich die zwei Male, als ich Business Class geflogen bin, eine Weile lesen, bevor mein Gehirn abgeschaltet hat.
      Auf Langstreckenzügen fällt es mir tatsächlich leichter zu arbeiten, wenn ich in Fahrtrichtung sitze; wenn der Zug ziemlich voll ist, schaltet mein Gehirn aber wieder ab.

  • Die Geschichte, dass man Aktienkurse, Spielstände, Wetter und Ähnliches geschickt bekommen konnte, erinnert mich an eine Funktion, die Google früher als SMS-Dienst angeboten hat.
    Vor meinem ersten Smartphone habe ich das sehr viel genutzt; wenn man W[ZIP code] an 46645 (GOOGL) schickte, bekam man das Wetter per SMS zurück.
    stock:[symbol] funktionierte auch, und es gab noch mehrere Funktionen, die ich inzwischen vergessen habe.
    Natürlich hat Google es eingestellt, aber solange es lief, war es ziemlich cool.

    • In meiner PHP-Zeit habe ich einen Twitter-Bot namens SongBuddy gebaut, der anhand von Textfragmenten Songs finden sollte.
      Die Idee war, ein paar Zeilen Liedtext per SMS-DM, wie Twitter sie damals unterstützte, zu schicken; der Bot suchte bei Google nach " lyrics", parste die Ergebnisse und schickte Künstler und Titel per SMS zurück.
      Es funktionierte nicht besonders gut, aber ich war ziemlich stolz darauf.
    • Die Website zur Währungsumrechnung, die ich nutze, wird von einem Professor betrieben und läuft vermutlich auf einem Pentium III-Rechner, den er unter einer Uni-Treppe versteckt hat, aber sie ist seit Jahrzehnten am Leben und wirkt, als würde sie ewig weiterlaufen.
    • Ich habe mit Twilio und einer AWS-Instanz ein SMS↔ChatGPT-Interface gebaut.
      Dadurch kann ich mit meinem tragbaren Satellitenkommunikator inReach Mini 2 von überall auf der Erde aus ChatGPT Fragen stellen, und es ist ziemlich schön, das sogar mitten im Death Valley tun zu können.
    • Ich habe diesen Dienst mit meinem Klapphandy ständig genutzt.
      Google-Suchanfragen einzutippen dauerte lange, und bis die Ergebnisse kamen, konnten ein bis zwei Minuten vergehen, aber es war besser als nichts.
      Ich habe es vor allem benutzt, um die Adresse von Orten zu suchen, zu denen ich wollte, und sie dann in mein TomTom einzugeben; die Zeiten haben sich sehr geändert.
    • Ich frage mich, wann das war.
      Als ich um 1995 bei einer Telekom-Forschungsfirma arbeitete, einer Ericsson-Tochter, kam mir so eine Idee; das Paradebeispiel waren Status-Updates zu Flügen.
      Weil niemand sich vorstellen konnte, dass P2P-Messaging, bei dem man auf einer Zifferntastatur für einen Buchstaben mehrfach drücken musste, so populär werden würde, wirkten Informationsdienste angesichts der zunehmenden Datenmengen im frühen Web wie die beste Anwendung.
      Teletext gab es auch noch, und es gab auch ein separates Projekt, das ihn scrapte.
      Interessant ist aber, wenn man darüber nachdenkt, wofür wir, die Zugriff auf SMS hatten, und die breite Öffentlichkeit es am Ende tatsächlich genutzt haben.

  • Interessant ist, dass der Autor einem abstrakten TCP über einem gemeinsam bearbeiteten Feld ziemlich nahe gekommen ist.
    Das könnte schon für sich genommen ein sehr cooles Tool sein.
    Wenn man auf hoher Ebene nur entwirft, wie beide Seiten auf eine gemeinsame Ressource lesen und schreiben, kann man sich einen Proxy vorstellen, der den Rest komplett übernimmt und als SOCKS-Proxy bereitstellt.

    • Soweit ich weiß, wurde TCP/IP über DNS bereits implementiert, um an kostenpflichtigen Boingo-Hotspots an Flughäfen kostenloses Internet zu nutzen.
      Am Ende wurde kostenloses WLAN zum Standard, sodass das nicht mehr besonders aufregend war, und jetzt sind wir beim Kampf um kostenloses WLAN an Bord angekommen.
      Letztlich wird auch WLAN im Flugzeug überall kostenlos sein, und bei mehreren Airlines ist es das bereits.
    • Seit unser Mobilfunkanbieter angefangen hat, bei Tarifen mit Datenlimit mit „unbegrenztem WhatsApp“ zu werben, denke ich schon seit Jahren darüber nach.
      Es ginge zwar nur Text und keine Bilder oder Videos, aber für normales Web-Browsing hätte es gereicht.

  • Vor ein paar Jahren beschloss der Dekan unserer Universität, nach 22 Uhr das LAN-Netzwerk zu sperren, mit der Begründung, „Spiele würden die Anwesenheit beeinträchtigen“ oder so ähnlich.
    Die Umsetzung bestand darin, sämtlichen Traffic von und zu IP-Adressen zu blockieren; TCP selbst wurde aber nicht blockiert, und IPv6, das damals auch nicht mehr ganz neu war, hatte man völlig vergessen.
    Also baute ich eine einfache P2P-Chat-App, die über IPv6 lief. Das einzige Problem war, dass ich meine Freunde dazu bringen musste, ihre IPv6-Adressen zu teilen und in den Kontakten zu behalten.
    Es funktionierte gut, aber später stellte ich fest, dass es viel einfacher war, zu einem Computer außerhalb des Netzwerks zu tunneln.

  • Das scheint mir ein fast perfektes Beispiel zu sein, das an den Beitrag mehr nutzlose Software schreiben und die anschließende HN-Diskussion erinnert.
    Verändert es das Leben? Vermutlich nicht.
    Hat es Spaß gemacht, es zu bauen und damit zu experimentieren? Ziemlich sicher.
    Wir sollten mehr von so etwas bauen.
    https://ntietz.com/blog/write-more-useless-software/
    https://news.ycombinator.com/item?id=37911900