On Firefox, web accessible resources are available at "moz-extension://<extension-UUID>/myfile.png" <extension-UUID> is not your extension's ID. This ID is randomly generated for every browser instance. This prevents websites from fingerprinting a browser by examining the extensions it has installed. https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
Doesn't the idea of swapping extension specific IDs to your browser specific extension IDs mean that instead of your browser being identifiable, you become identifiable?
I mean, it goes from "Oh they have X, Y , and Z installed" to "Oh, it's jim bob, only he has that unique set of IDs for extensions"
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.
In order to create the data source that LinkedIn's extension-fingerprinting relies on to work, someone (at LinkedIn*?) almost certainly violated the Chrome Web Store TOS—by (perversely*) scraping it.
* if LinkedIn didn't take the data from an existing data source
"The code" here you're referring to (fetch_extension_names.js[1]) isn't and doesn't claim to be LinkedIn's fingerprinting code. It's a scraper that the researcher behind this repo wrote in order to themselves create the CSV that they're publishing.
LinkedIn's fingerprinting code, as the README explains, is found in fingerprint.js[2], which embeds a big JSON literal with the IDs of the extensions it probes for. (Sickeningly enough, this data starts about two-thirds of the way through the file* and isn't the culprit behind the bulk of its 2.15 MB size…)
* the one (on line 34394) starting:
const r = [{
id: "aacbpggdjcblgnmgjgpkpddliddineni",
file: "sidebar.html"
Do they respect my data? Why do they get to track me across sites when I clearly don't want them to but someone can't scrape their data when they don't want them to. Why should big companies get the pass but individuals not? They clearly consider internet traffic fair game and are invasive and abusive about it so it is not only fair to be invasive and abusive back, it is self defense at this point.
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.
No, I consider all data collection and scraping egregious. From that perspective, LinkedIn is hypocritical when Microsoft discloses every filesystem search I do locally to bing.
I'm sure there are issues with fake accounts for scraping, but the core issue is that LinkedIn considers the data valuable. LinkedIn wants to be able to sell the data, or access to it at least, and the scrapers undermine that.
They could stop all the scraping by providing a downloadable data bundle like Wikipedia.
We enjoy the fruits of an LLM or two from time to time, derived from hoards of ill gotten data. Linkedin has the resourses to attempt to block scraping, but even at the resource scale of LI I doubt the effort is effective.
I am not denying that scraping is useful. If it wasn't people wouldn't do it. But if the site rules say you aren't allowed to scrape, then I don't think people should be hostile towards the people enforcing the rules.
Well, they can try to enforce the rules; that's perfectly fair. At the same time, there are many methods of "trying" which I would not consider valid or acceptable ones. "Enforcing the rules" does not give a carte blanche right to snoop and do "whatever's necessary." Sony tried that with their CD rootkits and got multiple lawsuits.
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!
I mean, regardless of who they are or even if you don’t like what LinkedIn does themselves with the data people have given them, the random third parties with the extensions don’t additionally deserve to just grab all that data too, do they?
Eh. I worked at a company which made an extension which scraped LinkedIn. We provided a service to recruiters, who would start a hiring process by putting candidates into our system.
The recruiters all had LinkedIn paid accounts, and could access all of this data on the web. We made a browser extension so they wouldn’t need to do any manual data entry. Recruiters loved the extension because it saved them time.
I think it was a legitimate use. We were making LinkedIn more useful to some of their actual customers (recruiters) by adding a somewhat cursed api integration via a chrome extension. Forcing recruiters to copy and paste did’t help anyone. Our extension only grabbed content on the page the recruiter had open. It was purely read only and scoped by the user.
Chrome is the new IE6. Google set themselves up to be the next Microsoft and is "ad friendly" in all the creepy ways because that's what Google IS an ad company. All they've contributed to security is diminishing the capability of adblockers and letting malware to do bad things to you as consumers.
> 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?
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":
Fingerprinting. There are a few reasons you'd do it:
1. Bot prevention. If the bots don't know that you're doing this, you might have a reliable bot detector for a while. The bots will quite possibly have no extensions at all, or even better specific exact combination they always use. Noticing bots means you can block them from scraping your site or spamming your users. If you wanna be very fancy, you could provide fake data or quietly ignore the stuff they create on the site.
2. Spamming/misuse evasion. Imagine an extension called "Send Messages to everybody with a given job role at this company." LinkedIn would prefer not to allow that, probably because they'd want to sell that feature.
Another thing... they alter the localStorage & sessionStorage prototype, by wrapping the native ones with a wrapper that prevent keys that not in their whitelist from being set.
I didn't find popular extensions like uBlock or other ad blockers.
The list is full of scammy looking data collection and AI tools, though. Some random names from scrolling through the list:
- LinkedGPT: ChatGPT for LinkedIn
- Apollo Scraper - Extract & Export Apollo B2B Leads
- AI Social Media Assistant
- LinkedIn Engagement Assistant
- LinkedIn Lead Magnet
- LinkedIn Extraction Tool - OutreachSheet
- Highperformr AI - Phone Number and Email Finder
- AI Agent For Jobs
These look like the kind of tools scummy recruiters and sales people use to identify targets for mass spamming. I see several AI auto-application tools in there too.
I’m probably on the list. I made a LinkedIn Redactor that allowed you to add keywords and remove posts from your thread that included such words. It’s the X feature but for LinkedIn. Anyway, got a cease and desist from those lame fucks at LI. So I removed from the chrome store but it’s still available on GitHub.
No. Firefox always randomizes the extension ID used for URLs to web accessible resources on each restart [1]. Apparently, manifest v3 extensions on Chromium can now opt into similar behavior [2].
It doesn't work. The person who posted the comment you're responding to has absolutely no idea what he's talking about. He confabulated the entire explanation based on a single misunderstood block of code containing the comment «Remove " - Chrome Web Store" suffix if present» in the (local, NodeJS-powered) scraper that the person who's publishing this data themselves used to fetch extension names.
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.
Is there no browser setting to defend against this attack? If not, there should be, versus relying on extension authors to configure or enable such a setting.
I imagine that it would require browsers to treat web requests from JS differently from those initiated by the user, specifically pretending the JS-originating requests are by logged-out or "incognito" users (by, I suppose, simply not forwarding any local credentials along, but maybe there's more to it than that).
Which would probably wreak havoc with a lot of web apps, at least requiring some kind of same-origin policy. And maybe it messes with OAuth or something. But it does seem at least feasible.
How do you patch it? The extensions themselves (presumably) need to access the same web accessible resources from their content scripts. How do you differentiate between some extension’s content script requesting the resource and LinkedIn requesting it?
The file is then available using a URL like: moz-extension://<extension-UUID>/images/my-image.png"
<extension-UUID> is not your extension's ID. This ID is randomly generated for every browser instance.
This prevents websites from fingerprinting a browser by examining the extensions it has installed.
It does by default, except for the files from the extension that the extension author has explicitly designated as content-accessible. It's explained ("Using web_accessible_resources") at the other end of the link.
If this is true, it's insane that this would work:
- why does CWS respond to cross-site requests?
- why is chrome sending the credentials (or equivalent) in these requests?
- why is the button enabled server-side and not via JS? Google must be confident in knowing the exact and latest state of your installed extensions enough to store it on their servers, I guess
It's not true. The person you're responding to has a habit of posting implausible-but-plausibly-plausible nonsense, and that's not how this works at all.
I made the mistake of trying to skim the code hastily before I had to leave to run an errand, and yes it turns out I was wrong, but please refrain from the personal comments, and no, I don't have any such "habit."
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.)
Looks like Firefox is immune.
This works by looking for web accessible resources that are provided by the extensions. For Chrome, these are are available in a webpage via the URL chrome-extension://[PACKAGE ID]/[PATH] https://developer.chrome.com/docs/extensions/reference/manif...
On Firefox, web accessible resources are available at "moz-extension://<extension-UUID>/myfile.png" <extension-UUID> is not your extension's ID. This ID is randomly generated for every browser instance. This prevents websites from fingerprinting a browser by examining the extensions it has installed. https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
And they said that using a browser with sub-5% market share would cause us to miss out on the latest and greatest in web technology!
chrome was made by ex-firefox devs, chrome is still not as good!
This is probably a naive question, but...
Doesn't the idea of swapping extension specific IDs to your browser specific extension IDs mean that instead of your browser being identifiable, you become identifiable?
I mean, it goes from "Oh they have X, Y , and Z installed" to "Oh, it's jim bob, only he has that unique set of IDs for extensions"
It's not a naive question. This comment says it's not possible to do that: https://news.ycombinator.com/item?id=46905213
Oh, it's (re)randomised upon each restart, whew, thanks for the heads up
edit: er, I think that that also suggests that I need to restart firefox more often...
Maybe, but how long are the extension ids? And if they are random, how long to scan a trillion random alphanumeric ids, to find matches?
I presume the extension knows when it wants to access resources of its own. But random javascript, doesn't.
The extension IDs are UUIDs/GUIDs, so 128 bits of entropy. No site is going to be able to successfully scan that full range.
ChatGPT told me it can be done though.
It won't disclose how, as it says it has had several users report it. And that it expects 50% of the bounty, and will use it for GPU upgrades.
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.
In order to create the data source that LinkedIn's extension-fingerprinting relies on to work, someone (at LinkedIn*?) almost certainly violated the Chrome Web Store TOS—by (perversely*) scraping it.
* if LinkedIn didn't take the data from an existing data source
a problem for linkedin != "a problem". The real problem for people is the back room data brokering linkedin and others do.
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?
"The code" here you're referring to (fetch_extension_names.js[1]) isn't and doesn't claim to be LinkedIn's fingerprinting code. It's a scraper that the researcher behind this repo wrote in order to themselves create the CSV that they're publishing.
LinkedIn's fingerprinting code, as the README explains, is found in fingerprint.js[2], which embeds a big JSON literal with the IDs of the extensions it probes for. (Sickeningly enough, this data starts about two-thirds of the way through the file* and isn't the culprit behind the bulk of its 2.15 MB size…)
* the one (on line 34394) starting:
1. <https://github.com/mdp/linkedin-extension-fingerprinting/blo...>2. <https://github.com/mdp/linkedin-extension-fingerprinting/blo...>
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.
Do they respect my data? Why do they get to track me across sites when I clearly don't want them to but someone can't scrape their data when they don't want them to. Why should big companies get the pass but individuals not? They clearly consider internet traffic fair game and are invasive and abusive about it so it is not only fair to be invasive and abusive back, it is self defense at this point.
They don’t need to track your web browser when they’re owned by Microsoft, because they track every action at a lower level.
What lower level? Microsoft owns internet?
The operating system. For example see the Windows 11 screenshot debacle/scandal.
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.
No, I consider all data collection and scraping egregious. From that perspective, LinkedIn is hypocritical when Microsoft discloses every filesystem search I do locally to bing.
I'm sure there are issues with fake accounts for scraping, but the core issue is that LinkedIn considers the data valuable. LinkedIn wants to be able to sell the data, or access to it at least, and the scrapers undermine that.
They could stop all the scraping by providing a downloadable data bundle like Wikipedia.
LLMs scrape Wikipedia all the time, or at least attempt to.
The data bundle doesn't help that at all.
Yes, until it becomes abusive and malignly affects innocents.
We enjoy the fruits of an LLM or two from time to time, derived from hoards of ill gotten data. Linkedin has the resourses to attempt to block scraping, but even at the resource scale of LI I doubt the effort is effective.
I am not denying that scraping is useful. If it wasn't people wouldn't do it. But if the site rules say you aren't allowed to scrape, then I don't think people should be hostile towards the people enforcing the rules.
Well, they can try to enforce the rules; that's perfectly fair. At the same time, there are many methods of "trying" which I would not consider valid or acceptable ones. "Enforcing the rules" does not give a carte blanche right to snoop and do "whatever's necessary." Sony tried that with their CD rootkits and got multiple lawsuits.
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!
I mean, regardless of who they are or even if you don’t like what LinkedIn does themselves with the data people have given them, the random third parties with the extensions don’t additionally deserve to just grab all that data too, do they?
I say the same thing about my start menu sending every action I perform to bing.
Eh. I worked at a company which made an extension which scraped LinkedIn. We provided a service to recruiters, who would start a hiring process by putting candidates into our system.
The recruiters all had LinkedIn paid accounts, and could access all of this data on the web. We made a browser extension so they wouldn’t need to do any manual data entry. Recruiters loved the extension because it saved them time.
I think it was a legitimate use. We were making LinkedIn more useful to some of their actual customers (recruiters) by adding a somewhat cursed api integration via a chrome extension. Forcing recruiters to copy and paste did’t help anyone. Our extension only grabbed content on the page the recruiter had open. It was purely read only and scoped by the user.
Surely they do! The data is in the public internets, aren't they?
They'd put Widevine or PlayReady DRM on the website if they could, I'm sure.
why can't they?
Chrome is the new IE6. Google set themselves up to be the next Microsoft and is "ad friendly" in all the creepy ways because that's what Google IS an ad company. All they've contributed to security is diminishing the capability of adblockers and letting malware to do bad things to you as consumers.
[delayed]
> Google set themselves up to be the next Microsoft
Google became a monopoly. All monopolies do this.
I wrote an article about it a couple of months ago. I also explain why, how and a way to prevent it.
https://javascript.plainenglish.io/the-extensions-you-use-ar...
To clarify, you talk about why it's possible, not why LinkedIn is doing it, right? Or did I miss something in your article.
I wrote a blog post recently about the technique used by LinkedIn to do extension probing, as well as other ways to do it with less side effects
https://blog.castle.io/detecting-browser-extensions-for-bot-...
I can confirm.. open up linkedIn.. hit F12 and watch the error count keep going up and up and up
Screenshots found here https://x.com/DenisGobo/status/2018334684879438150
xcancel link: https://xcancel.com/DenisGobo/status/2018334684879438150
Setup a quick CDP connection. Have Claude Code attach and inject JS into Page.addScriptToEvaluateOnNewDocument. Loads before the page.
Typical early hooks: • fetch wrapper • XMLHttpRequest.prototype.open/send wrapper • WebSocket constructor wrapper • history.pushState/replaceState wrapper • EventTarget.addEventListener wrapper (optional, heavy) • MutationObserver for DOM diffs • Error + unhandledrejection capture
what would this do?
> 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-...
Curious question: why would they check for installed extensions on one's browser?
Fingerprinting. There are a few reasons you'd do it:
1. Bot prevention. If the bots don't know that you're doing this, you might have a reliable bot detector for a while. The bots will quite possibly have no extensions at all, or even better specific exact combination they always use. Noticing bots means you can block them from scraping your site or spamming your users. If you wanna be very fancy, you could provide fake data or quietly ignore the stuff they create on the site.
2. Spamming/misuse evasion. Imagine an extension called "Send Messages to everybody with a given job role at this company." LinkedIn would prefer not to allow that, probably because they'd want to sell that feature.
3. User tracking.
most automations for sales and marketing use browser extensions... linkedIn wants you using their tools not 3rd party
Their own tools suck, that’s the issue.
For a social network, more information about their users = better ad targeting. It likely gets plumbed into models to inform user profiles.
Look at the actual list. It's primarily questionable AI tools, scrapers, lead generation tools, and other plugins in that vein.
I would guess this is for rate limiting and abuse detection.
An attempt at fingerprinting, I suppose?
Another thing... they alter the localStorage & sessionStorage prototype, by wrapping the native ones with a wrapper that prevent keys that not in their whitelist from being set.
You can try this by opening devtools and setting
I suggest everyone take a look at the list of extensions and their names for some very important context: https://github.com/mdp/linkedin-extension-fingerprinting/blo...
I didn't find popular extensions like uBlock or other ad blockers.
The list is full of scammy looking data collection and AI tools, though. Some random names from scrolling through the list:
- LinkedGPT: ChatGPT for LinkedIn
- Apollo Scraper - Extract & Export Apollo B2B Leads
- AI Social Media Assistant
- LinkedIn Engagement Assistant
- LinkedIn Lead Magnet
- LinkedIn Extraction Tool - OutreachSheet
- Highperformr AI - Phone Number and Email Finder
- AI Agent For Jobs
These look like the kind of tools scummy recruiters and sales people use to identify targets for mass spamming. I see several AI auto-application tools in there too.
See also: a demo page for the same technique that can enumerate many extensions installed in your browser: https://browserleaks.com/chrome
I’m probably on the list. I made a LinkedIn Redactor that allowed you to add keywords and remove posts from your thread that included such words. It’s the X feature but for LinkedIn. Anyway, got a cease and desist from those lame fucks at LI. So I removed from the chrome store but it’s still available on GitHub.
[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...
This is a security vulnerability and should be patched. Sorry, LinkedIn.
(Alternatively extension developers can modify their extensions to block these requests!)
No kidding. I am shocked this works.
Does Firefox have a similar weakness?
No. Firefox always randomizes the extension ID used for URLs to web accessible resources on each restart [1]. Apparently, manifest v3 extensions on Chromium can now opt into similar behavior [2].
[1]: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
[2]: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
It doesn't work. The person who posted the comment you're responding to has absolutely no idea what he's talking about. He confabulated the entire explanation based on a single misunderstood block of code containing the comment «Remove " - Chrome Web Store" suffix if present» in the (local, NodeJS-powered) scraper that the person who's publishing this data themselves used to fetch extension names.
I don't see any evidence of this happening in Firefox. Either it's more difficult or they just didn't bother, either way I'm happy.
Edit: Can't find much documentation on exactly how the anti-fingerprinting works, but this page implies that the browser blocks extension detection: https://support.mozilla.org/en-US/kb/trackers-and-scripts-fi...
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.
Is there no browser setting to defend against this attack? If not, there should be, versus relying on extension authors to configure or enable such a setting.
I imagine that it would require browsers to treat web requests from JS differently from those initiated by the user, specifically pretending the JS-originating requests are by logged-out or "incognito" users (by, I suppose, simply not forwarding any local credentials along, but maybe there's more to it than that).
Which would probably wreak havoc with a lot of web apps, at least requiring some kind of same-origin policy. And maybe it messes with OAuth or something. But it does seem at least feasible.
As people have said it’s not making requests to web store, that’s just part of this repository looking for what extensions it’s blocking via nodejs
Browsers already have strong protections against that sort of thing, look up the same-origin policy and CORS
I see, I was too credulous.
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.
How do you patch it? The extensions themselves (presumably) need to access the same web accessible resources from their content scripts. How do you differentiate between some extension’s content script requesting the resource and LinkedIn requesting it?
Firefox already mitigates this by randomizing the extension path: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
Doesn't the browser know which script it's running?
Why can't it just deny access to the specified path, except to the extension itself?
It does by default, except for the files from the extension that the extension author has explicitly designated as content-accessible. It's explained ("Using web_accessible_resources") at the other end of the link.
If this is true, it's insane that this would work:
- why does CWS respond to cross-site requests?
- why is chrome sending the credentials (or equivalent) in these requests?
- why is the button enabled server-side and not via JS? Google must be confident in knowing the exact and latest state of your installed extensions enough to store it on their servers, I guess
It's not true. The person you're responding to has a habit of posting implausible-but-plausibly-plausible nonsense, and that's not how this works at all.
I made the mistake of trying to skim the code hastily before I had to leave to run an errand, and yes it turns out I was wrong, but please refrain from the personal comments, and no, I don't have any such "habit."
[delayed]
Wouldn't that mean 2900 requests from fingerprint.js??
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-...