Y'a des génies du crime, et puis y'a Peter Stokes, alias Bouquet, 19 ans, presque toutes ses dents, double nationalité américano-estonienne, et surtout membre de Scattered Spider, le collectif qui a déjà plumé MGM et Caesars.
Le mec a tellement bien réussi son coup qu'il est parti se payer des vacances à Tokyo, sauf que pour fêter ça, en bon teubé, il a posté sur Snapchat des selfies de sa grosse tête avec un tout nouveau bijou : un collier en diamants HACK THE PLANET. Comme dans
le film de 1995
mais en plus bling bling !
Hé bien grâce à ça, le FBI a fini par le coffrer lors de son escale d'Helsinki.
Bouquet (oui, j'ai pas précisé mais c'est son pseudo) opérait donc dans le groupe Scattered Spider, ce collectif d'ados anglophones qui ne s'embête pas avec des failles zero-day parce que de toute façon, ils ne sauraient pas les utiliser.
À la place, ils ont leur propre méthode super technique vous allez voir... ils appellent le support IT de la cible et embobinent un pauvre mec pour qu'il reset le 2FA d'un admin.
Et voilà comment notre cher Bouquet a pu sortir 100 Go de données d'un revendeur de produits de luxe (la plainte désigne sobrement la "Company F", mais ça pue Harrods d'après la presse anglaise) en seulement quelques heures, réclamé 8 millions de rançon, et causé plus de 2 millions de dégâts.
Du coup, plainte fédérale à Chicago, 6 chefs (wire fraud, conspiracy, computer intrusion comme ils disent là-bas avec l'accent cowboy), + extradition vers les USA en cours. C'est le bouquet final pour lui ! (Oui, jeu de mots, roh roh roh).
Tyler Buchanan, 24 ans, autre membre du club, a de son côté déjà plaidé coupable d'avoir empoché 8 millions en crypto via du SMS phishing. Faut dire qu'en 2024, le groupe envoyait fièrement des messages genre "Fuck off, FBI" aux agents fédéraux qui enquêtaient sur eux.
Très rebelles nos kikoulool ! Enfin, comme vous le savez, qui fait le malin tombe dans le ravin, et qui fait le mariole avec un collier finit avec des bracelets ^^. (J'ai pas trouvé mieux, déso... lol)
Bref, Bouquet vient à lui seul d'écrire le chapitre 1 du manuel "Comment ne PAS être un cybercriminel à succès" et dont la règle n°1 est : "Si t'es recherché par le FBI, ne montre pas ton butin sur Snapchat"
Énorme retournement de situation. ShinyHunters, le groupe qui
avait piraté Rockstar via Anodot mi-avril
et exigé une rançon, a fini par balancer ses données sur internet quand l'éditeur a refusé de payer. Le but était de faire mal financièrement à Take-Two, sauf que les chiffres révélés étaient si impressionnants que l'effet a été l'exact opposé. En effet, l'action Take-Two est passée d'environ 202 dollars à presque 208 dollars en une matinée, soit une capitalisation boursière qui a pris à peu près un milliard de dollars dans la foulée. C'est fou !
Ce que les hackers ont mis en ligne, c'est notamment que GTA Online génère
plus d'un million de dollars par jour
, soit autour de 500 millions par an. Et tout cela, 13 ans après le lancement sur 5 plateformes différentes, simplement grâce aux Shark Cards (les cartes prépayées du jeu). Pour un éditeur qui s'apprête à sortir son GTA 6 en novembre prochain, faut dire que ce genre de stats montre qu'ils ont les reins hyper solides, ce qui rassure les investisseurs.
Bref, au lieu de sanctionner Take-Two pour la fuite de données et la faille Anodot, Wall Street y a simplement vu la confirmation de ce que tout le monde soupçonnait : la machine à cash de Rockstar tourne à plein régime, et un éventuel GTA 6 au même niveau de monétisation, même partielle, ferait exploser les compteurs !!
Rockstar a également publié une déclaration courte et carrée pour dire que la violation n'aurait pas d'impact sur le studio ou le dev de GTA 6. Rien de plus...
C'est donc un retournement de situation assez fou côté où des hackers, en cherchant à frapper l'éditeur au portefeuille, lui ont en fait permis de gonfler sa capitalisation d'un milliard. Difficile de faire pire en termes de coup raté ^^. A moins que les gens de ShinyHunters aient fait un peu de délit d'initié en amont avant de leaker les données... allez savoir ??
Reste à voir si la SEC ou les autorités européennes voudront enquêter sur cette fuite, sachant qu'au passage des données salariés et de joueurs ont aussi été exposées. Quoiqu'il en soit, côté marché, c'est plié et le cours de l'action est resté bien haut !
En 1992, Eddie Gil de la boîte anglaise Source R&D et Frank Ballouz de Fabtek s'étaient mis en tête d'une chose : transformer la Game Boy en PDA. La console à pile AA de Nintendo avec son écran vert pissette devait, dans leurs rêves les plus fous, devenir l'agenda électronique des cadres dynamiques. Le projet s'appelait WorkBoy, et il a même été présenté au CES en 1992, puis... plus rien.
Évaporé durant 28 ans.
Jusqu'à ce qu'en 2020,
Liam Robertson, le mec derrière DidYouKnowGaming
, retrouve un prototype fonctionnel chez Frank Ballouz lui-même. Ballouz l'avait sur son étagère depuis trois décennies. Quand Robertson l'a contacté, il lui a lâché tranquillou : "Oh yeah, j'ai le WorkBoy derrière moi" et après 7 mois de relances, le proto est finalement arrivé dans les mains de Robertson pour être testé en vidéo :
Le WorkBoy, c'est un clavier QWERTY plus gros que la Game Boy elle-même, avec une cartouche dédiée qui se branche dans l'emplacement où d'ordinaire, on met les jeux. Et à l'intérieur du clavier, il y a une horloge, de la mémoire interne (la Game Boy n'en avait pas, c'était LE problème majeur de l'époque), ainsi que tout un OS de bureautique de poche.
Et au menu des fonctionnalités, on avait donc le droit à un calendrier, un répertoire téléphonique, un convertisseur d'unités (parce qu'en 1992 vous saviez jamais quand ce serait le moment de convertir des pieds en mètres en pleine réunion), une calculatrice, et même un traducteur multilingue.
Mais le clou du spectacle, c'est la carte du monde qui jouait... les hymnes nationaux en 8-bit ! Voilà, je crois que là, tout est dit ! Vous cliquez sur la France, et hop vous avez la Marseillaise version Tetris. Vous cliquez sur l'URSS, vous avez l'Internationale en mode bip-bip. C'était fou pour l'époque !!
Eddie Gil avait passé des années à peaufiner ce truc, et Ballouz utilisait son carnet d'adresses Nintendo (il avait été cadre chez Nintendo Of America du temps des bornes d'arcade) pour pousser le projet en interne. Le lancement était alors prévu pour décembre 1992... l'usine était prête et la certification quasi bouclée.
Et puis Nintendo a annoncé qu'ils allaient faire baisser le prix de la Game Boy !! C'était la cata car d'un coup, l'accessoire WorkBoy, à 90 dollars environ, devenait plus cher que la console qu'il était censé compléter !
Ballouz a refait ses calculs, a fait la grimace, et a annulé la production quelques mois avant le CES. Game over pour le projet. Et voilà comment pendant trois décennies, le seul souvenir tangible du projet, c'était quelques photos floues et une marque déposée.
Mais le truc cool suite à cette redécouverte, c'est que Robertson a aussi mis la main sur le code source du WorkBoy via le fameux
Nintendo Gigaleak
de 2020 (c'était une fuite massive des serveurs Nintendo qui a balancé pelle-mêle des ROMs prototypes, du code source, des trucs internes...).
Un anonyme sur Twitter lui a alors signalé qu'on pouvait choper la ROM en ligne. Robertson était mal à l'aise avec la source car c'était du code volé, mais bon, il a fini par graver le binaire sur une cartouche et réussi à faire tourner le proto.
Et là, surprise : le truc a fonctionné nickel. "C'est plus rapide que mon ancien smartphone", a balancé Robertson. Faut dire qu'en 1992, avoir une UI réactive sur un écran 160×144 pixels en 4 nuances de vert, c'était de l'orfèvrerie. À l'époque, les développeurs savaient optimiser leur code au cycle CPU près, et ça se voyait...
Par contre, le WorkBoy nécessitait obligatoirement le hardware physique pour fonctionner correctement car l'horloge et la mémoire interne sont dans le clavier et pas dans la cartouche. Du coup, l'émulation pure ne suffisait pas. C'est probablement pour ça qu'on n'en avait jamais entendu parler avant que Ballouz daigne sortir le sien du grenier.
Ce WorkBoy disparu était l'incarnation parfaite de cette ère charnière où on cherchait à entasser de la productivité dans tout ce qui avait un microprocesseur. Comme quoi, bien avant le PalmPilot (1996), dans la foulée du Psion 3 (sorti un an plus tôt), Nintendo et ses partenaires avaient donc déjà flairé le truc.
Si vous avez committé du code depuis VS Code depuis mi-avril, allez tout de suite vérifier vos messages de commit car vous avez peut-être un nouveau co-auteur que vous n'avez jamais embauché.
En effet, Microsoft a discrètement basculé le réglage par défaut de l'éditeur pour ajouter Co-authored-by: Copilot <[email protected]> à des commits que VS Code considérait à tort comme contenant des contributions IA, même quand vous n'avez pas utilisé Copilot, et même quand vous avez explicitement désactivé toutes les fonctions IA.
Et le résultat de tout ce bordel, vous pouvez le lire dans la
PR #310226
qui a explosé sur GitHub : 372 pouces baissés contre 2 levés, 30 réactions "confused", et des dizaines de commentaires furieux.
L'
issue de suivi #314311
, ouverte ensuite par dmitrivMS pour faire son point public, a elle aussi reçu un torrent de réactions virulentes. Tu m'étonnes, ils font vraiment n'importe quoi...
Maintenant si vous êtes dans ce cas, vous pouvez neutraliser ça immédiatement, ajoutez dans votre settings.json :
"git.addAICoAuthor": "off"
C'est le seul réglage qui marche vraiment, parce que dans la version buguée même chat.disableAIFeatures à true n'arrêtait pas le soucis. Et pour votre historique déjà bien pollué, un git rebase -i ou un git filter-branch permettra de virer les contributeurs parasites dans vos derniers commits. Mais après bonne chance si vos commits sont déjà sur des PR mergées chez d'autres. Là c'est mort...
Ce que les devs reprochent à Microsoft, c'est pas vraiment d'avoir créé l'option (elle existait depuis VS Code 1.110 en opt-in tranquille). Non, le vrai problème c'est surtout ce qu'il y a derrière cette vilaine Pull Request... 2 fichiers touchés, le change de "default", absolument AUCUNE description, une seule review d'approbation toute nulle, et hop, c'est mergé OKLM.
Pour un changement qui touche les messages de commit de plusieurs millions de devs, ça sent quand même la décision unilatérale prise à l'arrache entre 2 portes...
Et puis surtout il y a le
bug #313064
qui a fait basculer l'histoire de la simple polémique à la grosse colère communautaire.
En effet, la nouvelle valeur par défaut "all" attribuait à Copilot des complétions qui ne venaient PAS de Copilot. Un dev explique par exemple avoir tapé son code à la main, vérifié son message de commit, supprimé toute suggestion Copilot, écrit le sien à la main... et a finalement retrouvé quand même Co-authored-by: Copilot dans le git log final.
Et comme le mode "je ne veux pas d'IA" n'était pas plus respecté, l'IA s'auto-créditait quand même sur tout et n'importe quoi.
Côté communauté, le ton est monté très vite. Sur le fil GitHub, y'en a un qui écrit que, je cite, "C'est pas une régression, c'est de la fraude. On ne peut pas s'attribuer un travail qu'on n'a pas fait." et un autre dev parle de "vandalisme" pur.
Windows Central
a même sorti un titre choc : "This could cost people their jobs", parce que dans les boites en fintech ou sur du code soumis à audit, faire passer du code humain pour de l'IA-assisté peut coller un fail d'audit et faire péter des contrats. Ah bah ouais, j'avoue que je n'y avais pas pensé...
Heureusement, Microsoft a fini par bouger puisque dans VS Code 1.118 , le default est finalement repassé de "all" à "chatAndAgent", déjà moins agressif. Et dans la
PR #313931
, dmitrivMS a remis le default à "off" pour la version 1.119, dont le déploiement public commence justement aujourd'hui.
Bien sûr, la Product Manager a fait son mea culpa public, en reconnaissant, je cite que "la manière dont c'était implémenté et déployé n'a pas atteint le niveau de correction attendu", ce qui, dans la langue corporate, veut dire "on est des branleurs, déso, bisous".
Maintenant ce qui revient souvent dans les commentaires, c'est que Claude Code et Codex CLI font la même chose par défaut quand ils committent, sauf que la différence, c'est que ces agents committent quand C'EST EUX qui ont écrit le code, donc le co-author est tout a fait légitime.
VS Code, lui, modifiait des commits écrits à la main par des humains donc c'est pas du tout le même problème. Et pour le coup, sur Codex CLI la mention reste aussi désactivable via une option alors que chez Claude Code même si c'est pareil, l'opt-out n'est pas toujours très respecté d'après les retours que j'ai pu lire.
En tout cas, ce loupé arrive dans un climat déjà tendu puisque Microsoft pousse Copilot dans Windows, dans Notepad, dans Office, et même
jusque dans l'écosystème Apple via une extension Xcode
, dans tous les coins, et beaucoup de devs commencent à voir chaque nouveauté MS à travers ce prisme. La théorie du "ils gonflent les KPI Copilot pour les boards et les analystes" de plus en plus crédible et comme personne n'aime se sentir transformé en stat marketing, tout le monde commence à se barrer des outils et services Microsoft.
Maintenant, si vous voulez vraiment vous protéger des prochains coups foireux de M$, je vous propose d'abord de basculer sur
VSCodium
ou
Zed
, deux éditeurs sans télémétrie ni AI imposée. Et ensuite, déménager vos repos chez
Codeberg ou Forgejo
en suivant la procédure de migration que je vous donne dans cet article Patreon, comme ça même si Microsoft fait n'importe quoi côté éditeur, votre code n'est plus chez eux côté forge.
À voir maintenant si Microsoft tient ses promesses sur le consentement explicite avant toute mention d'agent IA, ou si on rejouera ce film encore et encore tous les 6 mois sur une autre fonctionnalité.
Si vous faites tourner WireGuard depuis un réseau filtré par DPI (Genre en Russie, Iran, Chine, et autres pays défenseurs de la libertéééé (non)), vous avez sans doute remarqué que les tunnels tombent rapidement. En effet, les signatures des protocoles et notamment du protocole WireGuard sont devenues facilement identifiables. Les filtres modernes de censure sont ainsi capable de les bloquer en quelques secondes. C'est pour ça que
wg-obfuscator
, sorti par Alexey Cluster (le dev derrière
le mod hakchi de la NES Classic Mini
dont je vous parlais en 2017), m'a tapé dans l'œil.
Concrètement, c'est un petit proxy en C qui se glisse entre votre WireGuard et le réseau. Vous le lancez aux deux bouts du tunnel, et lui déguise les paquets pour qu'ils ressemblent à du STUN (le protocole utilisé par les outils de visioconf, rarement bloqué) ou à un flux random pas reconnaissable. WireGuard continue ainsi de tourner sans aucune modification...
C'est vraiment bien fichu son truc et surtout, par rapport à
AmneziaWG
(un célèbre fork de WireGuard souvent cité comme référence en obfuscation), hé bien y'a juste un binaire à rajouter, alors que AmneziaWG, lui, modifie TOUT le protocole. Il faut donc remplacer les client ET le serveur ce qui est bien relou.
Comme wg-obfuscator se contente uniquement de faire le proxy, vous gardez votre setup WireGuard classique et donc ça fonctionnera partout... Sur OpenWrt, MikroTik avec RouterOS 7.4+ sur ARM64/x86_64 via Docker, NixOS, Android, ou un simple Raspberry.
Par contre, l'outil utilise une clé symétrique en texte clair donc c'est pas du chiffrement fort, mais du camouflage.
Côté config, on est sur du fichier INI tout simple :
Après c'est pas dit dans la doc mais je pense que c'est compatible IPv4 seulement... Donc oubliez l'IPv6 pour le moment. Ensuite il faut les deux extrémités sous votre contrôle, donc oubliez les VPN commerciaux type NordVPN ou ProtonVPN tant qu'ils ne déploient pas wg-obfuscator côté serveur.
Ah et un dernier détail qui vaut le coup d'être noté, c'est le mode two-way avec static-bindings. En fait si vos deux peers ont une IP publique, vous pouvez parfaitement configurer à la main vos mappings NAT pour permettre à chacun d'initier la connexion, sans dépendre d'un serveur central.
Mackie Kannard-Smith vient de sortir
Kawaii
, une GameCube qui tient dans un porte-clés avec une vraie carte mère Nintendo dedans. Pas d'émulation ni de Raspberry Pi déguisé mais juste du silicium d'origine charcuté à mort pour rentrer dans 60 × 60 × 15,8 mm ! Pour vous donner une idée, c'est plus petit qu'une Game Boy Color et c'est le boîtier en alu bleu anodisé qui fait office de dissipateur thermique passif.
Le truc tourne en réalité sur une carte mère de Wii sévèrement modifiée. Mackie a choisi la Wii (sortie en 2006) plutôt que la GameCube d'origine, parce que la Wii partage la même architecture mais avec une finesse de gravure plus récente. Du coup, c'est plus facile à miniaturiser même si pour arriver à ses fins, il a dû appliquer une technique baptisée Omega Trim qui consiste à tronçonner la PCB multicouche au scalpel et à reconnecter chaque piste à la main avec du fil ultra-fin. Pas simple quand on a des gros doigts ^^.
L'encodeur AV est délocalisé, la NAND flash relogée ailleurs, et le processeur est sous-volté dynamiquement via un régulateur custom. Vous chargez alors les jeux sur une carte microSD qui est scellée à l'intérieur !
Alors pour changer de jeu, il n'y a pas d'autre choix que de littéralement désassembler la console. C'est pas top côté pratique mais comme c'est du prototype de l'extrême et pas une console destinée au grand public, je pense que ça passe ^^.
Et là où c'est bien fichu je trouve, c'est avec le dock magnétique composé de pogo-pins, de 4 ports manettes GameCube d'origine, d'un USB-C pour l'alim, et d'une sortie AV analogique. Comme ça vous posez simplement la console sur la base et vous vous retrouvez avec un setup de salon classique.
Côté température, sans ventilo externe, ça chauffe vite par contre. Le boîtier alu fait son boulot, mais y'a quand même des limites physiques qu'on ne peut pas changer... Donc impossible de l'utiliser trop longtemps sans y ajouter un refroidissement actif en plus (genre ventilo ou watercooling).
Après, vous le savez, j'adore ce genre d'exploit et ce n'est d'ailleurs pas le premier mod du genre que je vous présente. Je vous avais déjà parlé du
Short Stack
de loopj, qui réduisait une Wii au format d'un paquet de cartes. Et devinez quoi, loopj a aussi contribué à Kawaii !
En réalité, cette communauté de tarés du fer à souder se retrouve sur le forum
BitBuilt
, où ils s'échangent les techniques de découpe extrême depuis des années, alors si vous voulez vous lancer, c'est the place to be !
Les fichiers de conception de la console Kawaii
sont publiés sur GitHub
, mais Mackie prévient : y'a aucun guide de build, et la réplication est "extrêmement difficile". En clair, c'est pas un mod du dimanche.
Faut une station de soudage à l'air chaud, une loupe binoculaire, des nerfs en acier et une connaissance fine de l'architecture Wii. À vrai dire, c'est sûrement plus simple d'attendre qu'un mod commercial inspiré du projet sorte un jour (coucou la GameCube Mini qui sortira probablement un jour...). Maintenant, si vous voulez voir la bête en action, Macho Nacho Productions a sorti une review de 21 minutes qui fait bien le tour de la machine :
Bref, Kawaii ça sert à rien, c'est techniquement aberrant comme dirait l'autre, et c'est exactement pour ça que c'est classe !
DOOM, Fallout, Theme Hospital, Civilization... il y a sur le web des milliers de jeux DOS jouables directement dans votre navigateur, gratuitement, sans installer quoi que ce soit. Car oui mes amis, l'émulation DOS dans le browser a vraiment mûri, et il existe des dizaines de bons sites qui vous permettent de jouer à tout un tas de jeux disparus. Je vous propose donc une bonne dizaine d'entre eux classés par ordre alphabétique.
Mais avant, faut savoir que tous fonctionnent plus ou moins sur la même base. C'est du DOSBox compilé en WebAssembly pour tourner dans un onglet de votre navigateur et ensuite la différence entre tous ces sites se joue sur leur catalogue, la légalité du contenu qu'ils proposent, et quelques fonctionnalités bien pensées. (Si vous cherchez plutôt à faire tourner des vieux .exe Windows,
RetroTick
fait ça très bien aussi.)
On commence par Best DOS Games le petit nouveau sorti en 2023 qui compte déjà +900 jeux et 50 000 joueurs. Ce qui le démarque surtout ce sont ses fonctionnalités de sauvegarde cloud et de Hall of Fame communautaire si vous avez un compte. C'est un super site très agréable à utiliser au quotidien notamment grâce à son interface.
Best Old Games, lui, dépasse volontairement le cadre des jeux DOS : SNES, Commodore 64, arcade, ZX Spectrum, Master System... Il est ligne depuis 2004, couvre +600 titres sur 9 plateformes, et tous les jeux sont disponibles en téléchargement ou à jouer directement en ligne. L'angle abandonware est d'ailleurs totalement assumé, par contre, certains titres n'ont pas encore de version jouable en ligne. Ce sera donc uniquement du téléchargement pour cela. Hyper pratique donc si votre nostalgie du gaming ne s'arrête pas à MS-DOS, mais un peu fourre-tout.
DOS Games Archive pousse la philosophie de préservation depuis 1998, avec 1 641 jeux répartis dans 17 catégories. Le site dispose d'un blog et d'un forum toujours très actifs et il propose uniquement du contenu légal (shareware, freeware, domaine public). Le truc bien vu ce sont surtout ces liens directs vers GOG pour les titres dont vous voudriez acheter la version commerciale complète. Par contre, pas de sauvegardes cloud... chaque session repartira de zéro si vous quittez votre partie. Mais c'est la référence pour jouer "proprement".
DOS Zone est de loin le plus complet et le plus moderne du lot. Plus de 2 000 titres MS-DOS, sans pub, avec support mobile et mode hors-ligne. La techno derrière s'appelle js-dos, qui une implémentation DOSBox compilée en WebAssembly. Et tenez vous bien, le site vous propose également un Game Studio pour créer et publier vos propres jeux DOS directement depuis le navigateur. Y a de quoi y passer des heures !!
DOSGames.com c'est le vétéran de la scène ! Ce site est en ligne depuis janvier 1999, bien avant YouTube, Twitter ou Facebook ! Il a été fondé par Darren Hewer qui voulait sauvegarder tous ces titres DOS "devenus difficiles à trouver" à l'époque. Il propose plus de 2 300 jeux shareware et freeware légaux. L'interface a un peu vieilli (comme nous tous ^^) mais 25 ans de fidélité au poste, ça force le respect !
L'Internet Archive n'est pas à proprement parler un site de jeux puisque c'est le projet de préservation numérique le plus ambitieux de la planète. Mais je ne pouvais pas faire l'impasse dessus car leur collection MS-DOS regroupe aussi des milliers de titres jouables directement dans votre navigateur, gratuitement et sans pub. Après, je trouve que l'interface est moins bien taillée pour le gaming que d'autres sites. Par contre pour dénicher un titre introuvable ailleurs, c'est le top !
MyAbandonware c'est un autre site d'abandonware de référence mondiale avec +37 000 jeux couvrant DOS, Windows, Amiga, Mac, Atari et bien d'autres plateformes. Il y a donc beaucoup de titres DOS qui sont jouables directement dans le navigateur, mais le site reste avant tout une encyclopédie du jeu rétro avec des fiches complètes : screenshots, année, éditeur, manuel...etc. Y'a tout !!! Donc c'est super précieux si vous voulez comprendre l'histoire d'un vieux titre en plus de le faire tourner.
PlayDOSGames.com lui est plus modeste et propose 655 jeux réparti dans 18 catégories, avec, s'il vous plait, de la sauvegarde dans le cloud ! Vous commencez une partie ici, et hop, vous la continuez ensuite depuis votre téléphone ou un autre ordi. Créé en 2013, et dispo en 10 langues, ce n'est donc pas le plus gros catalogue, mais c'est le meilleur pour jouer en mode nomade.
RGB Classic Games est aussi plutôt modeste puisqu'il ne propose que 565 titres, mais chaque version de chaque jeu est archivée. Le site est en ligne depuis mars 2005, et couvre aussi BeOS, que OS/2, Win16 et d'autres systèmes d'exploitation plus en marge. La plupart des titres sont à télécharger et pas à jouer en ligne donc si c'est pour passer le temps au taf, dans le navigateur sans install, laissez tomber. Mais pour les puristes qui veulent une release bien précise, c'est là qu'il faut aller !
Et puis on a WePlayDOS qui organise son catalogue par saga : Oregon Trail, Civilization, Zork, DOOM, Warcraft... Je trouve que c'est une idée intelligente pour explorer une franchise plutôt que de chercher un titre précis à chaque fois. Après le catalogue est petit donc si votre jeu n'est pas dans une saga connue, y'a des chances que vous repartiez brocouille (vous l'avez ?). Mais pour de la découverte par série, carrément bien pensé.
Pour ma part, j'ai opté pour dos.zone et Best DOS Games car je trouve que ce sont les plus riches en fonctionnalités. Mais si vous voulez de l'archive sérieuse, DOSGames.com ou DOS Games Archive conviendra mieux ! Et si votre truc c'est le multi-écrans, PlayDOSGames fera très bien le job.
Aujourd'hui, c'est un jour un peu spécial pour moi, puisque c'est l'anniversaire de mon site web ! Alors je tenais à célébrer ça avec vous parce que les années filent à la vitesse de l'éclair et qu'on ne fête jamais assez les choses.
Et il s'en est passé des choses en 22 ans quand même. J'ai démarré ça comme un site perso, et qui, parce que les gens aiment bien ranger les trucs dans des cases, est devenu un "blog", puis un "média", et qui sait ce que ce sera demain...
Mais pour moi, c'est toujours mon petit bout de moi sur le web et l'objectif est toujours le même : Partager les trucs qui m'intéressent pour vous donner de quoi bidouiller à la maison ou au boulot. Toujours pas de ligne éditoriale claire, parfois de l'actu, parfois des tutos, parfois des reviews de logiciels, parfois des trucs plus perso... Peu importe tant que ça me plait.
Sachez qu'en 2025, j'ai publié environ 1300 articles sur ce site. C'est beaucoup mais moins qu'en 2011 et 2012 où j'étais à +1400 par an. Et en 2008, aïe aïe, record du monde avec +1600 articles dans l'année. C'était une époque où j'avais du temps et surtout où il se passait pas mal de choses au niveau tech. Envie de tout tester, de toucher à tout, et de tout vous raconter ! Comme aujourd'hui finalement !
Et en 2026, malgré quelques moustiques qui tentent de me faire dérailler, ça va être encore plus riche puisque j'ai délégué une partie de "l'actu fraiche" à mon ami Vincent qui fait un boulot top ! L'objectif est de me libérer un peu de temps pour à la fois mettre un point final aux combats actuels dans lesquels mon site se trouve depuis 6 mois (et dont je ne peux malheureusement pas vous parler mais ça viendra) et également avoir plus de temps pour la bidouille
et les Patreons qui me soutiennent
! Je leur suis tellement reconnaissant !
Depuis 2004, tout a évolué c'est vrai. Le paysage tech a changé, les sujets d'intérêts des uns et des autres ont évolué (je l'espère pour vous ^^), et moi-même je m'intéresse à de nouvelles thématiques. En 2004 c'était comment optimiser eMule, comment installer Ubuntu et des astuces de base de registres Windows... En 2026, c'est plutôt comment faire tourner ses propres IA en locale, comment auto-héberger tel ou tel truc, ou encore comment se mettre en sécurité suite à la découverte de telle ou telle faille de sécurité...etc.
Et je sais qu'il y en a parmi vous qui sont là depuis le tout début. Vous m'avez vu changer 2 fois de CMS, je-sais-plus-combien de fois de design, plusieurs fois d'hébergeur, passer de la bannière pub omniprésente à un site sans aucune pub programmatique...etc. Vous vous reconnaitrez et cet anniversaire, c'est autant le vôtre que le mien !
Je continue aussi à vous en proposer pour tous les goûts... Des articles vulgarisés pour les débutants, des tutos plus complexes pour les gens + confirmés, et des choses qui peuvent parfois intéresser 15 000 personnes ou n'en intéresser que 4 ou 5... Peu importe. Ma boussole ce sont les retours que vous me faites par mail ou via le Patreon, et le seul filtre que je m'impose est "Est ce que ça m'intéresse ?". Parce qu'il n'y a rien de plus chiant que d'écrire sur un sujet qui ne m'intéresse pas. C'est pour ça que je ne traite pas de TOUTE l'actu tech qui passe... Je "cherry pick" comme on dit, que ce qui me plait et basta.
Et ça semble plutôt fonctionner puisque l'audience est au rendez-vous. Vous êtes en effet depuis le début de l'année entre 1,5 et 2 millions à passer ici chaque mois.
Je mets ça sur le compte de la refonte technique du site qui est + rapide, + agréable à lire (mode sombre, mode dys, etc.), sans bannière pub ni cookies publicitaires mais aussi sur l'augmentation du nombre d'articles grâce à Vincent et grâce à mes problèmes actuels qui m'empêchent de dormir et qui font que je me réfugie dans le boulot. Et il y a aussi l'arrivée des LLM qui m'ont permis de gagner du temps sur la recherche d'information, sur ma propre compréhension de certains sujets, sur des aspects plus pratiques comme la relecture, la validation des infos, la saisie des méta données, les images et j'en passe...
Grâce à ça, je fais moins d'impasses, je dis moins de conneries, je peux rentrer plus dans certains détails qui autrefois m'auraient échappé...etc. Je suis plus dans une recherche de qualité et de consistance dans mes articles que de productivité (j'sais pas si je battrai mon record de 2008 ^^). Et évidemment, ça a un impact... Des articles plus fouillés et moins fouillis, un meilleur référencement naturel et surtout, des lecteurs qui reviennent parce qu'ils découvrent des trucs.
Bien sûr, tout n'est pas parfait et ça ne le sera jamais mais je pense que j'ai trouvé un bon équilibre avec ces nouveaux outils.
Maintenant les bases restent les mêmes qu'en 2004... Un site ouvert, avec un flux RSS complet, sans paywall, sans article réservé aux abonnés, sans newsletter premium. Tout est ici, pour tout le monde, gratuit, indexable, citable. Le
Patreon
existe en parallèle pour celles et ceux qui veulent un peu plus (et surtout pour me soutenir directement, ce qui me touche énormément), mais 100% de ce qui est publié sur korben.info est accessible librement. C'était une évidence en 2004, et c'est resté un choix en 2026.
Je sais que le site ne plaît pas à tout le monde et c'est OK. 22 ans à publier presque tous les jours, forcément ça intrigue, ça énerve, ça incite même parfois à m'inventer une vie ou des anecdotes à mon sujet. Mais bon, c'est le revers de la médaille et si tout le monde était d'accord avec moi, ce serait pas drôle. Donc tant pis pour ceux que j'irrite, et merci à ceux qui me lisent encore... y compris en cachette ^^.
Après j'ai pas de grand plan pour la suite. Pas de roadmap, pas de pivot, pas de levée de fonds, pas de série documentaire sur ma vie. Juste l'envie de continuer à faire ce que je fais depuis 22 ans : Chercher des trucs qui m'intéressent, les tester, les comprendre et vous les raconter. Et même s'il ne se passe pas une journée où je ne me pose pas la question de tout arrêter, et bien je continue parce que j'adore ça.
Si vous utilisez le gestionnaire de mots de passe intégré à Microsoft Edge, et que vous le trouvez cool, hé bien accrochez-vous les amis, car Tom Jøran Sønstebyseter Rønning, chercheur norvégien en cybersécurité, vient de publier sur GitHub un PoC qui dump TOUS vos credentials en clair directement depuis la mémoire du processus du navigateur ! Et de ce que j'ai compris, Microsoft a l'air d'assumer ça tranquillou...
Et n'allez pas croire qu'activer "l'Authentification avant remplissage automatique" dans Edge règle le souci... Ça ne change absolument RIEN au problème, parce que les credentials sont chargés en clair en RAM dès l'ouverture du navigateur. Cette option bloque uniquement l'interface, et pas la mémoire. La seule vraie parade, c'est donc de basculer carrément vers
un gestionnaire de mots de passe
comme Bitwarden, KeePassXC, ou
Mistikee
car tant qu'ils restent verrouillés, ils ne chargent rien en mémoire.
Le PoC, baptisé EdgeSavedPasswordsDumper, tient en un seul fichier C#. Tom a choisi .NET Framework 3.5 plutôt qu'une version récente, parce que AMSI, l'Antimalware Scan Interface qui inspecte en temps réel le code .NET sous Windows, a une couverture vraiment réduite sur la 3.5 par rapport aux versions modernes. Du coup, le binaire passe plus facilement sous les radars des EDR et antivirus.
Maintenant, le truc, c'est que ce sujet n'est pas nouveau. En effet, en juin 2022, Zeev Ben Porat de chez CyberArk publiait déjà
un papier
détaillant exactement la même méthode appliquée à Chromium en général (et dont Edge découle...). Il utilisait les APIs Windows OpenProcess et ReadProcessMemory pour lire la mémoire privée des processus du navigateur et y récupérer URLs, logins, mots de passe et même cookies de session. Et à l'époque, Microsoft et Google avaient répondu en gros pareil, à savoir que c'était hors du "threat model", donc que c'était pas la peine de corriger.
Sauf que 4 ans plus tard, Tom Rønning n'arrivait pas à reproduire le dump sur Chrome avec la même méthode. En effet, le navigateur de Google semble charger ses credentials de façon plus granulaire (lazy loading, déchiffrement au besoin) plutôt que tout exposer en RAM dès l'ouverture. Alors que Edge, lui, n'a pas évolué et charge encore TOUS les credentials en clair dès le démarrage du navigateur, qu'on en ait besoin ou pas, et surtout les garde en mémoire tant que le processus parent tourne. Et c'est cette différence-là que Tom met en lumière avec son outil.
Après concernant la dangerosité de ce problème, faut que je nuance un peu tout ça car pour viser sa propre session Edge, l'attaquant n'a pas besoin d'être admin (un malware tournant sous votre compte y arrivera). Par contre, pour aller lire la mémoire des AUTRES utilisateurs sur la même machine, là, il faut les droits administrateur.
Et c'est surtout ce scénario que Tom met en avant dans son README. Il y parle d'un terminal server où plusieurs utilisateurs seraient connectés simultanément via RDP, et sur lequel un admin compromis pourrait dumper les mots de passe de tous les autres avec leur Edge ouvert, y compris les sessions déconnectées tant que le processus parent tourne. C'est assez spécifique quand même mais pas impossible évidemment...
Microsoft, contacté par Tom avant publication, a bien sûr répondu que le comportement était "by design"... Leur doc Edge enterprise explique même noir sur blanc que les attaques physiquement locales et les malwares sont hors du modèle de menace et qu'aucun navigateur n'est armé pour résister à un attaquant déjà infiltré dans le compte utilisateur.
C'est cohérent c'est vrai... Mais ça occulte un truc qui reste très "gênant" comme disent les ados. C'est que leur implémentation expose une surface d'attaque plus large que leurs concurrents basés sur le MÊME moteur Chromium. C'est pas normal....
Et côté communauté, ça n'a pas trainé non plus, puisque Whitecat18 sur GitHub a déjà sorti un
portage Rust
du PoC. C'est intéressant car Rust offre encore moins de surface AMSI que .NET 3.5 et se compile comme un binaire natif sans aucune dépendance. Donc pour un attaquant, c'est un upgrade de furtivité significatif... Et pour un défenseur, c'est surtout une raison de plus de pousser vos utilisateurs vers des vrais gestionnaires de mots de passe.
Concernant la
divulgation responsable
, Tom Rønning a fait les choses dans les règles : signalement à Microsoft, attente de la réponse officielle, présentation publique le 29 avril 2026 à BigBiteOfTech (l'évènement Palo Alto Networks Norway), puis publication du PoC.
Voilà... Microsoft persiste, Edge reste as-is (lumière !), et la sécurité de vos mots de passe est officiellement votre problème. Donc si vous utilisez Edge, je pense que ça vaut clairement le coup de migrer vers un gestionnaire externe... vous verrez, c'est pas la mer à boire.
Jellyfin sans GPU, c'est la croix et la bannière dès que quelqu'un lance un film en 4K. Mais c'était sans compter sur
ffmpeg-over-ip
qui est capable de transformer un serveur équipé d'un GPU en endpoint de transcoding distant, accessible via un simple binaire qui se fait passer pour ffmpeg. Y'a pas de passthrough GPU, ni besoin de vous lancer dans la config de point de montage réseau exotique.
Le principe c'est que le client reçoit les commandes ffmpeg de
Jellyfin
(ou Emby), les sérialise et les envoie ensuite via TCP (port 5050) vers un serveur qui lui dispose d'un bon GPU. Et côté Jellyfin, rien ne change puisque le binaire répond exactement comme ffmpeg le ferait (et je vous rassure, y'a un peu d'authentification pour éviter de vous faire squatter votre serveur de transcoding à l'insu de votre plein gré).
Alors imaginons un peu dans quelle situation ça peut être utile... Par exemple, vous pourriez avoir un NUC ou mini-PC tout neuf qui fait tourner Jellyfin dans Docker, et à côté une vieille tour avec une GTX qui traîne dans un coin pour le transcodage. L'avantage c'est que plusieurs clients peuvent ainsi partager le même serveur GPU en parallèle, donc ffmpeg-over-ip peut valoir le coup si vous avez du matériel qui dort dans un coin.
L'outil est signé Anees Iqbal (steelbrain) et voici comment l'installer (pensez à vérifier le contenu du .sh avant) :
curl -fsSL https://ffmpeg-over-ip.com/install-client.sh | sh
Windows a aussi droit à son équivalent PowerShell si vous voulez.
Pour brancher ça sur
Jellyfin
ensuite, c'est direction Dashboard → Playback → chemin ffmpeg → et faites pointer vers ffmpeg-over-ip-client. Notez que ffprobe doit aussi être redirigé car Jellyfin l'appelle séparément pour les métadonnées. Vous pouvez faire un lien symbolique pour être tranquille :
ln -s ffmpeg-over-ip-client ffprobe
Et ensuite, pour vérifier, cette commande : ./ffmpeg-over-ip-client -version devrait vous retourner les infos de l'instance ffmpeg distante. Si ça répond, c'est que c'est bon !
Notez que la config permet de passer par des variables d'environnement du genre FFMPEG_OVER_IP_CLIENT_ADDRESS pour l'adresse du serveur, FFMPEG_OVER_IP_CLIENT_AUTH_SECRET pour la clé HMAC. Et pour tout ce qui est paramètres avancés, disons que les remappings de filtres complexes qu'on peut faire avec ffmpeg nécessitent encore un fichier .jsonc à créer et paramétrer.
Côté serveur, les accélérations supportées sont : NVENC (NVIDIA), QSV (Intel), VAAPI (Linux), AMF (AMD), VideoToolbox (macOS). Et comme c'est basé sur jellyfin-ffmpeg, du coup y'a toutes les accélérations habituelles sans avoir à recompiler.
Par contre, attention si le serveur GPU tombe, y'aura aucun fallback automatique vers le CPU local. Et si votre réseau interne est en 100Mbps et que vous transcodez du 4K HEVC, le goulot d'étranglement sera le transit réseau, pas le GPU. Donc optez pour un réseau en gigabit minimum dans ce cas.
Bref, c'est simple, propre, et très bien pensé par exemple pour les setups Docker qui n'ont pas d'accès direct au matériel.
Vous connaissez ICON, qui imprime des maisons en béton avec ses grosses machines ? Hé bien Terran Robotics fait en fait pareil, mais avec de la terre, ou plutôt avec l'argile extraite directement du terrain. Du coup ça revient carrément moins cher.
Leur techno consiste en un robot suspendu par des câbles entre quatre tourelles dressées aux coins du chantier qui crache de l'argile. Zach Dwiel (CEO, ex-Intel) et Danny Weddle (CDO, architecte) ont développé ce système depuis 2019 et leur premier chantier est actuellement en cours.
D'abord la pince robotisée ramasse l'argile sur place. Ensuite elle la dépose couche par couche sur les murs en construction. Un outil de compactage tasse chaque dépôt, et des caméras couplées à du machine learning évaluent la qualité de la paroi en continu.
Le matériau
c'est ce qu'on appelle de l'adobe
. Rien à voir avec Photoshop, hein... De l'adobe c'est un mélange entre de l'argile, de la terre, de l'eau et de la paille. L'avantage c'est que tout est sourcé directement sur le terrain.
Bon, ça suppose que la terre soit suffisamment argileuse, ce qui n'est pas garanti partout, mais dans la plupart des cas ça passe. D'après l'un des inventeurs : "C'est le matériau le moins cher pour construire. Notre but c'est le logement abordable." L'adobe offre en prime une bonne inertie thermique et régule naturellement l'humidité et le son.
Source : Terran Robotics
Par contre, je vais rien leur dire mais de ce que je connais au BTP, c'est quand même pas l'idée du siècle de construire SUR un terrain argileux à cause du gonflement et de la rétractation de l'argile en période de pluie / sécheresse... Breeeef, j'suis pas sûr que j'opterai pour ça moi... Après si l'argile est récupérée plus loin, pourquoi pas...
Quoi qu'il en soit, la première maison sort au Texas, sur le campus Proto-Town, un terrain de 485 hectares près de Lockhart financé par Josh Kushner, Bill Ackman et Fred Ehrsam (co-fondateur de Coinbase).
Ce 1er chantier a 2 murs en adobe et 2 en bois seulement pour tester... Mais la prochaine maison sera réalisée 100% en terre et ils visent la construction de 20 maisons cette année. La portabilité c'est l'argument fort de cette techno car au lieu de déplacer un gros engin qui mobilise une logistique complète, tout tient dans un petit camion. Ainsi, un opérateur peut gérer plusieurs chantiers simultanément.
Comparé à de l'impression 3D béton à la ICON, le fait d'utiliser directement ce qui se trouve sur le terrain, c'est moins de capital de départ, moins de matière transportée, et surtout c'est déployable n'importe où. C'est le principe des robots à câbles parallèles (CDPR) appliqué au bâtiment... dans l'esprit des
projets robotiques open source
mais à l'échelle d'une maison entière !
Bref, construire avec de l'argile je trouve ça chouette car c'est quand même une méthode qui a fait ses preuves et que l'humain emploie depuis des millénaires. Mais construire sur de l'argile, j'suis moins fan. Quoi qu'il en soit, c'est une chouette invention je trouve !
Deux fois plus rapide que LZ4 en décompression ?? Ah bon c'est possible ? Évidemment, quand Bertrand Lebonnois a publié
zxc sur GitHub
, et m'a envoyé un email pour me prévenir, j'ai été jeter un œil, surtout aux benchmarks.
Eh bien après analyse, c'est bien réel !
La philosophie de zxc est assez tranchée vous allez voir. Il s'agit d'une lib WORM (Write-Once, Read-Many) qui permet de compresser une fois lentement, à la compilation ou en CI, et ensuite de décompresser comme vous voulez des millions de fois sur les appareils de vos utilisateurs à la vitesse de l'éclair. Avec zxc, on accepte que la compression soit lente et complexe (pour trouver le bitstream parfait), afin que la décompression soit méga rapide et simple pour le processeur. C'est aussi simple que ça.
Le revers de la médaille, c'est que si vous voulez de la compression à la volée ou du streaming temps réel, ce n'est clairement pas adapté. Par contre, si vous produisez des assets une fois et qu'ensuite, vous les servez des milliers de fois, alors vous êtes exactement dans la cible.
En pratique, sur macOS M2 avec un corpus de test standard, zxc dépasse les ~12 000 Mo/s en décompression, contre ~5 600 Mo/s pour LZ4 --fast dans le même test. L'écart reste également hyper solide ailleurs : 1,8× sur ARM serveur (Google Axion) et 2× sur x86_64 (AMD).
Et l'API proposée par zxc ne s'arrête pas à un compresseur basique. En effet, un mode "seekable" permet d'accéder à n'importe quelle position d'une archive sans scanner le fichier depuis le début. Par exemple, vous packagez vos
assets de jeux vidéo
dans une seule archive zxc, et quand le joueur charge une texture précise, vous lisez directement le bon bloc, et pas tout le fichier.
Côté installation, c'est simple : brew install zxc sur macOS, apt install zxc sous Debian ou Ubuntu, pip install zxc-compress, npm install zxc, cargo add zxc-compress ou vcpkg install zxc sous Windows.
Des bindings officiels existent aussi pour Rust, Python, Node.js, Go et WASM et la communauté a aussi ajouté Nim et Free Pascal de son côté. Et comme c'est codé en C, y'a aucune dépendance lourde.
Sache que pour assoir la crédibilité du projet, zxc a été intégré dans lzbench et TurboBench, les deux outils de référence permettant de comparer les algos de compression. Et le paquet est déjà dispo dans les versions testing et unstable de Debian, ce qui veut dire que les mainteneurs ont validé le truc !
Bref, si vous gérez de la compression d'assets ou de firmwares dans votre pipeline, ça vaut le coup d'y jeter un oeil.
Merci à Bertrand pour l'info et chapeau pour le boulot !
Si vous utilisez
Claude Code
au quotidien, vous connaissez ce goût de sang qui vous monte dans la bouche lorsque, sans prévenir, cette putain de limite de quota imposée par Anthropic vous explose à la gueule ! Et le pire c'est que vous n'avez pas l'impression d'avoir fait grand chose.
En réalité, la vraie raison c'est surtout le "bruit" de toutes vos sorties shell. Un git log, un cargo test, un npm build... votre agent IA ingère tout ça comme du petit lait alors qu'il n'a besoin que d'une fraction pour comprendre ce qui se passe.
Breeef, c'est pas ouf quoi.
Heureusement pour vous RTK (Rust Token Killer) vient régler en partie ce problème. RTK c'est développé par un Français et c'est un proxy CLI en Rust qui s'intercale entre votre shell et votre agent IA, intercepte les commandes courantes et compresse leur sortie avant qu'elle n'atterrisse dans le contexte de votre agent.
Comme ça plutôt que de massacrer vos prompts ou de changer vos habitudes (et dieu sait que vous avez horreur de changer d'habitudes..lol), il attaque le bruit à la source grâce à 4 stratégies de compression : un filtrage du boilerplate, un regroupement des lignes similaires, une troncature intelligente et de la déduplication des répétitions.
Et tout ça s'intègre merveilleusement bien via un hook pour Claude Code, GitHub Copilot, Cursor, Gemini CLI, Windsurf, Cline, Codex... soit une bonne dizaine d'outils supportés !
Ainsi, votre git status devient rtk git status sans changer quoi que ce soit à vos habitudes... RTK fait tout le filtrage dans votre dos, ce qui est parfait ! C'est un outil qu'on installe et qu'on oublie.
Par exemple un git diff passe de 12 000 tokens à 960, soit 92% d'économie, un npm test tombe de 6 000 à 600 tokens et une session de refactoring sur 12 fichiers passe de 74 700 à 6 960 tokens d'après les benchmarks. En pratique, les utilisateurs constatent des économies autour de 70% sur l'ensemble d'une journée de boulot, ce qui représente plusieurs millions de tokens par semaine pour ceux qui bossent avec des agents IA à plein régime.
Moi ça fait plusieurs mois que je le teste et voici mes stats. Ça donne quand même 81,5 % d'économie de tokens !!
L'installation se fait en une commande : brew install rtk sur macOS, ou un script curl pour les autres plateformes, ou cargo install --git https://github.com/rtk-ai/rtk si vous préférez compiler ça vous-même.
Avec la commande rtk gain vous verrez un tableau comme ci-dessus avec les statistiques par commande, et rtk gain --history donnera l'historique détaillé. Y'a plus de 100 commandes couvertes, de git aux runners de tests en passant par AWS CLI, kubectl et docker. Par contre, ça marche pas super bien si vos sorties de commandes sont déjà très courtes. Ça ne fera pas de miracle mais pour des diffs volumineux ou de suites de tests qui crachent 3 000 lignes à chaque fois, c'est tip top !
Si vous utilisez
des agents en mode autonome
où une boucle tourne sans intervention, c'est même encore plus pertinent car chaque itération accumule du bruit de façon cumulative, et du coup le contexte se remplit de trucs inutiles à vitesse grand V. Moins de bruit grâce à RTK, c'est donc une économie de tokens mais c'est également un meilleur signal pour votre agent.
RTK est dispo en open source sur
GitHub
sous licence Apache 2.0.
Vous avez un service qui tourne sur le port 8080, mais aucune authentification native dessus et vous voulez ajouter OAuth2 sans avoir à toucher au code ? Vous êtes vraiment exigeant dans la vie !
Mais comme vos désirs sont des ordres, je vous présente oauth2-proxy dont c'est EXACTEMENT le boulot !
Le principe avec cet outil c'est qu'il se glisse entre l'utilisateur et votre application. Ainsi, si la personne n'est pas connectée, elle est alors redirigée vers son provider OAuth2 ou OIDC. Et une fois le token validé, popopop, la requête repart vers son point d'origine avec les infos utilisateur dans les headers HTTP. Et voilà comme votre app reçoit le nom, l'email, et les groupes associés à l'utilisateur ! Plus besoin de gérer l'auth dans votre code c'est que du bonheur !
Et la liste des providers supportés par oauth2-proxy est longue : Google (c'est celui par défaut), GitHub, GitLab, Microsoft Entra ID, Keycloak, Gitea / Forgejo, NextCloud, DigitalOcean, LinkedIn, Bitbucket, Cisco Duo... et un bon vieux client OIDC générique pour tout ce qui expose un accès standardisé. Comme ça si votre SSO interne parle OIDC, vous êtes déjà couvert !
Côté déploiement, c'est un simple binaire en Go et c'est également disponible en image Docker sur quay.io/oauth2-proxy/oauth2-proxy, pour AMD64, ARM64, ARMv6/v7, et quelques architectures plus exotiques du genre ppc64le, s390x pour les bandeurs de mainframes ^^.
Ensuite, l'outil peut fonctionner de 2 façons : Soit en proxy autonome devant votre service, ou en middleware intégré dans un reverse proxy existant comme nginx via le mécanisme auth_request. Dans ce second mode, oauth2-proxy ne fait en réalité que vérifier la session et répondre du code 202 ou 401. C'est nginx qui gère le routage et le proxy lui se contente d'authentifier les gens.
Et voilà, si vous cherchez à minimiser la surface d'attaque, c'est la config à privilégier. Tout est là :
github.com/oauth2-proxy/oauth2-proxy
, avec la doc complète. Et si vous cherchez quelque chose de plus intégré, avec tunnel et gestion des tunnels VPN en prime, il y a aussi
Pangolin
dont je vous ai parlé. Et pour du plus simple en contexte Docker,
TinyAuth
fera également très bien le taf.
Comme vous le savez, les LLMs sont assez probabilistes de par leur nature. C'est leur force mais également leur principal problème de sécurité car si votre agent IA a une probabilité de 1% de faire une grosse connerie des enfers par session, sur 100 sessions vous montez à environ 63% de chances qu'il en arrive au moins une.
Heureusement, Agent Safehouse vous permet d'encapsuler votre agent préféré dans un profil sandbox macOS au niveau du kernel afin de réduire drastiquement la surface d'attaque sur votre système de fichiers.
Le principe de base, c'est le deny-default. Tout est refusé par défaut puis des autorisations sont ensuite ouvertes au compte-gouttes : lecture/écriture dans le répertoire du projet, accès lecture seule aux toolchains installés, et les exceptions système nécessaires au fonctionnement (runtimes, homebrew, réseau).
Par défaut, les clés privées SSH et les fichiers de credentials AWS ne sont pas lisibles donc si l'agent essaie d'accéder à ~/.ssh, il se prend une erreur "operation not permitted". C'est une couche de durcissement mais pas une barrière de sécurité absolue puisque le réseau, lui, reste ouvert par défaut, et des variables d'environnement peuvent encore exposer vos credentials. Mais pour tout ce qui est erreurs accidentelles et autres hallucinations destructrices en mode Claude a fumé la moquette, ça permet de leur couper la chique.
Cela repose sur
le mécanisme sandbox-exec
, l'outil natif macOS qu'Apple a fini par marquer "deprecated" sans vraiment le retirer. Agent Safehouse s'en sert tout simplement comme fondation et y ajoute de la configuration par profil et les intégrations agents par dessus.
Sandbox-exec est en effet le seul mécanisme natif macOS qui s'applique en wrapper arbitraire depuis la ligne de commande, sans avoir besoin de se taper un setup préalable comme on pourrait le faire avec Docker ou une VM.
Et c'est surtout plus léger et plus pratique pour un usage au quotidien donc si vous faites tourner Claude Code ou Codex plusieurs heures par jour, ça peut servir, au moins pour votre tranquillité d'esprit.
L'installation se fait via Homebrew comme ceci :
brew install eugene1g/safehouse/agent-safehouse
Ou via un script curl si vous évitez Homebrew. Ensuite, vous remplacez votre appel habituel par safehouse [agent] [options]. Donc pour Claude Code ça donnerait ceci :
safehouse claude --dangerously-skip-permissions
Les functions shell (bash, zsh, fish) peuvent encapsuler ça automatiquement pour que votre agent soit sandbox par défaut à chaque appel et il est toujours possible de contourner cela via un simple command claude si besoin.
La liste des agents supportés est Claude Code, Codex, OpenCode, Amp, Copilot CLI, Gemini CLI, Aider, Goose, Cursor Agent, Cline, Kilo Code et d'autres.
Après c'est macOS uniquement pour l'instant, et surtout sandbox-exec étant techniquement plus maintenu par Apple, il pourrait très bien disparaître dans une future version de macOS. Donc faudra vivre avec ce risque ^^.
Hier soir Lilian, fidèle lecteur de Korben m'a envoyé une vidéo incroyable qui retrace 5h de combat sur Age of Empires 2 résumées en 34 minutes par TheGreatReview.
Faut savoir que je suis fan d'Age of Empires
depuis le premier épisode de 1997
. AoE 1, 2, Mythology, AoE 3... j'ai laissé un nombre indécent d'heures sur ces titres, donc forcément, voir ces longues heures de matchs condensées en chouette récit, ça ravive de vieux souvenirs !
Lors de cette partie, 2 joueurs avec un très très bon niveau s'affrontent ainsi durant des heures, quasiment sans ressources, en mettant au point toutes sortes de stratégies pour faire capituler leur adversaire. De l'AoE2 raconté à la voix posée, avec beaucoup de stratégie, d'imagination et surtout de patience ! Mais je ne vais pas vous en dire plus pour ne pas vous spoiler.
Gardez-vous ça pour la pause déj', ça ne dure que 34 minutes et franchement ça vaut le coup !
BrowserQuest est de retour les amis ! Hé ouais, el famoso MMO HTML5 que Little Workshop avait pondu pour Mozilla en 2012 vient de ressurgir sur
threej.in
, alors que Mozilla avait officiellement archivé
le repo GitHub
en janvier 2024.
En allant sur ce lien, vous choisissez le nom de votre personnage, et hop, vous vous retrouvez comme y'a plus de 10 ans, dans un monde 2D en pixel art prêt à vous taper avec des rats et des squelettes direct dans le navigateur.
Petit rappel pour les endormis du fond à côté du radiateur, quand BrowserQuest est sorti en mars 2012, c'était un événement !! Mozilla voulait avec ce jeu, montrer au monde entier que le navigateur pouvait faire tourner un MMO temps réel sans Flash, sans aucun plugin, mais juste avec du HTML5 et des WebSockets. Le studio parisien Little Workshop (les frères Guillaume et Franck Lecollinet) avait alors livré une démo incroyable qui ressemblait à un Zelda 16 bits, avec des quêtes, de l'équipement, un chat intégré et même du combat coopératif. Comme je suis viiieux de fous, je vous en avais même
parlé à l'époque
.
Car techniquement, c'était du sérieux... Canvas pour le rendu 2D, Web Workers pour charger la map sans freezer la page, localStorage pour sauvegarder votre perso, CSS3 Media Queries pour s'adapter au mobile, et surtout WebSockets pour la communication bi-directionnelle avec le serveur Node.js.
Du coup le jeu pouvait encaisser des CENTAINES de joueurs simultanés, avec un pic réel enregistré à plus de 1 900 connexions en même temps. C'est ouf ! Faut dire que
2 ans plus tôt, Quake 2 tournait déjà en HTML5
et on commençait alors tous à comprendre que notre navigateur allait devenir une véritable plateforme gaming.
Sauf que voilà, Mozilla n'a jamais vraiment maintenu BrowserQuest après le buzz initial. Le serveur officiel browserquest.mozilla.org a fini par mourir, le repo GitHub a basculé en mode DEPRECATED, et en janvier 2024, la fondation a appuyé sur le bouton "Archive" pour de bon. Fin du game ! Sniiiif...
Sauf que le code est sous licence MPL 2.0 et le contenu en CC-BY-SA 3.0 donc en gros, n'importe qui peut reprendre le bousin, le réhéberger et le relancer !
Hé bien c'est exactement ce que threej.in a fait et ça fonctionne parfaitement, y compris l'aspect multijoueur. L'écran de crédit affiche même encore "Made for Mozilla by Little Workshop" comme si rien n'avait bougé.
Perso, je trouve ça cool qu'un projet open source archivé aussi culte puisse continuer à vivre grâce à un inconnu qui a pris la peine de le remettre en ligne. C'est aussi à ça que servent les licences libres finalement... prolonger la vie des programmes au-delà de la motivation de leurs créateurs. Chouette hein ?
À l'époque, encaisser 1900 joueurs en simultané sur un backend Node.js relevait de la prouesse technique, alors qu'aujourd'hui, tout semble beaucoup plus facile puisqu'on trouve des dizaines de jeux .io et autres qui tournent dans un onglet de browser sans que ça nous fasse lever un sourcil. La techno derrière BrowserQuest est devenue tellement banale qu'on a tous oublié à quel point elle était impressionnante à l'époque !
Bref, c'est gratuit, c'est dans le navigateur, et ça tient toujours debout !
Quand j'achète un truc avec ma CB, c'est vrai que j'évite maintenant de demander le ticket de carte bancaire. Ça ne me sert à rien, et puis j'en fais quoi après ? Je le jette à la poubelle ?
Heureusement qu'il n'y a pas de données confidentielles dessus et que tous les chiffres de ma CB sont masqués avec des petites étoiles sauf une partie, généralement les 4 derniers, qui sont en clair évidemment.
Bref, tout roule, nan ? Hé bien noooon, parce que Metin Ozyildirim, un chercheur en sécurité, vient d'expliquer sur son site comment ces étoiles en fait c'est pas vraiment un secret.
En fait, quand vous effectuez un achat en ligne, le marchand pose une question à votre banque pour valider la carte, du genre "hey Crédit Agricole, est-ce que ce numéro existe ?" et la banque répond connement oui ou non.
Et le souci c'est que cette question, n'importe qui peut la poser depuis n'importe où dans le monde, en testant des numéros au pif jusqu'à tomber sur le bon. C'est ce qu'on appelle du brute force, et avec une bonne machine et une connexion correcte, ça permet de tourner tranquillement à la fréquence de 6 tentatives par seconde, soit environ 130 000 essais possibles étalés sur une nuit. C'est donc très largement assez pour reconstituer les chiffres manquants quand on n'en a que 6 à deviner.
Et surtout, il arrive parfois que le marchand soit un peu trop bavard. Par exemple si vous tapez un mauvais numéro, il vous répond "Cette carte de crédit n'est pas valide". Si la date d'expiration est fausse, il vous dit gentiment "Cette carte a expiré". Et si le CVV est faux ? "Le code CVV n'est pas correct".
Comme le dit Metin dans son post, ce genre d'indice aide carrément à bruteforcer les infos de la CB. Bah oui, si le marchand vous confirme noir sur blanc que vous êtes à 3 chiffres près du jackpot, pourquoi s'arrêter hein ? C'est un peu comme dans ces films où y'a un gars qui braque un coffre-fort qui fait "clic" à chaque bon chiffre.
Et comme ça donc que Metin Ozyildirim s'est fait piller son compte bancaire il y a environ 1 an. L'attaquant a fait tourner son bruteforce comme ça durant 6 heures, en répartissant ses requêtes sur plusieurs sites e-commerce différents pour passer sous les radars.
Et une fois la carte complète reconstituée, restait plus qu'à dépenser le pognon ! Et là pareil, certains marchands acceptent encore les paiements sans demander la double authentification 3D Secure. Ces marchands là, ce sont eux qui payent en cas de fraude, car ils prennent le risque. L'attaquant a juste eu à choisir un de ces marchands "hack-friendly", et a transféré l'argent vers un porte-monnaie électronique, qu'il a ensuite converti en cash.
Et voilà comment le plafond de la carte de Metin était à zéro avant qu'il ait terminé son premier café du matin !
La bonne nouvelle, c'est que la banque l'a remboursé. Par exemple en France, vous avez 13 mois pour contester une transaction frauduleuse via votre banque. C'est un droit et pas une faveur hein ! Mais si la banque considère que vous avez été négligent (carte prêtée, code partagé, phishing évident...etc), elle peut tout à fait refuser le remboursement, donc gardez des preuves et contestez vite !
Maintenant, la mauvaise nouvelle, c'est que ce qui est arrivé à Metin est de plus en plus fréquent.
Visa a même documenté
que ce genre d'attaques explose, et que la majorité des sites e-commerce sont mal protégés contre ce genre de bots qui font tourner ces scripts de bruteforcing.
Bref, y'a pas grand chose à faire de notre côté pour nous protéger de ça, si ce n'est d'activer les notifs de notre banque sur chaque transaction, configurer le plafond le plus bas possible (sans que ce soit gênant), et quand votre banque vous propose une carte virtuelle à usage unique pour les achats en ligne, n'hésitez pas à l'utiliser.
Et la prochaine fois que vous laisserez traîner un reçu de CB sur la table d'un resto, dites-vous que vous offrez peut-être un accès à votre compte au prochain margoulin qui passe !
Hello les amis, voici ma petite trouvaille du jour, idéale pour ceux qui jouent en ce moment avec des adresses IP :
ip66.dev
. C'est une base de géolocalisation IP et entièrement libre, livrée au format MMDB (le même que celui de MaxMind) qui permet de remplacer direct un fichier GeoLite2 dans vos libs existantes (Python, Go, Node.js), sans toucher au code.
L'équipe de Cloud 66 maintient cette liste à jour sous licence CC BY 4.0 et tout est utilisable simplement en récupérant le fichier mmdb.
Pour le télécharger :
curl-LOhttps://downloads.ip66.dev/db/ip66.mmdb
Ensuite pour interroger une IP, l'outil
mmdbinspect
de MaxMind fera le job. Si vous l'avez pas déjà, une ligne suffit :
go install github.com/maxmind/mmdbinspect/cmd/mmdbinspect@latest
mmdbinspect -db ip66.mmdb 8.8.8.8
À l'intérieur de la réponse, vous trouverez le numéro et le nom de l'ASN, le pays avec son code ISO, le continent, en IPv4 et IPv6 :
Au lieu de moudre des heuristiques opaques, ip66 préfère tout simplement agréger des sources à partir des 5 registres régionaux (AFRINIC, APNIC, ARIN, LACNIC, RIPE NCC) pour les allocations, le BGP via RouteViews et RIPE RIS pour les vues publiques d'annonces, le RFC 8805 geofeed quand les opérateurs déclarent eux-mêmes leurs localisations, sans oublier GeoNames pour tout ce qui concerne les libellés.
Du coup chaque enregistrement dispose de son propre niveau de confiance (Very High, High, Medium, Low) selon la qualité de la source. Y'a même des marqueurs pour identifier les IPs VPN / Tor et compagnie.
Notez par contre, que c'est du country-level, et pas du city-level comme GeoIP2 City ou IPinfo Core, mais pour enrichir des logs, sortir des stats par pays ou bloquer un continent entier, c'est largement suffisant !
Et si vous voulez l'exposer en API plutôt que la requêter en local, ça se branche nickel sur le
mmdb-server
, un petit serveur Python qui sert les fichiers MMDB en HTTP. Vous lui pointez ip66.mmdb dans son dossier db/ et hop, c'est plié !
Bref, un fichier mmdb à DL, et votre serveur sait maintenant que 8.8.8.8 c'est l'oncle Google.