LinkedIn Is Scanning Your Browser Extensions: How It Works and Why You Should Care
LinkedIn has over 1 billion members. Most of them have no idea that when they load a LinkedIn page, JavaScript running in the background is probing their browser to figure out which extensions they have installed. Password managers. Ad blockers. Productivity tools. LinkedIn is scanning your browser extensions, and the technique is both simple and deeply invasive.
Security researcher Feross Aboukhadijeh documented LinkedIn's scanning script in detail, showing that the platform checked for more than 30 specific browser extensions by exploiting a well-known feature of Chrome's extension architecture. Developer and privacy advocate Maciej Ceglowski first raised the alarm after noticing suspicious network requests on LinkedIn pages that appeared to be probing for installed extensions.
I've spent over 14 years building web applications, and I've worked on systems where we had to think hard about what data we collected and why. What LinkedIn is doing here crosses a line that most users don't even know exists.
How Does LinkedIn Scan Your Browser Extensions?
The technique is dead simple, which is what makes it so concerning.
Every Chrome extension has a unique identifier — a 32-character string that acts like a fingerprint. Extensions can also declare certain files as "web accessible resources" through a property in their manifest.json called web_accessible_resources. This is a legitimate feature. It lets extensions expose specific assets — icons, CSS files, scripts — so that web pages can interact with them. Google's official documentation explicitly warns that making resources web-accessible can allow websites to fingerprint extensions. Most extension developers ignore this warning.
LinkedIn's script exploits this by attempting to load a known resource from each extension ID on its list. The request follows a predictable pattern: chrome-extension://{extension-id}/{known-resource-path}. If the resource loads, the extension is installed. If it fails, it's not. Binary signal, repeated across 30+ extensions, and it happens in milliseconds before you've even scrolled past the first post in your feed.
As Feross Aboukhadijeh documented, the script didn't check for one or two extensions. It systematically worked through a curated list, turning each success or failure into a data point about the person on the other side of the screen.
The browser doesn't prompt you. There's no permission dialog. Your extensions are being inventoried without your knowledge or consent.
I've built feature detection scripts before. The pattern is common in frontend engineering — you probe for capabilities to serve the right experience. But there's a massive difference between checking if a browser supports IntersectionObserver and cataloguing which security tools someone has installed.
What Extensions Was LinkedIn Looking For?
This is where it gets uncomfortable. As Maciej Ceglowski noted, the list of probed extensions included password managers, ad blockers, and productivity tools like Grammarly and Evernote. This wasn't a narrow check for LinkedIn-specific browser add-ons. It was a broad inventory of a user's entire digital toolkit.
Think about what that list reveals. A password manager tells LinkedIn something about your security posture. An ad blocker signals your attitude toward advertising and tracking. Grammarly suggests you're writing frequently — maybe drafting messages, cover letters, or posts. Developer-focused extensions like React DevTools or JSON formatters reveal your profession. Accessibility tools reveal personal needs.
Combined, these signals paint a detailed profile. Not just of what you do on LinkedIn, but of who you are and how you work.
If you've followed the supply chain attack landscape — and I've written about how NPM supply chain attacks target JavaScript developers — you know that extension metadata is exactly the kind of intelligence an attacker would want. Knowing that a target uses a specific password manager narrows the attack surface. LinkedIn isn't an attacker, obviously. But when a mainstream platform normalizes this kind of enumeration, the technique gets more widely known and more likely to be copied by people who are.
Why Extension Fingerprinting Is a Real Privacy Risk
LinkedIn scanning browser extensions isn't just a LinkedIn story. It's about a tracking technique called browser fingerprinting that's rapidly becoming the post-cookie surveillance playbook.
Traditional tracking relies on cookies. Block cookies, and tracking gets harder. Browser fingerprinting takes a different approach entirely. It combines dozens of signals — your screen resolution, installed fonts, timezone, language settings, WebGL renderer, and yes, your installed extensions — to create a composite identifier that's unique to you. Research from the Electronic Frontier Foundation's Panopticlick project showed that the combination of these attributes can uniquely identify over 80% of browsers.
Extension data is especially useful in this cocktail because it's high-entropy. Most people have a unique combination of extensions. If LinkedIn (or any site) knows you're running uBlock Origin, Bitwarden, Dark Reader, Grammarly, and React DevTools, that five-extension signature probably identifies you uniquely among millions of users. No cookies required.
This is why, even if LinkedIn's intentions were completely benign, the precedent is dangerous. Every site that adopts this technique contributes to a fingerprinting ecosystem that makes anonymous browsing harder for everyone. And if you care about browser privacy — something I explored in my review of Proton Meet's encryption approach — extension scanning should be on your radar.
LinkedIn's Official Response: "Internal Research"
When confronted with the evidence, LinkedIn didn't deny it. A LinkedIn spokesperson told The Register that the script was part of an "internal research project" intended for A/B testing and to "ensure a safe and secure platform." The company claimed the data was not stored long-term or used for ad targeting.
I've heard this kind of response before. "Internal research project" is corporate speak for "we were testing something and didn't think anyone would notice." The security justification is particularly rich — scanning users' security tools to "ensure safety" is like a landlord photographing the contents of your medicine cabinet to "ensure a healthy building."
Even taking LinkedIn at their word, the response raises more questions than it answers. What does A/B testing have to do with knowing which password manager I use? How does enumerating ad blockers contribute to platform security? And "not stored long-term" is doing a lot of heavy lifting in that statement. How long is long-term? A day? A week? Long enough to build a profile?
The fundamental issue isn't what LinkedIn did with the data. It's that they collected it silently, without disclosure, and without consent.
How to Stop Websites From Detecting Your Browser Extensions
The good news: browser vendors have started taking this seriously. The bad news: protection is still incomplete.
Firefox users are in the best position. Firefox generates random, per-installation UUIDs for extension resource URLs instead of using the fixed extension IDs from the Chrome Web Store. This means the chrome-extension://{known-id}/ probing technique simply doesn't work. The URLs are unpredictable and different for every Firefox installation, making enumeration effectively impossible.
Chrome users have fewer options, but things are improving. Chrome's Manifest V3 introduced the ability to restrict web_accessible_resources to specific domains, so extension developers can limit which sites can access their resources. But this requires extension developers to actually opt in, and many haven't updated their manifests.
Here's what you can do right now:
- Switch to Firefox for LinkedIn browsing. Firefox's UUID randomization is the most effective defense against this specific technique.
- Use a dedicated browser profile for LinkedIn and other social platforms, with minimal extensions installed. Fewer extensions in the profile means less to fingerprint.
-
Audit your extensions' manifests. Check if extensions you use declare
web_accessible_resources. Extensions that don't expose any resources can't be detected this way. - Use anti-fingerprinting tools like Brave's fingerprinting protection or Firefox's Enhanced Tracking Protection, which blocks known fingerprinting scripts.
- Regularly review and remove extensions you don't actively use. Every installed extension increases your fingerprint surface. I made this same point in my piece on how info-stealer malware targets Chrome's stored credentials — fewer extensions mean a smaller attack surface across the board.
The Bigger Problem Nobody's Talking About
LinkedIn got caught. They're almost certainly not the only platform doing this. The web_accessible_resources technique has been documented in security research for years. Any website can run this same scan. Your bank. Your healthcare portal. That random SaaS tool your company just adopted last Tuesday.
The real question is whether browser vendors will close this loophole entirely. Firefox's approach of randomizing extension IDs is the right model. Chrome's half-measures with Manifest V3 restrictions help but don't solve the fundamental problem — the probing technique still works against any extension that declares web-accessible resources without domain restrictions.
I think we're heading toward a world where extension isolation becomes a browser-level default, not an opt-in feature. The same way browsers eventually blocked third-party cookies after years of half-measures, they'll eventually make extension enumeration impossible by default. But we're not there yet, and the gap between "we know this is a problem" and "we've actually fixed it" is where millions of users get fingerprinted every day.
Until then, every time you open LinkedIn, remember: the page isn't just showing you job posts and humble brags. It's reading your browser like an open book. And if a professional networking site is doing it, imagine who else is.
Originally published on kunalganglani.com
Top comments (0)