Dans un article publié le 16 janvier 2026, les chercheurs en cybersécurité de Huntress ont mis en lumière la face cachée d’une extension de blocage de publicités pour Chrome et Edge. Nommée NexShield, elle provoque volontairement le plantage du navigateur en préparation de l’assaut final.

Changer de navigateur sur iOS a longtemps eu un arrière-goût de recommencement : favoris à la main, mots de passe à re-synchroniser, historique perdu en route. Google s’apprête à gommer une bonne partie de cette friction. Dans Chrome 145 Beta pour iOS, une nouvelle option guide l’utilisateur pour importer directement depuis Safari ses favoris, son historique et […]

L’article Google facilite le passage de Safari à Chrome sur iPhone avec un nouvel outil d’import est apparu en premier sur BlogNT : le Blog des Nouvelles Technologies.

Lire plus

Lire plus

Google déploie Chrome 144 sur Windows, macOS et Linux. Cette version corrige dix failles de sécurité, dont plusieurs sont jugées critiques.

Cet article Chrome 144 est disponible, Google s’attaque à la sécurité a été publié en premier par GinjFo.

Je crois que j’ai ENFIN trouvé le lecteur de musique que j’aime !

J’ai jamais été consommateur de musique, de qualité lossless du moins (Rikito, si tu me lis), au point d’être un gros membre de WCD et ses successeurs où je ne suis d’ailleurs plus.

Mais en bon geek curieux, j’ai toujours eu un œil sur les solutions d’hébergement/téléchargement/streaming de musique. Je me contente d’ajouter des .torrent à Decypharr/AllDebrid, ne voulant plus stocker directement chez moi (hormis un peu de partage via DecypharsSeed) et ne supportant plus Lidarr (même en hébergeant mon instance pour les métadonnées).

Il m’a cependant été impossible de trouver un lecteur (Web et/ou iOS/Android) qui réponde à mes besoins : beau & moderne, simple, avec recherche par genres, artistes similaires, playlists et paroles notamment. En gros : une copie de Spotify.

J’ai relancé il y a quelques semaines mon Navidrome qui prenait la poussière dans un vieux reste de stack audio auto-hébergée. Après avoir des années utilisé Subsonic et dérivés, Plex ou encore Jellyfin pour jouer un peu de musique, j’étais passé sur Navidrome pour sa modularité et « bonne allure » de serveur de streaming dédié à ce type de médias.
Comme je veux l’utiliser avec Decypharr/AD, j’ajuste les volumes en conséquence :
– /mnt/:/mnt/:rshared
– /mnt/Fichiers/decypharr/qbit/music:/music:ro

Et j’utilise toujours Spotify, en sus de Deezer, pour les métadonnées. Pour le reste des variables d’environnement, tout est expliqué dans la documentation.
Pour cet article je n’ai mis que 3 albums en test.

services:
  navidrome:
    image: deluan/navidrome:latest
    user: 1000:1000
    ports:
      - "4533:4533"
    restart: always
    environment:
      - TZ=Europe/Paris
      - ND_BASEURL=https/audio.domain.tld
      - ND_AGENTS=spotify,deezer
      - ND_DEEZER_ENABLED=true
      - ND_ENABLEDOWNLOADS=false
      - ND_ENABLEEXTERNALSERVICES=false
      - ND_HTTPSECURITYHEADERS_CUSTOMFRAMEOPTIONSVALUE=SAMEORIGIN
      - ND_IGNOREDARTICLES="The El La Los Las Le La Les Os As O A Du"
      - ND_IMAGECACHESIZE=10GB
      - ND_LASTFM_ENABLED=false
      #- ND_LISTENBRAINZ_BASEURL=https://mb.domain.tld
      - ND_LISTENBRAINZ_ENABLED=true
      - ND_RECENTLYADDEDBYMODTIME=true
      - ND_SCANNER_ENABLED=true
      - ND_SCANNER_SCHEDULE="0 * * * *"
      - ND_SCANNER_WATCHERWAIT="10s"
      - ND_SCANNER_ARTISTJOINER= " | "
      - ND_SCANNER_FOLLOWSYMLINKS=true
      - ND_SCANNER_PURGEMISSING=always
      - ND_SEARCHFULLSTRING=true
      - ND_SPOTIFY_ID=xxx
      - ND_SPOTIFY_SECRET=xxx
      - ND_SUBSONIC_ARTISTPARTICIPATIONS=true
    volumes:
      - /mnt/:/mnt/:rshared
      - /mnt/Docker/navidrome:/data
      - /mnt/Fichiers/decypharr/qbit/music:/music:ro

Mais il me manquait encore surtout un tri par genres et… une WebUI plus moderne.

Je suis tombé sur Feishin qui est à la fois un client (desktop/Web) de streaming pour Navidrome, Jellyfin et Subsonic et un agrégateur de serveurs puisqu’on peut en ajouter plusieurs. On peut donc imaginer un partage de serveurs de musique Jellyfin entre amis.

Gavé d’options !

Attention, c’est avant-tout un client desktop (tous OS) et donc ne propose pas de système d’authentification. Ce qui fait que lorsque comme moi on l’installe en Docker pour en profiter hors LAN (via mon iPhone notamment), il faut ajouter un système d’authentification tel qu’Authelia ou bien « à l’ancienne », via Nginx proxy Manager dans mon cas :

Sur une machine Linux (ou dans un Docker), installer de quoi créer le mot de passe encoder à filer ensuite à NPM.

sudo apt install apache2-utils

Puis, créer un fichier htpasswd avec un utilisateur et un mot de passe dans un dossier auquel accède NPM

root@StreamBox:/home/aerya/docker/npm/data# htpasswd -c htpasswd aerya
New password:
Re-type new password:
Adding password for user aerya

Et on peut alors passer ça en paramètre dans NPM pour avoir le fameux pop-up d’identification quand on va sur l’URL concernée

Comme j’ai déjà Navidrome qui tourne sur https://audio.domain.tld, je mets Feishin sur https://music.domain.tld

Et le compose de Navidrome est très léger vu que ce n’est qu’une interface pour un autre outil

services:
    feishin:
        container_name: feishin
        image: 'ghcr.io/jeffvli/feishin:latest'
        environment:
            - SERVER_NAME=Musique
            - SERVER_LOCK=false
            - SERVER_TYPE=navidrome
            - SERVER_URL=https://audio.domain.tld
            - TZ=Europe/Paris
        ports:
            - 9180:9180
        restart: always

À la 1ère connexion il faut ajouter ton serveur. Il propose par défaut celui configuré dans le compose du dessus

Sur AndroidTV, j’utilise Symfonium de Tolriq, que j’ai bien connu dans une autre vie. Application payante (onetime 7-10€ selon frais) mais qui vaut le coup, jetez un œil à sa présentation sur le PlayStore.

Et sur iPhone, j’avais Amperfy et suis passé depuis peu sur Arpeggi, qui est en TestFlight (et closed source hélas…).

Dans l’immédiat, prière de bloquer tous les navigateurs IA pour minimiser l’exposition au risque.

Un document Gartner publié la semaine dernière fait cette recommandation aux CISO.

Google n’y est peut-être pas resté insensible. Quelques jours plus tard est en tout cas apparu, sur son blog sécurité, un post consacré à la navigation agentique dans Chrome – expérimentée depuis septembre.

Le groupe américain y met en avant son approche de défense « hybride » mêlant couches déterministe et probabiliste. Il l’accompagne d’un lien vers un autre post, daté de juin et centré sur l’injection de prompts dans Gemini (sur l’application et au sein de Google Workspace).

Ce post évoquait déjà l’approche de défense en couches. Entre autres techniques listées :

• Entraînement de Gemini avec des données antagonistes pour améliorer sa résilience
• Constitution d’un dataset de vulnérabilités pour entraîner des modèles classificateurs capables de détecter des instructions malveillantes
• Ajout d’instructions dans les pour rappeler à Gemini de se concentrer sur les tâches demandées et d’ignorer les éventuelles instructions antagonistes
• Détection et masquage des URL suspectes sur la base de la technologie Safe Browsing
• Demande de confirmation par l’utilisateur pour certaines actions et fourniture d’informations lorsqu’une attaque est bloquée

Paraphase, spotlighting… Des stratégies pour ignorer le contenu problématique

Dans son post sur la navigation agentique dans Chrome, Google se réfère aussi à ses « principes de sécurité pour les agents ». Synthétisés dans un document publié au printemps, ils figurent plus en détail dans un livre blanc sur la sécurité de Gemini 2.5, publié en parallèle. Parmi les stratégies de défense qui y sont présentées, outre celles susmentionnées, il y a la paraphrase, qui consiste à faire réécrire les données entrantes par une IA distincte afin d’invalider les instructions problématiques.
Il y a aussi le spotlighting. Cette technique de prompt engineering implique d’insérer des marqueurs dans les données d’entrée pour permettre au modèle de distinguer les blocs de tokens non fiables. Microsoft y a dédié un article l’an dernier. Il y expose trois variantes « cumulatives » dites délimitation, datamarking et encodage. La première démarque l’emplacement d’un input dans le prompt en y affixant un ou plusieurs tokens spéciaux. La deuxième va plus loin en entrelaçant un token spécial sur l’ensemble du texte. La troisième rend la démarcation encore plus évidente en transformant le texte avec un algo de type base64 ou ROT13.

Une technique d’extraction de flux made in DeepMind

Dans le modèle de sécurité agentique de Chrome, le spotlighting contribue à ce que Google appelle l’user alignment critic. Objectif : assurer que le modèle préfère suivre les instructions utilisateur et système plutôt que celles issues de contenus externes. L’architecture adoptée dans ce cadre s’inspire du pattern dual-LLM. (en complément au modèle principal, planificateur, un modèle secondaire intervient à chaque fois qu’on travaille avec du contenu non fiable). Elle se nourrit aussi d’une technique que DeepMind a appelée CaMeL. Son principe, dans les grandes lignes : extraire explicitement les flux de contrôle et de données depuis les requêtes fiables, de sorte que les données non fiables que récupère le LLM ne peuvent jamais impacter le flux du programme.

Le modèle secondaire mis en œuvre dans Chrome vérifie chaque action après sa planification et détermine si elle sert ou non l’objectif déclaré. Il ne reçoit que des métadonnées, ce qui évite son empoisonnement par le contenu externe. En cas de rejet d’une action, le modèle principal reçoit du feed-back pour reformuler son plan. Si les rejets s’enchaînent, le contrôle peut être donné à l’utilisateur.

Les défenses statiques comme le spotlighting ont leurs limites face aux attaques adaptatives. Dans ce contexte, il est nécessaire de durcir le modèle principal, en s’appuyant sur ses capacités de raisonnement. On touche là à l’autre composante de l’approche « hybride ». Dans ce domaine, en plus des éléments déjà abordés, on peut élaborer des modèles chargés d’analyser les plans d’actions des agents et de prédire le risque de résultats indésirables.

Les règles same-origin adaptées aux agents

Certaines briques fondamentales du modèle de sécurité de Chrome sont perpétuées dans l’agentique. L’isolation de sites en fait partie (les pages liées à des sites distincts sont toujours placées dans des processus distincts, chacun exécuté dans sa propre sandbox). Il en va de même avec les règles d’origine commune (same-origin policy). Elles limitent la façon dont les documents et les scripts d’une certaine origine peuvent interagir avec les ressources d’une autre origine. Par exemple, en bloquant l’utilisation de JavaScript pour accéder à un document dans un iframe ou pour récupérer des données binaires à partir d’une image intersites. Adaptées aux agents, elles ne leur permettent d’accéder qu’à des données dont l’origine a un lien avec la tâche à effectuer ou que l’utilisateur a explicitement partagées.

Pour chaque tâche, une fonction de portillonnage décide quelles origines sont pertinentes. Elles sont alors séparées en deux ensembles, suivis pour chaque session. D’un côté, les origines en lecture seul (Gemini peut en consommer le contenu). De l’autre, celles en lecture-écriture (Gemini peut réaliser des actions, comme cliquer et saisir des caractères). Si l’origine d’un iframe n’est pas sur la liste des éléments pertinents, le modèle n’en voit pas le contenu. Cela s’applique aussi au contenu issu de l’appel d’outils.

Comme dans le cas de l’user alignment critic, les fonctions de portillonnage ne sont pas exposées au contenu externe.
Il est difficile de trouver le bon équilibre du premier coup, admet Google. C’est en ce sens que le mécanisme actuellement implémenté ne suit que l’ensemble lecture-écriture.

Le programme bug bounty de Chrome clarifié pour l’agentique

Lors de la navigation vers certains sites sensibles (contrôle sur la base d’une liste), l’agent demande confirmation à l’utilisateur. Même chose pour la connexion à un compte à partir du gestionnaire de mots de passe Google. Et plus globalement dès lors que le modèle juge avoir à effectuer une action sensible. Il peut alors solliciter la permission ou donner la main à l’utilisateur.

Google en a profité pour mettre à jour les lignes directrices du programme de bug bounty de Chrome. Il y clarifie les vulnérabilités agentiques qui peuvent donner lieu à une récompense.

La plus élevée (20 000 $) vaut pour les attaques qui modifient l’état de comptes ou de données. Par exemple, une injection indirecte de prompt permettant un paiement ou une suppression de compte sans confirmation par l’utilisateur. Ce montant ne sera attribué qu’en cas de fort impact, de reproductibilité sur de nombreux sites, de réussite sur au moins la moitié des tentatives, et d’absence de lien étroit avec le prompt utilisateur.

La récompense maximale est fixée à 10 000 $ pour les attaques qui peuvent engendrer l’exfiltration de données sensibles. Et à 3000 $ pour celles qui contourneraient des éléments de sécurité agentique.

Illustration générée par IA

The post Google défend le modèle de sécurité agentique de Chrome appeared first on Silicon.fr.