Le BrowserGate de LinkedIn, et pourquoi une seule identité de navigateur ne suffit plus

Début avril, un groupe européen d'utilisateurs de LinkedIn baptisé Fairlinked e.V. a publié une enquête qui, selon la manière de compter, constituait soit l'histoire la plus détaillée, soit la moins surprenante du fingerprinting de navigateur de la décennie. Le JavaScript en frontal de LinkedIn, ont-ils montré, déclenche entre six et sept mille requêtes fetch() vers des URL chrome-extension:// chaque fois que vous chargez le site, teste si chacune d'entre elles aboutit, collecte 48 autres caractéristiques d'appareil et de navigateur, et expédie l'ensemble du paquet — chiffré RSA, attaché à chaque appel d'API ultérieur — vers le point de terminaison de télémétrie de LinkedIn.

Le reportage a été repris par The Next Web, vérifié indépendamment par 404 Privacy, et rétro-ingénieré au niveau du code dans une longue analyse technique qui détaille les charges utiles réelles. L'organisation sœur de Fairlinked, Teamfluence Signal Systems, avait déjà déposé un référé à Munich en janvier 2026 au titre du Digital Markets Act de l'UE (DMA — le règlement européen qui régit la manière dont les plateformes contrôleuses d'accès doivent traiter les utilisateurs). Le tribunal l'a rejeté. LinkedIn, de son côté, a déclaré aux journalistes que ces affirmations sont « totalement fausses » et que son balayage ne vise que les extensions qui violent ses conditions d'utilisation.

Ce billet ne porte pas sur la question de savoir si LinkedIn est dans son droit en Irlande ou en Allemagne. Il porte sur ce que cette histoire illustre : le navigateur dans lequel vous lisez ceci n'a jamais été conçu pour s'opposer à ce genre de choses et — plus important encore — ne peut pas s'y opposer, parce qu'il n'a qu'une seule identité à offrir.

Ce que fait réellement la page quand vous visitez linkedin.com

Deux mécanismes tournent en parallèle, et ils méritent d'être compris même si vous n'ouvrez jamais un panneau DevTools.

Détection active des extensions. La page embarque une liste codée en dur de plus de 6 000 identifiants d'extensions Chrome. Pour chacun, elle lance un fetch() vers un fichier connu à l'intérieur du paquet de cette extension — par exemple chrome-extension://<id>/manifest.json, ou une icône précise. Si le fetch aboutit, l'extension est installée ; si Chrome rejette la requête, elle ne l'est pas. L'astuce ne fonctionne que sur les extensions qui exposent au moins une « web-accessible resource », ce que font la plupart des véritables extensions. L'article signale qu'une variante furtive utilise window.requestIdleCallback() avec des délais échelonnés pour éviter d'illuminer l'onglet réseau.

Balayage passif du DOM (« Spectroscopy »). Parallèlement, la page parcourt votre DOM à la recherche de références d'URL chrome-extension://. Cela attrape les extensions qui injectent du contenu dans la page — celles que la liste codée en dur aurait pu manquer, ou les plus récentes dont la liste n'a pas encore connaissance.

Les résultats alimentent un pipeline de fingerprinting que LinkedIn appelle en interne APFC, pour « Anti-fraud Platform Features Collection », avec un nom secondaire, DNA, pour « Device Network Analysis ». Outre la liste des extensions, le pipeline collecte :

Ces signaux sont combinés en un blob chiffré et attachés comme en-tête HTTP à chaque requête d'API ultérieure que la page effectue — ainsi, le back-end de LinkedIn sait toujours, à chaque saut, exactement de quel appareil il s'agit. L'enquête rapporte que LinkedIn a pris des mesures — suspensions de comptes, avertissements — à l'encontre d'utilisateurs faisant tourner des extensions qu'il n'apprécie pas, ce qui est la preuve la plus directe que les données sont effectivement utilisées et non simplement collectées.

Il y a une véritable question enfouie sous la question juridique : si LinkedIn fait cela à cette échelle, combien d'autres sites en font une version plus modeste ? La réponse honnête, c'est : la plupart des grands. LinkedIn n'est atypique que par l'ampleur de sa liste d'extensions et par le soin avec lequel le tout a été conçu. Le reste du web grand public exécute la même recette de base à des degrés de sophistication variables.

Le problème n'est pas le fingerprinting. C'est la réutilisation d'identité.

Prenons un peu de recul. Canvas, WebGL, WebRTC, énumération des polices — rien de tout cela n'est nouveau. Tous les chercheurs en sécurité de ces dix dernières années ont écrit un essai qui se termine par « activez le resistFingerprinting de Firefox » ou « installez CanvasBlocker ». Ce conseil n'est pas faux, exactement, mais il passe à côté du mur porteur du problème.

Même si vous aviez une résistance parfaite au fingerprinting — chaque signal normalisé, chaque canvas vierge, chaque connexion WebRTC refusée —, votre navigateur n'aurait toujours qu'un seul pot de cookies, un seul fichier d'historique, un seul ensemble de sessions connectées, un seul coffre de mots de passe enregistrés, une seule liste d'extensions installées, une seule adresse IP à la couche réseau. Tout ce que vous faites sur le web sort de cette unique identité. Un fingerprinter qui ne peut pas lire votre canvas peut tout de même constater que la personne qui s'est connectée à LinkedIn, la personne qui s'est connectée à Facebook, la personne qui a consulté une petite librairie indépendante et la personne qui a vérifié son portail santé venaient toutes de la même instance de navigateur, avec les mêmes cookies, depuis la même IP. Et l'effet de réseau se joue entre les sites : les données de LinkedIn deviennent plus utiles dès qu'on les joint à celles de n'importe quel autre site.

C'est pourquoi une extension anti-fingerprinting isolée ne règle pas vraiment le problème, et pourquoi « utiliser un VPN » par- dessus un navigateur ordinaire ne le règle pas non plus. Un VPN change votre IP apparente, mais il ne scinde pas votre navigateur en plusieurs identités. Vous avez toujours un seul pot de cookies. Vous avez toujours un seul ensemble de sessions. LinkedIn et Facebook voient toujours la même machine — et maintenant, ce qui leur est utile, une machine qui a été recoupée avec l'historique d'IP d'un VPN.

L'argument du VPN par onglet

Voici la partie qui commence à sembler différente. Parce que chaque onglet Bromure est sa propre machine virtuelle Linux jetable, le VPN appartient à l'onglet, non au navigateur entier. Pas à l'ordinateur entier. À l'onglet.

Vous pouvez rattacher un point de sortie Mullvad en Suède à votre profil LinkedIn, un point de sortie ProtonVPN en Suisse à votre profil Facebook, Cloudflare WARP à un profil « liens au hasard », et absolument rien à votre profil bancaire local — le tout en même temps, sur le même Mac, dans la même application Bromure. LinkedIn voit la sortie suédoise. Facebook voit la sortie suisse. La banque voit votre véritable connexion domestique. Aucun d'eux ne dispose d'un moyen propre de remarquer qu'ils regardent le portable de la même personne.

Il ne s'agit pas d'une séparation théorique. Bromure démarre un véritable noyau Linux par onglet, à l'aide de Apple's Virtualization.framework. Chaque VM a sa propre pile réseau noyau, son propre /etc/hosts, sa propre arborescence de processus, son propre jeu de flags Chromium, son propre répertoire de profil sur son propre disque virtuel. Deux onglets sur deux sites qui font du fingerprinting, servis par deux points de sortie VPN différents, sont indiscernables de deux personnes distinctes utilisant deux ordinateurs portables distincts, parce qu'à la couche à laquelle opère le fingerprinting, ils le sont.

Le réglage de VPN par onglet se trouve dans le panneau VPN & Publicités du profil, avec trois options : Cloudflare WARP (le service de chiffrement grand public de Cloudflare), WireGuard (n'importe quel fournisseur, n'importe quel serveur auto-hébergé — collez un .conf), ou IKEv2 (pour les VPN d'entreprise). Le VPN tourne à l'intérieur de la VM, ce qui signifie que même le processus Chromium invité ne voit pas votre vraie IP.

Bromure désactive WebRTC par défaut

WebRTC est la cause directe de la fuite d'IP LAN dans BrowserGate. Il a été conçu pour les appels vidéo et audio de navigateur à navigateur et, par effet de bord de sa manière de découvrir les chemins réseau, on peut lui demander d'énumérer vos interfaces réseau locales. N'importe quel site — pas seulement ceux que vous appelez — peut exécuter cette énumération en arrière-plan et apprendre des choses comme « le routeur de cet utilisateur lui a attribué 192.168.1.47, donc il est sur un réseau domestique typique, la même plage qu'à la dernière visite depuis cette empreinte. »

Bromure désactive WebRTC par défaut pour tout profil qui n'a pas à la fois la webcam et le microphone activés. Concrètement : lorsqu'un profil n'a pas besoin d'accès à la webcam ou au microphone, le lanceur Bromure ajoute deux flags Chromium :

• --force-webrtc-ip-handling-policy=disable_non_proxied_udp
• --enforce-webrtc-ip-permission-check

et charge une petite extension de navigateur nommée webrtc-block qui remplace le constructeur RTCPeerConnection par un stub no-op. Ce dernier point compte : le flag de politique seul empêche l'IP de fuir par UDP, mais un fingerprinter déterminé peut toujours instancier RTCPeerConnection et observer le comportement ; le stub fait échouer même le constructeur. L'effet net, c'est qu'un site qui tente l'astuce de l'IP LAN à la LinkedIn, sur un profil Bromure qui n'a pas besoin de WebRTC, ne récupère rien.

Vous n'avez rien à activer pour cela. C'est l'état par défaut de tout profil qui n'a pas le matériel d'appel vidéo activé. Si vous activez le partage webcam ou microphone dans le panneau Médias d'un profil, les usages VPN et appels vidéo qui requièrent WebRTC reviennent automatiquement. Le réglage est « activé uniquement quand vous en avez réellement besoin », ce qui se rapproche de la manière dont le web était censé fonctionner.

Ce que l'isolation ne règle pas

Deux choses méritent d'être dites d'emblée. Premièrement, si vous vous connectez à LinkedIn avec votre vrai nom depuis chaque profil, LinkedIn sait que c'est vous. L'isolation ne vous rend pas anonyme auprès des services dans lesquels vous vous connectez volontairement ; elle casse la jonction d'identité inter-sites et elle empêche la réidentification passive entre sessions. Ce sont de véritables gains, mais ce n'est pas l'anonymat.

Deuxièmement, Bromure ne peut pas empêcher LinkedIn de faire tourner son balayage d'extensions à l'intérieur de la VM Bromure. Il peut, et il le fait, rendre les résultats de ce balayage sans intérêt : par défaut, un profil Bromure n'a aucune extension Chrome installée à part les extensions internes propres à Bromure, et celles-ci vivent sur des identifiants d'extensions différents, propres au profil, que la liste codée en dur de LinkedIn n'inclut pas. La page sonde scrupuleusement 6 000 identifiants ; rien ne revient. L'empreinte à 48 attributs est tout de même collectée — mais elle identifie une VM jetable dont le WebRTC, les cookies et l'IP ne recoupent aucune autre VM que vous faites tourner.

C'est suffisant pour désamorcer BrowserGate en tant qu'outil de corrélation inter-sites. Ce n'est pas suffisant pour vous cacher de LinkedIn une fois que vous êtes connecté, et nous n'allons pas prétendre le contraire.

Paramètres Bromure recommandés pour LinkedIn (et les sites similaires)

Si vous mettez en place un profil dédié à LinkedIn, ou un profil Facebook, ou n'importe quelle autre plateforme sociale connue pour son fingerprinting agressif, voici les réglages par défaut à vérifier. Tout ce qui suit se trouve dans le panneau des paramètres par profil (icône d'engrenage à côté du profil dans la liste).

Quelques remarques moins évidentes. WebRTC est déjà désactivé pour ce profil tant que la webcam et le microphone sont tous deux désactivés — vous n'avez pas besoin de le régler où que ce soit, et il n'y a pas de case à cocher pour lui, parce qu'il est dérivé de ces deux réglages.

Si vous faites tourner un profil LinkedIn dédié pour le travail et que vous voulez que la session VPN survive à la fermeture d'onglets individuels, associez Conserver les données de navigation avec Se connecter au démarrage sous WireGuard — le VPN se montera automatiquement chaque fois que vous rouvrirez ce profil.

Vous pouvez aller plus loin. Le panneau Avancé comporte une option Chiffrer les données de navigation, qui chiffre le disque persistant avec LUKS au moyen d'une clé stockée dans le Keychain macOS. C'est un niveau de paranoïa raisonnable pour tout ce qui touche aux réseaux sociaux et que vous voulez néanmoins voir survivre aux redémarrages.

La forme de la solution

BrowserGate est un bon symbole d'une chose qui est vraie depuis quelque temps et qui empire : les navigateurs ordinaires ne peuvent pas repousser de manière significative cette classe de surveillance, parce que toute leur architecture est bâtie autour d'une identité unique par instance de navigateur. Vous pouvez installer des extensions pour atténuer des fuites précises, et vous devriez ; mais la réponse structurelle, c'est un navigateur où chaque onglet est son propre ordinateur, avec son propre réseau, sa propre surface de confidentialité, et sa propre capacité à s'achever. Fermez la fenêtre, et cette identité — quelles que soient les données que le scanner de LinkedIn a collectées, quels que soient les cookies de corrélation qui s'y sont attachés — disparaît.

C'est toute la forme de la solution. Elle ne dépend pas de l'accord de LinkedIn pour cesser, et elle ne dépend pas du DMA. Elle dépend du fait que votre navigateur ait une forme différente de celui qui se trouvait sur le portable avec lequel vous l'avez acheté.