5 ms·

[removed]

by lapcat 9mo ago

[removed]

ronsor 9mo ago
This is a security vulnerability and should be patched. Sorry, LinkedIn. (Alternatively extension developers can modify their extensions to block these requests!)
- 0cf8612b2e1e 9mo ago
  No kidding. I am shocked this works. Does Firefox have a similar weakness?
  - burkaman 9mo ago
    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-firefox-blocks-enhanced-track#w_fingerprinters https://support.mozilla.org/en-US/kb/trackers-and-scripts-fi...
    - Wicher 9mo ago
      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.
  - cxr 9mo ago
    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.
  - tech234a 9mo ago
    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/WebExtensions/Chrome_incompatibilities#miscellaneous_incompatibilities https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web... [2]: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/web_accessible_resources#manifest_v3_syntax https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
    - tech234a 9mo ago
      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.
    - cxr 9mo ago
      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.)
- toomuchtodo 9mo ago
  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.
  - zahlman 9mo ago
    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.
    - circuit10 9mo ago
      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
      - zahlman 9mo ago
        I see, I was too credulous.
- MrGilbert 9mo ago
  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.
  - ronsor 9mo ago
    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.
cobertos 9mo ago
Wouldn't that mean 2900 requests from fingerprint.js??
- deleted 9mo ago
  [deleted]
halapro 9mo ago
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
- cxr 9mo ago
  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.
  - lapcat 9mo ago
    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."
    - cxr 9mo ago
      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.)
      - lapcat 9mo ago
        > 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.
        cxr 9mo ago
        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.
usefulposter 9mo ago
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-detection-lessons-from-linkedin-and-castle/ https://blog.castle.io/detecting-browser-extensions-for-bot-...
jsheard 9mo ago
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.
- what 9mo ago
  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?
  - jsheard 9mo ago
    Firefox already mitigates this by randomizing the extension path: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/web_accessible_resources 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.
    - zahlman 9mo ago
      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?
      - cxr 9mo ago
        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.
chocolatkey 9mo ago
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-fingerprinting/refs/heads/main/fingerprint.js https://raw.githubusercontent.com/mdp/linkedin-extension-fin...
deleted 9mo ago
[deleted]

[removed]

by lapcat 9mo ago

[removed]

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

0cf8612b2e1e 9mo ago
No kidding. I am shocked this works. Does Firefox have a similar weakness?
- burkaman 9mo ago
  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-firefox-blocks-enhanced-track#w_fingerprinters https://support.mozilla.org/en-US/kb/trackers-and-scripts-fi...
  - Wicher 9mo ago
    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.
- cxr 9mo ago
  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.
- tech234a 9mo ago
  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/WebExtensions/Chrome_incompatibilities#miscellaneous_incompatibilities https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web... [2]: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/web_accessible_resources#manifest_v3_syntax https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
  - tech234a 9mo ago
    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.
  - cxr 9mo ago
    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.)
toomuchtodo 9mo ago
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.
- zahlman 9mo ago
  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.
  - circuit10 9mo ago
    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
    - zahlman 9mo ago
      I see, I was too credulous.
MrGilbert 9mo ago
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.
- ronsor 9mo ago
  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.

cobertos 9mo ago

Wouldn't that mean 2900 requests from fingerprint.js??

deleted 9mo ago
[deleted]

halapro 9mo ago

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

cxr 9mo ago
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.
- lapcat 9mo ago
  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."
  - cxr 9mo ago
    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.)
    - lapcat 9mo ago
      > 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.
      - cxr 9mo ago
        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.

usefulposter 9mo ago

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-detection-lessons-from-linkedin-and-castle/ https://blog.castle.io/detecting-browser-extensions-for-bot-...

jsheard 9mo ago

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.

what 9mo ago
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?
- jsheard 9mo ago
  Firefox already mitigates this by randomizing the extension path: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/web_accessible_resources 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.
  - zahlman 9mo ago
    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?
    - cxr 9mo ago
      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.

chocolatkey 9mo ago

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-fingerprinting/refs/heads/main/fingerprint.js https://raw.githubusercontent.com/mdp/linkedin-extension-fin...

deleted 9mo ago

[deleted]