LinkedIn checks for 2953 browser extensions • Hacker News Board

Re: LinkedIn checks for 2953 browser extensions

#21

Post by usefulposter » Thu, Feb 05, 2026, 8:34 PM UTC

lapcat wrote: post #2

[removed]

Isn't it enumerating web_accessible_resources? Below static collectFeatures(e, t) there is a mapping of extension IDs to files in the const r (Minified JS, obviously.)

Edit: Confirmed. It's not pinging the Chrome Web Store. https://blog.castle.io/detecting-browser-extensions-for-bot-...

Re: LinkedIn checks for 2953 browser extensions

#22

Post by jsheard » Thu, Feb 05, 2026, 8:35 PM UTC

lapcat wrote: post #2

[removed]

Looks to me like LinkedIn is fetching chrome-extension://{extension id}/{known filename} and seeing if it succeeds, not pinging the web store.

Should be patched nonetheless though, that's a pretty obscene fingerprinting vector.

Re: LinkedIn checks for 2953 browser extensions

#23

Post by chocolatkey » Thu, Feb 05, 2026, 8:36 PM UTC

lapcat wrote: post #2

[removed]

That’s incorrect, it’s trying to load an asset (hardcoded unique per-extension path) for each extension, there is a huge list of these in the source code: https://raw.githubusercontent.com/mdp/linkedin-extension-fin...

Re: LinkedIn checks for 2953 browser extensions

#24

Post by bryanrasmussen » Thu, Feb 05, 2026, 8:38 PM UTC

rdoherty wrote: post #15

Skimming the list, looks like most extensions are for scraping or automating LinkedIn usage. Not surprising as there's money to be made with LinkedIn data. Scraping was a problem when I worked there, the abuse teams built some reasonably sophisticated detection & prevention, and it was a constant battle.

from the code doesn't look like they do anything if they have a match, they just save all the results to a csv for fingerprinting?

Re: LinkedIn checks for 2953 browser extensions

#25

Post by ronsor » Thu, Feb 05, 2026, 8:40 PM UTC

charcircuit wrote: post #19

hsbauauvhabzb wrote: post #16

Earlier quoted context omitted.

Wont someone think of poor little LinkedIn, a subsidiary of one of the largest data brokers in the world?

Why frame what you are trying to say like that? Businesses of all sizes deserve the ability to protect their businesses from abuse.

I think they framed it this way because they don't consider scraping abuse (to be fair, neither do I, as long as it doesn't overload the site). Botting accounts for spam is clear abuse, however, so that's fair game.

Re: LinkedIn checks for 2953 browser extensions

#26

Post by zahlman » Thu, Feb 05, 2026, 8:40 PM UTC

> This repository documents every extension LinkedIn checks for and provides tools to identify them.

I get that the CSV lists the extensions, and the tools are provided in order to show work (mapping IDs to actual software). But how was it determined that LinkedIn checks for extensions with these IDs?

And is this relevant for non-Chrome users?

Re: LinkedIn checks for 2953 browser extensions

#27

Post by MrGilbert » Thu, Feb 05, 2026, 8:41 PM UTC

ronsor wrote: post #5

lapcat wrote: post #2

[removed]

This is a security vulnerability and should be patched. Sorry, LinkedIn. (Alternatively extension developers can modify their extensions to block these requests!)

I'm not sure how you'd patch that. Any request that’s made from the current open tab / window is made on behalf of the user. From my point of view, it's impossible for the browser to know, if the request is legit or not.

Re: LinkedIn checks for 2953 browser extensions

#28

Post by usefulposter » Thu, Feb 05, 2026, 8:42 PM UTC

zahlman wrote: post #26

> This repository documents every extension LinkedIn checks for and provides tools to identify them. I get that the CSV lists the extensions, and the tools are provided in order to show work (mapping IDs to actual software). But how was it determined that LinkedIn checks for extensions with these IDs? And is this relevant for non-Chrome users?

Technical writeup from a few weeks ago by a vendor that explains how LinkedIn does it, then boasts that their approach is "quieter, harder to notice, and easier to run at scale":

https://blog.castle.io/detecting-browser-extensions-for-bot-...

Re: LinkedIn checks for 2953 browser extensions

#29

Post by schmidtleonard » Thu, Feb 05, 2026, 8:43 PM UTC

charcircuit wrote: post #19

hsbauauvhabzb wrote: post #16

Earlier quoted context omitted.

Wont someone think of poor little LinkedIn, a subsidiary of one of the largest data brokers in the world?

Why frame what you are trying to say like that? Businesses of all sizes deserve the ability to protect their businesses from abuse.

The big social media businesses deserve a Teddy Roosevelt character swooping in and busting their trusts, forcing them to play ball with others even if it destroys their moats. Boo hoo! Good riddance. World's tiniest violin.

This is a popular position across the aisle. Here's hoping the next guy can't be bought, or at least asks for more than a $400M tacky gold ballroom!

Re: LinkedIn checks for 2953 browser extensions

#30

Post by ronsor » Thu, Feb 05, 2026, 8:43 PM UTC

MrGilbert wrote: post #27

ronsor wrote: post #5

Earlier quoted context omitted.

This is a security vulnerability and should be patched. Sorry, LinkedIn. (Alternatively extension developers can modify their extensions to block these requests!)

I'm not sure how you'd patch that. Any request that’s made from the current open tab / window is made on behalf of the user. From my point of view, it's impossible for the browser to know, if the request is legit or not.

An ideal implementation of the same origin policy would make it impossible for a site (through a fetch call or otherwise) to determine whether an extension resource exists/is installed or the site simply lacks permission to access it.