Comment iOS 26.2 va améliorer ces 5 applications Apple

L’idée c’est de planquer du texte invisible à l’intérieur de n’importe quel caractère grâce aux sélecteurs de variation Unicode. Ces petits caractères invisibles se glissent après un emoji et peuvent encoder un message complet. À l’oeil nu, vous voyez juste un smiley. Mais en réalité, y’a peut-être tout un paragraphe caché dedans.

Dans cette vidéo, je vous montre donc comment utiliser l’outil open source de Paul Butler pour encoder et décoder vos propres messages. On teste aussi si ChatGPT arrive à lire ces messages cachés et je vous explique les applications concrètes comme le watermarking de contenu ou l’envoi de messages discrets.

C’est une technique à la fois fun et utile à connaître, que ce soit pour protéger vos créations ou juste pour impressionner vos potes geeks.

J’ai tout expliqué en 13 minutes, accessible même si vous n’y connaissez rien en Unicode. Et un grand merci à mes soutiens sur Patreon sans qui rien ne serait possible !

Enjoy !

Un système de fichiers compressé grâce à un LLM

Korben

Par :Korben

27 novembre 2025 à 13:02

Vous connaissez peut-être FUSE (Filesystem in Userspace), ce truc qui permet de créer des systèmes de fichiers custom sans toucher au noyau Linux. C’est grâce à lui notamment qu’on peut monter un Google Drive, un bucket S3 ou même un dossier distant via SSH comme un simple répertoire local.

Hé bien, Rohan Gupta a poussé ce concept jusqu’à l’absurde en créant LLMfuse, un système de fichiers où toutes les opérations sont gérées par un modèle de langage fine-tuné.

Ainsi, quand vous faites un ls, un chmod ou un cat sur ce filesystem, c’est un LLM qui répond et chaque opération FUSE devient une requête au modèle. Pour parvenir à ces fins, le développeur a entraîné un Qwen3-4B sur environ 15 000 paires prompt/completion générées à partir de simulations d’opérations filesystem. Le modèle a alors appris à lire le contenu des fichiers, modifier les métadonnées, et même à représenter l’arborescence complète en XML.

Bon, dit comme ça, ça ressemble à une expérience de savant fou un peu conne… Mais y’a un truc vraiment intéressant qui découle de tout ça. En effet, l’auteur a découvert que la combinaison du codage arithmétique avec son modèle fine-tuné permettait d’atteindre des taux de compression délirants. Sur un fichier texte classique, il obtient par exemple une compression 22 fois meilleure que gzip. Et pour une arborescence de fichiers représentée en XML, c’est environ 8 fois mieux que squashfs.

Alors comment c’est possible cette magie noire ? Bah ça remonte au théorème de Shannon de 1948 sur l’entropie où plus un modèle prédit bien les données, moins il faut de bits pour les encoder. Un LLM fine-tuné sur un type de données spécifique devient alors un compresseur hyper efficace pour ces données.

L’auteur est le premier à admettre que c’est une expérimentation, donc, pas de quoi vous emballer non plus… Après si vous souhaitez l’utiliser, vous avez besoin d’un GPU, que l’intégralité du système de fichiers tienne dans la fenêtre de contexte du modèle, et ça ne marche vraiment bien que sur des données textuelles. Pour vos vidéos 4K ou votre bibliothèque de jeux Steam, on repassera… snif…

D’ailleurs, le fait que lipsum.txt (le classique Lorem Ipsum) soit surreprésenté dans les données d’entraînement des LLM aide beaucoup à gonfler les chiffres de compression mais même sur d’autres types de textes “normaux” qui ressemblent à ce qu’on trouve sur Internet, les gains restent entre 5x et 20x par rapport à gzip.

Le code source est disponible sous licence MIT, avec notamment un utilitaire CLI appelé llmencode que vous pouvez tester en local si vous avez une bonne carte graphique sous la main.

Amusez-vous bien !

Source

HashJack - L'attaque qui met à mal les navigateurs IA

Korben

Par :Korben

27 novembre 2025 à 12:30

Les chercheurs de Cato Networks viennent de publier leurs travaux sur une nouvelle technique d’attaque baptisée HashJack, et l’idée c’est d’exploiter les fragments d’URL, vous savez le petit # suivi d’un truc à la fin des adresses web, pour injecter des instructions malveillantes dans les assistants IA intégrés aux navigateurs.

En temps normal, tout ce qui se trouve après le # dans une URL ne quitte jamais votre navigateur et c’est utilisé pour naviguer vers une section précise d’une page web, et les serveurs web ne voient jamais cette partie. Du coup, les outils de sécurité réseau non plus. Et c’est justement là que ça devient vicieux…

Car les assistants IA comme Gemini dans Chrome, Copilot dans Edge ou Comet de Perplexity ont accès à l’intégralité de l’URL, fragment compris. Un attaquant peut donc crafter une URL d’apparence légitime avec des instructions cachées après le #, et quand vous demandez à votre assistant IA de vous aider avec cette page, il va gentiment exécuter les commandes planquées. Cato Networks décrit ça comme la première injection de prompt indirecte capable de transformer n’importe quel site légitime en vecteur d’attaque.

D’après les tests de l’équipe de Cato, les scénarios d’attaque possibles sont variés puisque ça va du phishing classique où l’assistant vous donne un faux numéro de téléphone à appeler, à l’exfiltration de données vers des serveurs contrôlés par l’attaquant. Y’a aussi la désinformation avec de fausses infos boursières ou médicales, ou encore des instructions détaillées pour installer des backdoors.

Bref, c’est le jackpot pour les attaquants.

Niveau compatibilité de l’attaque, les trois principaux touchés sont Gemini pour Chrome, Copilot pour Edge et Comet de Perplexity. Bonne nouvelle quand même, Claude pour Chrome et Atlas d’OpenAI ne sont pas vulnérables, puisqu’iils n’accèdent pas directement aux fragments d’URL.

Côté réponse des éditeurs, c’est un peu le grand écart puisque Perplexity a classé le problème comme critique et a appliqué un correctif, Microsoft a fait pareil pour Copilot fin octobre mais par contre, Google a décidé de classer ça comme un “comportement attendu” et a marqué le bug en “Won’t Fix”.

Argh !! Donc si vous utilisez Gemini dans Chrome, vous êtes toujours exposé les amis !

Après faut relativiser quand même car l’attaque nécessite plusieurs étapes d’interaction de la part de l’utilisateur. C’est pas juste cliquer sur un lien et hop vous êtes pwned. Il faut visiter la page vérolée ET demander à l’assistant IA d’interagir avec le contenu. Mais bon, vu que de plus en plus de gens utilisent ces assistants pour des tâches quotidiennes, le risque existe.

D’ailleurs, HashJack s’inscrit dans une tendance plus large. Brave a publié une étude montrant que l’injection de prompt indirecte est un défi systémique pour toute la catégorie des navigateurs boostés à l’IA et des techniques similaires ont été testées avec succès contre Atlas de ChatGPT et d’autres. Même le CISO d’OpenAI admet que, je cite “l’injection de prompt reste un problème de sécurité non résolu à la frontière de la recherche”.

Voilà, si vous utilisez un Navigateur IA, soyez vigilant sur les URLs bizarres qu’on vous envoie et si c’est Gemini dans Chrome, peut-être qu’il vaut mieux attendre que Google se décide à considérer ça comme un vrai problème de sécu… ces fous !

Source

Vue lecture