LinkedIn Scans Your Browser Extensions. Here's the Code That Proves It

Something significant landed on Hacker News this week, and if you’re a developer who uses LinkedIn in the same browser where your work tools live, it deserves your full attention.

A German civil organization called Fairlinked published what they’re calling BrowserGate: a forensic investigation demonstrating that LinkedIn runs a covert scan of your installed Chrome extensions every time you visit linkedin.com. Not a heuristic estimate. Not a fingerprinting approximation. An explicit, hardcoded list of 6,167 extension IDs, probed one by one using the browser’s own fetch() API — and the entire system is buried inside a production JavaScript bundle shipped to every LinkedIn user on the planet.


How It Works, Technically

The mechanism is documented down to the line number.

Within a Webpack module identified as 75023, LinkedIn maintains a hardcoded array mapping extension IDs to known internal file paths — for example, {id: "aaaeoelkococjpgngfokhbkkfiiegolp", file: "assets/index-COXueBxP.js"}. For each entry, LinkedIn fires a fetch() request to chrome-extension://{id}/{file}. If the extension is installed and has that file declared as web-accessible, the request succeeds. LinkedIn logs the ID as detected.

The system operates in two modes: a parallel batch that fires all 6,000+ requests simultaneously via Promise.allSettled(), and a sequential staggered mode with a configurable delay between requests — designed to reduce visibility in network monitoring tools. The scan can also be deferred to requestIdleCallback, executing when the browser is idle so the user perceives no performance impact and no visible trace remains.

A second detection layer called Spectroscopy traverses the entire DOM tree searching for chrome-extension:// strings injected by extensions in page attributes and text nodes — a passive method that captures extensions even when active fetch scanning misses them.

The results are encrypted and transmitted to LinkedIn’s li/track telemetry endpoint. They also go to HUMAN Security (formerly PerimeterX), a third-party cybersecurity firm, via an invisible zero-pixel tracking element loaded on every page.

The list grew from approximately 461 extensions in 2024 to 6,167 by February 2026. Someone is actively maintaining it.


What They’re Looking For

This is where it stops being a technical curiosity and becomes something more serious.

The scanned extensions include tools that reveal religious beliefs and political orientation. They include 509 job-search tools — meaning LinkedIn can identify users secretly job hunting on the very platform where their current employer can see their profile. And over 200 products that directly compete with LinkedIn’s own sales tools: Apollo, Lusha, ZoomInfo. Since LinkedIn knows every user’s employer, it can map which companies use which competitor products — silently extracted from users’ browsers without anyone knowing.

LinkedIn has already sent compliance threats to users of third-party tools. The inference is that scan data is being operationalized.


Why This Matters Especially for Developers

If you’re a developer, you probably have a browser profile that’s a goldmine: extensions for API testing, DevTools enhancements, credential managers, MCP integrations, GitHub utilities, authentication helpers. Some might be internal tools. Some might reveal your company’s tech stack.

LinkedIn can now map: your name → your employer → your installed tools. That’s not a privacy inconvenience — it’s a business intelligence operation at scale.

There’s no consent dialog for any of this. It’s not mentioned in LinkedIn’s privacy policy. Under GDPR, several of the data categories being inferred — religious beliefs, political orientation, disability-related tools, job-search behavior — are explicitly prohibited from processing without explicit consent. Not merely regulated: prohibited.


The Legal Response

A Munich court received the first formal action in January 2026. Teamfluence, an Estonian software company, filed for preliminary injunction against LinkedIn Ireland and LinkedIn Germany before the Landgericht München I, under the Digital Markets Act, EU competition legislation, and German data protection rules. The case is being heard by the same judge who previously ruled against Google in a competition proceeding under the DMA.

Fairlinked’s complete evidence package — including the source bundle, annotated code excerpts, and the extensions database — is publicly available at browsergate.eu.


What You Can Do Now

The most direct mitigation is browser separation: use a dedicated browser profile (or a different browser entirely) for LinkedIn, isolated from extensions touching your professional tools and authenticated services.

Beyond that, this story is worth following. The DMA angle is particularly significant: the EU ordered LinkedIn to open its platform to third-party tools. LinkedIn’s documented response was to expand a surveillance system targeting exactly the tools the regulation was designed to protect. That’s not a gray area.

For developers who built careers trusting their browser tools, this is a reminder that trust must be earned, verified — and when necessary, revoked.


Do you use LinkedIn in the same browser where you run your development tools? Tell us in the comments.