PySkyWiFi : créer un Wi-Fi lent et gratuit sur les vols long-courriers

 (robertheaton.com)
1 points par GN⁺ 2024-07-10 | 1 commentaires | Partager sur WhatsApp
  • PySkyWiFi est une expérience qui utilise comme stockage temporaire les champs de profil d’un compte de miles aériens, accessibles même avant paiement, pour faire transiter très lentement des requêtes et réponses HTTP pendant un vol long-courrier
  • Le prototype initial créait une messagerie en mettant à jour et en interrogeant le champ du prénom/nom du compte, puis a été étendu avec un daemon au sol lisant des requêtes comme STOCKPRICE: APPL et renvoyant les résultats
  • L’architecture finale se compose d’un sky proxy dans l’avion et d’un ground daemon connecté à Internet, l’URL cible étant transmise via l’en-tête X-PySkyWiFi des requêtes curl locales
  • La transmission découpe les requêtes HTTP en petits morceaux, puis les ordonne avec des segments DATA, ACK, END et des numéros de séquence à 6 chiffres
  • L’auteur a évité d’envoyer en continu des requêtes automatisées à de vrais comptes de compagnie aérienne ; le test final s’est limité à appeler au curl, via GitHub Gist, la page d’accueil d’un blog et à recevoir une réponse HTML quelques minutes plus tard

Une voie de contournement trouvée dans le portail Wi-Fi avant paiement

  • La page de connexion au Wi-Fi de l’avion demandait un paiement, mais autorisait gratuitement la connexion à un compte de miles aériens même avant paiement
  • En voyant le champ du nom dans l’écran de modification du profil, l’auteur a estimé que cette valeur pouvait servir de petit canal de communication avec l’extérieur
  • Il avait d’abord envisagé Go comme langage d’implémentation, mais a choisi Python parce que cela permettait de nommer l’outil PySkyWiFi
  • Le code source est publié sur PySkyWiFi

Prototype 1 : messagerie instantanée via le champ du nom

  • Après connexion de deux clients au même compte de miles aériens, les messages sont échangés en mettant à jour et en lisant à tour de rôle le champ du nom
    • Si l’un change le nom en Hello how are you, l’autre le lit
    • Puis s’il le remplace par Im fine how are you, le premier voit la réponse
  • Modifier le nom directement dans l’interface étant fastidieux, l’opération a été automatisée avec un outil en ligne de commande
    • L’outil se connecte au site web et met à jour le champ du nom du compte de test avec le message
    • Il interroge le champ du nom toutes les quelques secondes et, si la valeur change, l’affiche comme réponse de l’interlocuteur
  • L’auteur a décidé de ne plus envoyer de données automatisées à un vrai compte de miles aériens, et s’est contenté de vérifier qu’environ 10 mises à jour rapides du nom réussissaient toutes
    • Ce résultat suggère que le compte ne limitait probablement pas la vitesse ni le nombre de requêtes
  • Le développement ultérieur s’est poursuivi en reproduisant le même principe avec GitHub Gists et des fichiers locaux
    • C’était plus rapide et plus simple pour itérer que d’utiliser un compte de miles aériens

Prototype 2 : récupérer des informations externes avec un daemon au sol

  • À l’étape suivante, un daemon est exécuté sur un ordinateur connecté à Internet, au sol ou dans le cloud
  • Le daemon interroge en continu le champ du nom du compte de miles aériens et cherche des requêtes structurées envoyées depuis l’avion
    • Exemple : STOCKPRICE: APPL
    • Exemple : SCORE: MANUNITED
  • Lorsqu’il détecte une nouvelle requête, le daemon l’analyse, récupère l’information via l’API pertinente, puis la renvoie vers l’avion par l’intermédiaire du compte de miles aériens
  • À partir de cette étape, il devient possible d’aller au-delà d’un simple chat et de consulter des informations en temps réel comme des cours de Bourse ou des scores sportifs

Architecture complète avec sky proxy et ground daemon

  • PySkyWiFi est un protocole de type TCP/IP qui pousse une requête HTTP complète dans un compte de miles aériens, tandis qu’un ordinateur au sol exécute la vraie requête HTTP puis remonte la réponse de la même façon
  • Il comporte deux composants
    • sky proxy : un proxy exécuté sur l’ordinateur portable dans l’avion
    • ground daemon : un daemon exécuté sur un ordinateur connecté à Internet, à la maison ou dans le cloud
  • Avant utilisation, il faut d’abord lancer le daemon au sol, puis se connecter au Wi-Fi dans l’avion et exécuter le sky proxy sur l’ordinateur portable
  • L’utilisateur envoie une requête HTTP au proxy local avec un outil comme curl
    • Exemple : curl localhost:1234 -H "X-PySkyWiFi: example.com"
    • L’URL cible réelle est placée dans l’en-tête personnalisé X-PySkyWiFi
  • Le daemon au sol supprime l’en-tête X-PySkyWiFi et l’utilise pour router la requête vers le site web cible
    • Le corps de la requête et les autres en-têtes sont transmis tels quels
  • À la fin du processus, l’utilisateur reçoit une réponse HTTP comme pour une requête Internet normale, mais selon l’état du réseau de l’avion, la requête peut rester bloquée plusieurs minutes et le débit peut tomber à quelques octets par seconde

Morceaux, ACK et aller-retour HTTP avec un second compte

  • Le sky proxy reçoit la requête curl et découpe toute la requête HTTP en morceaux
    • La quantité de données pouvant tenir dans le champ du nom du compte de miles aériens est faible
  • Chaque morceau est écrit dans l’ordre dans le champ du nom du premier compte de miles aériens
  • Le ground daemon interroge le compte ; lorsqu’il découvre un nouveau morceau, il le lit et laisse un accusé de réception indiquant que le morceau suivant peut être envoyé
  • Une fois toute la requête HTTP réassemblée, le ground daemon envoie la vraie requête sur Internet
  • La réponse HTTP suit la même procédure en sens inverse
    • Le ground daemon découpe la réponse en morceaux et les envoie
    • Pour simplifier l’implémentation, les morceaux de réponse utilisent un second compte de miles aériens
    • Le sky proxy lit les morceaux, réassemble la réponse HTTP et la renvoie à l’appel curl initial

Séparation des rôles entre couche de transport et couche réseau

  • La logique de communication de PySkyWiFi est divisée entre couche de transport et couche réseau
  • La couche de transport décide quelles données envoyer et dans quel ordre
    • La façon de découper les longs messages en petits morceaux
    • La façon dont le destinataire signale qu’il est prêt à recevoir le morceau suivant
    • Un rôle très vaguement similaire à TCP
  • La couche réseau écrit et lit dans le stockage réel les données définies par la couche de transport
    • Ce stockage peut être un compte de miles aériens, un fichier local ou un profil Discord
  • Cette séparation facilite l’ajout de nouvelles plateformes de miles de compagnies aériennes
    • Il suffit d’implémenter une nouvelle couche réseau ; la couche de transport reste inchangée
    • Une couche réseau de test peut lire et écrire dans des fichiers locaux au lieu d’un compte de miles aériens

Règles de transmission avec DATA, ACK et END

  • Une connexion de transport PySkyWiFi est composée de deux tubes
    • Chaque client dispose d’un tube SEND pour l’écriture et d’un tube RECV pour la lecture
    • Les comptes de miles aériens peuvent servir de tubes
  • Un client PSWF ne peut, à un instant donné, qu’envoyer ou recevoir
    • En mode envoi, il ne voit pas les données envoyées par l’autre partie
    • En mode réception, même s’il envoie des données, l’autre partie ne les voit pas
    • Ce n’est pas une communication bidirectionnelle permanente comme avec TCP
  • Les longs messages sont transmis avec des segments DATA, ACK et END
    • DATA : composé de la lettre D, d’un numéro de séquence complété à 6 chiffres et des données réelles du morceau
    • Exemple : D000451adline": "Mudslide in Wigan causes m
    • ACK : composé de la lettre A et du numéro de séquence à 6 chiffres confirmé
    • Exemple : A000451
    • END : une seule lettre E indique la fin du message
  • Après avoir envoyé DATA, l’émetteur attend de recevoir l’ACK correspondant au numéro de séquence
    • Lorsqu’il reçoit A000451, il considère que le morceau 000451 a été traité et envoie le morceau 000452
  • Quand le récepteur voit END, il considère que le message est terminé, puis l’émetteur et le récepteur échangent leurs rôles

Interface d’implémentation de la couche réseau

  • La couche réseau fournit une interface simple pour écrire et lire des données dans un stockage
  • Deux opérations sont obligatoires
    • send(msg: str) : écrit msg dans le stockage
    • recv() -> str : lit un message depuis le stockage
  • Dans une implémentation basée sur des miles aériens, ces deux opérations correspondent à l’écriture et à la lecture du champ du nom du compte
  • Deux attributs sont également obligatoires
    • sleep_for : durée en secondes pendant laquelle la couche de transport attend entre deux interrogations du tube RECV
    • segment_data_size : nombre de caractères pouvant tenir dans un segment
  • sleep_for peut être faible pour une implémentation de test sur fichiers, mais pour une implémentation avec compte de miles aériens, il doit être d’au moins quelques secondes afin d’éviter d’envoyer trop de requêtes au serveur distant
  • segment_data_size doit correspondre à la taille maximale du champ du compte de miles aériens utilisé ; l’exemple est d’environ 20 caractères
  • Deux hooks facultatifs existent
    • connect_send() : appelé lors de l’initialisation du tube SEND ; dans une implémentation avec miles aériens, il peut servir à se connecter avec un nom d’utilisateur et un mot de passe pour obtenir des cookies
    • connect_recv() : appelé lors de l’initialisation du tube RECV

Encodage base26 et pistes d’amélioration de la bande passante

  • Les formulaires HTML de comptes de miles aériens peuvent refuser les caractères non alphabétiques dans le nom
    • Stephen peut être accepté
    • GET /data?id=5 peut être refusé
  • Pour contourner cela, la couche réseau doit encoder les segments en base26 avant de les écrire dans le compte de miles aériens
    • La base26 représente les chaînes uniquement avec les lettres de A à Z
    • Elle transforme une chaîne d’octets en un grand nombre, puis le représente comme un nombre en base 26 avec les lettres A à Z
    • Exemple : b26_encode("Hello world") renvoie CZEZINADXFFTZEIDPKM
  • La couche de transport n’a pas besoin de connaître cet encodage
    • La couche réseau convertit les octets en base26 avant écriture, puis les restaure en octets à la lecture
  • La base26 rallonge fortement les chaînes et réduit la bande passante
    • Utiliser une base52 avec majuscules et minuscules permettrait de raccourcir les chaînes, mais cela reste une amélioration pour une version 2
  • La bande passante peut être augmentée en agrandissant la taille des segments
    • Même si un champ ne peut stocker que 20 caractères, écrire simultanément dans 5 champs de 20 caractères permet d’envoyer un segment de 100 caractères en une seule requête
    • Le récepteur peut lire les 5 champs en une requête et les concaténer à nouveau

Pistes d’amélioration avec HTTP CONNECT et test final

  • PySkyWiFi pourrait créer un meilleur tunnel en utilisant des requêtes HTTP CONNECT au lieu d’échanger manuellement des requêtes HTTP
  • CONNECT est la méthode utilisée par la plupart des proxies HTTP ; avec elle, PySkyWiFi pourrait fonctionner comme un proxy au niveau système et traiter aussi les requêtes du navigateur
  • Avec CONNECT, PySkyWiFi négocierait directement une connexion TLS avec le site web cible, ce qui chiffrerait le trafic passant par le compte de miles aériens
  • L’inconvénient est que l’implémentation demanderait beaucoup plus de travail
  • Lors du test final, les données ont été tunnelées via GitHub Gist pour charger au curl la page d’accueil d’un blog, et une réponse HTML a été reçue quelques minutes plus tard

À lire aussi

1 commentaires

 
GN⁺ 2024-07-10
Commentaires Hacker News

  • Il y a des dizaines d’années, mon épouse utilisait Google Voice SMS en lisant et en répondant directement depuis la boîte de réception Gmail, et comme elle détestait les téléphones portables, elle se promenait avec un vieux Kindle Keyboard livré avec de la 3G illimitée
    Le navigateur basique du Kindle permettait d’ouvrir la version allégée de Gmail, donc on pouvait s’en servir comme d’un appareil SMS sans abonnement mensuel, le seul problème étant l’absence d’alertes pour les nouveaux messages
    Après l’avoir jailbreaké pour essayer d’ajouter un compteur sur l’écran d’accueil, je me suis dit qu’il suffisait de placer ce compteur à côté du nom de l’appareil Kindle, modifiable depuis le compte Amazon
    Un serveur domestique se connectait à Amazon via une automatisation du navigateur pour renommer l’appareil en My Kindle (x), où x était le nombre de messages Google Voice non lus, et le Kindle mettait à jour le nom sur l’écran d’accueil en moins d’une minute, ce qui a très bien fonctionné pendant des années

    • Si je me souviens bien, la facture AT&T des Kindle 3G était énorme
      Dans mon souvenir, économiser quelques octets représentait déjà près d’un million de dollars d’économies
    • J’ai prêté un Kindle Keyboard à un collègue qui partait en voyage, et il s’est fait voler au Mexique
      À l’époque, c’était probablement presque le plus vieux Kindle encore fonctionnel, donc le voleur a sans doute juste pris ce qu’il y avait dans le sac
      Plus tard, j’ai retrouvé un Kindle Keyboard à 20 dollars sur un marché aux puces, mais la batterie est morte six mois après ; j’ai encore l’appareil, donc je me demande combien coûterait une batterie de remplacement
    • Cette 3G gratuite était vraiment incroyable
      On pouvait tant bien que mal utiliser Gmail dans le navigateur, et j’avais même créé un site web compatible Kindle pour jouer à des jeux textuels en choisissant parmi plusieurs ROM zmachine de Zork
      Le site avait même eu un petit écho après avoir été mentionné sur quelques sites d’actualité
    • Moi aussi, j’ai fait ça
      Je n’avais pas l’intégration astucieuse avec le changement de nom du Kindle, mais j’ai envoyé des SMS pendant un temps avec un Keyboard Kindle et sa 3G illimitée
    • Avant d’acheter un smartphone, j’utilisais un Kindle Keyboard pour me guider en voiture lors des longs trajets
      Il arrivait tout juste à faire tourner le site web de Google Maps

  • Il y a longtemps, j’ai pris un ferry d’environ 20 heures entre l’Italie et la Grèce ; il y avait un Wi‑Fi payant basé sur l’internet par satellite, mais je n’avais pas envie de payer
    L’accès à Stripe pour le paiement était ouvert et, en regardant, je me suis aperçu que toutes les pages de stripe.com, y compris la documentation développeur, étaient accessibles, alors j’ai commencé à gaspiller de la bande passante en téléchargeant des images en boucle
    Puis je me suis souvenu que Stripe avait besoin d’un accès au CDN Fastly pour fonctionner, et que Reddit utilisait aussi Fastly ; après m’être connecté à Stripe, j’ai remplacé l’en-tête HTTP Host par reddit.com, ce qui m’a permis de consulter Reddit
    Les images ne marchaient pas, car i.redd.it n’utilise pas Fastly, mais en faisant pointer old.reddit.com vers l’IP Fastly de Stripe dans /etc/hosts et en ignorant de terrifiantes erreurs TLS, j’ai même pu me connecter

    • Avec ce genre de comportement, les personnes qui subissent probablement le préjudice sont les passagers de l’avion qui paient réellement pour utiliser ce service
      Si la connexion ralentit au point qu’ils n’achètent plus jamais le service, le fournisseur y perd aussi, et cela peut également augmenter la facture de bande passante sortante de Stripe
      J’évite même les téléchargements sur le cellulaire par peur d’avoir un impact négatif sur les gens autour de moi
    • Je ne vois pas très bien ce qu’on gagne exactement avec ce genre d’attitude
      Je comprends l’expérience intellectuelle qui consiste à explorer jusqu’où l’on peut accéder depuis une connexion bridée, mais gaspiller délibérément de la bande passante, c’est un peu comme laisser couler l’eau d’un robinet dans des toilettes publiques ou boucher les toilettes jusqu’au débordement
    • C’est du domain fronting, et c’est désormais bloqué par tous les grands CDN
      https://en.wikipedia.org/wiki/Domain_fronting
    • La prochaine fois, tu laisseras peut-être aussi couler l’eau de l’hôtel pour leur donner une leçon, parce qu’ils ont osé proposer un service payant
    • Je me demande pourquoi, face à un service pour lequel tu ne voulais pas payer, ton premier réflexe a été d’en abuser ou d’en dégrader le fonctionnement

  • Il y a quelques semaines, j’attendais les enfants dans un centre commercial pendant leur cours et j’ai essayé d’utiliser le Wi‑Fi gratuit ; la connexion du portable réussissait, mais il indiquait qu’il n’y avait pas d’internet
    En vérifiant la passerelle par défaut, j’ai vu que c’était connecté à un modem Cisco, avec un outil de diagnostic et une liste des appareils connectés, mais la connexion internet était désactivée
    J’ai cherché le modèle sur mon téléphone, et j’ai vu que le compte administrateur était le numéro de série avec un mot de passe vide ; il y avait aussi un exemple de format, et l’un des appareils connectés portait justement un nom qui ressemblait exactement à ce format
    Je me suis connecté tel quel, j’ai activé le bouton internet, quinze secondes plus tard il est passé au vert, puis j’ai aussi redéfini le mot de passe de l’appareil

    • En rendant visite à ma famille, je me suis déjà connecté au Wi‑Fi non sécurisé d’un voisin pour tenter d’accéder au VPN de mon entreprise
      Le VPN ne se connectait pas ; comme il était facile d’entrer dans le routeur, j’ai modifié le réglage MTU et tout s’est immédiatement remis à fonctionner

  • J’adore ce genre de hacking au sens originel du terme
    Cela dit, en vérifiant récemment, il semble que sur skywifi, le DNS global se résolve normalement même sans paiement ; sur le vol que j’avais pris, un simple tunnel iodine classique aurait probablement aussi fonctionné
    https://github.com/yarrick/iodine

    • Il y a quelques années, j’exploitais un service iodine public ouvert à tous
      Pour éviter les signalements d’abus, je faisais passer le trafic sortant du serveur par Tor ; je collectais aussi des logs sur les réseaux de train, d’hôtel et d’aéroport où cela fonctionnait, et je proposais également d’autres protocoles de tunneling
      C’était un projet amusant pendant un temps, et j’aurais dû le laisser tourner
      De nos jours, certains serveurs DNS, surtout Google, randomisent la casse des requêtes DNS, ce qui casse sévèrement certains encodages et rend le tunneling DNS un peu plus difficile
    • Il y a 6 ans, iodine fonctionnait sur le Wi‑Fi d’une autre compagnie aérienne
      L’idée et le principe sont amusants, mais en pratique c’est presque inutilisable à cause du débit, sauf peut-être pour faire passer une messagerie au-dessus d’UDP ;-)
    • Si le DNS est autorisé par le pare-feu, pourquoi ne pas simplement utiliser WireGuard sur UDP/53 au lieu de toucher au protocole DNS lui-même ?

  • « J’ai oublié de recharger mon casque, donc Limp Bizkit a commencé à sortir des haut-parleurs de l’ordinateur portable. Heureusement, les autres passagers de l’avion n’avaient pas l’air d’y prêter attention, alors on en a tous profité joyeusement. »
    Ce genre de personne manque de savoir-vivre élémentaire dans les lieux publics.
    Beaucoup de gens autour ont très probablement été gênés, mais étaient sans doute trop polis pour dire de ne pas leur imposer un bruit inutile.

    • Si l’auteur écrit « ceci est de la satire », la satire est ratée.
    • Je l’ai lu comme une blague.
      Il y a tellement de gens dépourvus de ces règles élémentaires de politesse que ça m’a semblé être une blague amusante, et j’imagine au moins que l’auteur n’est pas réellement ce genre de personne.
    • La blague n’était pas particulièrement drôle, mais elle colle au sujet du texte.
      Elle donne l’image d’un hacker qui voit la possibilité d’un Internet gratuit comme une opportunité exploitable, tout en prenant ensuite ses distances en montrant qu’il n’est pas le genre de personne à abuser réellement des systèmes d’une compagnie aérienne ; le ton du début ressemble donc à un procédé stylistique.
    • Je crois que c’est ce que les humains appellent de « l’humour ».
    • J’espère, comme les autres, que c’était une blague.
      Sinon, c’est un comportement incroyablement grossier et froid.

  • Je me demande si je suis le seul à être toujours fatigué en avion, au point de ne rien pouvoir faire d’autre que fermer les yeux et attendre que ça se termine.
    Rien que l’idée de sortir un ordinateur portable ou un livre m’épuise, il y a trop de bruit et sans casque à réduction de bruit il est difficile de se concentrer.
    On a déjà passé au moins deux heures à quitter la maison, prendre train et tram, puis passer la sécurité, et la nourriture peu saine de l’aéroport n’aide pas non plus.
    Pendant la moitié de l’année il fait soit trop chaud soit trop froid, et avec un sac à dos de 10 kg qui me fait transpirer en permanence, je n’ai plus du tout envie de faire quoi que ce soit une fois dans l’avion.

    • J’ai un TDAH adulte, et même si j’ai plus de mal à me concentrer au travail, je peux au contraire me concentrer comme un laser dans l’avion ou dans d’autres lieux complexes.
      C’est contre-intuitif, mais j’ai entendu dire que beaucoup de cerveaux TDAH fonctionnent ainsi, et le temps passé en avion est le plus productif pour moi.
    • Avant, j’essayais de sortir mon ordinateur portable pour faire quelque chose, mais depuis que le pas entre les sièges a diminué, il est devenu vraiment difficile de sortir quoi que ce soit de plus grand qu’une tablette.
      Il faut le poser sur les genoux, ou alors risquer que l’écran se casse si la personne devant incline son siège ; c’est d’ailleurs arrivé à un collègue il y a quelques années.
      Maintenant, je sors simplement mon iPad et mon casque à réduction de bruit pour regarder des films ou des séries.
    • Tu n’es pas le seul.
      Mon corps réagit exactement de la même manière, et je pense que c’est lié à la baisse du taux d’oxygène dans l’air.
      Ce n’est pas un problème de bruit mais d’air, même si les casques à réduction de bruit sont vraiment efficaces.
      Cela dit, certaines personnes ne semblent pas du tout affectées et arrivent quand même à faire des choses utiles en avion.
    • Moi, c’est exactement l’inverse.
      Même si je suis épuisé ou en manque de sommeil, je n’arrive ni à m’endormir ni à me sentir fatigué dans un avion, donc les vols transatlantiques sont encore plus pénibles, et quand mon compagnon de voyage dort pendant 8 heures, j’ai presque l’impression qu’il se moque de moi.
    • Tu n’es pas le seul.
      En vol, mon cerveau devient complètement embrumé, au point que je garde les yeux fermés jusqu’à l’atterrissage ; si j’essaie de lire ou de travailler, mon cerveau s’éteint au bout de 5 à 10 minutes.
      Curieusement, le repas servi à bord me donne à chaque fois des ballonnements, au point d’avoir besoin de médicaments juste après l’atterrissage.
      Fait intéressant, les deux fois où j’ai voyagé en classe affaires, j’ai pu lire un peu avant que mon cerveau ne s’éteigne.
      Dans les trains longue distance, il m’est vraiment plus facile de travailler si je suis assis dans le sens de la marche, mais si le train est assez bondé, mon cerveau s’éteint de nouveau.

  • En lisant cette histoire d’envoi de cours de bourse, scores sportifs ou météo, ça m’a rappelé les anciennes fonctionnalités que Google proposait via son service SMS.
    Je l’ai énormément utilisé avant d’acheter mon premier smartphone : il suffisait d’envoyer W[ZIP code] au 46645 (GOOGL) pour recevoir la météo par SMS.
    stock:[symbol] marchait aussi, ainsi que bien d’autres fonctions que j’ai oubliées depuis.
    Bien sûr, Google a fini par l’arrêter, mais tant que ça a duré, c’était assez génial.

    • À l’époque où je bricolais en PHP, j’avais créé un bot Twitter appelé SongBuddy qui retrouvait une chanson à partir de quelques paroles.
      On lui envoyait quelques lignes de texte via les DM SMS pris en charge par Twitter à l’époque, il faisait une recherche Google sur " lyrics", analysait les résultats, puis renvoyait par SMS l’artiste et le titre.
      Ça ne marchait pas très bien, mais j’en étais assez fier.
    • Le site de conversion de devises que j’utilise est géré par un professeur, et il tourne probablement sur un Pentium III caché sous un escalier de l’université ; pourtant il survit depuis des décennies et on dirait qu’il tiendra éternellement.
    • J’ai créé une interface SMS↔ChatGPT avec Twilio et une instance AWS.
      Grâce à ça, je peux poser des questions à ChatGPT depuis n’importe où sur Terre avec un communicateur satellite portable inReach Mini 2, et c’est plutôt appréciable de pouvoir demander quelque chose même au beau milieu de Death Valley.
    • J’utilisais ce service en permanence avec mon téléphone à clapet.
      Taper une requête Google prenait du temps et il fallait parfois attendre 1 à 2 minutes pour recevoir le résultat, mais c’était toujours mieux que rien.
      Je m’en servais surtout pour chercher l’adresse d’un lieu où je voulais aller afin de la saisir ensuite dans mon TomTom ; les temps ont bien changé.
    • Je me demande à quelle époque c’était.
      Vers 1995, quand je travaillais dans une société de recherche en télécommunications, filiale d’Ericsson, j’avais eu cette idée, et l’exemple emblématique était les mises à jour de statut de vol.
      Comme personne n’imaginait que la messagerie P2P, où il fallait appuyer plusieurs fois sur un pavé numérique pour saisir une seule lettre, deviendrait si populaire, les services d’information semblaient être le meilleur usage possible dans un Web naissant où les données se multipliaient.
      Le Teletext existait encore, et il y avait aussi un projet séparé pour en extraire les données.
      Mais quand on pense à ce que nous, qui avions accès au SMS, et le grand public en avons finalement fait, c’est assez intéressant.

  • Il est intéressant que l’auteur se soit approché d’assez près d’un TCP au-dessus d’un champ d’édition partagé abstrait.
    En soi, ça pourrait déjà devenir un outil très sympa.
    On peut imaginer un proxy qui, tant qu’on conçoit à haut niveau la manière de lire et d’écrire dans la ressource partagée des deux côtés, se charge de tout le reste pour l’exposer sous forme de proxy SOCKS.

    • À ma connaissance, du TCP/IP sur DNS a déjà été implémenté pour obtenir un accès Internet gratuit sur les hotspots d’aéroport Boingo payants.
      Finalement, le Wi‑Fi gratuit est devenu la norme, donc ce n’est plus rien d’extraordinaire, et maintenant la bataille s’est déplacée vers le Wi‑Fi gratuit à bord des avions.
      Au final, le Wi‑Fi en vol finira lui aussi par être gratuit partout, et c’est déjà le cas chez plusieurs compagnies aériennes.
    • J’y pense depuis des années, depuis que notre opérateur télécom a commencé à promouvoir du « WhatsApp illimité » dans ses forfaits avec quota de données.
      Ça n’aurait permis que le texte, pas les images ni la vidéo, mais cela aurait largement suffi pour une navigation web classique.

  • Il y a quelques années, le doyen de notre université disait en substance que « les jeux avaient un impact sur l’assiduité » et a décidé de couper le réseau LAN après 22 h
    La mise en œuvre consistait à bloquer tout le trafic par adresse IP, mais TCP lui-même n’était pas bloqué, et l’IPv6, qui n’était déjà plus vraiment nouveau à l’époque, avait été complètement oublié
    J’ai donc créé une petite appli de chat P2P fonctionnant en IPv6, et le seul vrai problème était de devoir partager les adresses IPv6 avec mes amis pour qu’ils les gardent dans leurs contacts
    Ça marchait bien, mais j’ai fini par découvrir qu’il était bien plus simple de faire du tunneling vers une machine en dehors du réseau

  • Cela ressemble à un exemple presque parfait de l’article écrivons plus de logiciels inutiles et de la discussion HN qui a suivi
    Est-ce que cela change la vie ? Probablement pas
    Est-ce que c’était amusant à créer et à explorer ? Presque certainement
    Nous devrions en faire davantage
    https://ntietz.com/blog/write-more-useless-software/
    https://news.ycombinator.com/item?id=37911900