Clés Google exposées et Gemini & Push-to-talk chiffré via Tor - Actualités Hacker News (26 févr. 2026)

On commence par le sujet sécurité qui fait lever un sourcil: les clés API Google qui commencent par “AIza…”. Pendant des années, Google a martelé que ces clés ne sont pas des secrets: elles servent surtout d’identifiant de projet, notamment pour Maps ou Firebase, et on les voit souvent côté client. Sauf que Truffle Security explique que l’arrivée de l’API Gemini change la donne. Le point critique, c’est l’effet “extension rétroactive des privilèges”. Si une équipe active l’API “Generative Language” dans un projet Google Cloud existant, des clés déjà créées dans ce projet—y compris celles qui traînent publiquement dans le JavaScript d’un site—peuvent, sans avertissement clair, devenir valides pour appeler Gemini. Et comme beaucoup de clés sont en mode “Unrestricted” par défaut, elles se retrouvent implicitement utilisables pour toutes les API activées dans le projet. Scénario d’attaque: un acteur malveillant scrappe une clé exposée sur une page web (par exemple un embed Maps), puis tente des appels Gemini. Truffle mentionne des endpoints comme “/v1beta/files” ou “/cachedContents” qui pourraient révéler des fichiers uploadés, des datasets, ou du contexte mis en cache. Même sans extraction de données, l’abus peut coûter cher: génération de facturation, épuisement de quotas, voire déni de service économique pour les usages légitimes. Pour mesurer l’ampleur, Truffle a scanné Common Crawl (novembre 2025) et dit avoir trouvé 2 863 clés publiques encore “vivantes” qui fonctionnaient pour Gemini. Le passage le plus piquant: ils affirment avoir repéré une clé sur un site produit de Google, déployée publiquement depuis au moins février 2023, et l’avoir utilisée pour interroger “/models” avec un retour “200 OK”. Côté réponse, l’affaire a d’abord été qualifiée de “comportement intentionnel”, puis reclassée en bug, avec une catégorie de type “Single-Service Privilege Escalation, READ (Tier 1)”, et des travaux de remédiation toujours en cours en février 2026. Concrètement, les recommandations sont très opérationnelles: vérifiez quels projets ont l’API Generative Language activée, imposez des restrictions d’usage aux clés, évitez les clés “unrestricted”, faites tourner les clés exposées, et si vous voulez industrialiser la chasse aux fuites, des outils comme TruffleHog peuvent tester la validité et l’accès Gemini.

On reste dans la protection de la vie privée, mais côté open source, avec TerminalPhone. Le concept est volontairement “low tech” dans la forme et plutôt malin sur le fond: un outil de push-to-talk, voix et texte, anonyme et chiffré de bout en bout, qui passe par des services cachés Tor. Ce qui le distingue d’un appel VoIP classique, c’est son modèle “j’enregistre puis j’envoie”. Au lieu de streamer de l’audio en continu, vous enregistrez un message complet; ensuite il est compressé en Opus, chiffré—par défaut en AES-256-CBC—puis envoyé en un seul bloc. L’auteur présente ça comme un moyen de réduire certaines signatures de trafic par rapport à un flux continu, même si, évidemment, Tor n’efface pas tous les risques de corrélation. Le projet tient dans un unique script Bash auto-contenu, et il n’y a pas d’infrastructure centrale: pas de serveur, pas de compte, pas de numéro. L’“identité” de chaque personne, c’est son adresse .onion. Et il y a des détails qui font sérieux: négociation de chiffrements, possibilité de changer de cipher en cours d’échange, option de signer les messages du protocole avec HMAC-SHA256, et même des précautions comme passer des secrets à OpenSSL via des descripteurs de fichiers pour éviter qu’ils apparaissent dans les listings de processus. Le README est aussi honnête sur les limites: le secret partagé doit être échangé hors bande, il n’y a pas de forward secrecy, et si un terminal est compromis, le clair peut fuiter. Côté installation, l’idée est simple: on clone, on lance “bash terminalphone.sh”, on auto-installe tor, opus-tools, sox, socat, openssl, et sous Android c’est possible via Termux—avec Termux:API pour accéder au micro. Bref: pas une appli grand public, mais un outil intéressant pour comprendre comment on peut faire du “walkie-talkie” chiffré en s’appuyant sur Tor et un protocole texte minimaliste.

Troisième volet sécurité—plus irritant, celui-là: le scraping de GitHub pour envoyer du marketing. Un post “Tell HN” raconte avoir reçu des emails non sollicités, ciblés selon les repos auxquels la personne contribue. Une startup mentionnée, Run Anywhere (W26), est accusée d’avoir utilisé ces signaux; et d’autres, comme Voice.AI, auraient fait pareil. Le mécanisme est tristement simple: Git, par conception, embarque un nom et une adresse email dans les métadonnées de commit. Pas besoin d’API GitHub: il suffit de cloner un dépôt public pour récupérer l’historique et aspirer des emails. Même chose, selon des commentaires, après un simple “star” sur un repo, ce qui donne l’impression d’être observé en permanence. Un employé GitHub est intervenu pour rappeler que c’est contre les conditions d’utilisation, et que GitHub peut bannir—mais c’est un jeu du chat et de la souris. Les parades sont pragmatiques: configurer les commits avec l’adresse “no-reply” fournie par GitHub, utiliser des alias, ou un domaine perso en catch-all pour mieux filtrer et identifier les sources de fuite. Moralité: dans l’open source, la transparence des outils peut devenir un canal de spam si on ne cloisonne pas les identités.

Passons à l’outillage IA, avec Agent Swarm de Desplega.ai, open source sous licence MIT. L’ambition: orchestrer une équipe d’agents de code—Claude Code, Codex, Gemini CLI et autres—comme on orchestrerait une petite “task force” logicielle. L’architecture est assez classique mais bien emballée: un agent “lead” reçoit des demandes via Slack, GitHub, email ou API, découpe en sous-tâches, puis délègue à plusieurs agents “workers” isolés en conteneurs Docker. Au milieu, un serveur MCP fait l’interface vers une base SQLite pour la coordination, la persistance, et l’historique. Et par-dessus, un dashboard permet de suivre en temps réel les tâches, les files de priorité, les dépendances, et même les conversations inter-agents. Deux idées reviennent souvent dans ce genre de systèmes, et Agent Swarm les pousse: d’abord la planification—priorités, pause/reprise, tâches récurrentes façon cron—ensuite la mémoire. Ici, ils parlent de “compounding memory”: le système génère des souvenirs consultables à partir des résumés de sessions, des résultats, y compris les échecs, et des notes fichiers. Ils utilisent des embeddings OpenAI (text-embedding-3-small) pour rendre ça recherché et réinjectable. Enfin, il y a un côté “identité persistante” assez concret: des fichiers comme SOUL.md, IDENTITY.md, TOOLS.md, CLAUDE.md, synchronisés et évolutifs, plus un script de démarrage par agent pour conserver des ajustements d’outillage. En bref, un cadre qui vise moins le gadget que l’exploitation en continu, avec des intégrations (Slack, GitHub App, AgentMail, Sentry) pensées pour coller au quotidien d’une équipe.

Dans la même veine IA, mais côté stratégie et gouvernance: Anthropic assouplit une partie de ses engagements de sécurité avec sa “Responsible Scaling Policy v3”. Historiquement, Anthropic s’est construit une image “safety-first”, avec des garde-fous internes assez explicites. Or, la nouvelle version remplace des contraintes plus fermes par un cadre plus flexible, revendiqué comme “non contraignant” et susceptible d’évoluer. Le changement qui fait parler: la suppression d’une exigence précédente qui impliquait de mettre en pause l’entraînement de modèles plus puissants si les capacités dépassaient ce que l’entreprise juge contrôlable en matière de sécurité. L’argument avancé est compétitif: si les acteurs prudents s’arrêtent et que les moins prudents continuent, on pourrait se retrouver avec un monde “moins sûr”. Anthropic dit aussi vouloir séparer ses plans internes de sécurité de ses recommandations publiques pour l’industrie. Ils promettent néanmoins une “Frontier Safety Roadmap”, et insistent sur l’idée d’auto-évaluation publique: rapports réguliers sur les menaces, les mitigations et les capacités. Le contexte politique et commercial est aussi mentionné: un climat anti-régulation à Washington, et des tensions rapportées avec le Pentagone autour de “lignes rouges” comme les armes contrôlées par IA ou la surveillance de masse domestique. En parallèle, Benedict Evans pose une question plus large: si tout le monde a des modèles comparables, où se crée l’avantage durable? Son diagnostic sur OpenAI est rude: pas de technologie unique difficile à répliquer, une base d’utilisateurs énorme mais peu engagée—“mile wide, inch deep”—et des incumbents comme Google ou Meta capables d’utiliser leur distribution pour rattraper et dépasser. Evans souligne que seule une minorité paie, que beaucoup d’utilisateurs utilisent sporadiquement, et que l’interface chatbot ressemble à une commodité difficile à différencier—un champ de saisie, une réponse. Il interprète l’intérêt pour la publicité comme un moyen de financer la masse d’usagers non payants, mais doute que “meilleur modèle” suffise à créer de l’habitude. Et il reste sceptique sur une vision “plateforme” où l’identité ChatGPT deviendrait un standard transversal: les partenaires n’aiment pas devenir des tuyaux, et les workflows réels cassent souvent les abstractions. La photo d’ensemble est assez claire: la course est autant une affaire de distribution, d’intégrations et de produit, qu’une affaire de scores de benchmark.

On termine avec trois sujets plus transverses—culture tech, science, et ingénierie. D’abord, un billet sur le fait que l’excellence technique ne gagne pas forcément. L’auteur décrit un pattern que beaucoup reconnaîtront: la solution la plus correcte est validée… puis rejetée parce qu’elle crée un coût immédiat, une gêne, ou qu’elle expose des dysfonctionnements. Ce qui est “invisible” aujourd’hui—ne pas corriger des warnings, ne pas rembourser la dette technique—devient visible plus tard, sous forme d’incident. Le texte critique aussi certains processus de “consensus” qui se transforment en droit de veto: inclure toutes les parties impactées peut, en pratique, empêcher toute amélioration. Le point qui pique le plus, c’est “responsabilité sans autorité”: on attend de la personne la plus compétente qu’elle éteigne les incendies, mais on ne lui donne pas le pouvoir d’éviter les décisions qui les déclenchent. Conclusion proposée: soit aligner autorité et responsabilité, soit changer d’organisation. Ensuite, une page carrière qui a circulé: Hightouch met en avant une culture “kind and talented”, des valeurs très startup—efficacité, impact, humilité—et une organisation hub + remote. Ça n’a pas le même ton qu’un billet de gouvernance, mais c’est intéressant comme miroir: d’un côté, des entreprises qui brandissent valeurs et vitesse; de l’autre, les frictions très concrètes quand le changement touche aux habitudes. Côté science: des chimistes de Scripps Research publient une refonte structurelle du fentanyl pour viser un analgésique puissant, mais potentiellement moins dangereux sur la respiration. Ils remplacent l’anneau central par une géométrie spirocyclique—2-azaspiro[3.3]heptane—et rapportent conserver l’analgésie grâce à un “ancrage” électrostatique clé au niveau du récepteur μ-opioïde, tout en modifiant d’autres interactions. Point notable: pas de recrutement détectable de la voie beta-arrestin, souvent associée à des effets indésirables comme la dépression respiratoire. Dans leurs tests, le ralentissement de la respiration n’apparaît qu’à très forte dose et reste temporaire; et la demi-vie annoncée est courte, autour de 27 minutes. C’est un résultat précoce, mais c’est exactement le type de piste qui pourrait guider une nouvelle génération d’opioïdes moins meurtriers, dans un contexte d’épidémie d’overdoses. Et enfin, un plaisir d’ingénieur: IEEE Spectrum décortique le son de Jimi Hendrix comme de l’ingénierie des systèmes analogiques, plutôt qu’un mystère. L’article se focalise sur “Purple Haze” et reconstruit la chaîne: Fuzz Face, Octavia, wah-wah, ampli Marshall, et surtout la boucle de feedback acoustique entre la guitare, les haut-parleurs et la pièce. L’auteur va jusqu’à convertir des schémas en modèles SPICE, simuler dans ngspice, et produire des échantillons audio via Python. On y apprend, par exemple, que la faible impédance d’entrée de la Fuzz Face rend le potentiomètre de volume de la guitare crucial pour “nettoyer” le son, ou encore que l’Octavia, avec sa rectification et inversion de forme d’onde, renforce des harmoniques donnant cet effet d’octave. Une façon très concrète de rappeler que le “son” est souvent le produit d’une chaîne entière—composants, réglages, et espace physique.