Justin Poehnelt, Senior Developer Relations Engineer chez Google, vient de balancer sur Github un outil en ligne de commande (CLI), codé en Rust qui permet de faire un truc trop pratique, à savoir piloter entièrement Workspace depuis le terminal. Ce logiciel nommé GWS est donc capable de gérer Gmail, Drive, Calendar, Sheets et sept autres services Google d'un coup. Et en plus, comme il a été conçu pour les agents IA, donc c'est pas juste pour vous et votre terminal !
Une fois installé via npm, cargo, brew ou un binaire pré-compilé, vous tapez gws auth login pour vous authentifier via OAuth et vous pouvez ensuite attaquer onze services depuis votre shell : Drive, Gmail, Calendar, Sheets, Docs, Chat, Admin, Apps Script, Tasks, Workspace Events et Model Armor.
Niveau archi, au lieu de hard-coder chaque commande dans le binaire, gws interroge tout simplement le Discovery Service de Google au démarrage et reconstruit son arbre de commandes à la volée. Du coup quand Google ajoute un endpoint à l'API Sheets, le CLI le voit apparaître tout seul. C'est trop bien parce que ça évite de devoir attendre une release pour utiliser un éventuel nouveau service de Google. Et pour un agent IA qui re-fetch le schéma à chaque run, c'est plutôt une bonne idée.
Donc en plus de démarrer en moins d'une seconde, GWS crache des sorties en JSON structurées, y'a un mode --dry-run qui montre la requête sans l'envoyer, et de l'auto-pagination via --page-all. Et côté commandes utilitaires, vous avez aussi les + qui sont des helpers cousus main tels que gws gmail +send, gws drive +upload, gws calendar +agenda, gws sheets +append, gws gmail +triage et un gws gmail +standup-report qui résume vos mails de la semaine en quelques lignes.
Le repo embarque aussi 40+ skills d'agent prêts à l'emploi du type "résume mes mails non lus" ou "génère mon rapport", une extension
Gemini CLI
qui s'installe avec gemini extensions install https://github.com/googleworkspace/cli, et le helper +sanitize-response qui fait passer la sortie par Model Armor (le filtre anti-prompt-injection de Google Cloud) pour éviter les réponses bizarres.
En gros, c'est un outil pensé pour faire piloter votre Workspace par Claude, Gemini ou n'importe quel agent. Comme ça vous allez pouvoir écrire un workflow qui lit vos mails non lus, en fait un résumé, le poste dans un Chat et classe tout ça proprement dans Drive... sans avoir à toucher à la souris ni avoir à utiliser votre cerveau léthargique. Elle est pas belle la vie ?
Sauf que. Le projet porte le disclaimer "This is not an officially supported Google product", et un employé Google a confirmé sur le thread Hacker News (presque 1000 points, quand même) que c'est un projet DevRel. Comprendre : pas de SLA, pas de roadmap garantie, pas d'équipe SRE qui veille au grain. Vous savez comment ça finit chez Google avec ce genre de statut !
Bref si vous êtes chaud pour tester, le binaire est dispo ici . Maintenant reste à voir si Google lui donnera un statut officiel ou si GWS s'éteindra discrètement comme tant d'autres projets internes oubliés...
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 linux-distros@vs.openwall.org. 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 :
# Cloner, compiler, et lancer
git clone https://github.com/V4bel/dirtyfrag.git
cd dirtyfrag
sudo apt install gcc -y && gcc -O0 -Wall -o exp exp.c -lutil && ./exp
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 :
sh -c "printf 'install esp4 /bin/falseninstall esp6 /bin/falseninstall rxrpc /bin/falsen' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"
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.
Source : https://github.com/V4bel/dirtyfrag
Vous le savez, il y a un algorithme dans votre téléphone qui décide ce que vous allez lire aujourd'hui et il s'appelle Google Discover.
Google Discover, c'est le flux d'articles qui apparaît quand vous ouvrez l'appli Google sur Android ou iOS, ou que vous swippez à gauche depuis la home de votre smartphone Android et Chrome mobile aussi. Et pas besoin d'avoir cherché quoi que ce soit puisque Google analyse votre historique, connait vos centres d'intérêt, et vous sert ainsi des articles « adaptés » en continu.
Sauf que l'algo confond souvent « ce que vous voulez lire » avec « ce qui génère le plus de clics ». Et là, ça part en couille sévère...
Du coup vous vous retrouvez avec des articles qui expliquent que le cash va être interdit dans deux mois, que les conducteurs avec une moustache vont devoir repasser le permis, ou que l'Union Européenne s'apprête à requalifier la pizza comme « sandwich plat » pour l'assujettir à une nouvelle taxe.
Et pendant ce temps, les vraies actus tech que vous aimez tant, elles, se noient quelque part entre deux horoscopes et une pub déguisée en article. Et c'est d'ailleurs ça le gros défaut de tous les flux algorithmiques : ils optimisent l'engagement mais pas l'exactitude. On est tous humain, alors forcément un titre alarmiste battra toujours un article de qualité sobre et bien sourcé. L'algo se contrefout royalement de respecter les 3 neurones qui vous reste... ^^
Mais Discover a quand même un truc pas con ! En fait depuis fin de l'année dernière, Google permet de suivre directement des éditeurs sur le réseau, un peu comme un flux RSS mais sans lecteur à installer ni boîte mail à gérer. Suffit de cliquer sur un bouton et hop, les articles de vos sources préférées remontent en priorité dans votre feed Google Discover !
Par exemple, si vous voulez voir les articles de Korben.info apparaître dans votre flux (de la vraie tech, sourcée, sans moustaches ni taxes pizza), c'est par là, il suffit d'aller sur mon profil Google Discover et de cliquer sur le bouton "Suivre sur Google".
Et comme ça, une fois abonné, mes publications remonteront directement dans votre Discover. Perso, je trouve ça pas mal du tout comme système.
Bref, si vous ne voulez pas que votre téléphone vous apprenne demain que les chats seront bientôt recensés comme « animaux de surveillance passive » par un nouveau décret gouvernemental, pensez à bien choisir vos sources !
Et pour trouver les liens de vos médias préférés, vous pouvez passer par cet outil de Julien .
Speedtest.net c'est pratique, sauf que ça a été racheté par Accenture en 2026 et chaque test envoie votre IP, le nom de votre FAI et votre localisation à leurs serveurs...
Alors pourquoi ne pas adopter LibreSpeed , l'alternative open source que vous hébergez chez vous, et qui ne contient aucun sans tracker ??? L'outil est signé Federico Dossena, ça a été lancé en 2016 et c'est sous licence LGPL v3. Et ce que ça mesure c'est la vitesse du download, de l'upload, le ping, le jitter , et ça relève aussi l'adresse IP et le nom de votre FAI.
Côté déploiement, c'est du classique. Vous déposez les fichiers sur votre serveur, dont speedtest.js et speedtest_worker.js pour le frontend, vous configurez le backend via config.json, et hop c'est lancé. Un simple VPS ou n'importe quelle autre machine sur votre LAN fera l'affaire.
Et comme vous choisissez le serveur de test, y'a pas de saturation par d'autres utilisateurs, pas de route réseau bizarre vers un data center à l'autre bout de l'Europe et surtout, les résultats sont parfaitement reproductibles donc pour les "homelabers" (c'est comme ça qu'on dit ?) ou les équipes réseau, c'est assez chouette.
Il y a aussi le mode multi-serveur pour comparer des endpoints, le partage de résultats via lien unique, et un CLI librespeed avec ses flags --server et --host pour les fans du terminal. Des backends officiels en Go et Rust existent aussi sur le github de
librespeed
, signe que le projet est sérieux.
Et surtout, les résultats sont fiables, sauf si votre serveur plafonne à 20 Mbit/s et dans ce cas, vous mesurerez sa liaison et pas la vôtre. Ça coule de source, mais je tenais à le préciser quand même...
Voilà, l'interface est moche, en tout cas beaucoup plus que celle de Speed.cloudflare.com , par contre l'essentiel est là. Et surtout, les mesures restent chez vous plutôt que de partir ailleurs.
Le YouTubeur « Flamethrower » a documenté un projet aussi inutile que satisfaisant : utiliser un hamster comme source d'énergie pour charger son smartphone.
Le principe est simple sur le papier. Vous prenez un hamster, vous le mettez dans une roue, vous reliez la roue à un générateur, et au bout d'une nuit complète d'activité rongeuse, vous obtenez assez de jus pour démarrer la charge d'un téléphone. Pas pour finir la charge, hein. Juste pour la commencer.
Le maker a utilisé un module CJMCU-2557, basé sur la puce TI BQ25770. C'est un composant fait pour récupérer de très petites quantités d'énergie : il accepte des tensions entre 0,1 et 5,1 V (avec un minimum de 0,6 V pour démarrer), un courant max de 0,1 A, et il intègre un supercondensateur pour stocker ce qui rentre.
La roue du hamster fait tourner un petit générateur à courant continu, qui alimente le BQ25770, qui charge le supercondensateur, qui charge ensuite des cellules Li-ion 18650 récupérées sur des batteries usagées. Avec ce relais, l'énergie hamster finit par se stocker dans des batteries qui peuvent ensuite charger un téléphone via un câble USB classique. Bricolage propre.
Maintenant la vraie question : combien d'énergie produit réellement un hamster ? Eh bien très peu en fait.
La chaîne complète de conversion (mécanique vers électrique, supercondensateur vers cellule 18650, cellule vers téléphone) génère des pertes à chaque étage. Du coup, après une nuit, vous avez juste assez pour commencer la charge, pas pour la terminer. C'est très loin du panneau solaire, et encore plus loin d'une simple prise murale.
Mais bon, ce n'est évidemment pas le but. Le projet existe pour démontrer qu'on peut techniquement le faire, pas pour révolutionner la production d'énergie domestique. Le hamster a fait sa petite course, le maker a sa vidéo YouTube avec une vraie puce dedans, et tout le monde apprend quelque chose sur la récupération d'énergie à très basse puissance. Les commentaires de Hackaday ironisent d'ailleurs déjà sur le potentiel du hamster pour la "domination mondiale", ce qui résume assez bien le ton du projet.
Bref… un hamster qui charge votre téléphone, c'est mignon, c'est inutile, et c'est exactement pour ça que c'est génial.
Source : Hackaday
Le Royaume-Uni a mis en place via l'Online Safety Act un système de vérification d'âge obligatoire sur les plateformes accessibles aux mineurs, avec contrôles biométriques à la clé pour estimer l'âge à partir d'un selfie.
Sur le papier, c'était la grande solution pour empêcher les ados d'accéder à TikTok, Instagram ou aux sites pour adultes. En pratique, c'est l'inverse : les enfants britanniques se passent les méthodes pour passer outre, et les méthodes en question sont parfois franchement drôls
En fait, selon une étude d'Internet Matters, près de la moitié des enfants britanniques (46 %) considèrent les systèmes de vérification d'âge comme faciles à contourner, et un tiers reconnaissent l'avoir déjà fait.
Les méthodes documentées vont de la classique fausse date de naissance au VPN, mais aussi à des techniques plus créatives : envoyer une vidéo du visage de quelqu'un d'autre, voire d'un personnage de jeu vidéo, et le meilleur : se dessiner une moustache au feutre pour tromper l'estimation d'âge faciale. J'adore.
Côté plateformes, c'est du coup difficile à gérer. L'Online Safety Act prévoit des amendes importantes contre les services qui laisseraient passer ces contournements, mais le régulateur Ofcom rame pour qualifier la responsabilité quand le gosse a triché lui-même avec une astuce que la plateforme n'a pas su détecter.
Internet Matters relève d'ailleurs que les adultes profitent aussi de ces failles, ce qui complique encore le tableau quand un majeur peut piquer la session d'un mineur, ou inversement.
L'autre limite, c'est la captation des données biométriques. Pour vérifier qu'un gosse est bien un gosse, il faut analyser son visage, ce qui veut dire stocker (ou au moins traiter) une image biométrique d'un mineur.
Plusieurs experts ont déjà soulevé le paradoxe : pour protéger les enfants, on les oblige à transmettre leur visage à une plateforme étrangère. Et si la plateforme se fait pirater (spoiler : ça arrive régulièrement), on a une fuite de données très sensibles dans la nature.
Vous l'avez compris, une régulation qui se fait contourner par un coup de feutre sous le nez, c'est probablement le signe qu'il faut revoir la copie.
Source : Independent
Bon, maintenant que vous avez vos chaînes IPTV qui tournent via Tunarr ou xTeVe, votre flux XMLTV est super propre. Mais il vous manque un seul truc : Un guide de programme potable.
Hé bien GridTV développé par l'ami JohnnyBeGood est là pour ça !
GridTV c'est une interface web en PHP/JS/CSS qui transforme toute source XMLTV compatible en guide TV façon grille horizontale, avec l'indicateur "maintenant" visible en permanence, un barre de progression du programme en cours, et les émissions passées qui se retrouvent automatiquement grisées. C'est exactement ce à quoi ressemble le guide TV de votre box opérateur, mais en mieux, et pour votre propre contenu !
Pour le déploiement, Docker est le chemin recommandé plutôt que de tout configurer à la main : git clone, cd GridTV, docker compose up -d, et hop, vous ouvrez localhost:8080.
Un assistant de setup vous demandera alors votre source EPG obligatoire et une playlist M3U si notamment vous voulez utiliser le player intégré, et une fois validé, vous retombez directement sur la grille.
Ça se met en place en moins de 5 min mais si vous préférez installer sans Docker, ou plutôt sans la couche conteneur, il y a également sur le Github des exemples de config pour Apache et Nginx dans la doc. Caddy fonctionnera aussi et la doc concernant Traefik, c'est pour le cas où GridTV tourne en Docker mais derrière un reverse proxy.
Côté fonctionnalités, le player HLS s'ouvre en PiP (Picture in Picture) dans un coin en cliquant sur une chaîne et le multi-EPG vous permettra de configurer plusieurs sources avec un petit switch. GridTV propose aussi des rappels de programme via notifications navigateur, 15 minutes avant la diffusion. Mais pour en profiter, l'onglet du browser doit rester ouvert et les notifs autorisées.
Et il y a aussi possibilité de générer un export PDF/PNG du guide sur 24h. C'est pas indispensable mais ça permet pour ceux qui veulent d'imprimer le programme de la soirée.
Chaque visiteur de l'instance peut aussi utiliser / paramétrer ses propres URLs XMLTV/M3U, car rien n'est stocké côté serveur. Hé oui, tout passe par le localStorage du navigateur donc vous pouvez partager votre instance avec autant de monde que vous voulez, ça n'a pas d'impact.
La version Steampunk
Et il y a même des thèmes genre cyberpunk, steampunk, magazine ou le thème par défaut. Et la page de monitoring admin expose également une sonde accessible via un endpoint compatible Uptime Kuma qui renvoie le code HTTP 200 si tout va bien. Sinon, ce sera du code 503. Bref, ça vous connaissez...
Bref, l'outil est jeune mais bien construit et une démo live tourne ici guide.demo.johnnybegood.fr . A suvire donc....
Et si vous cherchez juste des listes de chaînes IPTV gratuites , c'est par là !
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, 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.
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.
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.
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).
Étapes simples :
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'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.
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. *
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"