upvote

points

by lapcat4 hours ago |
comments
upvoteby chocolatkey4 hours ago|
next
[-]
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...
reply
upvoteby ronsor4 hours ago|
prev|
next
[-]
This is a security vulnerability and should be patched. Sorry, LinkedIn.

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

reply
upvoteby 0cf8612b2e1e4 hours ago|
parent|
next
[-]
No kidding. I am shocked this works.

Does Firefox have a similar weakness?

reply
upvoteby tech234a3 hours ago|
parent|
next
[-]
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...

reply
upvoteby cxr1 hours ago|
parent|
next
[-]
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.)

reply
upvoteby tech234a2 hours ago|
parent|
prev|
[-]
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.
reply
upvoteby cxr3 hours ago|
parent|
prev|
next
[-]
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.
reply
upvoteby burkaman4 hours ago|
parent|
prev|
[-]
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...

reply
upvoteby MrGilbert4 hours ago|
parent|
prev|
next
[-]
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.
reply
upvoteby ronsor4 hours ago|
parent|
[-]
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
upvoteby toomuchtodo4 hours ago|
parent|
prev|
[-]
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.
reply
upvoteby zahlman4 hours ago|
parent|
[-]
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.

reply
upvoteby circuit103 hours ago|
parent|
[-]
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

reply
upvoteby zahlman3 hours ago|
parent|
[-]
I see, I was too credulous.
reply
upvoteby jsheard4 hours ago|
prev|
next
[-]
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.

reply
upvoteby what3 hours ago|
parent|
[-]
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?
reply
upvoteby jsheard3 hours ago|
parent|
[-]
Firefox already mitigates this by randomizing the extension path: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

    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.
reply
upvoteby zahlman3 hours ago|
parent|
[-]
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?

reply
upvoteby cxr3 hours ago|
parent|
[-]
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.
reply
upvoteby cobertos4 hours ago|
prev|
next
[-]
Wouldn't that mean 2900 requests from fingerprint.js??
reply
upvoteby 3 hours ago|
parent|
[-]
deleted
reply
upvoteby halapro4 hours ago|
prev|
next
[-]
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

reply
upvoteby cxr3 hours ago|
parent|
[-]
It's not true. The person you're responding to has a habit of posting implausible-but-plausibly-plausible nonsense, and it's not how this works at all.
reply
upvoteby lapcat2 hours ago|
parent|
[-]
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."
reply
upvoteby cxr2 hours ago|
parent|
[-]
Wrong again. (PS: The fact that you have now replied—which automatically disables comment deletion—is the only thing that prevented my removing it just now. So great job.)
reply
upvoteby lapcat2 hours ago|
parent|
[-]
> The fact that you have now replied—which automatically disables comment deletion—is the only thing that prevented my removing it just now. So great job.

How was I supposed to know that you intended to delete it?

In any case, you may still have time to edit your comment, as I did with my erroneous root-level comment, since I can't delete that either, for the same reason.

reply
upvoteby cxr2 hours ago|
parent|
[-]
Not interested. You also shouldn't have done that. You broke the thread—exactly what HN's no-deleting-comments-that-have-replies check was created to prevent.

Consider this: just stop being reckless.

reply
upvoteby 3 hours ago|
prev|
next
[-]
deleted
reply
upvoteby usefulposter4 hours ago|
prev|
[-]
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-...

reply