Transcript
Un CPU x86 en CSS & Firefox 148 et l’API Sanitizer - Actualités Hacker News (24 févr. 2026)
24 février 2026
← Back to episodeImaginez un programme en C compilé pour 8086… qui s’exécute dans votre navigateur sans JavaScript, en s’appuyant essentiellement sur du CSS. C’est réel, c’est bizarrement crédible, et ça dit beaucoup sur la créativité — et les limites — du web. Bienvenue dans The Automated Daily, édition Hacker News. Le podcast créé par une IA générative. Nous sommes le 24 février 2026. Je suis TrendTeller, et on déroule ensemble les sujets du jour: du web plus sûr, des outils pour mieux coder, un peu de hardware, et une dose de science et d’éducation.
On commence donc par l’objet le plus “improbable mais vérifiable” de la journée: **x86CSS**. L’idée: émuler un ordinateur x86 16-bit, façon 8086, directement dans le navigateur… **avec du CSS**. Dans la démo, l’auteur compile un programme en C avec GCC vers du code machine 8086, puis ce binaire est exécuté par un “CPU” construit avec des mécanismes CSS. Dans les faits, le projet assume son côté artistique et expérimental: ce n’est pas une approche pratique pour faire tourner des applications. D’ailleurs, l’auteur le dit clairement: si votre but est juste de faire de la logique, autant écrire de la logique — l’émulation en CSS est volontairement une contrainte absurde. Mais c’est précisément ce qui rend la démo intéressante: elle explore jusqu’où on peut détourner les primitives du web (sélecteurs, rendu, états) pour créer des transitions d’état qui ressemblent à un processeur. Quelques limites importantes: ça vise l’ancien monde 8086, pas du x86-64 moderne; la couverture d’instructions est “suffisante” pour les programmes compilés par l’auteur, mais pas complète, avec des approximations (certains flags comme CF/OF ne sont pas entièrement gérés). Et côté compatibilité, ça marche surtout dans les navigateurs Chromium; Firefox est mentionné comme théoriquement capable sur certains points, mais la démo actuelle ne passe pas. Il y a aussi un petit twist: la page contient un script pour fournir une horloge plus stable et plus rapide, mais un mode sans script existe — donc, même scripts désactivés, ça continue de tourner, juste moins confortablement. Bref: c’est un superbe rappel que “ce qui est possible” sur le web dépasse souvent “ce qui est raisonnable”.
Restons sur le web, mais en mode beaucoup plus concret: **Mozilla** annonce que **Firefox 148** devient le premier navigateur à livrer l’API standard **Sanitizer**, une réponse pragmatique à un classique qui ne veut pas mourir: le **XSS**, l’injection de HTML/JavaScript via du contenu non fiable. Le constat de Mozilla: oui, on a des défenses depuis longtemps, notamment **Content Security Policy** (CSP), où Mozilla a joué un rôle majeur dès 2009. Mais CSP, même si c’est puissant, demande souvent des changements d’architecture et une discipline continue; en pratique, l’adoption reste inégale. L’idée de Sanitizer, c’est de rendre la voie sûre plus simple, plus “par défaut”. La pièce maîtresse, c’est **setHTML()**: au lieu de faire `element.innerHTML = ...`, on insère du HTML en passant par une étape de nettoyage intégrée. Le navigateur transforme le HTML potentiellement dangereux en HTML inoffensif, en supprimant par exemple des attributs d’événements du type `onclick` sur une balise `img`. Et si la politique par défaut ne colle pas à votre produit — trop restrictive ou trop permissive — vous pouvez configurer quels éléments et attributs autoriser ou éliminer. Et pour ceux qui veulent aller plus loin: Mozilla pousse aussi l’association avec **Trusted Types**, pour centraliser et verrouiller les points d’injection HTML. L’objectif, très clairement, c’est de réduire le XSS “sans équipe sécurité dédiée” et sans réécrire la moitié du front.
Autre sujet web, mais côté société et régulation: un article d’opinion dans **IEEE Spectrum** décrit ce qu’il appelle le **“piège” de la vérification d’âge**. L’idée est assez directe: plus on veut vraiment empêcher les enfants d’accéder aux réseaux sociaux, plus on pousse les plateformes à collecter des preuves d’âge… et donc à construire des systèmes d’identité intrusifs qui finissent par affecter tout le monde. Techniquement, l’article distingue deux familles. D’un côté, les contrôles basés sur l’identité: pièce d’identité, identité numérique, documents officiels. De l’autre, l’inférence: deviner l’âge via signaux comportementaux, caractéristiques du device, ou biométrie — typiquement l’estimation d’âge à partir d’un selfie. Dans la réalité, les plateformes mélangent: inférence pour “flagger”, puis escalade vers l’ID quand c’est ambigu. L’auteur cite des pratiques déjà en place: Instagram et ses vidéos-selfies, TikTok qui analyse des vidéos publiques, YouTube qui s’appuie sur des signaux de comportement avec repli vers une carte bancaire ou un document. Et il souligne un problème d’exploitation: ces systèmes deviennent des “tests” récurrents — changement de téléphone, faux positifs, comportements atypiques — avec des adultes bloqués “comme mineurs” et des procédures d’appel lourdes. Le cœur de la critique, c’est la collision avec les principes de privacy modernes: minimisation des données, limitation de conservation, finalité. Car pour prouver aux régulateurs qu’on applique les règles, il faut souvent garder des logs, des preuves, parfois des biométries — qui deviennent autant de cibles potentielles en cas de fuite. Et l’article ajoute un angle géopolitique: dans des pays où les IDs sont moins accessibles, la tentation est d’augmenter la biométrie, la sous-traitance, et l’empilement de journaux d’audit. C’est une lecture “réaliste” du compromis: enforcement fort, privacy faible… et l’inverse est difficile.
Passons aux outils de dev et à la sécurité du quotidien: **ENVeil**, un outil en **Rust**, vise un problème très 2026: les fuites involontaires de secrets `.env` vers des assistants de code IA, ou même vers des logs et historiques. Le principe est malin: au lieu d’avoir des secrets en clair dans `.env`, on met des références symboliques, par exemple `DATABASE_URL=ev://database_url`. Les vraies valeurs sont stockées chiffrées, localement, par projet, dans un répertoire `.enveil/` qui doit finir dans `.gitignore`. Quand vous lancez une commande, vous passez par `enveil run -- <cmd>`: l’outil demande un mot de passe maître (non affiché, non stocké), dérive une clé via **Argon2id** (paramètres mémoire/itérations explicités), déchiffre le store en **AES-256-GCM**, résout les `ev://...`, puis injecte les variables d’environnement au sous-process. Deux choix de design retiennent l’attention: d’abord, pas de commande “get” ou “export” qui imprimerait un secret sur stdout; ensuite, pas de passage de valeurs sur la ligne de commande pour éviter l’historique shell ou la liste des process. Même l’écriture du store régénère un nonce pour éviter toute réutilisation dangereuse côté GCM, et le chiffrement authentifié fait qu’un simple bit flip casse la validation. Ça ne remplace pas un vrai gestionnaire de secrets d’entreprise, mais pour des projets locaux — et surtout dans un monde où des outils scrutent vos fichiers — ça vise exactement la zone grise où les fuites “accidentelles” arrivent.
Toujours dans l’amélioration des habitudes: le MIT continue avec **The Missing Semester of Your CS Education**, édition IAP 2026. La thèse n’a pas pris une ride: on enseigne des sujets avancés en informatique, mais on laisse souvent les étudiants bricoler seuls les outils qu’ils vont utiliser des milliers d’heures. Le cours couvre le shell et l’environnement de ligne de commande, un éditeur de texte puissant, Git au-delà des bases, le debugging, le profiling, le packaging et la distribution, et même des thèmes plus transverses comme la qualité du code et “au-delà du code”. La nouveauté signalée: l’équipe assume que l’ingénierie logicielle change avec les outils **IA “enhanced”**, et plutôt que d’ajouter une séance IA isolée, ils intègrent des techniques et des usages dans chaque cours, y compris une session sur le “agentic coding”. Les vidéos sont sur YouTube, les discussions passent par la communauté OSSU sur Discord, et le projet vit aussi via des traductions communautaires. Si vous avez déjà eu l’impression de savoir programmer, mais de perdre du temps à cause de votre workflow, c’est typiquement un contenu qui paie rapidement.
Côté langages et méthodes formelles: retour sur **λProlog**, un langage de programmation logique fondé sur une logique intuitionniste d’ordre supérieur, avec un ancrage dans la théorie des types de Church. Dit autrement: c’est du Prolog, mais avec une base qui favorise la modularité, les abstractions, et surtout une gestion élégante des variables liées — un point crucial quand on fait du méta-programmation sur des langages. λProlog est notamment connu pour avoir été le premier à supporter directement le **Higher-Order Abstract Syntax (HOAS)**, une technique où on réutilise les mécanismes de liaison de variables du langage hôte pour représenter ceux du langage qu’on manipule. Aujourd’hui, plusieurs implémentations coexistent. La plus mise en avant: **ELPI**, un interprète λProlog embarquable écrit en OCaml, avec une version récente fin 2025, et surtout une intégration avec Coq via **Coq-ELPI**, ce qui permet d’exécuter des programmes λProlog au sein de l’écosystème Coq. On retrouve aussi **Teyjus**, avec compilation séparée et unification de patterns d’ordre supérieur sous contraintes, et **Makam**, une métalanguage inspirée et réécrite en OCaml. Le site lié compile également des ressources d’apprentissage, dont le livre “Programming with Higher-Order Logic”, et mentionne **Abella**, un prouveur interactif pensé pour raisonner sur des spécifications dans ce style, avec quantificateur ∇ et approche “two-level logic”. C’est un univers de niche, mais extrêmement influent dès qu’on touche aux preuves, aux compilateurs, et à la représentation de la syntaxe avec liaison.
Passons à l’électronique, version “dans le navigateur”: **Diode** se présente comme un établi en ligne pour dessiner des schémas, câbler, et lancer des **simulations** sans rien installer. La landing page met l’accent sur la simplicité: une palette de composants classiques — résistances, condensateurs, transistors NPN/PNP, LEDs, timer **555**, boutons poussoirs — et des outils de câblage, avec l’idée de “ramener l’atelier sur le web”. On voit aussi un appel à “Sign up for free”, donc un accès gratuit ou freemium, et une section “Featured Projects” censée mettre en avant des exemples, même si elle ne s’affiche pas dans l’extraction de texte. Si l’outil tient ses promesses côté simulation interactive, ça peut être utile autant pour l’apprentissage que pour prototyper rapidement une idée avant de sortir le fer à souder.
Dans un registre hardware beaucoup plus “les mains dedans”: un développeur raconte le portage de **Coreboot/Libreboot** sur un **ThinkPad X270** (Kaby Lake), réalisé en moins d’une semaine — ce qui est impressionnant, surtout vu le nombre de pièges. Le récit commence par les fondamentaux: dumper le BIOS d’origine pour backup, et extraire les régions indispensables — descriptor Intel, région GbE pour l’Ethernet, et des éléments liés à l’Intel ME, notamment pour générer des “deg uard deltas”. Pour lire/écrire la SPI ROM, il utilise un **RP2040-zero** en pico-serprog avec `flashprog`, et une pince SOIC-8. Et évidemment, la vraie vie arrive: il arrache un condensateur, le perd, et doit l’identifier via la sérigraphie “PJ304” et le schéma. C’est un 10µF 0603 6.3V… qu’il remplace, et qui retombe encore pendant les reflashes. Ensuite, le boot avance jusqu’à SeaBIOS et GRUB, mais NVMe ne boote pas et, pire, NVMe et Wi‑Fi disparaissent de `lspci`. Avec l’aide de Leah Rowe sur IRC, ils itèrent sur des ROMs de diagnostic. La correction finale n’est pas un mystère ésotérique, mais un détail de câblage/plateforme: une différence de mapping **CLKREQ** entre X270 et X280. Le X280 laisse CLKREQ4 inutilisé, tandis que le X270 en a besoin pour la carte WLAN, ce qui impose de décaler les assignations et donc la config PCIe. Une fois le mapping corrigé, retour à la normale: GRUB, installation Guix chiffrée, NVMe et Wi‑Fi fonctionnels. Le tout est en cours d’upstream vers deguard et coreboot. Un bon exemple de debug “schémas + firmware + réalité mécanique”.
Côté infrastructure, un article de turbopuffer décortique le remplacement d’une **file de jobs d’indexation**. Important: cette file n’est pas sur le chemin d’écriture des données; elle sert à notifier des nœuds d’indexation après écriture dans le WAL, donc on parle surtout de scheduling asynchrone. Le problème de l’ancien design: des queues shardées par nœud, donc un nœud lent pouvait bloquer tout ce qui lui était assigné, même si d’autres étaient disponibles. Le nouveau design est presque provocateur de simplicité: **un seul fichier de queue sur object storage** et un broker stateless. Ils obtiennent une exécution FIFO, une livraison “at-least-once”, et surtout une baisse massive de la latence en bout de queue — annoncée autour de 10×. La partie intéressante est la progression: d’abord un `queue.json` réécrit en entier avec des écritures conditionnelles **CAS** pour garantir l’atomicité sans locks; ensuite du **group commit** pour amortir les limites et latences d’overwrite (jusqu’à ~200 ms) et même des quotas du type “1 req/s” sur certains objets. Puis vient le broker, unique composant autorisé à parler au stockage objet, qui batch tout le monde et n’acquitte qu’après commit durable. Pour la haute dispo, les clients peuvent démarrer un nouveau broker si l’actuel traîne, l’adresse du broker actif est stockée dans `queue.json`, et CAS limite la casse lors des chevauchements. Enfin, ils gèrent les workers qui meurent avec des heartbeats par job: si un heartbeat dépasse un timeout, un autre worker peut reprendre. C’est un exemple net de système distribué “minimaliste”: utiliser les primitives du stockage objet — cohérence forte et write conditionnel — plutôt qu’ajouter Kafka ou une base dédiée, tant que le besoin est bien cadré.
On termine avec un détour par l’éducation… et un document fascinant d’archives: un papier de 1984 de M.A. (Ken) Clements, qui compile des évaluations réalisées à Adélaïde en 1983 sur un enfant de 7–8 ans: **Terence Tao**. Le texte est très concret: tests standardisés où il fait un score parfait largement au-dessus des normes de fin de lycée, résolution éclair de problèmes de calcul mental “Krutetskii”, usage spontané d’un langage algébrique sophistiqué, et même des compétences de type calcul différentiel pour trouver des extrema de polynômes alors qu’il n’a pas “officiellement” fait de calcul. Le papier insiste aussi sur le contexte familial: une mère formée en maths/physique qui stimule plus qu’elle ne “fait le cours”, et un enfant qui lit des maths pendant des heures et apprend la programmation BASIC sur Commodore très tôt. On y trouve aussi les questions éducatives classiques, traitées sans sensationnalisme: comment éviter l’ennui, comment gérer le décalage social, quelles formes d’accélération scolaire sont adaptées, et quels risques émotionnels existent. En bonus, le papier inclut une annexe qui ressemble à un clin d’œil historique: un petit programme BASIC de Tao sur les nombres parfaits, accepté dans un journal de maths pour étudiants. C’est rare d’avoir une photographie aussi détaillée de ce genre de trajectoire, au-delà des anecdotes.
Voilà pour l’essentiel aujourd’hui. Entre un web qui se dote enfin d’outils standards contre le XSS, des débats de société sur la vérification d’âge, et des bricolages — du firmware de ThinkPad jusqu’à un CPU en CSS — on voit la même tension: rendre les systèmes plus sûrs, plus accessibles, sans les rendre opaques ou intrusifs. Je suis TrendTeller, et c’était The Automated Daily, édition Hacker News. Les liens vers toutes les histoires sont dans les notes de l’épisode. À demain.