Clés API volées - Comment éviter une facture à 82 000 dollars
82 314 dollars, c'est l'incroyable facture que s'est mangé un dev mexicain après 48 heures d'utilisation frauduleuse de sa clé API Gemini. Sa dépense habituelle était de 180 dollars par mois environ, j'imagine que ça lui a fait un peu mal aux fesses. Et c'est une bonne raison pour moi de vous inciter une nouvelle fois à bien sécuriser vos clés API !
Le gars bosse dans une petite startup et de ce que j'ai compris, quelqu'un a chopé ses credentials et s'est lâché sur Gemini 3 Pro pendant deux jours. La réponse de Google ? "Responsabilité partagée". En gros, eux sécurisent l'infra, et vous sécurisez vos clés. Si vous vous faites plumer, c'est votre problème !
Et c'est pas un cas isolé car les chercheurs de Truffle Security ont scanné le web et trouvé 2 863 clés Google API exposées en clair sur des sites publics. Toutes identifiables par le préfixe AIza.
Sauf que comme je vous l'expliquais dans un article précédent, ces clés, à la base, étaient conçues comme de simples identifiants de projet pour Maps et Firebase et la doc Google disait carrément qu'elles n'étaient pas secrètes ! Et quand l'API Gemini a été activée sur ces projets, hé bien ces clés sont devenues des clés d'authentification, sans que personne ne réalise ce changement de paradigme.
Mais bon, plutôt que de chialer comme des fragiles, voyons comment éviter de se retrouver dans cette situation ^^.
Scanner vos secrets existants
Avant tout, faut savoir si vous avez déjà des fuites. Deux outils open source font ça très bien.
TruffleHog scanne vos dépôts Git, vos fichiers, et même vos buckets S3 pour trouver des secrets qui traînent. L'install est simple :
brew install trufflehog
trufflehog git https://github.com/user/project --only-verified
Le flag --only-verified c'est le truc important, ça teste si les secrets trouvés sont encore ACTIFS. Parce que trouver une vieille clé révoquée, on s'en fiche. Attention, ça ne marche pas sur les repos privés sans token d'accès.
Y'a aussi Nosey Parker qui fait le même genre de boulot mais perso, je trouve TruffleHog plus complet pour les clés cloud, même si Nosey Parker est plus rapide pour les gros repos.
Après si vous bossez avec des clés Google spécifiquement, cherchez le pattern AIza dans votre code. Un simple grep suffit :
grep -r "AIza" . --include="*.js" --include="*.py" --include="*.env"
Empêcher les fuites à la source
Scanner c'est bien, mais empêcher les secrets d'atterrir dans Git, c'est mieux. Et pour cela, rien de plus simple... Suffit d'installer un pre-commit hook.
git-secrets d'AWS fait exactement ça :
brew install git-secrets
cd mon-projet
git secrets --install
git secrets --register-aws
Du coup, chaque git commit vérifie automatiquement qu'il n'y a pas de clé AWS qui traîne. Vous pouvez ajouter vos propres patterns (genre AIza pour Google) :
git secrets --add 'AIza[0-9A-Za-z_-]{35}'
git secrets --add 'sk-proj-[0-9a-zA-Z]{48}'
Le deuxième pattern, c'est pour les clés OpenAI (format sk-proj-). D'ailleurs, stockez TOUT dans des fichiers .env et vérifiez que .env est dans votre .gitignore. Ça devrait être un réflexe ! Le piège classique c'est surtout le fichier .env.example qui contient en fait de vraies clés... c'est du vu et revu sur GitHub.
Pour aller plus loin, Vault de HashiCorp gère également vos secrets de manière centralisée avec du chiffrement, de la rotation automatique et des audit logs. C'est carrément le niveau supérieur notamment pour les équipes. C'est bien plus safe que le .env .
Détecter un vol avant la catastrophe
Notre dev mexicain a découvert sa facture APRÈS 48 heures. Deux jours, c'est une éternité alors voilà comment réagir en minutes, et pas en jours.
Sur Google Cloud, allez dans Billing > Budgets & Alerts. Créez un budget avec des seuils à 50%, 90% et 100% de votre budget mensuel. Activez les notifications par email ET par Pub/Sub pour déclencher une Cloud Function qui coupe automatiquement les clés si le seuil est dépassé.
Chez OpenAI, c'est dans Settings > Billing > Usage limits. Vous pouvez définir un hard cap mensuel. Au-delà... plus rien ne passe. Même chose à peu près pour Claude d'Anthropic aussi...
Et surtout, activez la rotation automatique de vos clés. Sur Google Cloud :
gcloud services api-keys list
gcloud services api-keys create --display-name="gemini-prod-$(date +%Y%m)"
gcloud services api-keys delete ANCIENNE_CLE_ID
Les restrictions d'API c'est pas un luxe donc sur chaque clé, limitez les services autorisés (Gemini uniquement si c'est son usage), les IPs sources et le nombre de requêtes par minute. Sauf si vous aimez les surprises à 5 chiffres sur votre relevé bancaire, une clé sans restriction, c'est une carte bleue sans plafond.
Perso, je me suis mis des alertes sur tous mes comptes cloud, que ce soit AWS, GCP ou Azure. Genre, si ça dépasse 50 balles en une journée... hop, notification sur le téléphone. Finalement, c'est 5 minutes de config qui peuvent vous éviter des mois de galère.
Perplexity Comet : une invitation de calendrier suffisait pour piller vos mots de passe 1Password
Des chercheurs en sécurité ont découvert deux failles dans Comet, le navigateur IA de Perplexity. Une simple invitation de calendrier piégée suffisait pour accéder aux fichiers locaux de la machine et prendre le contrôle d'un coffre-fort 1Password, le tout sans aucun clic de l'utilisateur.
Une invitation de calendrier, et c'est tout
L'attaque est d'une simplicité qui fait froid dans le dos. Les chercheurs de Zenity Labs, qui ont baptisé la faille « PleaseFix », ont montré qu'il suffisait d'envoyer une invitation de calendrier contenant des instructions malveillantes cachées. Quand l'utilisateur interagit avec cette invitation dans Comet, l'IA du navigateur exécute en toute décontraction les instructions, sans broncher. Pas besoin de cliquer sur un lien, pas besoin de télécharger quoi que ce soit : le simple fait de consulter l'événement suffisait. Le problème vient de ce qu'on appelle l'injection de prompt indirecte : l'IA ne fait pas la différence entre les instructions légitimes et le contenu malveillant planqué dans un calendrier.
Des fichiers locaux aux mots de passe
Deux failles distinctes ont été identifiées. La première permettait d'accéder au protocole file:// sans restriction, ce qui veut dire que Comet pouvait lire n'importe quel fichier sur votre machine. Les navigateurs classiques bloquent logiquement cela depuis des années, mais les navigateurs IA comme Comet ne respectent pas encore, hélas, les mêmes règles de sécurité. La seconde est plus grave : quand l'extension 1Password était déverrouillée dans Comet, un attaquant pouvait naviguer dans le coffre-fort, récupérer les identifiants et même changer le mot de passe du compte pour un verrouillage total.
Corrigé en deux temps
Perplexity a été prévenu du problème dès la fin octobre 2025, et un correctif a été déployé le 23 janvier 2026. Mais voilà, ce correctif n'était pas suffisant et les chercheurs ont réussi à le contourner sans trop de problème. Un second patch, plus efficace, a suivi le 13 février. L'accès au système de fichiers est désormais bloqué par défaut dans Comet. Mais attention : côté 1Password et blocage de domaines, les protections sont toujours à configurer manuellement par l'utilisateur.
On ne va pas se mentir, ce genre de faille rappelle que les navigateurs IA sont encore une technologie immature côté sécurité. Le fait qu'une invitation de calendrier puisse siphonner un coffre-fort 1Password est assez flippant. Et Comet n'est pas un cas isolé : LayerX a trouvé des problèmes comparables avec les extensions Claude Desktop, et Zenity avait déjà présenté des résultats similaires sur ChatGPT Enterprise et Gemini à la Black Hat en août dernier. Le vrai problème avec cette histoire, c'est que ces navigateurs veulent pouvoir tout faire à votre place, mais ils ne sont pas vraiment foutus de faire la différence entre une demande légitime et une vilaine attaque. Bref, prudence avec les navigateurs « intelligents ».
Sources : The Register , The Decoder
Demucs-rs - Séparez vos morceaux en stems depuis le navigateur
Séparer la voix, la batterie ou la basse d'un morceau, ça relevait du rêve d'audiophile il y a encore quelques années. Fallait installer Python, se taper Spleeter, galérer avec les dépendances CUDA... bref, un super truc de barbu. Mais ça, c'était avant, les amis !
Demucs-rs , une réécriture en Rust du modèle HTDemucs v4 de Meta, tourne maintenant directement dans votre navigateur grâce au WebGPU. Batterie, basse, voix, tout le reste..., chaque élément se retrouve ainsi isolé dans son propre fichier WAV. Et y'a rien à installer, puisque tout se passe côté client, sur votre machine.
Pour vous en servir, vous pouvez aller sur la web app , vous glissez-déposez votre fichier MP3 (ou WAV, FLAC, OGG, M4A... ça bouffe à peu près tout), et vous patientez... Le premier lancement télécharge le modèle (~84 Mo pour le standard), donc prévoyez une connexion correcte.
L'interface de la web app - vous glissez votre fichier et c'est parti
Comptez alors quelques minutes selon la durée du morceau. En sortie, vous aurez alors plusieurs fichiers WAV séparés que vous pourrez écouter, jouer en solo ou télécharger individuellement.
Les pistes séparées, prêtes à écouter ou télécharger
Trois modèles sont dispos. Le mode 4 pistes suffit dans 90% des cas. Il y a aussi le modèle 6 stems, ou plutôt htdemucs_6s, qui est pas mal pour du rock ou du jazz. Et pour les obsessionnels de la qualité, y'a le fine-tuned à 333 Mo... mais prévoyez une pause café, parce que ça va être long de fou !
Voilà, comme ça, si vous voulez faire un karaoké maison, vous virez la voix et vous gardez l'instrumental. Ou si votre truc c'est de sampler une ligne de basse d'un vieux morceau de funk ou encore pratiquer la guitare en jouant par-dessus le morceau original sans la partie guitare, c'est entièrement possible !
D'ailleurs, si vous aviez testé Spleeter avec Ableton à l'époque, c'est le même principe mais en BEAUCOUP plus simple !!
Perso, le fait que ça tourne dans le navigateur, c'est top, sans parler du fait que vos morceaux restent sur votre disque.
Maintenant, si la version navigateur vous semble un peu longue, y'a le CLI natif qui exploite Metal sur Mac et Vulkan sur Linux/Windows. Pour l'installer, clonez le repo et lancez make cli (Rust requis) :
git clone https://github.com/nikhilunni/demucs-rs
cd demucs-rs && make cli
Le binaire atterrit dans target/release/demucs, 24 Mo. Le modèle se télécharge au premier lancement.
Côté utilisation, c'est du gâteau :
demucs song.mp3 # 4 pistes dans ./stems/
demucs -s vocals chanson.mp3 # juste la voix
demucs -m htdemucs_6s -s guitar solo.flac # isoler la guitare
demucs -m htdemucs_ft morceau.mp3 # qualité max
En sortie, chaque stem est un fichier WAV. Vous virez le vocals.wav, vous gardez le reste... et tadaaa, karaoké instantané pour votre voix de casserole ! C'est carrément plus rapide qu'en WebAssembly.
Et si vous bossez dans un DAW sur macOS, y'a aussi un plugin VST3/CLAP pour faire la séparation directement dans Logic ou Reaper (sauf que bon, c'est macOS only pour l'instant, quoi).
Après sachez que sur certains passages très chargés, la voix peut baver un peu dans la piste "other" ou inversement mais pour du remix amateur ou du sampling, ça suffit largement !
D'ailleurs, j'sais pas si vous vous souvenez, mais les plugins IA d'Audacity embarquent aussi Demucs v4. Mais là avec Demucs-rs c'est natif et surtout indépendant d'Audacity.
Et bien sûr, tout est open source sous licence Apache 2.0 !
Amusez-vous bien !
YggTorrent hacké et fermé - L'arroseur arrosé
C'est la grosse actu du jour ! YggTorrent, le plus gros tracker torrent francophone, a fermé DÉFINITIVEMENT ses portes après une cyberattaque survenue le 3 mars 2026. Un site de piratage qui se fait... pirater. Oups !
Un hacker du nom de Gr0lum a revendiqué l'opération baptisée YGGLeak. D'après lui, il aurait exfiltré la base de données complète du site, soit environ 6,6 MILLIONS de comptes utilisateurs. Il s'agit d'emails, de mots de passe hashés en bcrypt, d'adresses IP, d'historiques de navigation... genre, le package complet. Donc pas exactement le genre de truc que vous voulez voir traîner dans la nature.
De leur côté, l'équipe d'Ygg a publié un long communiqué où ils se posent en victimes. Selon eux, un ancien admin viré aurait gardé des accès et orchestré le sabotage de l'intérieur. Ils parlent de "trahison" et jurent que les mots de passe étaient "hashés et salés" (en gros, pas en clair... mais bon, ça rassure moyen quand toute votre base est dans la nature).
Sauf que la version de Gr0lum raconte une toute autre histoire. Le hacker accuse la plateforme d'avoir stocké pas moins de 54 776 numéros de cartes bancaires (sans qu'on sache si c'est des numéros complets ou tronqués), d'avoir mis en place du tracking comportemental poussé et même du fingerprinting de wallets crypto via un script (Sci.js) qui détectait Phantom, MetaMask ou Trust Wallet sur les machines des visiteurs. On est donc carrément loooooiiiiin du petit tracker communautaire sur lequel vous téléchargiez vos ISO Linux ^^.
Et le dossier complet publié par Gr0lum va encore plus loin. Un module baptisé Security.php aurait collecté les données de cartes bancaires COMPLÈTES... numéro, CVV, date d'expiration, nom du porteur, le tout relayé via un processeur de paiement tiers. Plusieurs utilisateurs sur Reddit ont d'ailleurs signalé des prélèvements frauduleux après avoir payé sur le site. En bonus, Ygg utilisait un service de DDoS (stresscat.ru) pour matraquer des trackers concurrents comme la-cale.space et sharewood.tv.
D'ailleurs, faut remettre un peu de contexte. Le 21 décembre 2025, Ygg avait lancé son fameux "Mode Turbo" qui limitait les utilisateurs gratuits à 5 téléchargements par jour... sauf si vous passiez à la caisse (86 euros). Résultat, d'après les données exfiltrées, le chiffre d'affaires a carrément TRIPLÉ en janvier 2026 pour atteindre ~490 000 euros sur le seul mois. Sur l'ensemble, on parle de 5 à 8,5 millions d'euros de revenus, avec près de 250 000 commandes traitées. Du coup, pour un site soi-disant "bénévole", ça fait beaucoup, j'avoue.
Côté technique, le hack est un cas d'école. Gr0lum a trouvé un port SphinxQL (9306) exposé sans authentification sur un serveur de pré-production. De là, lecture de fichiers arbitraires, récupération d'un mot de passe admin en clair dans un fichier sysprep, puis rebond de serveur en serveur via SMB et SSH. Trois jours seulement et 19 Go de données exfiltrées. Contrôle total. Le serveur de pré-prod tournait sous Windows Server 2019 avec le pare-feu désactivé et Defender coupé. Du grand art !
Pour le blanchiment des revenus crypto, ça passait par Tornado Cash avec conversion en Monero via ChangeNOW... le combo parfait pour disparaître de la blockchain. L'équipe avait même acheté le domaine warezfr.com fin décembre 2025 et bossait sur un nouveau tracker baptisé RageTorrent. Ils voyaient loin.
Si vous aviez un compte sur Ygg, surtout si vous utilisiez le même email et le même mot de passe sur d'autres services (oui, on sait que c'est votre cas ^^), changez le ailleurs, car même avec du hash salé, sur 6,6 millions de comptes y'a forcément des mots de passe type "123456" qui vont tomber en quelques secondes. Vérifiez aussi sur Have I Been Pwned si votre adresse a fuité.
Ah et bonne nouvelle, y'a déjà un successeur. Un collectif nommé Utopeer a récupéré le catalogue et lancé ygg.gratis. Attention, aucune garantie de fiabilité là non plus, hein.... Comme d'hab, méfiance.
C'est un peu comme Bato.to en janvier dernier... les géants du piratage tombent les uns après les autres... après T411 en 2017, après Zone-Téléchargement, après Bato.to, c'est donc au tour d'Ygg de tirer sa révérence, sauf que cette fois, c'est pas la police qui a frappé, mais visiblement un de leurs propres utilisateur avec quelques compétences...
MilimoVideo - Le studio de cinéma IA 100% local
MilimoVideo, c'est un studio de production vidéo boosté à l'IA qui tourne entièrement en local sur votre ordi... pas de cloud, juste votre GPU qui mouline quoi...
Et contrairement à ce que vous pensez (je suis dans vos têtes !! lol), ce n'est pas un énième générateur prompt-to-video à la Sora . Non, il s'agit d'un vrai NLE ... ou plutôt un éditeur non-linéaire pour ceux qui découvre, avec une timeline multi-pistes, du trim au frame près et tout le toutim, sauf que derrière, y'a 4 modèles d'IA qui bossent ensemble main dans la main.
Du côté moteur, on retrouve donc LTX-2, un transformer dual-stream de 19 milliards de paramètres pour la génération vidéo. Text-to-video, image-to-video, interpolation de keyframes... c'est le package complet. Ensuite, pour les images, c'est Flux 2 Klein avec l'IP-Adapter qui maintient la cohérence visuelle de vos personnages d'un plan à l'autre, comme ça, finis les visages de vos acteurs qui changent toutes les 3 secondes.
Et y'a aussi SAM 3 pour la segmentation. Vous cliquez sur un objet dans la vidéo, hop, il le détecte et le suit alors automatiquement d'un bout à l'autre du clip. Et pour finir, Gemma 3 se charge d'améliorer vos prompts pour que les résultats soient plus "cinématiques".
Le truc cool, c'est surtout le système de "Story Elements" je trouve car avec ça, vous pouvez créer des personnages, des lieux, des objets, et vous les invoquez ensuite dans vos prompts avec un @Personnage. Du coup, le studio injecte les bonnes références visuelles pour garder une cohérence sur tout votre projet. Faut voir ça un peu comme des variables de code, mais pour du cinéma.
Et si vos plans dépassent 121 frames, le "Quantum Alignment" découpe la génération en morceaux et raccorde ces segments sans couture visible. Voilà comment les transitions entre bouts générés sont gérées proprement sans que vous ayez à lever le petit doigt. Magique hein ?
Pour voir ce que ça donne en pratique, voilà une démo qui montre le workflow complet :
Côté retouche, y'a aussi de l'inpainting (vous peignez un masque sur la vidéo et Flux 2 remplace la zone) et du tracking d'objets bidirectionnel. C'est carrément pas mal pour un projet open source sous licence Apache 2.0, vous ne trouvez pas ?
Après côté config, faut quand même du matos. Avec une carte NVIDIA, comptez 16 Go de VRAM (recommandés) et sur Apple Silicon, c'est M1 Max ou mieux avec 32 Go de RAM. Oubliez votre PC à 500 balles, quoi car en dessous de ces specs ça ne marchera pas.
L'ensemble s'installe via un git clone classique, le backend tourne sur FastAPI avec SQLite, le frontend sur React 18... et le tout communique en temps réel via SSE. Après, si vous êtes plutôt à la recherche d'un éditeur vidéo classique dans le navigateur , c'est pas le même délire, car là avec MilimoVideo on est dans la génération pure.
Bref, si les workflows ComfyUI à rallonge vous filent des boutons, MilimoVideo mérite donc le coup d'oeil.
Merci à Lorenper pour le partage !
Faux repos GitHub - Pourquoi c'est un problème
Vous avez peut-être vu ça passer y'a pas longtemps, les scientifiques ne savent plus démêler le vrai du faux dans leurs propres publications. À NeurIPS 2025 , 100 citations hallucinées ont été retrouvées dans 51 papiers acceptés et à l' ICLR 2026, sur plus de 75 000 reviews analysées, 21% étaient entièrement générées par IA.
Bienvenue dans le monde du doute permanent !
Maintenant, si vous pensez que ça ne concerne que les chercheurs, détrompez-vous car de mon côté, ce que j'observe, c'est que les faux repos GitHub, c'est le même fléau côté tech, et surtout un vrai problème pour tous ceux qui relayent des projets open source comme moi.
Vous avez peut-être vu passer mon article d'hier sur WiFi DensePose , un projet à 25 000 étoiles sur Github qui promettait de détecter les postures humaines via le signal WiFi. Le code Python est détaillé, crédible en surface, il y a des tas d'issues ouvertes avec de vraies questions d'utilisateurs différents, des tas de pull requests parfaitement crédibles, une documentation hyper léchée... et le tout est adossé à un vrai papier de recherche de Carnegie Mellon .
Pour moi, ça avait l'air carrément sérieux ! Donc j'en ai fait un article.
Sauf qu'après coup, différentes personnes ont creusé plus profondément le code (Merci Nicolas), et ont trouvé des choses assez étranges partout dans le code. En fait, le truc générait des données aléatoires en se faisant passer pour du traitement de signal WiFi. C'est du vibe coding à l'état pur et quand des gens ont posé des questions dans les issues... ces dernières ont été vite supprimées. Faut dire que le piège était quasi parfait.
Et c'est tout le problème ! Car pour évaluer si un projet GitHub est légitime, je me base sur plusieurs signaux. Le code, les issues et les PRs, le nombre de stars, la reprise sur Reddit ou Hacker News, les commentaires, les articles dans la presse et quand je peux (et là c'était pas le cas car ça demande pas mal de matos que j'avais pas), je teste évidemment... Mais du coup, quand TOUS ces signaux sont fabriqués de toutes pièces, y'a plus aucun repère !
Parce que figurez-vous que les étoiles Github, ça s'achète (y'a des services entiers dédiés à ça), les issues se génèrent par IA, le code compile, les tests passent, le README est nickel, et le développeur a d'autres projets crédibles sur son profil. Vraiment tout est conçu pour que ça fasse parfaitement illusion.
Et comme ce sont souvent des projets émergents sur des technos de pointe, y'a pas grand monde qui a le matos ni le temps de vérifier par soi-même. Du coup, voilà comment moi et d'autres, on se retrouve à relayer des projets bidon sans le savoir. Et dire que j'étais à 2 doigts d'acheter le matos pour tenter l'aventure...
Les chercheurs se fient au peer review, aux citations, à la réputation du journal et moi c'est pareil avec les stars, les contributions, et le relai médiatique. Sauf que dans les deux cas, l'IA a rendu ces marqueurs de confiance complètement bidons. C'est pour ça que je fais ce parallèle car de mon point de vue, c'est le même combat.
Et le pire, c'est que c'est même pas du code malveillant. Y'a pas de backdoor, pas de malware planqué, pas de minage crypto en douce. C'est juste du code qui donne l'ILLUSION de fonctionner, ou plutôt, qui PRÉTEND fonctionner. Tout ça apparemment pour faire ce qu'on appelle du "portfolio padding"... c'est-à-dire gonfler son CV de développeur avec des faux projets open source à des milliers de stars pour impressionner les recruteurs.
Perso, j'avoue ça me dépasse.
Maintenant, comme c'est nouveau pour tout le monde, il va falloir apprendre à éviter de tomber dans le panneau. J'y ai réfléchi un peu et finalement, ça passe par une analyse plus approfondie du code et de l'historique du projet... On peut par exemple vérifier le git log parce qu'un projet à 25 000 étoiles et 3 commits en 2 semaines, c'est louche, donc méfiance. Et surtout, faut chercher des retours d'utilisation concrets et des issues techniques pointues. Après encore faut-il avoir des compétences techniques assez poussées (par exemple en traitement du signal) pour capter ce qui y est raconté... Pas simple hein ?
Faudrait peut-être que je me fasse un skill un peu poussé pour qu'une IA soit capable de faire ce taf chiant à ma place. Je vais y réfléchir.
Bref, on est tous dans la même galère, à devoir douter de tout ce qui brille sur GitHub et ailleurs et ça c'est bien emmerdant.
Des sous-traitants de Meta pourraient regarder vos vidéos captées avec les Ray-Ban Meta
Savez-vous que Meta a vendu 7 millions de paires de Ray-Ban Meta l'an dernier ? Le succès commercial est dingue, mais une enquête du quotidien suédois SVD montre que des sous-traitants basés au Kenya visionnent certaines vidéos privées, enregistrées par les lunettes pour entraîner l'IA de Meta. La CNIL a ouvert une enquête.
7 millions de paires en un an
EssilorLuxottica a confirmé le chiffre : plus de 7 millions de lunettes connectées vendues en 2025. C'est trois fois plus que les 2 millions écoulés entre le lancement fin 2023 et début 2025. La gamme s'est élargie avec les Oakley Meta et un modèle haut de gamme à 800 dollars, le Ray-Ban Meta Display, qui ajoute un affichage tête haute. Le marché des lunettes connectées n'est clairement plus un sujet de niche, et Meta domine le segment.
Des sous-traitants qui voient tout ?
Selon l'enquête du quotidien suédois SVD, des milliers d'annotateurs de données basés au Kenya, employés par le sous-traitant Sama pour le compte de Meta, visionnent les vidéos captées par les Ray-Ban Meta pour entraîner ses modèles d'IA. Et ce qu'ils voient n'est pas toujours anodin. Les travailleurs rapportent être tombés sur des scènes de salle de bain, des moments intimes et des cartes bancaires filmées par les utilisateurs. Un employé raconte qu'un utilisateur portait ses lunettes pendant que son partenaire se trouvait dans la salle de bain. Les conditions d'utilisation de Meta précisent que les interactions avec l'IA peuvent être "examinées de façon automatique ou manuelle", mais on doute que les utilisateurs aient bien compris ce que "manuelle" veut dire dans ce contexte.
La CNIL et la LED qui ne sert à rien
Côté protection des personnes filmées, la situation n'est pas mieux. Les Ray-Ban Meta ont une petite LED blanche qui s'allume pendant l'enregistrement, censée prévenir les gens autour. Sauf que certaines bidouilles permettent de la masquer, et la CNIL l'a bien noté. L'autorité française a ouvert une enquête après une plainte et considère que l'intrusion dans la vie privée est "possiblement énorme". Des créateurs de contenu ont d'ailleurs utilisé ces lunettes pour filmer des passants à leur insu, la BBC ayant documenté le cas de pick-up artists filmant des femmes dans des lieux publics. Et puisque filmer dans un espace public reste légal en France, les victimes n'ont quasiment aucun recours. Des étudiants de Harvard ont aussi démontré qu'on pouvait coupler les lunettes à un système de reconnaissance faciale pour identifier des inconnus dans la rue et accéder à leurs données personnelles.
On ne va pas se mentir, j'adore mes Ray-Ban Meta que j'utilise quotidiennement, mais 7 millions de caméras portées sur le nez de gens qui se baladent partout, avec des vidéos qui finissent chez des sous-traitants au Kenya, c'est quand même un problème. La politique de confidentialité de Meta reste volontairement floue sur ce qui est collecté et sur qui regarde ces images. La petite LED de sécurité qui se neutralise facilement n'aide en rien.
Sources : Clubic , UCStrategies
Le fisc sud-coréen publie carrément ses mots de passe crypto dans un communiqué de presse
Le Service national des impôts sud-coréen a publié par erreur les phrases de récupération de portefeuilles crypto saisis lors d'une opération contre la fraude fiscale. Résultat, un inconnu a siphonné l'équivalent de 4,8 millions de dollars en quelques heures. Les fonds ont finalement été restitués, mais l'affaire fait quand même pas mal jaser.
La photo de trop
Il y a quelques jours, le fisc sud-coréen annonçait avoir mené des perquisitions chez 124 contribuables soupçonnés de fraude fiscale, pour un butin total de 8,1 milliards de wons, soit environ 5,6 millions de dollars en espèces, montres et biens de luxe. Pour communiquer sur l'opération, l'agence a partagé des photos des saisies avec la presse. On y voyait des liasses de billets, des objets de valeur, et plusieurs portefeuilles Ledger posés bien en évidence sur une table.
Sauf que sur au moins deux d'entre eux, la seed phrase, cette suite de mots qui donne le contrôle total d'un portefeuille crypto, était parfaitement lisible. Un inconnu a repéré l'aubaine, déposé un peu d'Ethereum sur le wallet pour couvrir les frais de transaction, puis exécuté trois transferts pour vider les 4 millions de tokens Pre-Retogeum qui s'y trouvaient. Valeur estimée : 4,8 millions de dollars quand même.
Un vol pour rien
Une vingtaine d’heures plus tard, les tokens ont été renvoyés à leur portefeuille d'origine. Pourquoi ? Parce que le Pre-Retogeum est un token quasiment invendable. Le volume de transactions quotidien sur les plateformes décentralisées ne dépassait pas 332 dollars au moment des faits. Concrètement, le voleur s'est retrouvé avec des millions en poche, mais sans aucun acheteur potentiel en face. Et comme toutes les transactions sont enregistrées sur la blockchain, toute tentative de revente aurait été immédiatement grillée.
Pas une première
C'est le deuxième incident du genre en Corée du Sud. En 2021, la police de Séoul avait perdu 22 bitcoins, soit environ 1,5 million de dollars, après les avoir confiés à un prestataire externe. Le vice-Premier ministre a donc ordonné un examen en urgence de la façon dont les administrations gèrent les actifs numériques saisis. Le fisc a présenté ses excuses, expliquant avoir voulu "fournir une information plus vivante au public", et a promis de revoir ses procédures de A à Z. La police a quand même été chargée de retrouver l'auteur du vol.
Franchement, publier la seed phrase d'un portefeuille crypto dans un communiqué de presse, il fallait quand même oser. C'est la deuxième boulette crypto du gouvernement sud-coréen, et visiblement, la gestion des actifs numériques par les administrations publiques est un sujet complexe pour les autorités.
Sources : the register , coindesk
ExifTool - Un PNG piégé peut pirater votre Mac
Si vous utilisez ExifTool sur macOS, j'ai une mauvaise nouvelle pour vous ! Une faille critique vient d'être découverte dans cet outil que tout le monde (moi y compris) utilise pour lire et modifier les métadonnées des fichiers et c'est pas joli joli.
Cette vulnérabilité, référencée en tant que
CVE-2026-3102
, touche toutes les versions jusqu'à la 13.49 et c'est spécifique à macOS. Cela permet à un attaquant de planquer des commandes système dans les tags de métadonnées d'un fichier image et quand ExifTool traite le fichier avec le flag -n... les commandes s'exécutent directement sur votre machine.
L'exploitation est ridiculement simple et 2 étapes suffisent. On vous envoie une image qui a l'air parfaitement normale, vous la passez dans l'outil pour lire ses métadonnées, et l'injection de commande se déclenche. L'attaquant peut alors ensuite télécharger des payloads malveillants ou carrément se servir dans vos fichiers sensibles.
C'est l'équipe GReAT de Kaspersky qui a trouvé le problème. Bon après, la bonne nouvelle c'est que Phil Harvey, l'auteur du soft, a déjà sorti le correctif dans la version 13.50, et ça depuis le 7 février dernier... donc ça fait presque un mois que le patch est dispo.
Du coup, si vous avez des scripts qui traitent automatiquement des images avec ExifTool sur votre Mac, par exemple dans un pipeline de
forensique
ou d'
analyse EXIF
, vérifiez ILLICO la version installée (exiftool -ver pour checker). Comme la complexité d'exploitation est faible, n'importe quel script kiddie pourrait s'en servir, donc autant agir vite.
Pour mettre à jour, un petit brew upgrade exiftool et c'est réglé (sinon, le .pkg est dispo sur le
site officiel
). Attention, pensez aussi à vos scripts automatisés qui lancent ExifTool en arrière-plan, car c'est souvent là que les vieilles versions trainent...
Allez, bonne soirée les amis !
80 ans d'ordinateurs résumés en 1 vidéo
Je connaissais pas la chaine YouTube Branch Education, et je suis content d'être tombé là dessus parce qu'il ont eu une idée un peu dingue qui devrait vous plaire. En fait, ils ont démonté physiquement plus de 60 ordinateurs, consoles et smartphones, dessoudé les puces des cartes mères, pris des centaines de photos, et tout reconstruit en modèles 3D... ou plutôt, en reproductions ultra-détaillées. Et comme résultat, ils ont sorti une vidéo de 33 minutes qui retrace 80 ans d'évolution informatique... et vous allez voir, c'est plutôt classe.
En fait, quand je dis "modèles 3D", je vous parle pas de schémas vaguement animés... Non, chaque machine a été modélisée, de l'ENIAC de 1945 jusqu'à la Nintendo Switch et pour les plus récentes, comme je vous le disais, l'équipe a carrément dessoudé les composants pour voir l'intérieur des puces.
La vidéo utilise d'ailleurs une analogie bien trouvée pour visualiser la puissance de calcul : les briques LEGO. En fait, c'est tout bête... un calcul par seconde c'est une brique 2×4.
Du coup l'ENIAC et ses 5 000 opérations par seconde, ça donne un petit cube de rien du tout, la Super Nintendo et ses 1,8 million d'instructions c'est un cube qui remplit une pièce entière et le premier iPhone c'est un cube de la taille d'un immeuble de 2 étages. Quand aux cartes graphiques actuelles avec leurs téraflops... on sort carrément du cadre !
L'ENIAC
Si vous aimez les briques LEGO et l'informatique , vous allez être servis.
Le truc génial, c'est que la vidéo ne se contente pas de lister des ordis avec leurs specs. En fait, elle découpe l'Histoire de l'informatique en 8 "âges" distincts, chacun avec ses propres avancées. Et ce que vous voyez ici, c'est la première partie qui couvre les trois premiers : la "transistorisation" (adieu les 17 000 tubes à vide de l'ENIAC), le packaging des transistors avec IBM et les circuits intégrés, et l'arrivée des premiers processeurs.
Parce que l'évolution des ordinateurs, c'est PAS juste la loi de Moore. Entre la Super Nintendo et la Switch, y'a 26 ans d'écart et les transistors ont été multipliés par 80 000... Mais la puissance de calcul c'est par 1,4 MILLION qu'elle a été multipliée !!
La vidéo explique aussi comment les géants de chaque époque finissent par se faire dépasser... IBM contrôlait 70% du marché dans les années 60-70... Intel qui a raté le virage du mobile dans les années 2010...etc. Le piège, c'est qu'à chaque nouvel "âge", les règles changent et ceux qui ne s'adaptent pas se font bouffer.
Perso, je trouve le passage sur l'ENIAC assez ouf. 30 tonnes de machine, 17 000 tubes à vide, et quand l'un d'eux claquait (et ça arrivait souvent), fallait retrouver lequel dans une salle entière de racks. Les transistors étaient finalement plus fiables... sauf que quand y en avait un de mort, bonne chance aussi pour le trouver.
La vidéo est en anglais, mais les sous-titres traduits automatiquement en français sont dispo. D'autres épisodes couvriront les 5 âges suivants, jusqu'aux processeurs IA donc abonnez vous à leur chaine (j'ai pas d'actions en bourse chez eux...). Si vous êtes du genre nostalgique de la tech d'antan , vous allez adorer !
Merci à Lorenper pour le partage !