WiFi-Daten auf einem Southwest-Flug ohne Internet ansehen

 (jamesbvaughan.com)
1 Punkte von GN⁺ 2023-09-29 | 1 Kommentare | Auf WhatsApp teilen
  • Als auf einem Direktflug von St. Louis nach Oakland auf dem Rückweg von der Strange Loop die 8-Dollar-Internetzahlung fehlschlug, wurde geprüft, welche Daten sich im Bord-WiFi auch ohne Internetzugang abrufen lassen
  • In den Netzwerkanfragen des Southwest-WiFi-Portals fiel ein wiederholt erfolgreiches Endpoint current.json auf, dessen Antwort offenbar die Grundlage der Flugstatus-Seite bildet
  • Dieses Endpoint ließ sich auch ohne Cookies oder Header per curl aufrufen und lieferte unter anderem Flughöhe, Koordinaten, voraussichtliche Ankunftszeit, Ground Speed, verbleibende Distanz, Flugfortschritt und den Status der Satellitenverbindung zurück
  • Mit den gesammelten Daten wurden Flughöhe, ETA und Ground Speed visualisiert; abgesehen von der Sinkflugphase schwankte die Höhe nur um etwa 20–30 Fuß
  • Es war kein besonders praktischer Fund, aber allein mit dem vom Bord-WiFi-Portal offengelegten Flugstatus-JSON lassen sich während des Flugs Daten sammeln und analysieren

Erkundung des Bord-WiFi nach einer fehlgeschlagenen Zahlung

  • Auf einem Direktflug von St. Louis nach Oakland auf dem Rückweg von der Strange Loop sollte über das Bord-WiFi-Portal von Southwest ein 8-Dollar-Internetzugang gekauft werden, aber keine Zahlungsmethode wurde akzeptiert
  • Die Webseite zeigte keine hilfreiche Fehlermeldung an, daher wurden die fehlgeschlagenen Anfragen mit den Netzwerk-Entwicklertools des Browsers untersucht
  • In der fehlgeschlagenen Anfrage selbst war kaum ein Hinweis zu finden, aber die wiederholt erfolgreiche Anfrage an current.json stach hervor

Die von current.json zurückgegebenen Flugstatusdaten

  • Die Antwort von current.json scheint die Daten zu liefern, mit denen die Flugstatus-Seite des Bord-WiFi-Portals betrieben wird
  • Eine Beispielantwort enthält unter anderem folgende Werte
    • sat_commlink_portal.status: conn_ok
    • satcomm_status.commlink: active
    • satcomm_status.linkparams: not-stale
    • pcent_flt_complete: ein Wert, der den Flugfortschritt darzustellen scheint
    • altVal: aktuelle Flughöhe
    • lat, lon: aktuelle Koordinaten
    • dtzone: Zeitzone des Ziels
    • within_us: ob der Flug innerhalb der USA stattfindet
    • etad: voraussichtliche Ankunftszeit am Ziel
    • gspdVal: aktuelle Ground Speed
    • ttgc: ein Wert, der die verbleibende Zeit darzustellen scheint
    • dist_remain: verbleibende Distanz
    • actime24: aktuelle Uhrzeit in irgendeiner Zeitzone

Die Browser-Anfrage mit curl nachbilden

  • Mit der Browser-Funktion „Copy as cURL“ ließ sich schnell ein Aufrufbefehl für das Endpoint erzeugen
  • Diese Funktion gibt es in Firefox und Chromium-basierten Browsern und sie ist nützlich, wenn man eine vom Browser gesendete Anfrage mit denselben Headern reproduzieren will
  • Die Experimente zeigten jedoch, dass die in der Anfrage enthaltenen Cookies und Header nicht zwingend nötig waren und sich die Daten schon mit einem einfachen curl-Aufruf wie diesem abrufen ließen
curl 'https://getconnected.southwestwifi.com/current.json'
  • Danach wurde eine Schleife gestartet, die alle 30 Sekunden Daten abruft und in eine Logdatei schreibt
watch -n 30 "curl https://getconnected.southwestwifi.com/current.json | jq -c >> flight-logs"

Offene Fragen zu den Antwortfeldern

  • Die meisten Felder waren intuitiv, aber bei einigen Werten blieb die Bedeutung unklar
    • der Unterschied zwischen sat_commlink_portal.status und satcomm_status.commlink
    • ob pcent_flt_complete auf Distanz oder auf geschätzter Zeit basiert
    • wie stark altVal, etad und gspdVal während des Flugs schwanken
    • wofür das ac in actime24 steht
  • actime24 wirkte nicht wie die aktuelle Uhrzeit am Standort des Flugzeugs, sondern eher wie die aktuelle Uhrzeit am Ziel, weshalb sich ac nur schwer als „aircraft“ deuten lässt

Visualisierung der während des Flugs gesammelten Daten

  • Mit den gesammelten Daten wurden Veränderungen bei Flughöhe, ETA und Ground Speed visualisiert

  • Veränderung der Flughöhe

    • Zunächst sollte geprüft werden, wie viel Rauschen in den Höhendaten steckt
    • Über die gesamte Spannweite war das Rauschen schwer zu erkennen; nach Herausnahme der Sinkflugphase lagen die Schwankungen der Höhe bei etwa 20–30 Fuß
    • Diese Stabilität war höher als erwartet, aber ob das im normalen Bereich liegt oder wie genau die Daten sind, blieb offen

  • Veränderung der ETA

    • Die ETA wurde als vernünftig stabil erwartet, und nach dem anfänglichen Startverlauf blieb sie im ruhigen Flug tatsächlich stabil
    • Offen blieb, ob sich die ETA bei einer wetterbedingten Landeverzögerung allmählich verlängern würde oder erst am Ende sprunghaft ansteigt

  • Veränderung der Ground Speed

    • Auch die Ground Speed war wie erwartet stabil
    • Zunächst wurde die Geschwindigkeit in MPH dargestellt, aber Leser auf HN wiesen darauf hin, dass es sich bei diesem Wert wahrscheinlich um knots handelt
    • Da die Datenerfassung nicht ganz zu Beginn des Flugs startete, ließ sich die Kurve beim Erreichen der Reisegeschwindigkeit nicht beobachten

Fazit

  • In den gesammelten Daten fand sich nichts besonders Nützliches oder Überraschendes
  • Auch ohne Internetzugang lässt sich mit dem vom Bord-WiFi-Portal offengelegten Flugstatus-JSON während des Flugs Daten sammeln und analysieren

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-09-29
Meinungen auf Hacker News

  • Als mein Sohn etwa 9 oder 10 war, sah ich, dass er im Flugzeug auf seinem Handy das Internet nutzte. Da ich nie für Internet bezahlt hatte, fragte ich ihn, wie er das machte.
    Er sagte, ein Schulfreund habe ihm erklärt, man müsse in den Wi-Fi-Einstellungen die Zahlen der per DHCP zugewiesenen IP-Adresse ändern. Damals ließ American Airlines offenbar nur die IPs zahlender Nutzer zu; wenn also jemand eine IP im Bereich 192.168 erriet und sich als jemand anderes ausgab, konnte er die Verbindung ohne zusätzliche Authentifizierung übernehmen.
    Ich sagte ihm zwar, er solle das lassen, war aber ein wenig stolz auf seinen Mut, es auszuprobieren.

    • Bei früheren kostenpflichtigen Wi-Fi-Hotspots habe ich Ähnliches oft gemacht.
      Zuerst habe ich mit nmap -sP das gesamte Subnetz per Ping-Sweep durchsucht, um den ARP-Cache mit brauchbaren IP-/MAC-Adressen zu füllen, und dann nacheinander IP- und MAC-Adresse geändert, bis ich eine Kombination fand, die durch die Firewall kam.
      Dass ich bei Wayport (heute AT&T WiFi) als NOC-Ingenieur gearbeitet hatte, half mir, die Architektur zu verstehen.
    • Ich habe dieselbe Methode in Flugzeugen und Hotels genutzt; in Hotels war die Erfolgsquote höher.
      Dort war es weniger wahrscheinlich, dass die andere Person genau in diesem Moment online war, und auch weniger wahrscheinlich, dass die Verbindung abbrach.
      Als Kind habe ich noch einen anderen kleinen Hack gemacht: Zu der Zeit, als Airlines spezielle Kopfhörer für Bordfilme verkauften oder verliehen, bestand der Anschluss aus zwei nebeneinanderliegenden Löchern und der Stecker aus zwei Röhrchen.
      Vor dem Boarding nahm man im Fast-Food-Lokal im Terminal ein paar Strohhalme mit, möglichst Knickstrohhalme, steckte sie zu einem langen Strohhalm zusammen, führte ein Ende in den Anschluss und hielt das andere ans Ohr – so konnte man den Filmton kostenlos hören.
    • Vor ein paar Jahren hatte ich in einem Southwest-Flugzeug vergessen, OpenVPN auszuschalten, und konnte ohne zu bezahlen über den Tunnel auf das Internet zugreifen.
      Damals wurden für nicht zahlende Nutzer offenbar nur gängige Ports (80, 443, 53 usw.) blockiert; später wurde diese Lücke geschlossen.
    • Eine wirklich erstaunliche Anekdote.
      Der Zustand der Sicherheit offener Wi-Fi-Netze ist tatsächlich ziemlich bedauerlich, und ich weiß auch nicht, wie Airlines es wesentlich einfacher besser machen könnten.
      Wenn die Geräte es unterstützen, könnte man Opportunistic Wireless Encryption [1] verwenden und die Authentifizierung nicht an eine bestimmte MAC-Adresse, sondern an eine bestimmte OWE-Session binden; ich weiß aber nicht, wie stabil OWE-Sessions sind.
      Wenn man sich bei jedem Wechsel des Access Points erneut anmelden müsste, wäre das sehr unpraktisch.
      Es ist schade, dass die Sicherheit von kostenpflichtigem oder kostenlosem Wi-Fi noch kein gelöstes Problem ist und weiterhin maßgeschneiderte Ad-hoc-Lösungen wie fragile Captive Portals nötig sind, die selektiven Traffic wie Zahlungen, 3DS und E-Mails zum Zurücksetzen von Passwörtern durchlassen müssen.
      Schön wären auch ein standardisierter Endpoint und eine API, über die Clients erkennen können, ob sie aktuell verbunden, eingeschränkt oder zahlungs-/authentifizierungspflichtig sind, sowie die Möglichkeit, ein Authentifizierungstoken zu erhalten und sich innerhalb derselben Session nahtlos wiederzuverbinden.
      Hotspot 2.0 und WPA-EAP (WPA Enterprise) gibt es zwar, aber sie sind eher auf von Mobilfunkanbietern betriebene Hotspot-Netze beziehungsweise Unternehmensumgebungen zugeschnitten; für den Anwendungsfall „Bezahlen über ein Webportal“ passen sie nicht wirklich gut.
      [1] https://en.wikipedia.org/wiki/Opportunistic_Wireless_Encrypt...
    • Früher gab es Apps, die in einem bereits mit dem Internet verbundenen Netzwerk IP- und MAC-Adressen scannten.
      Wenn man die Einstellungen auf eine dieser MAC-Adressen änderte, konnte man die Verbindung allein nutzen, nachdem der ursprüngliche Nutzer fertig war.
      Auf Geschäftsreisen weigerte ich mich, für Wi-Fi zu bezahlen; zu der Zeit, als Flughäfen und Cafés noch kostenpflichtige Zugänge anboten, war das ziemlich nützlich.
      Heute braucht man es kaum noch, aber an Orten, an denen der Zugang weiterhin etwas kostet, kann es immer noch helfen.

  • „Diesen Daten zufolge schwankte die Flughöhe des Flugzeugs nur um etwa 20–30 Fuß. Stabiler als erwartet!“
    Autopiloten sind sehr gut und regeln Servos anhand der Druckhöhe.
    Viele Druckhöhen-Encoder in modernen Flugzeugen, zum Beispiel die Geräte, die die vom Transponder per SSR-Radar oder ADS-B gemeldete Höhe liefern, haben eine Codierungsauflösung von 25 Fuß.
    Was hier zu sehen ist, ist höchstwahrscheinlich ebenfalls diese 25-Fuß-Auflösung; es gibt auch Encoder mit 10-Fuß-Auflösung, aber 25 Fuß sind sehr verbreitet.

    • Ich weiß nicht, welche Sensordaten die im Artikel erwähnte API erhält, aber die meisten Verkehrsflugzeuge senden auch die Genauigkeit der ermittelten Position sowie die Genauigkeit der vertikalen Position/Höhe.
      Wenn man auf der Karte https://globe.adsbexchange.com/ ein Flugzeug anklickt und in der linken Seitenleiste ganz nach unten scrollt, sieht man den Abschnitt „Accuracy“.
      ADS-B Exchange zeigt Rc/v, also die Genauigkeit der vertikalen Position, nicht an, die anderen Werte aber schon.
      Weitere Details siehe https://mode-s.org/decode/content/ads-b/7-uncertainty.html.
    • Bei Kleinflugzeugen ist ein Bereich von 20–30 Fuß nicht ungewöhnlich, wenn man aufmerksam von Hand fliegt.
      Ein Verkehrsflugzeug im Reiseflug nutzt natürlich vermutlich den Autopiloten.
      Als ich früher einmal Flight Following bekam und etwa 100 Fuß absank, fragte mich der Lotse, ob alles in Ordnung sei; ich war überrascht, dass sie so genau hinschauen.
      Ich hatte vor einem Überwasserabschnitt vergessen, die Schwimmweste anzulegen, und während ich sie anzog, meiner Frau, die damals noch keinen Flugunterricht hatte, die Steuerung übergeben.
      Später machte auch meine Frau ihre Lizenz, und ich fand interessant, wie präzise die Radarverfolgung ist, wenn die Flugsicherung deswegen eingreift.
    • Es wäre spannend gewesen, mit dem Handy einen GPS-Track inklusive Höhe aufzuzeichnen und zu vergleichen.
      Druckhöhe und GPS sind unterschiedlich, und ich wäre neugierig, ob der Unterschied deutlich springt, wenn man den barometrischen Höhenmesser auf eine andere AWOS-Referenz neu einstellt.
      Ich weiß nicht, wie das bei Großflugzeugen gehandhabt wird, aber in Kleinflugzeugen muss man den Höhenmesser auf das lokale Wetter einstellen.
      Die Wetterstation misst den Luftdruck auf ihrer eigenen Höhe, gibt per Funk den auf „Meereshöhe korrigierten“ Wert durch, und diesen stellt man am Höhenmesser ein, um die barometrische Höhenanzeige an die lokalen Wetteränderungen anzupassen.
      Selbst wenn man eine Stunde fliegt und zum selben Ort zurückkehrt, kann sich die Höhenmessereinstellung um ein paar Millibar geändert haben.
    • Durch die Einführung von RVSM dürfte das viel präziser geworden sein.
      Der vertikale Mindestabstand zwischen Flugzeugen lag früher bei 2000 Fuß und wurde Anfang der 2000er auf 1000 Fuß reduziert.
    • Ich habe einmal gelesen, dass in manchen Situationen zu hohe Präzision sogar gefährlich sein kann.
      Wenn ein Pilot zum Beispiel auf 3000 Fuß fliegt, ist er exakt auf 3000 Fuß, und wenn ein anderer Pilot auf Kollisionskurs ebenfalls 3000 Fuß anstrebt, ist die Kollision praktisch sicher.
      Bei weniger genauer Höhe wäre es wahrscheinlicher, dass es nur zu einer Beinahekollision kommt.
      Die Lösung bestand wohl darin, runde Zahlen zu vermeiden und stattdessen etwa 2950 Fuß oder 3050 Fuß zu verwenden.
      Die Details können falsch sein, aber ich bin mir ziemlich sicher, dass dieses Problem ernsthaft untersucht wurde.

  • Vor ein paar Monaten habe ich dasselbe entdeckt und einen CLI-Flugtracker gebaut, der diese API nutzt.
    Ich habe ihn bei einigen Airlines getestet, und weil sie alle denselben Anbieter für Bord-Internet nutzen, funktionierte er fast perfekt.
    [1]: https://github.com/NalinPlad/OuterFlightTracker

    • Cool.
      Ich wollte etwas Ähnliches bauen, hatte aber nicht genug Erfahrung, um während des Flugs ohne Internet-Recherche ein TUI zu erstellen.
      Trotzdem schön, dass es das schon gibt.

  • So erhält man dieselben Daten auf einem Delta-Flug:

    $ curl https://wifi.delta.com/api/flight-data | jq  

    {  
"timestamp": "2023-07-11T14:54:41Z",  
"eta": "17:48",  
"flightDuration": 278,  
"flightNumber": "DAL786",  
"latitude": 39.723472595214844,  
"longitude": -97.1514205932617,  
"noseId": "3879",  
"paState": false,  
"vehicleId": "N879DN",  
"destination": "KPDX",  
"origin": "KATL",  
"flightId": "N879DN_SF_20230711121358",  
"airspeed": null,  
"airTemperature": 24,  
"altitude": 33922,  
"distanceToGo": 179,  
"doorState": "Closed",  
"groundspeed": 442,  
"heading": -73,  
"timeToGo": 174,  
"wheelWeightState": "Off"  
}

    Es gibt auch ein interessantes Schnipsel:

    $ curl -s https://wifi.delta.com/api/flight-data | jq -r '"https://maps.google.com/?q=";, .latitude, ",", .longitude' | tr -d '\n'; echo  
https://maps.google.com/?q=40.5615234375,-101.2824478149414
    • Mit der String-Interpolation von jq geht es noch einfacher: 
      $ curl -s https://wifi.delta.com/api/flight-data | jq -r '"https://maps.google.com/?q=\(.latitude),\(.longitude)"'
    • Ich habe diese URL gerade im Flugzeug ausprobiert, und sie funktioniert tatsächlich.
      Die Informationen sieht man zwar auch in der UI des Wi-Fi-Portals, aber als JSON-Klumpen fühlt es sich noch einmal anders an. 
      {"timestamp":"2023-09-28T21:57:39Z","eta":"23:45","flightDuration":164,"flightNumber":"DAL992","latitude":47.4557876586914,"longitude":-111.73490905761719,"noseId":"3883","paState":false,"vehicleId":"N883DN","destination":"KMSP","origin":"KSEA","flightId":"N883DN_SF_20230928195737","airspeed":null,"airTemperature":null,"altitude":35273,"distanceToGo":13,"doorState":"Closed","groundspeed":499,"heading":95,"timeToGo":107,"wheelWeightState":"Off"}
      Bitte entschuldigt die JSON-Formatierung, ich bin am Handy.
    • Wenn man frische Luft möchte, wäre es schön, wenn man die Tür per POST-Request öffnen könnte.
    • Interessant ist die Entscheidung, statt planeId oder tailNumber das allgemeinere vehicleId zu verwenden.
      Ich frage mich, ob es unter Deltas Betriebsmitteln andere Arten gibt, die zu dieser API passen.
      Außerdem frage ich mich, wie viel jemand, der andere interne Systeme kennt, aus der flightId über die Systemstruktur ableiten könnte.
      Von außen wirkt es zwar nach nicht mehr als einem zusammengesetzten Schlüssel aus ohnehin bekannten Daten, aber interessant ist es trotzdem.
    • "airspeed": null
      Lässt einen beunruhigt aus dem Fenster schauen.

  • Ich würde gern sehen, dass jemand einen Proxy baut, der über die für kostenloses iMessage oder WhatsApp erlaubte Verbindung beliebige Daten verschickt.
    Etwa so, dass man zu Hause ein WhatsApp-Relay betreibt und aus dem Flugzeug Nachrichten hin- und herschickt.
    Ganz grundsätzlich könnte man wohl eine URL an WhatsApp zu Hause schicken, dort die Webseite laden und das HTML als WhatsApp-Antwort zurücksenden lassen, um es dann zu rendern.
    Ich bin neugierig, wie viel man damit zum Laufen bringen könnte.
    Offenbar hat schon jemand ein TCP-Relay über WhatsApp gebaut, ziemlich cool.

    • https://github.com/aleixrodriala/wa-tunnel
    • Ich habe die Nutzungsbedingungen nicht gelesen, aber ich frage mich, ob man nicht einfach einen echten IP-Router hinstellen könnte.
      Man bezahlt den Zugang und spannt zusätzlich ein Wi-Fi-Netz auf.
      Wenn die SSID im Flugzeug „Foo“ heißt, nennt man es „Foo discounted“ und lässt im Captive Portal verschiedene „Rabatte“ auswählen, etwa für Veteranen, Senioren oder Kinder.
      Egal, was ausgewählt wird: Auf der Bezahlseite verlangt man 2 Dollar.
      Sobald die Servicekosten wieder drin sind, zeigt man späteren Besuchern an: „Alle Rabatte sind aufgebraucht, bitte nutzen Sie Foo.“
      Dann hätte ich kostenloses Internet, und die Nutzer des Routers/Portals hätten Internet für 2 Dollar.
      Die Upstream-Bandbreite wäre sicher miserabel, daher wäre es vermutlich einfach, den gesamten Traffic über meine eine Verbindung zu multiplexen.
      Man könnte das in ein Gerät wie einen RPi packen, aber damit es durch die Sicherheitskontrolle kommt, müsste es wie ein fertiges Produkt aussehen, etwa wie ein Musikplayer, und es müsste weiterlaufen können, wenn man den Tisch hochklappen muss oder auf die Toilette geht.
      Es erscheint sehr unwahrscheinlich, dass ein Flugzeug ein WIPS oder WIDS hat, das unerwünschte Wi-Fi-Verbindungen trennt.
      LAN-Partys sind ja schließlich nicht grundsätzlich verboten, oder?
    • Vor ein oder zwei Jahren, ein oder zwei Tage nach der ersten Beta von Apple Private Relay, bin ich geflogen und konnte während des gesamten Fluges kostenloses Wi-Fi nutzen.
      Vermutlich lag das daran, dass die Allowlist für iMessage oder Push-Benachrichtigungen auch das mit abdeckte.
      Vor dem Rückflug ein paar Tage später war es schon blockiert.
    • Statt „Wow, cool“ denke ich zuerst: „Kostenloses Messaging ist ein guter Vorteil, aber wenn es missbraucht wird, machen sie es dicht.“
      Meine Hacker-Zeit ist wohl vorbei.
    • Ich habe schon erlebt, dass Airline-Wi-Fi DNS-Traffic nicht blockiert.
      Mit einem DNS-Tunnel wie Iodine (https://github.com/yarrick/iodine) könnte man mit hoher Wahrscheinlichkeit etwas Ähnliches machen.

  • Southwest zeigt dieselben Daten auf einem hübscheren Bildschirm
    Auch ohne für WLAN zu bezahlen, kann man viele Informationen sehen, etwa Flugverfolgung, aktuelle Höhe, voraussichtliche Ankunftszeit und Position auf der Karte
    Vermutlich nutzt das dieselben Daten, für die der Autor das Verarbeitungsprogramm gebaut hat; im Grunde gibt es also eine Website, die man kostenlos besuchen kann

    • Genau, genau so ist es
      Man kann kostenlos eine schicke Statusseite sehen, die diese Daten visualisiert
      Ich habe sie trotzdem aus zwei Gründen gescrapt
      Erstens zeigt die Statusseite nur die aktuellen Werte an, ich wollte aber die vollständigen Flugdaten sehen
      Zweitens hat es Spaß gemacht
    • Auf einem kürzlichen US-Flug, ich glaube es war Alaska Airlines, gab es eine lokale LAN-Box, über die man per WLAN Filme und TV-Sendungen ansehen konnte, auch ohne Internetzugang
    • Damit ist die Frage geklärt: „Warum kommen so viele Flugzeugdaten zurück, wenn ich die Portal-Seite öffnen will?“

  • Mir gefällt der Geist dieses Beitrags
    Der Autor hätte diese Informationen wohl auch per Git-Scraping erfassen können
    https://simonwillison.net/2020/Oct/9/git-scraping/

  • Ich dachte, man könnte ein Foto aus dem Fenster machen und die GPS-Koordinaten aus dieser JSON-Ausgabe mit dem Bild verknüpfen
    Das wirkt ziemlich nützlich

    • Wenn man in der Kamera-App die Standortberechtigung aktiviert hat, landen die Koordinaten in den EXIF-Daten des Bildes
      Zivile GPS-Geräte aus den USA dürfen wegen der ITAR-Exportbeschränkungen für Rüstungsgüter oberhalb von 60.000 Fuß Höhe und über 1.000 Knoten nicht funktionieren

  • Falls man die Flugzeugdaten mit ADS-B-Daten vergleichen möchte: Das hier scheint der Flug des Originalautors zu sein
    https://www.flightaware.com/live/flight/SWA2340/history/2023...

    • Es ist zumindest möglich, dass die ADS-B-Datenquelle und die Datenquelle dieser API aus denselben Instrumenten und Flugsystemen berechnet wurden
    • Das ist der richtige Flug
      Gute Idee, schade, dass sie mir nicht eingefallen ist

  • Eine interessante Geschichte
    Aber stört sich niemand an diesem time-Format?
    Es wirkt wie eine seltsame Wahl; ich hätte etwas Standardisierteres wie ISO 8601 mit Zeitzonen-Offset erwartet
    "time": "Sun Sep 24 22:02:19 2023"

    • Ging mir ähnlich
      Es wirkt, als hätte die Person, die dieses System entworfen hat, die Zeit serverseitig in eine lokalisierte Darstellung anhand der Flugposition umgewandelt und sie dann ohne clientseitige Logik direkt in die Web-UI einfügen wollen
    • Sieht aus wie das Standardformat, das ctime verwendet
      Könnte ein Hinweis auf das zugrunde liegende Backend sein
      https://cplusplus.com/reference/ctime/ctime/