| ▲ | lapcat 4 hours ago |
| [removed] |
|
| ▲ | chocolatkey 4 hours ago | parent | 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... |
|
| ▲ | ronsor 4 hours ago | parent | prev | next [-] |
| This is a security vulnerability and should be patched. Sorry, LinkedIn. (Alternatively extension developers can modify their extensions to block these requests!) |
| |
| ▲ | 0cf8612b2e1e 4 hours ago | parent | next [-] | | No kidding. I am shocked this works. Does Firefox have a similar weakness? | | |
| ▲ | tech234a 3 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... | | |
| ▲ | cxr 38 minutes 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 is, however, do explain why the technique that LinkedIn actually uses is is a non-starter for Firefox.) | |
| ▲ | tech234a 2 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. |
| |
| ▲ | cxr 3 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. | |
| ▲ | burkaman 3 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... |
| |
| ▲ | MrGilbert 4 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. | | |
| ▲ | ronsor 4 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. |
| |
| ▲ | toomuchtodo 4 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. | | |
| ▲ | zahlman 4 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. | | |
| ▲ | circuit10 3 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 | | |
|
|
|
|
| ▲ | jsheard 4 hours ago | parent | 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. |
| |
| ▲ | what 3 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? | | |
| ▲ | jsheard 3 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.
| | |
| ▲ | zahlman 3 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? | | |
| ▲ | cxr 3 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. |
|
|
|
|
|
| ▲ | cobertos 4 hours ago | parent | prev | next [-] |
| Wouldn't that mean 2900 requests from fingerprint.js?? |
| |
|
| ▲ | halapro 4 hours ago | parent | 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 |
| |
| ▲ | cxr 3 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. | | |
| ▲ | lapcat 2 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." | | |
| ▲ | cxr 2 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.) | | |
| ▲ | lapcat 2 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. | | |
| ▲ | cxr 2 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. |
|
|
|
|
|
|
| ▲ | 3 hours ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | usefulposter 4 hours ago | parent | 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-... |