It isn’t exactly. They created a list of known extensions by their id and a file which is known to exist in that extension. The site iterates over each pair and tries to load that file, if it doesn’t error it knows the extension is installed. It’s a clever and difficult manual process, but it does bypass the security trying to prevent this kind of thing.
I read that their reasoning is it exists to block users that use known scraper extensions which bypass their terms of use. But don’t entirely buy that.
This is how I interpreted the original question and indeed it makes no sense, JavaScript from a website should not be allowed to interact with extensions like this.
It's actually the extension injecting itself into the webpage, often to interact with it. (I imagine much of this is just looking for global ExtensionName objects.)
Actually, the article is clear about what is happening technically, and it’s both. Chrome does, in fact, allow the page to make requests for resources stored in the extension bundle, and this is one of the two fingerprinting methods that the article describes.
I agree, and this is why I built 404. If you poke around the page a bit, you'll see a tool that prevents browser fingerprinting.
404 catches JS calls in JS proxies and returns mocked-up values (assigned by a profile), it also has protections against TLS fingerprinting, canvas fingerprinting, device enumeration, TCP/IP fingerprinting, HTTP header fingerprinting, and more.
The predatory practices that browser fingerprinting have enabled guised behind "fraud protection" are atrocious. Even with a VPN, even in incognito mode, a website can track me and see what I've been doing EVEN IF ITS NOT ON THEIR SITE.
Then a data broker buys all this data and uses an AI model to put it all into a pretty little package and sell it to Google, or the gov't, or something. It's scary.
Because extensions can and often do contain stuff like images or JS bundles that they inject into a target page's DOM. Not allowing a tab's context to load files from the chrome-extension:// namespace would break a lot of things.
True, but you'd expect the same CORS rules to apply for extensions.
Only pages originating from an extension are by default able to load resources from said extension.
Chrome exposes these files via a URL that you can fetch in javascript like you would any other file on a normal website. These local extension files usually contain code, styles or images that your browser needs to run the extensions.
CORS is a server setting to tell the browser not to load its data from potentially unsafe origins. If you set a server to send access-control-allow-origin: *, then your browser will happily load these resources for you regardless of where you currently are. And chrome extensions need to be loadable from everywhere to be able to inject code or images into pages, so enabling CORS for them would defeat their main purpose. The extensions themselves might even need to bypass an existing CORS setup for the website you are currently on to fetch additional data.
From the other end, yes extensions access all page data, but pages shouldn't access extension data at all; it feels like that should be the CORS violation.
"Chrome extensions can expose internal files to web pages through the web_accessible_resources field in their manifest.json. When an extension is installed and has exposed a resource, a fetch() request to chrome-extension://{id}/{file} will succeed. When the extension is not installed, Chrome blocks the request and the promise rejects.
LinkedIn tests every extension in the list this way."
Is that information available to websites? I figured they were doing some kind of novel hackery to self-detect extensions based on behaviour that would only happen if X extension was installed.
But that would be a lot of work for 6,300 extensions. Unless someone offers that as a service?
Well, just because LinkedIn still tries to send the requests on Brave doesn't mean the blocking doesn't work. The question is whether any request will give a valid response.
That said, I can't find conclusive info on whether this is blocked exactly. Brave does block "plugins" (which is why I assumed this includes this specific kind of fingerprinting), and the getExtension() call (which is probably unrelated), according to this page: https://brave.com/privacy-updates/4-fingerprinting-defenses-...
But since they don't explicitly mention the chrome-extension URL, you might be right.
I read that their reasoning is it exists to block users that use known scraper extensions which bypass their terms of use. But don’t entirely buy that.