60% des mots de passe hashés en MD5 peuvent être cassés en moins d'une heure... C'est ce que dit en tout cas
une étude de Kaspersky
publiée cette semaine qui se base sur +231 millions de mots de passe qu'on peut trouver sur le dark web et tirés de fuites ayant eu lieu entre 2023 et 2026. D'après leurs tests, 48% sont craqués en moins d'une minute et 60% en moins d'une heure. C'est pas très rassurant, surtout si votre base tourne encore au MD5.
Ce qui a changé ces dernières années, c'est surtout la puissance des GPU modernes qui n'a cessé d'augmenter. Par exemple, une RTX 5090 monte à 220 milliards de hash MD5 par seconde ce qui représente une augmentation de +34% par rapport à la RTX 4090 ! Du coup, louer un GPU cloud pour lancer une attaque par dictionnaire revient à quelques dizaines de centimes à quelques dollars de l'heure. C'est rentable hein ?
L'étude souligne aussi que 53% des mots de passe du corpus se terminent par des chiffres. Et là, du point de vue des règles hashcat, c'est du pain bénit car les crackers adorent la prévisibilité. Alors attention si vous administrez un service web avec une gestion de comptes utilisateur car les attaques modernes (dictionnaire + règles hashcat) règlent aujourd'hui son compte à une bonne partie du corpus et cela en moins d'une minute. Par contre, les mots de passe longs avec symboles variés résistent encore puisque c'est exponentiel ! Vaut mieux une phrase de passe avec plein de mots et facile à retenir du genre running-douche-afford-laborer-art-amber-deftly-acetone-lego-reoccupy qu'un mot de passe court et complexe comme 3d2^vO$RZ1.
Bref, MD5 pour les mots de passe c'est mort donc si vous avez encore ça dans vos bases, migrez moi tout ce bordel rapidement ! La migration maintenant, ça se fait vers Argon2id en priorité... Je balance pas ça au pif, hein, c'est le standard recommandé par OWASP et le NIST, et c'est memory-hard, donc les GPU ne peuvent pas juste brute-forcer des milliards de hashs par seconde comme avec MD5.
Après si votre stack est ancienne et qu'Argon2id n'est pas dispo, bcrypt reste une option solide. Dans tous les cas, évitez SHA-1, SHA-256 ou SHA-512 sans algorithme adaptatif car ils sont rapides par conception, donc tout aussi crackables que MD5.
Le chercheur en sécu Hyunwoo Kim vient de lâcher dans la nature Dirty Frag, un nouvel exploit kernel Linux qui enchaîne 2 vulnérabilités pour obtenir un accès root sur n'importe quelle distro majeure, avec un taux de réussite proche de 100%.
L'embargo devait tenir encore quelques semaines. Il n'a pas tenu.
Et problème (et c'est pour ça que je vous en parle) c'est que ça marche du feu de dieu, et que personne n'a encore de patch disponible !! Alerte rouge donc !!
La lignée "Dirty" a donc maintenant quatre membres.
Dirty COW
en 2016, avec ses 9 ans de présence silencieuse dans le kernel avant d'être découvert, Dirty Pipe en 2022,
Copy Fail
dont je vous parlais il y a tout juste 8 jours, découvert par une IA. Et maintenant Dirty Frag, qui s'appuie sur le même principe que Copy Fail tout en contournant sa mitigation connue.
Alors comment ça marche ?
Le concept du truc c'est l'abus d'un mécanisme tout à fait légitime du kernel Linux : splice(). Cette fonction permet de faire circuler des données entre deux descripteurs de fichiers sans les copier en mémoire. C'est très utile, très performant, mais dans certaines configurations, c'est surtout très catastrophique.
Dirty Frag exploite les modules réseau d'IPsec (ESP) et du protocole RxRPC, ainsi quand un attaquant utilise splice() pour faire passer une page du cache mémoire (disons, /usr/bin/su) dans un buffer réseau, le kernel effectue son chiffrement directement sur cette page en RAM et sans faire de copie.
Résultat, les premiers octets de /usr/bin/su en mémoire sont remplacés par du code malveillant qui ouvre un shell root. Un simple appel à su ensuite, et l'attaquant est root.
Deux CVE sont impliqués dans la chaîne. CVE-2026-43284 qui concerne les modules esp4 et esp6 et qui a été patchée depuis hier et CVE-2026-43500 qui concerne rxrpc et pour celle-ci, y'a aucun patch actuellement à l'heure où j'écris ces lignes.
Le fait de chainer les 2 exploits permet à chacun de combler les angles morts de l'autre. C'est un peu technique mais en gros, la variante ESP requiert les droits de créer un namespace utilisateur, ce qu'Ubuntu peut bloquer via AppArmor. Alors que de son côté, la variante RxRPC ne nécessite pas ce privilège, mais le module rxrpc.ko n'est chargé par défaut que sur... Ubuntu. Du coup, une fois combinés, ils couvrent toutes les distros majeures sans exception.
Hyunwoo Kim a reporté la faille aux mainteneurs des distribs le 30 avril dernier, avec un accord de divulgation coordonnée via [email protected]. Mais un tiers extérieur (appelons le "connard" ^^) a brisé l'embargo hier, d'où la publication immédiate du PoC, avec l'accord des maintainers, pour éviter qu'un exploit silencieux circule sans que personne soit prévenu.
Les versions testées et confirmées vulnérables sont donc Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, Fedora 44.
En gros, si vous avez un kernel compilé depuis début 2017, vous êtes dans le scope.
Tester avec Lima sur macOS
Si vous voulez reproduire ça dans un environnement contrôlé, l'idée c'est de lancer une Ubuntu 24.04 avec le kernel non patché et de faire comme ceci :
Et si tout se passe bien, vous obtenez alors un shell root sans faire paniquer le kernel comme chez moi ici :
Après le test, le page cache est contaminé donc avant de faire quoi que ce soit d'autre, faut le nettoyer. :
echo 3 > /proc/sys/vm/drop_caches
Ou plus simple, redémarrez la machine car la modification est uniquement en RAM, donc un reboot permet de repartir de zéro.
Alors que faire ?
Hé bien, comme aucun patch n'est disponible pour la plupart des distros à l'heure où j'écris ces lignes, vous pouvez vous mettre en boule et pleurer. Sauf si vous êtes sous AlmaLinux car eux ont déjà poussé des kernels corrigés. Après vous pouvez aussi sécher vos larmes si vous êtes sur une autre distro, et suivre cette remédiation qui vous prendra trente secondes :
Cette commande fait trois choses : elle blackliste les modules vulnérables pour qu'ils ne se rechargent pas au prochain boot, elle les décharge s'ils sont actifs, et elle nettoie le page cache au cas où il serait déjà corrompu.
Après c'est tranquille à faire car esp4, esp6 et rxrpc ne sont pas des modules que la plupart des machines desktop utilisent au quotidien. Les désactiver n'a donc aucun impact visible sur 99% des setups. Mais un serveur qui fait du VPN IPsec en mode transport ESP, lui, sera affecté...
En tout cas, surveillez ça de près car une fois que votre distro sortira le patch, faudra mettre à jour et rebooter.
Nouvelle alerte du côté de Node.js : une faille de sécurité critique a été découverte dans la bibliothèque vm2 : protégez vos applications de la CVE-2026-26956.
On connaît tous les grands noms des protocoles VPN : WireGuard, OpenVPN, IKEv2 (Surfshark VPN utilise les 3). Ce sont des bêtes solides, mais elles ont au départ été pondues pour des usages pro, avec des armées de serveurs en entreprise et des configs à rallonge. Puis on les a adaptés pour nous, les users lambda qui veulent juste binge-watcher une série sur Netflix ou checker ses mails sur le Wi-Fi crade du troquet du coin, sans se prendre la tête sur les détails techniques. Ça roule, mais c'est pas l'idéal.
Surfshark a dit stop au bricolage. Ils ont tout repris à zéro et lancé Dausos. Pas une énième couche de sauce marketing sur de l'existant, non : une architecture repensée de fond en comble. La promesse ? Vitesse, confidentialité et efficacité des ressources, sans un seul compromis. Et dans un écosystème où les VPN se battent sur le prix et les fonctionnalités cosmétiques, cette approche mérite qu'on s'y penche sérieusement. Je vais vous décortiquer tout ça, point par point, pour que vous pigiez bien ce que ça change concrètement.
Dausos en détail : pas une adaptation, une création native
Dausos, c'est le tout premier protocole VPN 100% maison chez Surfshark, taillé sur mesure pour les particuliers. Le nom ? Inspiré de la mytho balte, où "Dausos" évoque l'élévation et la protection divine, sympa comme clin d'œil pour un truc qui vous met à l'abri en ligne. L'idée centrale est de créer un tunnel qui colle pile à vos besoins, sans les contraintes des protocoles pros recyclés.
La grosse différence avec les classiques, c'est la gestion du trafic. La plupart des VPN font passer les datas de plein d'utilisateurs via des tunnels partagés sur un même serveur. C'est pratique pour l'opérateur (moins de ressources nécessaires), mais ça crée une surcharge permanente, des interférences potentielles entre sessions et un risque accru si un user foireux impacte les autres. Résultat : des perfs en dent de scie à certains moments et une sécurité des données pas toujours optimale.
Dausos inverse le principe. Chaque connexion (la vôtre) se voit coller un tunnel dédié et 100% isolé sur le serveur. Votre trafic ne croise jamais celui du voisin, même sur un même serveur bondé. Ça réduit les surfaces d'attaque (moins d'expositions aux fuites croisées), optimise les perfs en virant la contention ressource et renforce la confidentialité globale. C'est comme si vous aviez votre propre bande sur l'autoroute VPN, sans camion qui vous colle au cul.
Les briques techniques qui font la diff
Le protocole brille par ses choix d'implémentation pointus. Pas de demi-mesure ici. D'abord, le chiffrement : exit AES-GCM, la vieille garde fiable, mais datée. Place à AEGIS-256X2, un algo moderne taillé pour les CPUs récents (nouveaux Intel/AMD, Apple Silicon...). Plus rapide en chiffrement/déchiffrement, il bouffe moins de cycles processeur pour un niveau de sécu équivalent. Concrètement ? Votre débit reste au max, même sous charge.
Ensuite, la résilience post-quantique intégrée (voir aussi mon article sur
Surfshark et le post-quantique
). Ici ce n'est pas une rustine ajoutée après coup, l'architecture est née quantique-ready. Avec les ordis quantiques qui pointent le bout de leur nez (merci Google et consorts), ça protège vos données sensibles pour les 10-20 ans à venir. Ça pense à l'avance, quoi.
Troisième atout : l'adaptation dynamique. Dausos scanne votre réseau et votre hardware en live et ajuste les paramètres (MTU, compression, etc.) pour coller à la réalité. Fibre optique ? Full perf. Passage en 4G foireuse ou métro ? Stabilisation automatique sans drop. Pas d'interruption visible, juste du smooth.
Et pour la crédibilité l'outil à passé avec succès un audit indépendant par Cure53. Ces gars sont des pointures en sécu (ils ont bossé sur Signal, Proton, etc.) et le rapport est public, dispo pour tous. Pas de blabla, de la preuve béton.
Les gains concrets pour votre quotidien
Surfshark balance des chiffres : jusqu'à +30% de vitesse vs protocoles standards. Comme d'hab c'est à nuancer, hein, ça dépend de votre setup, du réseau et du serveur choisi, etc. Sur une fibre stable, c'est perceptible, mais pas fou. Par contre, en mobilité ou réseaux chiants (vacances, events), l'adaptation dynamique fait des miracles. Moins de lag, une connexion plus stable, que demande le peuple ?
tunnel vpn classique
L'isolation trafic ? C'est moins flashy, mais crucial. ça réduit les risques de fuites croisées et d'attaques par corrélation (un attaquant qui matche patterns entre différents utilisateurs). Côté mobile, l'efficacité en termes de ressources sauve un peu plus de batteries. L'optimisation CPU/GPU c'est une autonomie augmentée de 10-20% en VPN constant. Un détail, mais un détail qui change tout en déplacement.
Comment l'activer et disponibilité
Pour l'instant, Dausos est en bêta exclusive sur macOS via App Store. Pas de date ferme pour iOS/Android/Windows/Linux, mais un rollout progressif est annoncé (logique pour éviter le chaos).
Si vous avez la version DMG (non-App Store), désinstallez-la d'abord pour éviter les conflits, Bêta oblige des instabilités sont possibles. Si ça vous arrive, revenez vers WireGuard/OpenVPN en attendant, et signalez le bug au support.
Ce que j'en pense pour de bon
Ce que j'apprécie toujours autant, après des années à l'utiliser, c'est cette cohérence et ce côté proactif à toute épreuve. Surfshark ne fait pas semblant : opter pour des tunnels dédiés par utilisateur, ça coûte un bras en infra serveur (plus de ressources allouées, moins d'optimisation low-cost), mais ça livre du premium pur jus.
L'AEGIS-256X2, c'est du costaud. Ils sortent des rails AES-256-GCM usés jusqu'à la corde, avec un algo qui colle aux CPUs modernes et validé par la crème de la communauté crypto. Vision long-terme aussi avec le post-quantique natif, rare chez les VPN grand public, qui attendent souvent que le problème explose pour patcher à la va-vite.
La limite bêta macOS seulement ? Ouais, frustrant pour les autres plateformes (vous n'avez qu'à avoir du goût), mais malin comme tout. Mieux vaut roder le bestiau sur un terrain contrôlé avant de lâcher les hordes sur iOS, Android ou Windows. Ça évite les bad buzz et les forums en feu.
Est-ce que Dausos seul justifie de plaquer votre VPN actuel pour Surfshark ? Nope, pas encore. Mais pour les geeks qui kiffent l'innovation transparente, sans bullshit marketing, c'est un argument massue. Une vrai killer feature dans un océan de copies carbone.
Bref, à tester ou pas ? Si vous êtes sur macOS, foncez, c'est gratos et rapide à setup. Sur autre chose ? Gardez l'œil ouvert sur les annonces, ce protocole pourrait bien devenir la reférence pour les VPN perso d'ici 2-3 ans. La sécurité et les perfs, c'est pas un one-shot, c'est du boulot continu. Dausos en est l'exemple parfait. C'est grâce à ce type d'évolution discrète et solide que Surfshark a su s'imposer et creuser l'écart sur la durée.
Le tarif du moment
Si vous voulez tester Surfshark, sachez qu'un engagement de 24 mois + 3 mois offerts revient à 57,67€ TTC (soit moins de 2,15€/mois). La garantie satisfait ou remboursé de 30 jours vous laisse le temps de vérifier que l'outil correspond à vos besoins. Et l'abonnement protège tous vos appareils, sans limite.
*Transparence : il s'agit d'un lien affilié. Vous payez le même prix, mais une commission me revient si vous passez par là. C'est ce qui me permet de publier ce type de contenu sans recourir aux bannières publicitaires ou aux articles sponsorisés non identifiés. *
Palo Alto Networks (PAN-OS) : une faille de sécurité zero-day (CVE-2026-0300) exploitable sans authentification et déjà exploitée par des cybercriminels.
Une nouvelle menace cible l'application Mobile Connecté de Microsoft, utilisant CloudZ RAT et Pheno pour exfiltrer discrètement vos données mobiles sur Windows.
Y'a des génies du crime, et puis y'a Peter Stokes, alias Bouquet, 19 ans, presque toutes ses dents, double nationalité américano-estonienne, et surtout membre de Scattered Spider, le collectif qui a déjà plumé MGM et Caesars.
Le mec a tellement bien réussi son coup qu'il est parti se payer des vacances à Tokyo, sauf que pour fêter ça, en bon teubé, il a posté sur Snapchat des selfies de sa grosse tête avec un tout nouveau bijou : un collier en diamants HACK THE PLANET. Comme dans
le film de 1995
mais en plus bling bling !
Hé bien grâce à ça, le FBI a fini par le coffrer lors de son escale d'Helsinki.
Bouquet (oui, j'ai pas précisé mais c'est son pseudo) opérait donc dans le groupe Scattered Spider, ce collectif d'ados anglophones qui ne s'embête pas avec des failles zero-day parce que de toute façon, ils ne sauraient pas les utiliser.
À la place, ils ont leur propre méthode super technique vous allez voir... ils appellent le support IT de la cible et embobinent un pauvre mec pour qu'il reset le 2FA d'un admin.
Et voilà comment notre cher Bouquet a pu sortir 100 Go de données d'un revendeur de produits de luxe (la plainte désigne sobrement la "Company F", mais ça pue Harrods d'après la presse anglaise) en seulement quelques heures, réclamé 8 millions de rançon, et causé plus de 2 millions de dégâts.
Du coup, plainte fédérale à Chicago, 6 chefs (wire fraud, conspiracy, computer intrusion comme ils disent là-bas avec l'accent cowboy), + extradition vers les USA en cours. C'est le bouquet final pour lui ! (Oui, jeu de mots, roh roh roh).
Tyler Buchanan, 24 ans, autre membre du club, a de son côté déjà plaidé coupable d'avoir empoché 8 millions en crypto via du SMS phishing. Faut dire qu'en 2024, le groupe envoyait fièrement des messages genre "Fuck off, FBI" aux agents fédéraux qui enquêtaient sur eux.
Très rebelles nos kikoulool ! Enfin, comme vous le savez, qui fait le malin tombe dans le ravin, et qui fait le mariole avec un collier finit avec des bracelets ^^. (J'ai pas trouvé mieux, déso... lol)
Bref, Bouquet vient à lui seul d'écrire le chapitre 1 du manuel "Comment ne PAS être un cybercriminel à succès" et dont la règle n°1 est : "Si t'es recherché par le FBI, ne montre pas ton butin sur Snapchat"
Alors que les Fédérations françaises de football, de rugby, de tir, de golf ou encore le Ministère des Sports ont récemment été visés par des cyberattaques, une tendance se confirme : le monde du sport devient une cible privilégiée des cybercriminels. Tribune Cymbioz – Derrière cette multiplication des incidents, plusieurs facteurs structurels émergent : explosion […]
Une vulnérabilité silencieuse menace les systèmes Linux depuis près de dix ans. Baptisée CopyFail, cette faille permet à n’importe quel utilisateur d’élever ses privilèges pour devenir le maître absolu de la machine et la paralyser. Un danger majeur sur lequel revient Yaroslav Kikel, de l’Équipe de Recherche et d’Analyse Globale (GReAT) de Kaspersky. Tribune – […]
Énorme retournement de situation. ShinyHunters, le groupe qui
avait piraté Rockstar via Anodot mi-avril
et exigé une rançon, a fini par balancer ses données sur internet quand l'éditeur a refusé de payer. Le but était de faire mal financièrement à Take-Two, sauf que les chiffres révélés étaient si impressionnants que l'effet a été l'exact opposé. En effet, l'action Take-Two est passée d'environ 202 dollars à presque 208 dollars en une matinée, soit une capitalisation boursière qui a pris à peu près un milliard de dollars dans la foulée. C'est fou !
Ce que les hackers ont mis en ligne, c'est notamment que GTA Online génère
plus d'un million de dollars par jour
, soit autour de 500 millions par an. Et tout cela, 13 ans après le lancement sur 5 plateformes différentes, simplement grâce aux Shark Cards (les cartes prépayées du jeu). Pour un éditeur qui s'apprête à sortir son GTA 6 en novembre prochain, faut dire que ce genre de stats montre qu'ils ont les reins hyper solides, ce qui rassure les investisseurs.
Bref, au lieu de sanctionner Take-Two pour la fuite de données et la faille Anodot, Wall Street y a simplement vu la confirmation de ce que tout le monde soupçonnait : la machine à cash de Rockstar tourne à plein régime, et un éventuel GTA 6 au même niveau de monétisation, même partielle, ferait exploser les compteurs !!
Rockstar a également publié une déclaration courte et carrée pour dire que la violation n'aurait pas d'impact sur le studio ou le dev de GTA 6. Rien de plus...
C'est donc un retournement de situation assez fou côté où des hackers, en cherchant à frapper l'éditeur au portefeuille, lui ont en fait permis de gonfler sa capitalisation d'un milliard. Difficile de faire pire en termes de coup raté ^^. A moins que les gens de ShinyHunters aient fait un peu de délit d'initié en amont avant de leaker les données... allez savoir ??
Reste à voir si la SEC ou les autorités européennes voudront enquêter sur cette fuite, sachant qu'au passage des données salariés et de joueurs ont aussi été exposées. Quoiqu'il en soit, côté marché, c'est plié et le cours de l'action est resté bien haut !
Si vous avez committé du code depuis VS Code depuis mi-avril, allez tout de suite vérifier vos messages de commit car vous avez peut-être un nouveau co-auteur que vous n'avez jamais embauché.
En effet, Microsoft a discrètement basculé le réglage par défaut de l'éditeur pour ajouter Co-authored-by: Copilot <[email protected]> à des commits que VS Code considérait à tort comme contenant des contributions IA, même quand vous n'avez pas utilisé Copilot, et même quand vous avez explicitement désactivé toutes les fonctions IA.
Et le résultat de tout ce bordel, vous pouvez le lire dans la
PR #310226
qui a explosé sur GitHub : 372 pouces baissés contre 2 levés, 30 réactions "confused", et des dizaines de commentaires furieux.
L'
issue de suivi #314311
, ouverte ensuite par dmitrivMS pour faire son point public, a elle aussi reçu un torrent de réactions virulentes. Tu m'étonnes, ils font vraiment n'importe quoi...
Maintenant si vous êtes dans ce cas, vous pouvez neutraliser ça immédiatement, ajoutez dans votre settings.json :
"git.addAICoAuthor": "off"
C'est le seul réglage qui marche vraiment, parce que dans la version buguée même chat.disableAIFeatures à true n'arrêtait pas le soucis. Et pour votre historique déjà bien pollué, un git rebase -i ou un git filter-branch permettra de virer les contributeurs parasites dans vos derniers commits. Mais après bonne chance si vos commits sont déjà sur des PR mergées chez d'autres. Là c'est mort...
Ce que les devs reprochent à Microsoft, c'est pas vraiment d'avoir créé l'option (elle existait depuis VS Code 1.110 en opt-in tranquille). Non, le vrai problème c'est surtout ce qu'il y a derrière cette vilaine Pull Request... 2 fichiers touchés, le change de "default", absolument AUCUNE description, une seule review d'approbation toute nulle, et hop, c'est mergé OKLM.
Pour un changement qui touche les messages de commit de plusieurs millions de devs, ça sent quand même la décision unilatérale prise à l'arrache entre 2 portes...
Et puis surtout il y a le
bug #313064
qui a fait basculer l'histoire de la simple polémique à la grosse colère communautaire.
En effet, la nouvelle valeur par défaut "all" attribuait à Copilot des complétions qui ne venaient PAS de Copilot. Un dev explique par exemple avoir tapé son code à la main, vérifié son message de commit, supprimé toute suggestion Copilot, écrit le sien à la main... et a finalement retrouvé quand même Co-authored-by: Copilot dans le git log final.
Et comme le mode "je ne veux pas d'IA" n'était pas plus respecté, l'IA s'auto-créditait quand même sur tout et n'importe quoi.
Côté communauté, le ton est monté très vite. Sur le fil GitHub, y'en a un qui écrit que, je cite, "C'est pas une régression, c'est de la fraude. On ne peut pas s'attribuer un travail qu'on n'a pas fait." et un autre dev parle de "vandalisme" pur.
Windows Central
a même sorti un titre choc : "This could cost people their jobs", parce que dans les boites en fintech ou sur du code soumis à audit, faire passer du code humain pour de l'IA-assisté peut coller un fail d'audit et faire péter des contrats. Ah bah ouais, j'avoue que je n'y avais pas pensé...
Heureusement, Microsoft a fini par bouger puisque dans VS Code 1.118 , le default est finalement repassé de "all" à "chatAndAgent", déjà moins agressif. Et dans la
PR #313931
, dmitrivMS a remis le default à "off" pour la version 1.119, dont le déploiement public commence justement aujourd'hui.
Bien sûr, la Product Manager a fait son mea culpa public, en reconnaissant, je cite que "la manière dont c'était implémenté et déployé n'a pas atteint le niveau de correction attendu", ce qui, dans la langue corporate, veut dire "on est des branleurs, déso, bisous".
Maintenant ce qui revient souvent dans les commentaires, c'est que Claude Code et Codex CLI font la même chose par défaut quand ils committent, sauf que la différence, c'est que ces agents committent quand C'EST EUX qui ont écrit le code, donc le co-author est tout a fait légitime.
VS Code, lui, modifiait des commits écrits à la main par des humains donc c'est pas du tout le même problème. Et pour le coup, sur Codex CLI la mention reste aussi désactivable via une option alors que chez Claude Code même si c'est pareil, l'opt-out n'est pas toujours très respecté d'après les retours que j'ai pu lire.
En tout cas, ce loupé arrive dans un climat déjà tendu puisque Microsoft pousse Copilot dans Windows, dans Notepad, dans Office, et même
jusque dans l'écosystème Apple via une extension Xcode
, dans tous les coins, et beaucoup de devs commencent à voir chaque nouveauté MS à travers ce prisme. La théorie du "ils gonflent les KPI Copilot pour les boards et les analystes" de plus en plus crédible et comme personne n'aime se sentir transformé en stat marketing, tout le monde commence à se barrer des outils et services Microsoft.
Maintenant, si vous voulez vraiment vous protéger des prochains coups foireux de M$, je vous propose d'abord de basculer sur
VSCodium
ou
Zed
, deux éditeurs sans télémétrie ni AI imposée. Et ensuite, déménager vos repos chez
Codeberg ou Forgejo
en suivant la procédure de migration que je vous donne dans cet article Patreon, comme ça même si Microsoft fait n'importe quoi côté éditeur, votre code n'est plus chez eux côté forge.
À voir maintenant si Microsoft tient ses promesses sur le consentement explicite avant toute mention d'agent IA, ou si on rejouera ce film encore et encore tous les 6 mois sur une autre fonctionnalité.
La célèbre messagerie chiffrée n'attend pas l'arrivée des ordinateurs quantiques pour agir. Proton Mail intègre dès aujourd'hui un nouveau standard de chiffrement pour contrer les hackers qui interceptent vos messages maintenant en vue de les déchiffrer dans quelques années.
Depuis début avril 2026, les programmes d'installation de DAEMON Tools sont infectés par un logiciel malveillant suite à une attaque de type supply-chain.
Tous les utilisateurs de Proton Mail peuvent désormais activer la protection post-quantique sur leur compte afin de protéger leurs e-mails des futures menaces.
Protéger son domicile nécessite de choisir une solution adaptée parmi alarmes, caméras ou télésurveillance. Le coût varie selon le niveau de sécurité, le logement et les besoins spécifiques individuels actuels.
Connexion
