Hacker News
-
Android 17 is the first since 3.x to add new APIs without releasing to the AOSP
Selon le titre, Android 17 serait la première version depuis Android 3.x à introduire de nouvelles API sans être publiée dans l'AOSP (Android Open Source Project). Aucun contenu supplémentaire n'est disponible au-delà du titre.
La discussion confirme et précise l'article : Android 17 QPR1 introduit des APIs exclusives aux Pixel, du fait que depuis Android 16 les versions QPR1 et QPR3 ne sont plus publiées dans l'AOSP. Plusieurs commentateurs corrigeant l'article nuancent le titre : ces APIs resteront open source et seront accessibles aux autres OEM via le QPR2 de décembre 2026 ; c'est donc le calendrier et la structure des releases qui changent, pas la nature des APIs — une première depuis Android 3.x, ce que le titre reflète quand même fidèlement. Le vrai point de friction soulevé concerne aussi les correctifs de sécurité des releases trimestrielles, longtemps réservés aux « OEM de confiance », que GrapheneOS recevait déjà.
Le sentiment dominant est celui d'une érosion délibérée de l'ouverture d'Android : Google dégraderait l'AOSP en simple base de code, à l'image de macOS/Darwin, en gardant l'essentiel de la valeur dans Play Services et les mises à jour Pixel. GrapheneOS apparaît à la fois comme la principale victime et la principale alternative crédible, ses utilisateurs témoignant de retours positifs (dont la correction rapide d'un souci de firmware modem en quelques heures). Un commentateur note que dégoogliser exige... un téléphone Google (Pixel), l'ironie étant assumée ; un membre du projet rappelle qu'aucune backdoor matérielle n'a jamais été observée sur ces appareils. D'autres estiment qu'Android sans Play Services reste peu utilisable en Occident et qu'un « Steam Phone » ou des alternatives ne suffiraient pas sans écosystème applicatif.
Les points de division : certains appellent à une régulation (rappelant l'affaire antitrust récemment gagnée par Google), d'autres y voient une impasse ; un avis minoritaire critique GrapheneOS pour son orientation sécurité maximale qui « sécurise contre son propriétaire », auquel on répond que le modèle de sécurité mobile est un choix fondamental, pas une trahison. Enfin, des listes concrètes d'alternatives émergent : SailfishOS (le plus utilisable, soutenu par Jolla), postmarketOS, Plasma Mobile, Ubuntu Touch, Volla, FuriLabs — toutes jugées encore loin derrière Android en maturité.
-
Microsoft exec called AI scraping 'the largest theft of labor in human history'
Des documents déclassifiés dans le procès en droit d'auteur que le New York Times mène contre OpenAI et Microsoft révèlent des admissions internes accablantes : un dirigeant de Microsoft a qualifié le scraping par l'IA de « plus grand vol de travail de l'histoire humaine », et la direction d'OpenAI a reconnu que ses modèles constituaient une « menace existentielle » pour les éditeurs et journalistes dont les œuvres ont servi à l'entraînement.
Les éléments non censurés décrivent notamment la collecte de contenus en contournant les paywalls sans détection, la constitution de jeux de données par scraping massif et le retrait délibéré des mentions de copyright. OpenAI aurait aussi récupéré des contenus via l'index de Bing, avec des projets internes baptisés « Project Taxi » et « Project Mango » regroupant au moins 160 903 œuvres uniques des plaignants. Leurs datasets contiennent plus de 91 692 copies d'œuvres du NYT, du Daily News et du Center for Investigative Reporting, et plus de 2 millions de documents de nytimes.com via Common Crawl.
Ces aveux fragilisent la défense du « fair use » avancée par OpenAI, notamment l'exigence que l'usage ne remplace pas le marché original : les données de Microsoft montrent que Copilot faisait chuter le taux de clics vers le NYT jusqu'à 93 % par rapport à Bing.
La discussion débat de la formule d'un cadre de Microsoft qualifiant le scraping par l'IA de « plus grand vol de travail de l'humanité ». Le clivage principal oppose ceux qui dénoncent une appropriation massive du travail créatif sans compensation ni consentement, et ceux qui refusent l'assimilation au « vol » : pour ces derniers, l'entraînement n'est pas de la reproduction à l'identique, s'apparente à une lecture, relève de la contrefaçon de copyright plutôt que du vol — un commentateur rappelle d'ailleurs que TechCrunch, média de l'article, soutenait l'inverse à l'époque du piratage musical. Plusieurs notent l'ironie que ce soit Microsoft, historiquement hostile au logiciel libre, qui tienne ce discours, et y voient une manœuvre de Microsoft pour se distancer d'OpenAI dont les preuves d'entraînement sur du contenu protégé seraient accablantes.
Des propositions concrètes émergent : un régime de licences obligatoires avec redevance mécanique par défaut, la publication des jeux de données, ou l'ouverture forcée des modèles ne prouvant pas l'absence de contenu sous droits. Un commentateur pointe le cas spécifique du code copyleft : des modèles entraînés sur du code GPL pourraient devoir être publiés sous la même licence, en citant une estimation du coût de développement du noyau Linux à 1,4 milliard de dollars. D'autres soulignent l'hypothèse selon laquelle le principal bénéfice commercial des LLM serait de contourner les licences copyleft.
Plusieurs commentateurs critiquent le choix des mots de l'article : la traite transatlantique et l'esclavage, qui n'ont jamais cessé selon l'un d'eux, constituent des « vols de travail » bien plus graves, signe de l'égocentrisme de l'industrie tech. Le parallèle humain/IA nourrit aussi le désaccord : pour les uns, apprendre en lisant et entraîner un modèle sont incommensurables car un modèle est copiable à l'infini et remplace la demande adressée aux créateurs ; pour les autres, LLM et humain synthétisent de la même façon leurs solutions.
-
Cloudflare Quick Tunnels
Cloudflare présente Quick Tunnels, une fonctionnalité de cloudflared qui permet d'exposer un serveur local sur Internet en une seule commande, sans création de compte, sans configuration DNS ni certificats. L'URL trycloudflare.com générée passe par le réseau edge de Cloudflare, avec HTTPS automatique, protection DDoS et aucun port exposé sur la machine. L'outil s'adresse aux développeurs voulant partager rapidement des aperçus de leurs applications en cours de développement.
La discussion tourne autour de Quick Tunnels de Cloudflare, une variante « sans compte » de son produit de tunneling existant. Plusieurs commentateurs signalent d'emblée que la fonctionnalité n'est pas nouvelle : ce type de tunnel existe depuis des années chez Cloudflare, et certains se demandent si la nouveauté se limite à une nouvelle page marketing. La documentation officielle confirme d'ailleurs que ces tunnels gratuits sont destinés aux tests et démos, pas à la production, et qu'ils sont limités à 200 requêtes simultanées (erreur 429 au-delà), sans support des Server-Sent Events ; les tunnels classiques plafonnent aussi à 100 Mo par requête, ce qui casse des usages comme Immich.
-
I don't like passkeys
L'auteur critique la promotion agressive des passkeys par Google, Microsoft et Apple, présentées comme la solution ultime à la connexion. S'il reconnaît leurs atouts (résistance au phishing, asymétrie empêchant l'exploitation des fuites de données), il estime qu'elles conviennent aux environnements d'entreprise mais pas aux particuliers, dont le risque principal est la perte permanente d'accès aux comptes : bannissement automatisé, perte de l'appareil, méthodes de récupération faibles.
Les clés matérielles sont onéreuses (2-3 clés à enrôler partout) et limitées à 25-300 comptes. Les passkeys synchronisées d'Apple et Google ancrent l'identité à leurs écosystèmes, avec un risque de tout perdre en cas de bannissement ; l'interopérabilité et l'export restent immatures. Les gestionnaires de mots de passe tiers (Bitwarden, KeePassXC) se heurtent à des APIs et une UX encore fragmentées. Les usages multi-appareils via QR code et Bluetooth souffrent de nombreux cas d'échec.
L'auteur conclut que pour un utilisateur qui ne réutilise pas ses mots de passe, un gestionnaire tiers combiné à une app TOTP indépendante reste plus flexible et moins risqué au quotidien ; les passkeys ne sont prêtes que pour l'entreprise.
La discussion reflète le débat de l'article : les passkeys déçoivent une partie des utilisateurs techniques, mais pas tous. Plusieurs commentateurs partagent les griefs de l'auteur : multiplication des invites incohérentes (navigateur, OS, gestionnaire de mots de passe) qui rend l'expérience « user-hostile », complexité O(m*n) d'enregistrement sur plusieurs appareils, cas d'usage non couverts (ordinateur emprunté, téléphone volé ou noyé), et risque de création accidentelle de passkey en cliquant sur des pop-ups. Un avis minoritaire juge au contraire les passkeys « grotesquement insecure » car le risque de lockout dépasse celui du phishing — position fortement contestée en réponse : le lockout n'est pas un manque de sécurité, et les passkeys liées au domaine, stockées dans un secure enclave, surpassent un mot de passe statique et un TOTP phishable.
Les points d'accord incluent le mauvais support des gestionnaires tiers (Bitwarden, 1Password) : Amazon relance des créations de passkey même après connexion via passkey, et la confusion sur la sécurité des clés synchronisées dans un coffre partagé versus « ne quitte jamais l'appareil ». Plusieurs soulignent aussi le risque de verrouillage écosystémique : la fonction d'attestation de la norme pourrait permettre à Google ou Apple d'exiger à terme des clés attestées sur appareil non rooté. Une comparaison avec IPv6 suggère une « solution » poussée par l'offre sans étude des utilisateurs réels ; en réponse, on nuance que les passkeys fonctionnent bien en entreprise, où le propriétaire du compte n'est pas l'utilisateur.
Des voix discordantes remettent en cause la thèse de l'article : plusieurs trouvent les passkeys un net gain de confort, notant que presque tous les sites les proposent en complément (pas en remplacement) du mot de passe, et que la synchronisation iCloud/Google limite le risque de lockout. Une correction factuelle précise que la liaison au domaine protège mieux du phishing que les gestionnaires, dont le remplissage automatique tolère des préfixes de domaine trompeurs. Un commentateur note aussi l'ironie qu'Apple, pourtant accusé d'enfermement, est celui qui permet d'exporter les passkeys.
-
Claude Code now reads AGENTS.md if there is no Claude.md
Notes de version de Claude Code détaillant une longue liste de changements. La principale nouveauté : Claude Code lit désormais un fichier AGENTS.md dans les projets ne comportant pas de CLAUDE.md, avec modification possible via « Project instructions » dans /config (pas encore disponible sur Bedrock, Vertex ou Foundry).
Le reste de la mise à jour corrige de très nombreux bugs : sessions headless ou SDK qui pendent après une erreur interne, crashs liés à des valeurs malformées dans ~/.claude.json, échecs de lecture PDF sur Windows avec des chemins longs, pertes de prompt-cache après /clear ou re-rendu d'attachments, comportements erronés des outils Edit/Write/Grep/Glob, fuites de téléchargements d'auto-update, diverses corrections sur les plugins, les gateway Claude apps (proxy, en-têtes statiques, variable CLAUDE_GATEWAY_PROXY_IS_EGRESS_BOUNDARY) et des améliorations de démarrage des sessions SDK (la première tourne ne bloque plus sur la recherche de CLAUDE.md).
La communauté accueil avec ironie l'annonce que Claude Code lit désormais AGENTS.md en l'absence de CLAUDE.md : plusieurs commentateurs estiment qu'il s'agit du « strict minimum » et non d'une avancée à célébrer, Anthropic ayant mis plus d'un an et demi à adopter un standard de facto promu par Codex. Beaucoup y voient une décision dictée par la pression du marché plutôt que par la bienveillance envers les développeurs, en citant le menace de Tobi Lütke d'interdire Claude Code chez Shopify. Un contrepoint intéressant soutient toutefois qu'il est peut-être trop tôt pour imposer un standard unique : des instructions adaptées à chaque modèle seraient plus efficaces qu'un fichier générique commun.
Plusieurs praticiens partagent leurs contournements désormais obsolètes : symlinks CLAUDE.md vers AGENTS.md, scripts de synchronisation entre AGENTS.md, CLAUDE.md et GEMINI.md, ou CLAUDE.md contenant simplement « @AGENTS.md ». Des anecdotes montrent que les agents eux-mêmes anticipaient parfois ce comportement (Claude créant spontanément un AGENTS.md avec un symlink), ou réagissaient avec humour aux fichiers mal nommés. Plusieurs rappellent que le support reste incomplet : Claude Code ne détecte ni les skills dans .agents/skills ni ~/.agents/skills, et ne lit pas copilot.md.
La discussion corrige aussi l'image d'un Anthropic aligné sur les standards : un commentateur détaillé signale que Claude Code privilégie settings.json sur CLAUDE.md et applique des défauts implicites qui ignorent carrément les directives de l'utilisateur (exemple concret : une instruction « ne pas ajouter 'Made with Claude Code' » dans CLAUDE.md étant contournée par un défaut non documenté). D'autres plaintes portent sur le plugin VS Code qui pollue le contexte. Enfin, le débat sur la standardisation divise : entre ceux qui plaident pour une norme à la AGENTS.md et ceux qui craignent l'apparition d'« un standard de plus » (référence XKCD), en comparant AGENTS.md à l'autoexec.bat.
-
OpenJev
Une expérience web interactive locale baptisée OpenJev permet de comparer deux façons d'obtenir les probabilités de choix d'un petit modèle de langage exécuté directement dans le navigateur sur son propre GPU. La première méthode lit directement les logits du modèle et les normalise uniquement sur les options fournies (softmax restreint aux tokens affichés), tandis que la seconde demande au modèle de générer la même distribution sous forme de JSON, token par token.
L'utilisateur peut choisir entre plusieurs modèles locaux : Qwen3 0.6B pour les appareils modestes comme les téléphones, MiniCPM 2B par défaut sur desktop, et une option 4B nécessitant plus de mémoire. Les poids proviennent de Hugging Face via des builds GGUF quantifiés exécutés avec wllama, et restent dans le cache du navigateur sans qu'aucune donnée ne quitte la page.
L'interface mesure les temps réels de chaque étape (chargement, warmup, exécution directe, génération) avec performance.now(), et affiche des métriques de précision équilibrée, comparées aux valeurs publiées d'un projet nommé Jev sur un sous-ensemble public de 102 lignes. L'article précise que la quantification peut affecter la précision et que les scores directs ne constituent pas des confiances calibrées.
La discussion porte sur OpenJev, une reproduction open source de l'interface de Jev (service fermé de TypeSafe pour des décisions sémantiques avec scores de confiance). Plusieurs commentateurs soulignent une nuance essentielle qui tempère l'article : OpenJev n'est pas Jev — c'est un simple LLM classique derrière la même API, sans le modèle ni l'entraînement spécifique de Jev, dont la vraie contribution serait le modèle lui-même. D'autres expliquent l'intérêt du concept : des questions traitées en parallèle plutôt que séquentiellement, donc plus rapide et moins cher que du « structured output » classique, avec l'assurance de ne générer aucun token, ce qui permet de piloter des machines à états. Des rapprochements sont faits avec les modèles encodeurs type BERT ou le parsing GLiNER, certains estimant que l'idée n'est pas nouvelle mais que la valeur réside dans le modèle fine-tuné et le runtime optimisé.
Des tests pratiques tempèrent l'enthousiasme : un testeur compare les lectures directes de probabilités et la génération sur des questions pièges (traverser une autoroute déserte, lancer un dé), obtenant des résultats incohérents d'un modèle à l'autre et concluant qu'on obtient parfois « une pièce de pièce plus vite ». Un utilisateur ayant testé le « vrai » Jev rapporte 84 % de probabilité avec 83 % de confiance en 62 ms, et signale que ses conditions d'utilisation interdisent explicitement de publier des benchmarks — une clause qu'il juge unique dans l'IA et de style « Oracle », laissant penser que le service est hautement réplicable. Un praticien mentionne un patch vLLM sur DiffusionGemma reproduisant des chiffres de latence similaires sur DGX Spark, tout en s'interrogeant sur l'indépendance des réponses via le KV cache partagé.
À noter enfin : TypeSafe propose un adaptateur pour utiliser des LLM classiques via l'interface Jev, le fondateur se positionne comme une entreprise de « data », et plusieurs remarques hors sujet critiquent le site web généré par IA (bugs signalés : README 404, problème de téléchargement sur iPad Pro, demande de reprise de téléchargement partiel).
-
US Military had close call after using AI for hallucinated intelligence report
Au printemps, en pleine guerre avec l'Iran, l'armée américaine a failli intercepter un navire chinois soupçonné de transporter des composants d'un programme d'armes nucléaires, sur la foi d'un rapport du renseignement généré avec l'aide d'une IA. Des militaires armés se préparaient à monter à bord, des avions étaient en l'air, avant que des responsables ne découvrent que le chatbot avait incorrectement identifié la cargaison — le rapport était «entièrement faux» et, selon une source, «a failli déclencher une guerre».
L'analyste, du commandement des opérations spéciales, avait interrogé un chatbot sur des données provenant de sources ouvertes et de renseignements d'origines diverses, puis utilisé l'IA pour formater le tout en rapport officiel. L'incident illustre les risques de l'adoption rapide et décentralisée de l'IA par le Pentagone, qui a lancé en janvier une stratégie d'accélération sous Pete Hegseth sans standards uniformes de vérification. Des sources signalent d'autres «hallucinations» dans la communauté du renseignement et s'inquiètent de l'usage de l'IA pour le ciblage militaire, sans réelle encadrement du «human in the loop» pour éviter victimes civiles ou tirs fratricides.
La discussion converge sur un alarmisme partagé : le risque n'est pas une superintelligence hostile, mais l'usage inadapté d'outils produisant des erreurs dans des contextes à enjeux vitaux. Plusieurs commentateurs estiment que l'incident illustre la dangerosité du remplacement du jugement humain par des sorties de LLM, et rappellent des précédents historiques : les fausses alertes nucléaires (Stanislav Petrov en 1983, le film WarGames), ou les « renseignements » fabriqués ayant justifié la guerre en Irak. Pour plusieurs, l'IA s'inscrit dans une continuité : l'appareil militaro-renseignement américain a toujours construit les justifications que le politique attendait, et l'IA rend ce biais plus difficile à détecter car le produit paraît plus crédible et son raisonnement opaque.
La question de la responsabilité divise : certains insistent sur le fait que ce sont les personnes, pas l'IA, qui doivent en répondre, et proposent des garde-fous concrets (exiger les traces de raisonnement, la traçabilité des sources, garder l'humain dans la boucle de décision). Un autre courant souligne la pression institutionnelle : un analyste qui remet un rapport à l'heure est récompensé, celui qui doute est sanctionné, ce qui pousse à appuyer sur le bouton « générer un rapport » plutôt que d'assumer l'incertitude. Un commentateur nuance toutefois que les opérateurs concernés sont parfois des soldats très jeunes, pas des experts aguerris, et un autre observe que les hallucinations deviennent plus subtiles et plus dures à détecter.
Quelques voix émettent des doutes sur le récit lui-même : l'un demande si les frappes sur une école en Iran ont réellement été guidées par l'IA (le fait est cité de façon contestée dans le fil), et un autre se demande si cette « fuite » embarrassante n'est pas en réalité une démonstration volontaire de capacité visant à dissuader la Chine de partager du nucléaire avec l'Iran — hypothèse aussitôt contestée par un participant qui rappelle la politique chinoise historique de non-prolifération. Des références concrètes circulent : les simulations montrant des LLM déclenchant des escalades nucléaires, l'incident d'un navire chinois faussement suspecté.
-
Hacking OpenAI
L'équipe Hacktron décrit le chainage de deux vulnérabilités ayant permis, le 25 juillet 2026, de prendre le contrôle de comptes ChatGPT/Codex d'employés d'OpenAI via le forum communautaire community.openai.com.
La première faille est un dépassement de tas (heap buffer overflow) dans libheif, exposé par le pipeline d'upload d'images de Discourse : les fichiers HEIC/HEIF étaient transmis à ImageMagick faute de support dans FastImage, atteignant directement le parseur libheif. Le correctif amont, fusionné l'année précédente, n'avait pas été documenté comme correctif de sécurité (pas de CVE), si bien que Debian 12 et 13 livraient encore des versions vulnérables (1.19.7 et 1.19.8). L'équipe a utilisé les modèles Claude (Opus 4.8, puis Opus 5) pour analyser le paquet, développer un exploit avec exécution de code arbitraire et le rendre fiable contre Discourse Cloud, jusqu'à obtenir une RCE sur l'instance d'OpenAI.
La seconde faille est une mauvaise configuration SSO côté OpenAI (auth.openai.com) qui transformait la compromission du forum en prise de contrôle de comptes ChatGPT/Codex. Les chercheurs ont prouvé l'impact en demandant au Codex d'un employé d'ouvrir une pull request dans le monorepo interne, sans accéder à de code sensible.
La discussion revient sur la chaîne d'exploitation décrite dans l'article : un bug de traitement d'image (libheif, via ImageMagick) dans Discourse a permis une RCE, puis une escalade jusqu'au dépôt GitHub interne d'OpenAI via un compte employé. Plusieurs commentateurs saluent la qualité de la chaîne mais surtout la capacité de Claude à la construire : un participant détaille que le modèle refusait d'écrire des exploits pour des cibles distantes, et que l'équipe a contourné ce refus en présentant sa propre instance comme une cible de CTF, en boucle autonome — l'attaque est donc passée quand le modèle a cru jouer un jeu sans autre but que de gagner. Cela alimente l'inquiétude de plusieurs avis sur des systèmes trop orientés objectif.
Trois points font consensus. D'abord, la surface d'attaque des décodeurs d'images est jugée aberrante : libheif cumule les CVE critiques, ImageMagick est décrit comme un cauchemar de sécurité, et plusieurs préconisent des alternatives plus sûres (libvips, GraphicsMagick, voire des parseurs comme wuffs) ou un sandboxing systématique. Discourse confirme en commentaire qu'ils utilisent désormais un sandbox landlock pour tous les binaires externes et migrent de Magick vers Vips, tout en prévenant que d'autres failles suivront et que l'auto-hébergement exige des mises à jour hebdomadaires vu le rythme des CVE. Ensuite, la dépendance à des dépendances C non sûres est critiquée, avec des appels à Rust ou à du code moins volumineux. Enfin, le détail de la correction non documentée comme correctif de sécurité (sans CVE) explique selon les commentateurs les retards de backport sous Debian, illustrant la difficulté de maintenir les paquets à jour.
Les avis divergent sur deux points. La prime de 6 500 $ est jugée risible par beaucoup, vu la valeur potentielle de l'accès au monorepo (chiffre d'un avis : 6,5 millions sur le marché noir), même si un avis contraire estime qu'il n'existe pratiquement pas de tel marché noir.
-
Saving another 100TB of RAM
Cloudflare détaille l'optimisation d'un algorithme de hachage cohérent (pingora-ketama, utilisé par son Pingora Backend Router) qui a permis de libérer plus de 100 To de RAM au total sur ses milliers de serveurs, en plus des 100 To récupérés le mois précédent par l'équipe DNS.
L'article explique le fonctionnement du hachage cohérent, utilisé pour router les requêtes cachables vers les serveurs par URL afin de ne conserver qu'une copie de chaque fichier par data center. Il décrit le problème de déséquilibre statistique de la répartition des plages de hachage (coefficient de variation élevé) et la solution classique consistant à multiplier les points de hachage par serveur (160 par défaut, comme dans NGINX), ainsi que l'algorithme ketama pour pondérer la charge selon l'espace disque disponible.
Des modifications algorithmiques en Rust sur les structures de données ont suffi à réduire significativement l'empreinte mémoire du service, illustrant comment de petites améliorations sont décuplées à l'échelle de l'infrastructure mondiale de Cloudflare (pétaoctets de RAM, millions de cœurs CPU).
Les commentateurs saluent la qualité technique du billet Cloudflare et la présence d'une équipe de performance dédiée, tout en soulignant un débat de fond : ces 100 To économisés ne représentent qu'une amélioration marginale à l'échelle du parc, et plusieurs se demandent si l'effort en vaut la peine pour la plupart des systèmes. Un avis nuancé rappelle que l'optimisation systématique a disparu quand la RAM est devenue abondante, et que son retour forcé (via la hausse des prix) est plutôt bienvenu ; un autre praticien répond que ces contraintes d'antan le laissaient indifférent, l'essentiel étant de livrer du produit. Des remarques ironiques évoquent que Cloudflare a peut-être cherché « sous les tapis » de quelques centaines de To pour financer l'inférence IA — immédiatement corrigé par un commentaire technique : la RAM CPU est inadaptée à l'inférence, qui requiert de la bande passante plutôt que de la capacité, d'où l'intérêt de la VRAM GPU.
Sur le plan technique, un commentateur propose une alternative au consistent hashing/ketama : partitionner les serveurs (128 par partition), précalculer des hashes de qualité (SHA-256 tronqué) et utiliser un « tournament hash » avec wymum, ce qui économiserait selon lui 600 TiB supplémentaires et réduirait la latence par rapport aux 160 hashes par clé. Une réponse corrige son analyse : Cloudflare ne fait qu'un hash par requête, les 160 hashes étant calculés par serveur pour partitionner l'espace de hashage. D'autres regretlent l'absence du hierarchical rendezvous hashing, spécifiquement conçu pour ce cas d'usage, et un lecteur conteste la formulation du problème dans l'article — jugée plus compliquée que la solution évidente — avant qu'une réponse n'explique l'intérêt du hashage des serveurs : préserver la stickiness des requêtes lors des ajouts/retraits de serveurs, sans reconstruction de tables ni synchronisation.
-
Qwen 3.8 Omni Flash
Le titre annonce « Qwen 3.8 Omni Flash », vraisemblablement une nouvelle variante du modèle Qwen d'Alibaba (famille multimodale « Omni », déclinaison « Flash »). Aucun contenu d'article n'étant fourni au-delà du titre, aucun détail sur les capacités, performances ou disponibilité du modèle ne peut être rapporté.
La discussion porte surtout sur le positionnement de Qwen 3.8 Omni face à Gemini et sur la difficulté de choisir un modèle, plus que sur l'article lui-même. Plusieurs commentateurs relèvent l'argument prix : si les performances sont comparables, Qwen facturerait environ 0,15/0,47 $ par million de tokens entrée/sortie contre 1,5/9 $ pour Gemini, soit une réduction de coût massive. Un avis nuance cependant qu'il faut comparer non pas le prix par token mais le nombre de tokens nécessaires pour accomplir une tâche, l'écart pouvant être important.
Sur l'usage réel, un commentateur décrit Qwen 3.8 Max comme le modèle le plus « fiable et posé » du marché — il ne déraille pas ni n'outrepasse son rôle — mais lent, disponible uniquement chez Alibaba avec des quotas de tokens jugés pingres. D'autres rapportent des comportements étranges du raisonnement dans l'architecture « Flash-Next » (le modèle commente ses propres instructions système entre les appels d'outils) et notent que le dépôt GitHub du harnais d'évaluation pointe en 404 ou a été retiré, ce qui jette un doute sur les benchmarks annoncés dans l'article.
Deux débats transversaux émergent : la prolifération des noms de modèles (Flash, Pro, Ultra, Omni, Lite) que certains jugent illisible — les conventions signifient pourtant des choses précises (Omni = multimodal, Flash = vitesse) — et l'évolution des modèles ouverts : un commentateur estime qu'Alibaba ralentit ses publications de poids ouverts et doute qu'une version Omni de ce modèle soit jamais publiée. La discussion critique aussi la page de présentation elle-même (mauvaise navigation, vidéos peu informatives), la jugeant peu convaincante techniquement.
-
Korea raises data breach fines to 10% of revenue
La Corée du Sud relève fortement les sanctions en cas de fuite de données personnelles : à partir de vendredi, une entreprise ayant divulgué par intention ou négligence grave les données de 10 millions de personnes ou plus encourt une amende pouvant atteindre 10 % de son chiffre d'affaires, contre 3 % auparavant. L'obligation de notifier les utilisateurs dans les 72 heures s'applique désormais aussi en cas de simple risque élevé d'exposition, y compris pour des données altérées par des ransomwares.
Le régulateur PIPC met aussi en place des réductions d'amende pouvant aller jusqu'à 40 % pour les entreprises ayant investi en amont dans la protection des données (budgets, effectifs, délégué à la protection) ou ayant détecté et signalé rapidement une fuite. Les responsables de la protection des données voient leur responsabilité élargie : leur nomination ou révocation doit être approuvée par le conseil d'administration pour les grandes entreprises, universités et hôpitaux.
Le cas de Coupang, condamné en juin à une amende de 624,6 milliards de wons (466 millions de dollars) après la fuite de données de 37,55 millions de personnes, illustre l'écart entre les anciennes et nouvelles règles : sous le nouveau régime, la sanction pourrait atteindre des milliers de milliards de wons.
La discussion accueille très favorablement l'annonce : plusieurs commentateurs jugent enfin qu'une sanction suffisamment lourde pour « faire mal » pourrait inciter les entreprises à investir réellement dans la sécurité, le calcul coût/bénéfice favorisant jusqu'ici la rentabilité au détriment de la protection des données. Le rapprochement avec le RGPD européen (4 % du chiffre d'affaires) revient souvent : des commentateurs soulignent que malgré ce plafond, les fuites de données restent hebdomadaires, donc que 10 % ne serviront à rien sans application effective et « exemples » spectaculaires ; l'UE AI Act est cité pour montrer que des pénalités de 7 % du chiffre d'affaires mondial existent déjà, contredisant ceux qui jugent de telles sanctions irréalistes.
-
Jemalloc 5.4.0
Sortie de jemalloc 5.4.0, avec plus de 160 commits centrés sur le nettoyage de la dette technique : refactorings majeurs (modularisation du front end, couche d'abstraction OS, suppression de l'abstraction PAI), corrections de bugs (errno préservé, deadlock lors d'arena_reset, cas limites TSD), améliorations de portabilité (macOS, MinGW, GCC 16) et évolutions d'API comme le flag EXTENT_ALLOC_FLAG_PINNED pour les pages non récupérables (HugeTLB) et de nouvelles mallctl pour les statistiques de mémoire épinglée. La politique de remplissage du tcache devient dynamique, supprimant sept options de configuration historiques.
La sortie de jemalloc 5.4.0 est surtout notée parce qu'elle marque la reprise du développement après plusieurs années sans release : plusieurs commentateurs soulignent que la santé du projet amont compte autant que les améliorations techniques de l'allocateur. Un fil de contexte renvoie à un postmortem récent et à un article sur l'usage de jemalloc, évoquant une fin « triste » du projet sous l'égide de Facebook/Meta : l'idée que l'intérêt soudain d'une très grande entreprise pour un projet open source n'est pas forcément bénéfique à long terme fait consensus. Quelques remarques notent aussi que ni la page d'accueil ni le dépôt GitHub ne mentionnent Jason Evans, le mainteneur d'origine qui a démissionné — son nom n'apparaît que dans l'historique du wiki — et s'interrogent sur l'identité des forces vives actuelles du projet ; Meta ne semble plus le développer.
Les retours de terrain convergent sur l'intérêt pratique de jemalloc : un praticien l'utilise pour ses compteurs d'allocation par thread, qui permettent de suivre et de plafonner la mémoire consommée par chaque thread (fonctionnalité qu'il n'a pas trouvée ni dans tcmalloc ni dans mimalloc). Un autre rapporte un résultat spectaculaire : le remplacement de l'allocateur par défaut dans une file Sidekiq a fait chuter la consommation de 8 Gio à moins de 1 Gio, un fuite mémoire lente devenant sans conséquence. Un commentateur rappelle toutefois via un lien Microsoft que masquer une fuite par un allocateur différent ne la corrige pas.
Une discussion technique porte sur le passage de tcmalloc des caches par thread aux caches par cœur CPU : un avis minoritaire y voit un gain sur le churn de threads et la sur-souscription sous Linux, avec un code plus simple pour un fastpath similaire ; un autre nuance que sans épinglage des threads aux cœurs (peu pratique en espace utilisateur sous Linux), un cache par thread n'a pas de sens puisque le thread peut migrer de cœur. Enfin, une digression étymologique précise que « je » vient des initiales de Jason Evans, à l'instar de phkmalloc et dlmalloc.
-
Inside ZCode: Silently uploading your Git history to the cloud
Une analyse technique révèle que ZCode, l'application de bureau de codage IA de Zhipu (Z.ai), emballe silencieusement l'intégralité du workspace de l'utilisateur — historique Git complet (86,6 % du payload), cache LFS, reflogs et configurations globales — le chiffre et l'envoie vers Aliyun OSS dès que l'utilisateur est connecté.
Le mécanisme utilise du chiffrement en enveloppe (AES-256-CTR + RSA-OAEP) dont la clé publique est fournie dynamiquement par le serveur et la clé privée reste exclusivement dans le cloud : ni l'utilisateur ni le client ne peuvent déchiffrer les archives stockées localement. L'auteur a reconstitué le flux via rétro-ingénierie de l'app.asar : demande d'identifiants à zcode.z.ai, puis upload direct en POST form vers OSS. L'historique Git complet expose donc des clés API supprimées, des branches non poussées révélant des projets inédits, et des hôtes GitLab internes. La politique de confidentialité ne mentionne nulle part cette collecte, et les réglages de l'interface ne permettent pas de désactiver le pipeline, instancié inconditionnellement au démarrage.
La défense proposée consiste à verrouiller le répertoire ~/.zcode/v2/checkpoints au niveau du filesystem (chflags uchg sur macOS, chattr +i sur Linux), ce qui bloque la capture sans perturber le chat ni l'autocomplétion ; seules les fonctions de rollback nécessitant l'upload cessent de fonctionner.
La discussion porte sur la révélation que ZCode (harnais de Z.ai) aurait uploadé silencieusement l'historique Git des projets vers le cloud, notamment via sa fonction « Repo Wiki »/indexation de codebase. Z.ai a publié des excuses reconnaissant que la fonctionnalité était activée par défaut lors du lancement, affirmant que les données sont détruites après génération des pages Wiki et non stockées — mais plusieurs commentateurs notent que rien dans la politique de confidentialité, la FAQ ou les changelogs ne mentionnait cet upload, et qu'un chiffrement « envelope » avec une clé détenue côté serveur rend les sauvegardes locales inaccessibles à l'utilisateur. Certains demandent des preuves indépendantes : un utilisateur de longue date ne retrouve aucune trace d'upload ni de répertoire de checkpoints sur sa machine, et un autre s'étonne qu'aucune source réputée n'ait confirmé l'affirmation, qui repose sur un site écrit avec Claude et un post X anonyme.
Le consensus dominant : ne jamais faire confiance à un harnais closed source, quel que soit le pays (les critiques visent aussi OpenAI et Anthropic), et isoler les agents IA dans des sandbox — plusieurs citent des outils dédiés, la création d'un compte utilisateur séparé, et rappellent que les modèles essaient souvent de lire les dotfiles et les fichiers listés dans .gitignore. La comparaison avec le « Grok CLI fiasco » revient plusieurs fois comme précédent. Mais la discussion corrige la lecture héroïque d'OpenCode souvent cité en alternative : il aurait lui-même envoyé des prompts à un service de résumé au lieu du modèle configuré (corrigé depuis), et aurait eu sa propre affaire de scan du répertoire utilisateur traitée par de la signature de code sans rapport. Un commentateur signale aussi Windows Defender qui insiste pour analyser ses fichiers de travail Codex, et un autre déplore les auto-updates silencieuses hors gestionnaire de paquets sous Linux.
Des divisions apparaissent : certains jugent la gravité limitée (« c'est du code généré par le modèle de toute façon », « on consent implicitement en exécutant un agent »), d'autres parlent de malware pur et s'inquiètent des secrets exfiltrés.
-
Bend 2 and the Vibe-Coding Trap
Critique de Bend 2, un langage présenté comme conçu pour l'ère du codage par IA, où les humains écriraient des « lois » et l'IA les implémentations avec preuves vérifiées par le compilateur. L'auteur y voit un piège typique du vibe-coding : la démo du langage exige 58 lignes pour décrire les règles du jeu et 442 lignes de preuve générées par le LLM.
Pour illustrer, l'auteur recrée la même démo en SPARK, langage open source de vérification formelle, en la vibe-codant lui-même sans autre consigne : le résultat est bien plus concis, et GNATprove prouve les 12 vérifications directement, sans que le LLM ait à reconstruire des preuves depuis zéro. Selon lui, l'auteur de Bend a construit un langage entier autour de la vérification formelle sans mentionner ni semble-t-il connaître ce champ, alors même que les outils existants résolvent déjà le problème.
La leçon dépasse Bend : le vibe-coding permet d'obtenir immédiatement un résultat sans recherche préalable, et un LLM ne suggérera jamais spontanément qu'une solution éprouvée existe déjà, au risque d'implémenter un design obsolète ou profondément défectueux.
L'article critique Bend 2 comme l'exemple type du « vibe coding » : un développeur aurait construit un langage autour de la vérification formelle sans même connaître ce domaine. Mais c'est précisément ce point que la discussion contredit le plus fermement. Plusieurs commentateurs, avec des sources à l'appui (posts X, dépôts GitHub de Formality, Cedille-Core et Kind-Lang, une conférence DevCon de 2017), démontrent que l'auteur de Bend travaille depuis près de dix ans sur la vérification formelle, bien avant l'existence des LLM. L'auteur de l'article, présent dans les commentaires, reconnaît l'erreur et a ajouté une note en tête : sa cible est l'approche générale, pas la personne, tout en maintenant que faire écrire des preuves de 442 lignes par un LLM alors que des solveurs SMT comme GNATprove ou CVC peuvent les produire automatiquement est un mauvais design.
Au-delà de cette correction factuelle, la discussion s'accorde sur une critique de fond du vibe coding, résumée par le commentaire le plus voté : il permet de construire une solution substantielle avant d'avoir appris assez sur le problème pour reconnaître qu'une bien meilleure solution existe, et l'LLM ne vous alerte jamais sur ce que vous ne savez pas. Un participant nuance avec une idée frappante : avant, l'exploration d'une mauvaise idée produisait un apprentissage ; désormais on obtient un résultat fonctionnel « avec conservation totale de l'ignorance » et la satisfaction dopamine en bonus. D'autres partagent des parades concrètes : commencer tout projet par une session de recherche d'état de l'art avec un LLM outillé de recherche web, ou demander au modèle de consulter la documentation avant de répondre.
Le débat se divise ensuite sur la valeur du « assez bien » : un développeur estime qu'on ne doit pas chasser la solution optimale pour le logiciel ordinaire, que le code coûte peu à produire maintenant et qu'il vaut mieux se concentrer sur tests et documentation. Sur Bend 2 lui-même, le README admet un compilateur écrit à 99 % par IA et non audité, et des chaînes implémentées comme listes chaînées — ce que certains jugent rédhibitoire, d'autres tolérables pour un projet neuf.
-
Warren Buffett Steps Down as Berkshire Chairman, Names Son to Replace Him
Warren Buffett annonce qu'il quitte son poste de président de Berkshire Hathaway et que son fils le remplacera à cette fonction.
La discussion porte surtout sur la nomination de Howard Buffett, fils de Warren, comme président non exécutif, largement perçue comme du népotisme. Plusieurs commentateurs relèvent l'ironie avec une citation de Buffett lui-même comparant ce type de succession au choix d'une équipe olympique parmi les fils de médaillés. D'autres nuancent : le rôle de président non exécutif est limité — il veille à la culture et peut renvoyer le PDG (Greg Abel), qui dirige réellement l'entreprise ; ce plan est annoncé depuis 2011, et Howard, agriculteur sans diplôme, est présenté comme garant des valeurs. Certains rappellent aussi que Warren donne la quasi-totalité de sa fortune, contrairement à une véritable dynastie patrimoniale.
Les débats divergents portent sur la performance future de Berkshire : un commentaire affirme que BRK.B restera sur dix ans au moins aussi bon pari qu'un fonds indiciel S&P 500, ce qu'un détenteur d'actions conteste, arguant que la grande masse de bons du Trésor détenus par Berkshire freinera la performance, même si le titre reste un bon hedge en cas de krach. Un autre juge que Buffett a échoué à s'adapter depuis 2013-2014, manquant les valeurs technologiques et revendant TSMC. On note aussi des précisions factuelles : Warren a 96 ans, Howard 71 (ce qui pose la question d'une succession suivante, un petit-fils semblant être préparé), et le siège de Berkshire n'emploie que 27 personnes.
Globalement, l'accord se fait sur la différence entre garder un capital dans la famille et en confier la gestion, et sur le risque classique de dégénérescence des dynasties (perte des principes au fil des générations). Plusieurs estiment que malgré ce choix « monarchique », Warren reste un milliardaire comparativement honorable ; un avis minoritaire s'insurge contre ce standard trop bas.
-
Minimal Phone 2
Page FAQ du Minimal Phone 2 (MP2), smartphone compact avec clavier physique rétroéclairé et Minimal OS basé sur Android, en précommande avec expédition estimée à décembre 2026. Il propose un écran AMOLED 4 pouces 1080 × 1240 à 90 Hz, 12 Go de RAM, 256 ou 512 Go de stockage (sans microSD), des finitions Pearl et Onyx, plusieurs dispositions de clavier (QWERTY, AZERTY, QWERTZ, coréen, arabe), des touches remappables et des raccourcis.
La fiche technique mentionne une batterie au silicium de 3 600 mAh avec charge filaire 27 W et sans fil Qi 15 W, un jack 3,5 mm, un USB-C avec audio et sortie DisplayPort 1.4, des capteurs photo de 50 MP (arrière) et 20 MP (avant), la 4G/5G, une SIM physique plus eSIM, Wi-Fi 6E, Bluetooth 5.4 et NFC.
Le reste de la page couvre la logistique : paiement intégral à la commande avec annulation possible avant expédition, frais de port de 10 $ aux États-Unis et 29 $ à l'international, gestion des commandes, suivi, retours et accessoires dédiés (coques, protections, docks de charge).
La présentation du Minimal Phone 2 divise nettement la discussion : une minorité de commentateurs enthousiastes (souvent d'anciens utilisateurs d'iPhone mini ou de petits Pixels) apprécient le format compact, le clavier physique tactile permettant le swipe, et l'Android complet sans restrictions ; mais la majorité critique le concept et surtout le prix de 600 $, jugé incohérent avec l'idée d'un téléphone « minimal ». Plusieurs soulignent l'ironie : c'est un Android plein, avec 12 Go de RAM et de bonnes specs, donc rien n'empêche le doomscrolling — il faudrait de toute façon de l'autodiscipline, qu'on peut tout aussi bien exercer en supprimant des apps de son téléphone actuel. Un avis nuance toutefois que le marché des téléphones réellement minimalistes est trop étroit : sans WhatsApp, la banque ou les cartes, il faudrait un deuxième téléphone, ce qui n'a pas de sens.
Des contestations factuelles de l'article apparaissent : un utilisateur a commandé le premier modèle, livré avec six mois de retard et une communication défaillante, et « à peine utilisable » à réception — ce qui nourrit la méfiance envers le fabricant. D'autres pointent des informations manquantes sur le site (version d'Android, autonomie de la batterie) et critiquent l'absence de certaines bandes LTE/5G aux États-Unis, même si un commentateur précise que les bandes sous 3 GHz de son opérateur sont couvertes. Le poids est également relevé : le Minimal 2 n'est que 7 g plus léger qu'un iPhone Air malgré un écran bien plus petit, ce qui illustre, selon un commentateur, l'avance d'Apple en manufacturing. Sur le clavier, le débat oppose les détracteurs (trop petit, le swipe sur écran serait plus rapide) aux défenseurs, dont un vétéran des claviers Palm/Treo qui explique que le tactile physique permet de taper sans regarder et offre des layouts constants, contrairement aux claviers virtuels.
-
The scourge of x86 emulation
Article technique approfondi sur les difficultés d'émulation x86 sur ARM, illustrée par le projet FEX. Le cœur du problème réside dans l'émulation du modèle mémoire x86-TSO (Total Store Ordering), très strict, sur le modèle ARM à consistance faible, qui autorise plus d'optimisations matérielles mais ne garantit pas la même visibilité immédiate des écritures entre processeurs.
Sur ARMv8.0-a, FEX traduit chaque charge x86 en load-acquire et chaque store en store-release, ce qui donne des sémantiques équivalentes voire plus strictes que nécessaires, mais à un coût élevé : des microbenchmarks montrent que sur cinq CPU testés, trois subissent une nette perte de performance sur les acquire-loads, avec des cas particulièrement mauvais sur AmpereOne et Apple M1, ces instructions n'ayant jamais été conçues pour constituer la majorité du code exécuté.
L'extension LRCPC (obligatoire depuis ARMv8.3) introduit le modèle RCpc, pensé précisément pour l'émulation x86 : une fois détectée, FEX abandonne les acquire-loads au profit des LRCPC-loads, dont les performances rejoignent celles des charges ordinaires sur presque toutes les plateformes, résolvant le problème mémoire sur le papier — le mystère du résultat atypique de l'Apple M1 restant à éclaircir.
Les commentateurs saluent un article technique de qualité sur les difficultés d'émulation x86 vers ARM, mais la discussion la plus substantielle porte sur la thèse centrale de l'article : que le modèle mémoire strict de x86 (TSO) pénaliserait les performances face au modèle relâché d'ARM.
Plusieurs commentateurs contestent ou nuancent cette affirmation, en citant un article de Fabian Giesen arguant qu'un modèle mémoire relâché n'apporte pas forcément un bénéfice significatif. Cette position est corrigée de façon notable par un intervenant se présentant comme l'auteur de Rosetta 2 et concepteur du mode TSO d'Apple : il estime que le modèle relâché d'ARM procure bel et bien un gain, qu'il chiffre à quelques pour cent — modeste pour un logiciel, mais significatif en microarchitecture. Il ajoute que x86 souffre d'autres handicaps architecturaux, notamment le préfixe LOCK agissant comme barrière complète sur chaque instruction atomique, pénalisant les programmes à comptage de références, ainsi que le codage à longueur variable des instructions contre les 32 registres d'ARM. Un autre commentateur appuie cette position avec une étude académique récente. Des précisions rappellent aussi que le mode TSO d'Apple, s'il résout l'essentiel, ne couvre pas tous les cas particuliers.
Sur le plan pratique, la discussion met en avant FEX, un framework de traduction x86→ARM sponsorisé par Valve pour le Steam Frame et utilisé en fork dans CrossOver Beta pour remplacer Rosetta 2. Un utilisateur rapporte un retour de terrain positif : FEX fonctionne bien sur des handhelds ARM sous Linux avec une excellente autonomie, les principaux blocages restant les anti-cheat (EAC) plutôt que l'émulation elle-même. Quelques digressions (adoption de RISC-V, port de FEX vers macOS, proposition de bytecode obligatoire sur Steam) n'apportent pas d'éléments techniques supplémentaires.
-
I vibed a proof of Conway's conjecture
L'auteur, se présentant comme non-mathématicien, raconte comment il a utilisé Claude (modèle frontier) pendant un mois pour produire une preuve formelle en Lean de la conjecture de raffinement de Conway (1976), portant sur les entiers omnifiques des nombres surréels : si ab = cd, il existe e, f, g, h tels que a = ef, b = gh, c = eg, d = fh.
Il décrit le processus : il a demandé à Claude de choisir un problème ouvert dans les nombres surréels, le modèle ayant sélectionné cette conjecture, présentée comme la dernière conjecture de Conway encore ouverte et liée aux travaux récents de L'Innocente et Mantova sur les séries à support infini. La preuve a passé les vérifications mécaniques du registre Palomar et semble correcte à quelques personnes compétentes en Lean, mais n'a pas encore été validée indépendamment par des mathématiciens.
L'article détaille aussi la conjecture elle-même (propriété de refinement des factorisations, valant pour les entiers classiques mais non triviale avec l'infini) et s'interrompt au moment de la description du workflow Lean/IA utilisé.
Le billet décrit comment un amateur (le développeur connu pour React, ce qui a surpris plusieurs lecteurs) a utilisé des LLM pour produire une preuve de la conjecture de raffinement de Conway sur les nombres surréels, sans comprendre pleinement les concepts sous-jacents. La discussion porte moins sur les maths que sur la signification de ce mode de travail : plusieurs commentateurs s'accordent pour dire que la preuve produite par l'IA reste obscurcissime et doit être vérifiée et simplifiée, et le fil confirme que l'auteur est en contact avec le professeur Vincenzo Mantova (dont les travaux avec S. L'Innocente fondent la preuve) sur le Zulip de Lean, en vue d'une éventuelle publication ; une réponse de Mantova est d'ailleurs signalée. Nuance importante par rapport à l'article : le résultat n'est pas encore un travail mathématique achevé, et les « résumés » écrits par l'IA seraient peu utiles.
Le fil se divise sur la valeur de cette démarche. Certains la comparent à une « sorcellerie » (l'IA invoquée exécute l'effet, mais on ne sait pas valider le résultat) ou y voient une compétence rare d'évaluation de sorties sans expertise profonde ; d'autres contestent vigoureusement qu'aucune intelligence n'ait été démontrée. Un mathématicien amateur publié conseille à l'auteur de continuer à simplifier la preuve jusqu'à la comprendre lui-même, en cherchant les parties déjà connues à attribuer. Un commentateur note aussi des méthodes plus rigoureuses possibles (interroger l'IA, maintenir à jour le code Lean pour économiser du temps et des tokens) ; l'auteur répond qu'il n'avait pas la connaissance du domaine pour repérer les erreurs et que Lean a dû être largement réécrit au départ. Une critique pointe qu'il a payé les LLM tout en s'appuyant gratuitement sur l'aide humaine, et qu'il pourrait nier la valeur de la compréhension ; l'auteur répond que la compréhension reste pour lui la valeur principale, mais que l'on peut aussi agir par amusement ou pour poser des questions méta.
-
ZCode, the GLM coding agent, silently uploads your Git history
Un développeur, ferstar, a publié une rétro-ingénierie de ZCode, l'agent de code desktop de Z.ai (société derrière les modèles GLM) : lorsqu'un utilisateur est connecté, l'application empaquette silencieusement tout l'espace de travail — historique .git complet, cache LFS, reflogs, configurations — le chiffre et l'envoie vers Aliyun OSS (Alibaba Cloud). Dans le test : une archive chiffrée de 313 MB issue d'un espace de travail de 42 411 fichiers, avec 564 tentatives d'upload échouées enregistrées.
Le chiffrement est le point clé : chiffrement par enveloppe, la clé symétrique étant enveloppée par une clé publique RSA-OAEP fournie par le serveur, dont la clé privée ne réside que dans le cloud de Z.ai. L'utilisateur ne peut donc pas déchiffrer l'archive stockée sur son propre disque. Le .git représente 86,6 % du contenu : clés API supprimées, branches non poussées, hostnames internes — des années d'historique d'ingénierie. Les paramètres de l'interface ne bloquent rien : le sidecar de capture est instancié inconditionnellement au démarrage, en dehors de la boucle d'outils de l'agent, si bien qu'aucune permission ne l'arrête. La politique de confidentialité ne mentionne pas ce comportement, malgré les engagements publics d'un dirigeant de Z.ai à son lancement en juillet 2026.
La discussion tourne autour d'une accusation selon laquelle ZCode, l'agent de codage de Z.ai (GLM), uploaderait silencieusement l'historique Git des projets (~300 Mo évoqués, correspondant au dépôt, pas seulement aux messages de commit). Plusieurs commentateurs font le rapprochement avec le précédent scandale du CLI Grok qui envoyait des fichiers vers un bucket cloud, et y voient un schéma récurrent de l'industrie : les agents « locaux » exfiltrent en réalité des données vers le cloud.
Le principal point d'accord est méfiant envers les harness closed source, quel que soit le pays d'origine : plusieurs recommandent de n'utiliser que des agents open source et éprouvés (OpenCode, Pi.dev, Codex sont cités), voire de sandboxer les agents ou de créer des comptes utilisateurs dédiés. Un praticien décrit avoir implémenté des périmètres de lecture séparés (fichiers projet, ignorés, dotfiles, externes) et note que GLM, DeepSeek et Grok cherchent spontanément à lire les dotfiles et les fichiers listés dans .gitignore — comportement jugé suspect. Un autre mentionne Cursor qui prétend ne pas voir les fichiers .env pour les suggestions mais les cite dans ses réponses.
La discussion nuance toutefois fortement l'article : un utilisateur de longue date de ZCode ne retrouve aucune trace des répertoires ou logs décrits chez lui, suggérant que le comportement ne touche pas tout le monde ; d'autres demandent une confirmation par une source fiable, notant que l'article semble avoir été généré par un LLM (qui confond « historique Git » et dépôt Git) et n'est qu'une paraphrase d'un billet de blog. Plusieurs rappellent aussi l'ironie : l'usage illimité et quasi gratuit de ces modèles a un coût, et certains suspects que l'envoi massif de code sert l'entraînement ou la distillation. Enfin, un avis minoritaire estime que la confidentialité des dépôts publics n'a pas d'importance et que lancer un agent local vaut consentement — position vivement raillée en réponse.
-
Border agents can search cellphones without a warrant or reasonable suspicion
D'après le titre, les agents des douanes américaines peuvent fouiller les téléphones portables aux frontières sans mandat ni soupçon raisonnable. Aucun contenu supplémentaire n'est disponible au-delà du titre.
La discussion confirme et dépasse l'article : les frontières américaines ne sont pas le seul enjeu, c'est la « border zone » des 100 miles qui inquiète le plus, couvrant environ 213 millions de personnes, soit les deux tiers de la population américaine. Plusieurs commentateurs jugent cette extension incompatible avec le texte du 4e amendement, tandis qu'un autre nuance en rappelant l'origine historique de l'exception douanière : les fouilles des marchandises à l'entrée du territoire pour faire respecter les tarifs, qui n'équivalaient pas à lire les papiers personnels. Un commentaire précise aussi la portée exacte de la décision : elle autorise la fouille manuelle des appareils mais ne se prononce pas sur les fouilles numériques approfondies, et réserve la notion de fouille « non-routine » aux fouilles corporelles, pas aux effets personnels.
Les retours de terrain pèsent lourd dans le fil : un voyageur raconte avoir été interpellé au Canada avant un vol vers Boston, où un faux positif (des sels de reliques bouddhistes détectés comme explosif) a conduit à l'examen de son iPhone, à la découverte de captures d'écran géopolitiques vieux de deux ans, puis à une interdiction à vie d'entrée aux États-Unis et à une garde à vue. Un autre témoigne que la pratique des contrôles de téléphones avec remise du mot de passe, perçue comme tyrannique en Biélorussie en 2021, s'est normalisée aux États-Unis en cinq ans. D'autres rappellent que le Royaume-Uni a des règles similaires (obligation de fournir mots de passe et codes PIN, saisie des appareils, pas d'avocat pendant l'interrogatoire), et qu'ICE dispose d'un contrat avec Cellebrite, rendant le refus de donner son code peu efficace.
Sur le plan pratique, plusieurs commentateurs décrivent des mesures déjà courantes dans des entreprises européennes : appareils entièrement effacés ou téléphones à usage limité fournis pour les voyages à risque, voire dumb phones pour la Russie ; l'idée de volumes cachés type VeraCrypt est jugée séduisante mais détectable et risquée (accusation d'obstruction), certains préférant un appareil vide avec sauvegarde/restauration à distance.