iOS et notifications persistantes & Firefox, Tor et fingerprinting - Actualités Hacker News (23 avr. 2026)

On commence par la confidentialité sur mobile. Apple a publié une mise à jour iOS et iPadOS pour corriger un bug où des notifications censées être supprimées pouvaient rester stockées sur l’appareil, parfois pendant plusieurs semaines. Le point sensible, c’est que ces notifications pouvaient contenir le texte de messages issus d’apps comme Signal, y compris quand l’utilisateur pensait avoir tout effacé ou activé des messages éphémères. Pourquoi ça compte : beaucoup de protections “disparition automatique” reposent sur l’idée que le système d’exploitation ne garde pas de copies inattendues. Là, le problème n’était pas le chiffrement, mais la rétention de traces côté OS — et c’est précisément ce que les outils de forensic exploitent quand un téléphone est saisi.

Dans la même veine, Mozilla a corrigé une vulnérabilité de Firefox qui transformait un détail d’implémentation en outil de suivi. En gros, l’ordre des résultats renvoyés par l’API indexedDB.databases() pouvait révéler un identifiant stable, suffisamment riche pour relier l’activité d’un utilisateur entre sites, sans cookies. Le plus gênant : en navigation privée, cet identifiant pouvait survivre tant que le processus Firefox restait ouvert, et dans Tor Browser, il pouvait même traverser certaines actions de “nouvelle identité”. L’intérêt de l’histoire, c’est un rappel brutal : en matière de vie privée, des choses aussi banales que “l’ordre d’une liste” peuvent devenir un signal de fingerprinting. Correctif annoncé côté Firefox, mais tout l’écosystème Gecko doit suivre.

Et puis il y a la surveillance “invisible” qui passe sous les radars des applications : Citizen Lab affirme avoir identifié deux campagnes de traçage de localisation exploitant les failles historiques des réseaux de signalisation télécom, notamment SS7, et parfois Diameter quand les protections sont mal appliquées. Le tableau décrit ressemble à un scénario de film, sauf que c’est du quotidien : des sociétés-écrans se faisant passer pour des opérateurs, des requêtes de localisation qui transitent via quelques prestataires, et au final des cibles suivies à l’échelle internationale. Pourquoi c’est important : malgré des années d’alertes, ces protocoles restent un talon d’Achille structurel, difficile à corriger globalement, et particulièrement dangereux pour des personnes à risque, journalistes ou opposants.

On passe à l’infrastructure, avec un texte très critique sur le cloud moderne. L’ingénieur David Crawshaw explique qu’il construit une nouvelle plateforme, mais surtout il attaque l’idée que les briques de base des hyperscalers auraient “la bonne forme”. Dans sa vision, on s’est habitués à des compromis devenus normaux : des VM attachées à des tailles rigides CPU/mémoire, un stockage qui pousse vers des modèles distants et parfois lents, et un réseau où l’économie — notamment les frais d’egress — verrouille les architectures. Ce qui rend l’analyse intéressante, c’est son argument que Kubernetes et les couches PaaS maquillent le problème plus qu’elles ne le résolvent : si les primitives sont mal taillées, la portabilité et la simplicité deviennent des promesses quasi impossibles. Et avec l’arrivée d’agents de code basés sur l’IA qui pourraient augmenter la quantité de logiciels produits, la “friction cloud” passerait du statut d’ennui à celui de goulot d’étranglement financier et opérationnel.

Toujours côté développeurs, un projet attire l’attention : Honker, une extension chargeable pour SQLite, accompagnée de bindings, qui apporte une logique de NOTIFY/LISTEN façon Postgres… mais sans serveur séparé. L’idée, c’est de traiter files de jobs, pub/sub et événements comme des lignes dans la même base SQLite. Résultat : quand votre application écrit des données et publie un événement, tout peut être validé ou annulé ensemble, ce qui évite les “double écritures” et les incohérences qu’on rencontre souvent avec un broker externe. Pourquoi c’est notable : SQLite est de plus en plus utilisé dans des applis embarquées, des outils locaux, des services mono-machine — et ces contextes ont quand même besoin de tâches en arrière-plan fiables. Honker propose une voie “moins d’infra, plus de garanties”, à condition d’accepter les limites d’un modèle centré sur une machine.

Dans la rubrique apprentissage et outillage, un développeur a regroupé ses billets sur un gros projet personnel : écrire un compilateur C en Zig, chapitre par chapitre. Ce n’est pas une doc léchée, plutôt un carnet de bord — mais c’est précisément ce qui plaît à beaucoup de lecteurs : on voit les erreurs, les choix, la progression. Pourquoi ça compte : Zig continue de s’imposer comme un langage pertinent pour construire des outils bas niveau, avec une approche plus moderne que le C tout en restant proche de la machine. Et ce genre de série rend la barrière d’entrée moins intimidante pour celles et ceux qui veulent comprendre comment “naît” une toolchain.

On termine avec un sujet très concret, loin des datacenters : des tracteurs. Une startup canadienne, Ursa Ag, dit recevoir un fort intérêt d’agriculteurs américains en construisant des machines neuves… mais volontairement basées sur des moteurs diesel des années 1990 remanufacturés, et en évitant l’électronique moderne. Le pitch est simple : des moteurs réparables sans logiciel propriétaire, sans autorisation du concessionnaire, sans diagnostic verrouillé. Pourquoi c’est intéressant : c’est un signal que, dans certains métiers, la sophistication technologique peut être perçue comme un risque opérationnel, surtout quand elle s’accompagne de verrouillage et de coûts. Et si la demande se confirme, ça mettra une pression supplémentaire sur les grands fabricants pour concilier innovation, réparabilité et contrôle.