Posted by mdp 9 hours ago
const msg = createDoneMessage(); msg.style.opacity = '1';
console.log("Extensions sorted alphabetically!");
console.table(sortedCards.map(c => ({
name: getName(c),
id: c.id || '—'(Alternatively extension developers can modify their extensions to block these requests!)
Does Firefox have a similar weakness?
[1]: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
[2]: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
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.)
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...
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.
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.
Browsers already have strong protections against that sort of thing, look up the same-origin policy and CORS
Should be patched nonetheless though, that's a pretty obscene fingerprinting vector.
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.Why can't it just deny access to the specified path, except to the extension itself?
- 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
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.
Consider this: just stop being reckless.
Edit: Confirmed. It's not pinging the Chrome Web Store. https://blog.castle.io/detecting-browser-extensions-for-bot-...
Typical early hooks: • fetch wrapper • XMLHttpRequest.prototype.open/send wrapper • WebSocket constructor wrapper • history.pushState/replaceState wrapper • EventTarget.addEventListener wrapper (optional, heavy) • MutationObserver for DOM diffs • Error + unhandledrejection capture