LinkedIn ha scansionato 6.222 estensioni del browser sul dispositivo di ogni utente dell’UE

A good reminder why browser-based fingerprinting prevention is so important.

Also a reminder that Google has no interest in fingerprinting prevention, and only implemented it half-heartedly. You are better off using anything but Chrome, really!

I guess it is even more with reddit.

Made gdpr data request, e signed.

Lets see how it goes, noncompliance could result in fine that is percentage of their yearly profit.

P. S. – I recommend everyone does the same, could bottleneck their ability to respond, causing them to being shut down/banned in europe.

New documents reveal how LinkedIn’s BrowserGate system maps competitor tool usage, extracts trade secrets, and may breach criminal law across Germany, UK, and the EU.

[](https://ppc.land/author/luis/)

[Luis Rijo](https://ppc.land/author/luis/)

Apr 05, 2026 – 16 min read

LinkedIn logo cracked on glass tower, data streams radiating outward, browser icons orbiting at night.

A detailed technical investigation published this month exposes LinkedIn’s hidden browser scanning system as a multi-layer architecture that goes far beyond extension detection, collecting 48 hardware and software characteristics per session, routing encrypted data through third-party cybersecurity firms, and building company-level intelligence profiles of organisations across 200 countries – without disclosing any of this in its privacy policy.

The documents published by Fairlinked e.V., the European association of commercial LinkedIn users behind the [BrowserGate investigation](https://browsergate.eu/?ref=ppc.land), include a complete technical breakdown of the JavaScript code, an evidence pack containing a cryptographically timestamped archive, and a sworn affidavit from LinkedIn’s own senior engineering manager filed in German court proceedings. Taken together, they present the most detailed public account yet of how the system was built, what it collects, and why the investigators believe it crosses into criminal territory in at least two jurisdictions.

# The JavaScript file at the centre of it

Every technical claim in the BrowserGate investigation traces back to a single source: a JavaScript bundle served by LinkedIn to every Chrome user who visits the site. According to the Fairlinked investigation, the file is identified internally as Webpack chunk ID “chunk.905,” extension scan module 75023, and weighs approximately 2.7 megabytes across 13,159 lines of minified code. The framework is Ember.js, registered under globalThis.webpackChunk_ember_auto_import_.

Within that bundle, at line 9571 character offset 443, sits a hardcoded array. Each entry in the array has two fields: a 32-character Chrome Web Store extension ID and a known internal file path within that extension’s package – things like popup.html, icon.png, or manifest.json. According to the investigation, someone at LinkedIn has individually identified a specific web-accessible resource for each of the 6,222 extensions in the list. This is not automated scraping of extension IDs. It is a curated target list, maintained and expanded over time.

The filename of the JavaScript bundle changes with each deployment, as it is derived from the content hash. But the string literals, endpoint URLs, module exports, and detection functions remain searchable by keyword. Anyone with Chrome developer tools can open LinkedIn, locate the largest JavaScript bundle at roughly 2.7 megabytes, and search for the string fetchExtensions or any Chrome extension ID to find the system.

# Three detection stages, each catching what the last misses

The detection architecture operates as a three-stage fallback chain, with each layer designed to catch extensions that the previous one cannot reach. According to the Fairlinked technical documentation, the first stage is direct communication: the code attempts to contact an extension using Chrome’s externally_connectable messaging API. If the extension developer has disabled this channel in their manifest.json, detection fails and the system moves to stage two.

Stage two is resource probing, using the browser’s fetch() API to request a known internal file from each extension. According to the investigation, LinkedIn tests all 6,222 extensions through this method using Promise.allSettled(), which fires all requests simultaneously. A fulfilled response means the extension is installed. A rejected response means it is not. An alternative sequential mode, controlled by a parameter called staggerDetectionMs, introduces a configurable delay between each probe – slowing the scan down enough to reduce its visibility in network monitoring tools.

Stage three – the one LinkedIn calls “Spectroscopy” – operates differently. Rather than querying extension files, it walks the entire DOM tree of the page, inspecting every text node and element attribute for the string “chrome-extension://.” Any extension that has injected elements, modified attributes, or added scripts to the page leaves traces in the DOM that Spectroscopy extracts. The 32-character extension ID is pulled from the URL fragment. According to the investigation, a VPN that modifies even a single pixel of the rendered page is detectable through this method.

The two methods complement each other in a specific way. Active Extension Detection via fetch() can identify extensions that are installed but have injected nothing into the current page. Spectroscopy catches extensions that actively modify the page but may not be in LinkedIn’s hardcoded list. Together, according to the investigation, they cover both cases.

joke’s on them I don’t use Chrome.