Faille critique preuves zero-knowledge & Standard DO_NOT_TRACK pour télémetrie - Actualités Hacker News (3 mai 2026)

Sécurité d’abord, avec un cas d’école côté zero-knowledge. Des chercheurs ont révélé une faille critique dans le vérificateur dusk-plonk, utilisé pour sécuriser des transactions “shielded” sur Dusk Network. Le problème, c’est que le vérificateur acceptait certaines valeurs fournies par le prouveur sans les rattacher cryptographiquement aux engagements attendus. En clair: un attaquant pouvait fabriquer une preuve qui “passe” tout en contournant les contraintes du circuit. Pourquoi c’est important? Parce que sur un réseau vivant, ça peut vouloir dire: créer des fonds à partir de rien, ou valider des dépenses frauduleuses, et la couche de confidentialité rend ensuite l’anomalie plus difficile à repérer. L’équipe a même montré un proof-of-concept sur testnet local en créant et transférant des tokens comme si de rien n’était. Le correctif est sorti, mais la leçon dépasse Dusk: il faut des garde-fous mécaniques, standardisés, pour éviter ces évaluations non liées dans les implémentations ZK.

Dans un registre plus “privacy-by-default”, une proposition simple circule: DO_NOT_TRACK. L’idée est de standardiser un signal unique — une variable d’environnement, DO_NOT_TRACK=1 — que les outils de dev, SDK et frameworks pourraient respecter pour désactiver la télémétrie et autres requêtes non essentielles. Ce qui rend ça intéressant, ce n’est pas la technique: c’est l’ergonomie et la cohérence. Aujourd’hui, chaque outil a son propre switch, sa doc, son comportement, et ça crée un consentement confus. Si ce standard prenait, on aurait un bouton “stop” universel, lisible et automatisable, notamment en CI ou dans des environnements sensibles. Et au passage, le texte pousse aussi une idée plus saine: déplacer la télémétrie de l’opt-out vers l’opt-in.

On enchaîne avec un retour d’expérience rare sur la fiabilité logicielle à grande échelle: chez Mercury, une fintech, une base de code Haskell d’environ deux millions de lignes tourne en production… en manipulant de l’argent réel, et avec des ingénieurs qui apprennent souvent Haskell sur le tas. Le point central n’est pas “Haskell est magique”, mais une philosophie très opérationnelle: la fiabilité vient moins de l’obsession d’empêcher toute panne que de la “capacité d’adaptation”. En pratique, concevoir des systèmes qui se dégradent proprement, restent compréhensibles sous stress, et rendent la voie sûre la plus naturelle. Et là, le typage devient un outil d’exploitation: on encode des procédures critiques dans les interfaces, pour éviter qu’un geste dangereux — comme oublier d’émettre un événement transactionnel — puisse arriver “par accident”. Mais l’auteur met aussi en garde: trop d’invariants dans les types peut rigidifier l’ensemble et ralentir l’équipe. Autre point marquant: l’adoption de Temporal pour les workflows durables, afin de gérer retries, timeouts et récupération après crash de manière cohérente. Et côté observabilité, il insiste sur des patterns pragmatiques: points d’instrumentation explicites, injection de fonctions plutôt que logs incontrôlables, bref, penser production avant élégance.

Passons aux navigateurs: Ladybird, le projet de navigateur indépendant, a publié un point d’avancement très dense pour avril 2026. Beaucoup de contributions, et surtout des améliorations visibles. La plus “grand public”, c’est un lecteur PDF intégré basé sur pdf.js, avec du travail de performance parce que les gros PDF sont un vrai crash-test pour un moteur. On a aussi un historique mieux structuré, de l’autocomplétion dans la barre d’adresse plus intelligente, et une base SQLite pour stocker tout ça avec des contrôles côté interface. Sous le capot, c’est tout aussi intéressant: parsing HTML plus opportuniste pour démarrer plus tôt, compilation JavaScript hors thread principal, rendu plus réactif avec du travail réparti, et des optimisations GPU sous Linux pour éviter des allers-retours coûteux. Ce qui compte ici, c’est le signal: Ladybird se rapproche d’un navigateur utilisable au quotidien, avec des progrès mesurables en conformance et en perf — et ça diversifie un marché où les moteurs réellement indépendants sont rares.

Côté IA créative, un projet open-source attire l’attention: ml-sharp-web. C’est un “playground” dans le navigateur qui génère des Gaussian splats 3D à partir d’une seule image, en s’appuyant sur le modèle SHARP d’Apple. Pourquoi ça mérite un détour? Parce que ça montre une exécution end-to-end côté client: inférence via ONNX Runtime Web dans un worker, prévisualisation, puis export. Et surtout, le dépôt documente les obstacles réels qu’on rencontre quand on veut faire de l’IA lourde dans un navigateur: contraintes de la plateforme, besoin de cross-origin isolation pour certaines optimisations, et un détail très concret de déploiement — les poids du modèle qui ne se “bundlent” pas gentiment comme une librairie JavaScript classique. Dernier point, trop souvent ignoré: la licence. Le code peut être open-source, mais les poids du modèle peuvent rester soumis à des conditions séparées et restrictives. Ici, le projet sert aussi de rappel: l’IA, c’est autant du juridique que du technique.

On regarde maintenant Windows 11, version Insider. Microsoft dit avoir fait des ajustements de “qualité” depuis mars, notamment sur la transparence et la lisibilité de ce qui passe — ou non — de la preview à la version stable. Le changement le plus structurant, c’est la simplification en deux canaux: Experimental et Beta. Le message derrière, c’est de réduire la frustration habituelle des tests: dans Beta, moins de déploiements fragmentés, donc si une fonctionnalité est annoncée, elle apparaît pour tous ceux qui mettent à jour. Dans Experimental, plus de contrôle via des flags, et la possibilité de bouger plus facilement d’un canal à l’autre. Autre thème: moins de perturbations côté mises à jour, avec l’objectif de regrouper davantage de redémarrages. Et Microsoft “réajuste” aussi l’intégration AI: certaines entrées Copilot disparaissent ou sont renommées pour être moins omniprésentes. Enfin, File Explorer, Widgets et le système de découverte promettent d’être plus sobres par défaut, avec des gains de performance et de réactivité. En somme, une tentative de remettre un peu de discipline produit dans un cycle de preview souvent jugé bruyant.

En sciences, une étude de Stanford Medicine rappelle une vérité contre-intuitive: faire la moyenne des cerveaux peut vous raconter une histoire… qui est fausse pour presque tout le monde. Les chercheurs ont analysé des données fMRI de plus de 4 000 enfants de 9 à 10 ans pendant une tâche de contrôle inhibiteur, et ont comparé les résultats “moyenne de groupe” à des analyses au niveau individuel, essai par essai. Résultat marquant: certaines corrélations s’inversent. Un lien observé au niveau du groupe peut ne pas exister, ou même pointer dans l’autre sens, chez un enfant donné. Et en regardant individuellement, ils identifient des sous-groupes avec des stratégies et des signatures neuronales différentes, qui se neutralisent quand on moyenne tout. Pourquoi ça compte? Parce que pour des sujets comme l’ADHD ou, plus largement, la psychiatrie, ça renforce l’idée qu’il n’y a pas un seul chemin “neural” vers une difficulté: il y a plusieurs profils. Et donc, potentiellement, plusieurs types d’interventions à personnaliser plutôt qu’un diagnostic unique basé sur des statistiques globales.

Et pour finir, un détour archéologie qui vaut le coup. Une étude dans Science Advances rapporte que des Néandertaliens, sur le site de Neumark-Nord 2 en Allemagne, rendaient de la graisse à partir d’os il y a environ 125 000 ans. On savait qu’ils cassaient des os pour la moelle. Là, on parle d’une étape au-dessus: des os volontairement réduits en une multitude de fragments, chauffés dans l’eau pour extraire le gras — une ressource dense en énergie. Le site, au bord d’un lac, semble avoir été choisi comme zone de traitement centralisée, avec des restes provenant de nombreux animaux et des indices d’activité répétée et coordonnée. Ce que ça change? Ça pousse encore l’image de Néandertal vers plus de planification, de logistique et de gestion des ressources à l’échelle d’un paysage. Et ça rappelle qu’innovation “technique” ne veut pas toujours dire outils sophistiqués: parfois, c’est l’organisation et la stratégie qui font la différence.