Vos parents n'ont pas besoin d'une nouvelle leçon sur les liens à éviter. Ils ont besoin d'un navigateur qui voit le piège dans lequel ils sont sur le point de tomber — et qui dit quelque chose, à temps, avec des mots qu'ils comprennent.

Certains d'entre vous ont déjà reçu ce coup de fil. Celui où la voix de votre mère est déjà basse, déjà petite, et où elle dit je crois que j'ai fait quelque chose de mal sur l'ordinateur. D'autres l'attendent encore. L'objectif de ce billet est de décrire, en détail, la machinerie que nous avons construite pour que ce coup de fil arrive moins souvent — et, quand il arrive, pour que les dégâts s'arrêtent à un avertissement plutôt qu'à un compte vidé.

L'industrie de l'attaque a toujours chassé les personnes âgées.

L'hameçonnage n'a jamais été un jeu d'esprit. C'est un jeu probabiliste : une chaîne industrielle qui génère de fausses pages de connexion par milliers, usurpe des marques familières, écrit des messages au ton urgent et les diffuse par e-mail, SMS, réseaux sociaux et appels téléphoniques. Il suffit à l'attaquant qu'une seule personne, un seul jour, dans un seul moment d'inattention, tape un mot de passe dans la mauvaise case. Les grands-parents, les parents, les voisines veuves, toute personne qui a grandi en faisant confiance à une lettre de banque reçue par la poste — ils ne sont pas lents, ils sont confiants. Les attaquants le savent, et ils les ciblent délibérément.

Une seule personne âgée, assise chez elle, reçoit tout le poids d'une industrie mondiale de l'attaque — SMS, e-mails, appels téléphoniques, messages sociaux, faux avis de livraison, arnaques au remboursement. Les conseils anti-hameçonnage supposent qu'elle peut trier tout cela à la main. Elle ne le peut pas.

Les conseils de sécurité adressés aux grands-parents se résument depuis toujours à des variations sur soyez plus vigilants. Vérifiez l'URL. Survolez le lien. Ne faites pas confiance à l'expéditeur. Le problème n'est pas que les grands-parents sont négligents. Le problème est que l'industrie de l'attaque emploie des professionnels dont le métier à plein temps consiste à vaincre cette fameuse « vigilance ». L'écart entre les personnes qui défendent et celles qui attaquent est, aujourd'hui, gênant.

Ce que nous avons construit, en un coup d'œil.

Quand une page se charge dans Bromure, un petit inspecteur tourne à l'intérieur de la VM scellée du navigateur. Il observe la page comme un portier soupçonneux à une entrée — il regarde l'URL, les formulaires, le texte visible, les liens, les éventuels QR codes, et même ce que la page tente d'écrire silencieusement dans le presse-papiers. Si quelque chose cloche, les constats de l'inspecteur voyagent par un canal isolé vers un modèle. Le modèle lit les signaux, décide d'un verdict, rédige une explication en une phrase, et le renvoie. Bromure affiche le verdict sous forme de bannière sur la page. Une page d'hameçonnage avérée est redirigée vers un avertissement de site bloqué avant de pouvoir tromper qui que ce soit.

Le pipeline complet. Les étapes de la zone bleue tournent à l'intérieur de la VM invitée en bac à sable. Les étapes de la zone orange tournent sur le serveur Bromure. La barre jaune est un canal vsock — pas le réseau — qui transporte les constats entre les deux.

Le reste de ce billet, c'est le comment. C'est volontairement détaillé. Si vos parents sont la raison pour laquelle vous lisez ceci, n'hésitez pas à filer jusqu'à Où vont réellement vos données — et sachez que la réponse courte est : la fonctionnalité est désactivée par défaut, elle demande votre consentement, et tout ce qu'elle fait est documenté ci-dessous.

Étape un — l'inspection locale.

Avant que quoi que ce soit ne quitte votre ordinateur, un content script s'exécute dans la VM invitée. Il inspecte la page en plusieurs passes indépendantes. Aucune de ces passes n'est coûteuse. Toutes s'exécutent dans le navigateur, dans votre propre ordinateur, dans le même bac à sable scellé que la page elle-même.

Champs de mot de passe, dès qu'ils apparaissent

À l'instant où un <input type="password"> est attaché au DOM — avant même que vous ne l'ayez activé — l'inspecteur a déjà noté le domaine et vérifié si vous avez déjà entré un mot de passe ici auparavant. Première fois sur un nouveau domaine ? C'est déjà, à soi seul, un signal.

Structure du formulaire

Pages de connexion seules, sans navigation. Formulaires qui envoient leur POST vers un domaine différent de celui de la barre d'adresse. Formulaires prétendant appartenir à une marque dont le logo est hébergé sur un autre hôte. Chacun, pris séparément, est faible. Ensemble, ils font pencher la balance.

Incohérence de marque

Si la page affiche « Apple ID » mais que le domaine n'est pas celui d'Apple, ou si le logo est servi depuis un hôte suspect, cette incohérence est notée. Aucun appel réseau nécessaire — il s'agit simplement de reconnaissance de motifs sur ce qui est déjà présent dans la page.

Domaines homoglyphes

Les domaines comme аррӏе.com — rendus de façon identique à « apple.com » mais composés de sosies cyrilliques — sont presque toujours de l'hameçonnage. L'inspecteur les détecte en comparant la forme rendue à un ensemble de caractères connus pour être confondus.

Vocabulaire des arnaques

« Confirmez votre mot de passe. » « Vérifiez votre compte. » « Vous avez été sélectionné. » « Cliquez ici pour réclamer votre prix. » Chaque phrase est un signal faible. Une page qui en contient trois, à l'intérieur d'un formulaire de connexion, sur un domaine dont personne n'a jamais entendu parler, c'est une autre histoire.

QR codes et charges dans le presse-papiers

Un QR code qui se décode en URI de paiement crypto vers un portefeuille sans rapport. Une page qui écrit silencieusement une commande shell dans votre presse-papiers tout en vous disant d'« appuyer sur Win+R et coller ». Ce sont des schémas d'attaque modernes qui contournent tous les filtres traditionnels.

Un pré-filtre local s'assure également que l'inspecteur n'embête pas le serveur pour des sites dont personne n'a à s'inquiéter. Les cent mille premiers domaines de la liste Tranco, plus un ensemble trié d'une trentaine de fournisseurs SSO (Google, Microsoft, Okta, Apple, etc.), sont silencieusement ignorés tant que rien d'autre ne paraît suspect. La vraie banque de votre mère, sa vraie pharmacie et sa vraie messagerie ne feront jamais l'objet d'un rapport au serveur.

Si, après l'inspection locale, rien n'est intéressant, l'histoire s'arrête là. Aucune requête ne quitte l'ordinateur.

Étape deux — le second avis.

Si le dossier est intéressant — ou si un champ de mot de passe vient d'apparaître sur un domaine inconnu — un rapport structuré est envoyé pour évaluation. Pas une capture d'écran. Pas tout le DOM. Un résumé borné et assaini de signaux.

Ce que le modèle voit réellement. La page de gauche peut sembler parfaite au pixel près pour un humain ; le modèle, à droite, travaille à partir d'un petit dossier structuré de signaux — pas à partir des pixels rendus.

Le paquet contient l'URL, le domaine, le texte visible (plafonné aux alentours de 800 caractères, débarrassé des caractères de contrôle), un résumé de chaque formulaire (types de champs, libellés des boutons et URL d'action), les champs sensibles détectés, le titre et les principaux en-têtes de la page, l'hôte d'où provient l'image du logo, les drapeaux d'incohérence de domaine et d'homoglyphe, les signaux d'alerte au niveau de l'URL (marque dans un sous-domaine, punycode, tirets en excès), les drapeaux structurels (uniquement formulaires de connexion, autocomplétion du mot de passe désactivée, favicon en data-URI, iframes cachées), le contenu des QR codes décodés le cas échéant, et les charges inscrites silencieusement dans le presse-papiers. Toutes les chaînes sont plafonnées à de petites longueurs ; les tableaux sont plafonnés à de faibles comptes ; les caractères de contrôle ne survivent pas.

Sur le serveur, le dossier est confié à Claude Haiku 4.5 — un modèle petit et rapide. Le prompt système apprend au modèle à traiter tout ce qui se trouve dans le dossier comme de la preuve médico-légale non fiable : à supposer que la page a été construite par quelqu'un qui savait que le prompt existait et qui l'a écrite pour le tromper. Le prompt guide le modèle à travers neuf vérifications ordonnées (analyse du domaine, usurpation de marque, structure de la page, collecte d'identifiants, liens suspects, contenu frauduleux, QR codes, charges dans le presse-papiers, synthèse finale) et exige qu'il émette un seul objet JSON :

{
  "verdict": "phishing" | "suspicious" | "safe",
  "confidence": 0.0,
  "reason": "une courte phrase, en langage simple"
}

Les seuils sont délibérément calibrés. Au-dessus de 0,85, le verdict est phishing et le site est bloqué. Entre 0,4 et 0,84, il est suspicious et une bannière d'avertissement s'affiche. En dessous de 0,4, il est safe et rien n'est montré. Un seul signal faible — un mot d'arnaque, un favicon incohérent — ne suffit pas à franchir la barre. On dit explicitement au modèle qu'un faux positif sur la pharmacie de votre grand-mère est pire qu'une arnaque médiocre qui passe.

Deux voies rapides contournent entièrement le modèle quand la réponse est déjà évidente :

Raccourci d'incohérence de marque — si la page prétend être PayPal mais que le domaine est paypai-secure.xyz, le serveur renvoie suspicious immédiatement, sans appel au LLM et sans coût.
Cache — les verdicts sont indexés sur {domain, normalized path} et stockés en memcache pendant une heure. Une seconde visite à la même page ne coûte rien et répond en millisecondes.

Étape trois — le verdict sur la page.

Le verdict revient, et Bromure l'affiche en ligne — dans la page, au-dessus du contenu. Pas de pop-up. Pas de modal que vos parents doivent fermer avant de pouvoir voir ce qu'ils étaient venus consulter.

Les trois bannières possibles. Silence pour « sûr ». Un avertissement ambre pour « suspect », fermable, avec une porte de sortie « Je connais ce site ». Un interstitiel rouge pour « hameçonnage », où l'action par défaut est de revenir en arrière.

La ligne de motif est toujours une phrase unique, écrite pour la personne qui la lit, pas pour celle qui débogue. « Ce site se fait passer pour PayPal. N'entrez pas vos identifiants. » est ce que dit la bannière — pas un score de confiance, pas une trace de signaux, pas une liste de correspondances regex. L'objectif est que votre mère puisse lire la bannière une seule fois et savoir quoi faire.

Chaque fermeture d'une bannière « suspect » est limitée à la session en cours, ou promue à la liste des sites de confiance du profil si elle clique sur Je connais ce site. La décision de confiance lui appartient, pas au modèle.

La prise inter-domaines — un filet de sécurité qui n'a pas besoin d'un verdict.

Avant même qu'un verdict n'arrive, Bromure applique une règle absolue : un mot de passe n'est jamais envoyé à un domaine différent de celui qui figure dans la barre d'adresse, sans demander. Si un formulaire sur login.bank.com est sur le point d'envoyer un POST vers credentials.attacker.example, la soumission est interceptée et une modale apparaît.

La prise du mot de passe inter-domaines. Avant tout verdict du serveur, toute soumission de formulaire où la cible du mot de passe ne correspond pas au domaine de la page est interrompue par une confirmation explicite — qui nomme les deux domaines en langage clair.

Une courte liste blanche triée sur le volet — Google, Microsoft, Okta, Apple et quelques dizaines d'autres fournisseurs d'identité connus — exempte les authentifications fédérées légitimes de cette prise. Tout le reste reçoit la modale, à chaque fois. Cette seule règle, à elle seule, attrape une énorme part des pages d'hameçonnage d'identifiants avant même que le modèle n'ait rendu son verdict.

Où vont réellement vos données.

Deux contraintes guident le chemin des données. La première est le consentement. La seconde est l'isolation.

Consentement. La fonctionnalité est désactivée sur chaque nouveau profil. Pour l'activer, l'utilisateur ouvre Confidentialité & sécurité et se trouve devant une modale dédiée qui décrit, avant qu'aucune bascule ne soit activée, exactement ce qui est envoyé (URL, texte de la page, structure des formulaires, signaux d'alerte), où cela va (un serveur opéré par Bromure à bromure.io), combien de temps cela est conservé (journaux à court terme, pour la prévention des abus et l'amélioration du modèle), et comment la désactiver. La fonctionnalité n'est disponible que sur les profils persistants — pas sur les sessions éphémères et jetables — afin qu'une session de recherche anonyme ne puisse pas, par accident, laisser fuiter des données vers le serveur. Si vous installez Bromure sur le Mac de votre grand-mère et que vous activez la fonctionnalité pour elle, la bannière qu'elle voit est la preuve que le choix a été fait délibérément, pour son compte, par quelqu'un en qui elle a confiance.

Isolation. Le navigateur n'est pas directement connecté à internet. L'inspecteur non plus. Tous les constats voyagent par un canal vsock depuis la VM invitée jusqu'à l'hôte, sur un port interne — pas par l'interface réseau que voient les pages web, ni par aucun proxy que la page pourrait influencer. L'hôte relaie la requête vers l'API, reçoit le verdict et le rend à l'inspecteur. Aucune page web au monde ne peut atteindre le pont vsock ; aucune page web ne peut atteindre l'hôte directement ; aucune page web ne peut même savoir que le pont existe.

Le chemin des données. Les constats vont de l'extension invitée, via vsock, vers le pont de l'hôte, puis via HTTPS vers l'API. La page web ne touche directement aucun de ces sauts.

L'URL de la page vérifiée est journalisée sur le serveur, brièvement, pour la prévention des abus. Le texte visible est envoyé au modèle pour analyse et n'est pas conservé après la réponse. Rien de ce que vous avez tapé dans un formulaire n'est jamais dans le paquet. Si vous désactivez la fonctionnalité, aucune donnée n'est envoyée.

Rapide sur les pages que vous connaissez déjà.

Appeler un modèle de langage à chaque chargement de page rendrait le navigateur lourd. Bromure met les verdicts en cache de manière agressive, si bien que les pages les plus visitées d'internet sont quasiment gratuites à évaluer après la première visite — et si le serveur est hors d'atteinte, l'inspection locale continue de faire son travail.

Cache d'abord, modèle en dernier

Les verdicts sont mis en cache sur {domain, normalized path} pendant une heure. Une seconde visite sur la même page répond en millisecondes, sans toucher au modèle. Les raccourcis d'incohérence de marque contournent entièrement le modèle.

L'inspection locale est le plancher

Si le serveur est injoignable ou lent, l'inspection locale continue de tourner. Les bannières pour les cas les plus évidents — mots de passe inter-domaines, domaines homoglyphes, charges dans le presse-papiers — sont produites entièrement à l'intérieur de votre ordinateur, sans réseau.

La promesse, tenue.

Nous avons dit dans le premier billet que la défense devait être une seconde paire d'yeux qui ne cligne jamais. Voici ce que cette paire d'yeux fait réellement, à l'intérieur de Bromure, aujourd'hui.

Votre mère ne devrait pas avoir à passer un quiz de sécurité pour lire les nouvelles. Votre père ne devrait pas avoir à savoir ce qu'est un homoglyphe. Votre grand-père ne devrait pas avoir à se sentir bête parce qu'une voix polie au téléphone lui a dit d'installer un truc. Le navigateur devrait voir le piège, à temps, et le dire — en une phrase, pas en jargon — avant qu'un mot de passe ne quitte jamais le clavier.

C'est à cela que sert l'anti-hameçonnage de Bromure. C'est pour cela qu'il est désactivé par défaut, documenté avant d'être activé, isolé de la page, et bon marché à faire tourner à grande échelle. Installez-le sur le Mac de vos parents. Faites-leur faire un tour du panneau Confidentialité & sécurité. Activez la fonctionnalité. Ensuite, allez dîner.