LinkedIn's BrowserGate, and why one browser identity is no longer enough

In early April, a European LinkedIn-users' group called Fairlinked e.V. published an investigation that, depending on how you count, was either the most detailed or the least surprising browser-fingerprinting story of the decade. LinkedIn's own front-end JavaScript, they showed, fires between six and seven thousand fetch() requests at chrome-extension:// URLs every time you load the site, tests whether each one resolves, collects 48 other device and browser characteristics, and ships the whole bundle — RSA-encrypted, attached to every subsequent API call — back to LinkedIn's telemetry endpoint.

The reporting was picked up by The Next Web, independently verified by 404 Privacy, and reverse-engineered at the code level in a long technical breakdown that walks through the actual payloads. Fairlinked's sister organisation, Teamfluence Signal Systems, had already filed a preliminary injunction in Munich in January 2026 under the EU's Digital Markets Act (DMA — the European regulation that governs how gatekeeper platforms must treat users). The court denied it. LinkedIn, for its part, told reporters that the claims are "plain wrong" and that its scanning only targets extensions that violate its terms of service.

This post is not about whether LinkedIn is within its legal rights in Ireland or Germany. It is about what the story illustrates: the browser you are reading this in was never designed to push back on this kind of thing, and — more importantly — cannot push back on it, because it only has one identity to give.

What the page actually does when you visit linkedin.com

There are two mechanisms running in parallel, and they are worth understanding even if you never open a DevTools panel.

Active extension detection. The page ships a hard-coded list of 6,000+ Chrome extension IDs. For each one, it fires a fetch() to a known file inside that extension's package — chrome-extension://<id>/manifest.json, say, or a specific icon. If the fetch succeeds, the extension is installed; if Chrome rejects the request, it is not. The trick only works on extensions that expose at least one "web-accessible resource," which most real extensions do. The article reports that a stealth variant uses window.requestIdleCallback() with staggered delays to avoid lighting up the network panel.

Passive DOM scanning ("Spectroscopy"). Separately, the page walks your DOM looking for chrome-extension:// URL references. This catches extensions that inject content into the page — the ones the hard-coded list might have missed, or newer ones that the list has not yet learned about.

The results feed a fingerprinting pipeline LinkedIn calls APFC internally, for "Anti-fraud Platform Features Collection," with a secondary name of DNA for "Device Network Analysis." Alongside the extension list, the pipeline collects:

These signals are combined into an encrypted blob and attached as an HTTP header to every subsequent API request the page makes — so LinkedIn's backend always knows, at every hop, which exact device you are. The investigation reports that LinkedIn has taken action — account suspensions, warnings — against users running extensions it does not like, which is the most direct evidence that the data is in fact used and not merely collected.

There is a real question buried under the legal one: if LinkedIn is doing this at this scale, how many other sites are doing a smaller version? The honest answer is: most of the big ones. LinkedIn is unusual only in the breadth of its extension list and the care with which it was engineered. The rest of the consumer web runs the same basic playbook at varying levels of sophistication.

The problem is not fingerprinting. It is identity reuse.

Take a step back. Canvas, WebGL, WebRTC, font enumeration — these are not new. Every security researcher in the last ten years has written an essay that ends with "turn on Firefox's resistFingerprinting" or "install CanvasBlocker." That advice is not wrong, exactly, but it misses the load-bearing wall of the problem.

Even if you had perfect fingerprinting resistance — every signal normalized, every canvas blank, every WebRTC connection refused — your browser still has one cookie jar, one history file, one set of logged-in sessions, one saved-passwords vault, one installed-extensions list, one IP address at the network layer. Everything you do on the web comes out of that one identity. A fingerprinter that cannot read your canvas can still tell that the person who logged into LinkedIn, the person who logged into Facebook, the person who looked at a small independent bookshop, and the person who checked their health portal all came from the same browser instance with the same cookies from the same IP. And the network effect is cross-site: LinkedIn's data becomes more useful the moment it is joined with any other site's.

This is why a lone anti-fingerprinting extension does not really fix the problem, and why "use a VPN" on top of an ordinary browser does not fix it either. A VPN changes your apparent IP, but it does not split your browser into multiple identities. You still have one cookie jar. You still have one set of sessions. LinkedIn and Facebook still see the same machine — and now, usefully for them, a machine that has been cross-checked against a VPN's IP history.

The per-tab VPN argument

Here is the part that starts to feel different. Because every Bromure tab is its own disposable Linux virtual machine, the VPN belongs to the tab, not to the whole browser. Not to the whole computer. To the tab.

You can attach a Mullvad endpoint in Sweden to your LinkedIn profile, a ProtonVPN endpoint in Switzerland to your Facebook profile, Cloudflare WARP to a "random links" profile, and nothing at all to your local banking profile — all at the same time, on the same Mac, in the same Bromure app. LinkedIn sees the Swedish exit. Facebook sees the Swiss exit. The bank sees your actual home connection. None of them has a clean way to notice they are looking at the same person's laptop.

This is not a theoretical separation. Bromure boots a real Linux kernel per tab, using Apple's Virtualization.framework. Each VM has its own kernel network stack, its own /etc/hosts, its own process tree, its own set of Chromium flags, its own profile directory on its own virtual disk. Two tabs on two fingerprinting sites, served by two different VPN endpoints, are indistinguishable from two separate people using two separate laptops, because at the layer fingerprinting operates, they are.

The per-tab VPN setting lives under the profile's VPN & Ads panel, with three options: Cloudflare WARP (Cloudflare's consumer encryption service), WireGuard (any provider, any self-hosted server — paste in a .conf), or IKEv2 (for corporate VPNs). The VPN runs inside the VM, which means even the guest Chromium process does not see your real IP.

Bromure disables WebRTC by default

WebRTC is the direct cause of the LAN-IP leak in BrowserGate. It was designed for browser-to-browser video and audio calls and, as a side effect of how it discovers network paths, it can be asked to enumerate your local network interfaces. Any site — not just the ones you are calling — can run that enumeration in the background and learn things like "this user's router handed them 192.168.1.47, so they are on a typical home network, which is the same range as last visit from this fingerprint."

Bromure turns WebRTC off by default for any profile that does not have both webcam and microphone enabled. Concretely, when a profile does not need webcam or microphone access, the Bromure launcher adds two Chromium flags:

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

and loads a small browser extension called webrtc-block that replaces the RTCPeerConnection constructor with a no-op stub. That last part matters: the policy flag alone stops the IP from leaking over UDP, but a determined fingerprinter can still instantiate RTCPeerConnection and observe behaviour; the stub makes even the constructor fail. The net effect is that a site trying LinkedIn's LAN-IP trick, on a Bromure profile that does not need WebRTC, gets back nothing.

You do not need to toggle anything for this. It is the default state for any profile that does not have video-call hardware enabled. If you turn on webcam or microphone sharing in a profile's Media panel, the VPN and video-call use cases that need WebRTC come back automatically. The setting is "on only when you actually need it," which is closer to how the web was supposed to work.

What isolation does not fix

Two things worth naming up front. First, if you sign into LinkedIn with your real name from every profile, LinkedIn knows it is you. Isolation does not make you anonymous to services you voluntarily log into; it breaks cross-site identity joining and it stops passive re-identification between sessions. Those are real wins, but they are not anonymity.

Second, Bromure cannot stop LinkedIn from running its extension scan inside the Bromure VM. It can, and does, make the scan's results uninteresting: by default, a Bromure profile has no Chrome extensions installed other than Bromure's own internal ones, and those live on different, profile-scoped extension IDs that LinkedIn's hard-coded list does not include. The page dutifully probes 6,000 IDs; nothing comes back. The 48-attribute fingerprint is still collected — but it identifies one disposable VM whose WebRTC, cookies, and IP do not overlap with any other VM you run.

That is enough to defang BrowserGate as a cross-site correlation tool. It is not enough to hide you from LinkedIn once you are logged in, and we are not going to pretend otherwise.

Recommended Bromure settings for LinkedIn (and similar sites)

If you are setting up a dedicated LinkedIn profile, or a Facebook one, or any other social platform that is known to fingerprint aggressively, these are the defaults worth checking. Everything below is in the per-profile settings panel (gear icon next to the profile in the list).

A few non-obvious notes. WebRTC is already off for this profile as long as webcam and microphone are both off — you do not need to set it anywhere, and there is no checkbox for it, because it is derived from those two settings.

If you are running a dedicated LinkedIn profile for work and want the VPN session to outlast individual tab closures, pair Retain Browsing Data with Connect on Startup under WireGuard — the VPN will come up automatically every time you reopen that profile.

You can take this further. The Advanced panel has an Encrypt Browsing Data option, which encrypts the persistent disk using LUKS with a key stored in the macOS Keychain. That is a reasonable level of paranoia for anything social-media adjacent that you nonetheless want to survive reboots.

The shape of the fix

BrowserGate is a good symbol for something that has been true for a while and is getting worse: ordinary browsers cannot push back meaningfully against this class of surveillance, because their entire architecture is built around a single identity per browser instance. You can install extensions to mitigate specific leaks, and you should; but the structural answer is a browser where each tab is its own computer, with its own network, its own privacy surface, and its own ability to end. Close the window, and that identity — whatever data LinkedIn's scanner collected, whatever correlation cookies attached — is gone.

That is the whole shape of the fix. It does not depend on LinkedIn agreeing to stop, and it does not depend on the DMA. It depends on your browser being a different shape than the one that was on the laptop you bought this with.