Hacker News Reader

Comment by ronsor | Hacker News Reader

This is a security vulnerability and should be patched. Sorry, LinkedIn.

(Alternatively extension developers can modify their extensions to block these requests!)

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.

No kidding. I am shocked this works.

Does Firefox have a similar weakness?

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...

From memory from working with these a couple of years ago:

Firefox extension asset URLs are random and long (there's a UUID in there iirc). The extension itself can discover its randomized base so that it can output its asset URLs, but webpage code can't.

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 that contains 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.

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...

An additional improvement added in manifest v3 in both Chromium and Firefox is that extensions can choose to expose web accessible resources to only certain websites. Previously, exposing a web accessible resource always made that resource accessible to all websites.

That's a different form of defense. The original claim in this thread was that LinkedIn's fingerprinting implementation was making cross-site requests to Chrome Web Store, and that they were reading back the response of those requests.

Firefox isn't susceptible to that, because that's not how Firefox and addons.mozilla.org work. Chrome, as it turns out, isn't susceptible to it, either, because that's also not how Chrome and the Chrome Web Store work. (And that's not what LinkedIn's fingerprinting technique does.)

(Those randomized IDs for content-accessible resources, however, do explain why the technique that LinkedIn actually uses is is a non-starter for Firefox.)

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.

Reply on news.ycombinator.com