61–70 of 263 posts
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
Earlier quoted context omitted.
Why frame what you are trying to say like that? Businesses of all sizes deserve the ability to protect their businesses from abuse.
Do they respect my data? Why do they get to track me across sites when I clearly don't want them to but someone can't scrape their data when they don't want them to. Why should big companies get the pass but individuals not? They clearly consider internet traffic fair game and are invasive and abusive about it so it is not only fair to be invasive and abusive back, it is self defense at this point.
Earlier quoted context omitted.
Do they respect my data? Why do they get to track me across sites when I clearly don't want them to but someone can't scrape their data when they don't want them to. Why should big companies get the pass but individuals not? They clearly consider internet traffic fair game and are invasive and abusive about it so it is not only fair to be invasive and abusive back, it is self defense at this point.
They don’t need to track your web browser when they’re owned by Microsoft, because they track every action at a lower level.
Earlier quoted context omitted.
Why frame what you are trying to say like that? Businesses of all sizes deserve the ability to protect their businesses from abuse.
I'm sure there are issues with fake accounts for scraping, but the core issue is that LinkedIn considers the data valuable. LinkedIn wants to be able to sell the data, or access to it at least, and the scrapers undermine that. They could stop all the scraping by providing a downloadable data bundle like Wikipedia.
The data bundle doesn't help that at all.
Earlier quoted context omitted.
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?
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:// /images/my-image.png" 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?
Setup a quick CDP connection. Have Claude Code attach and inject JS into Page.addScriptToEvaluateOnNewDocument. Loads before the page. 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
Earlier quoted context omitted.
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 pol…
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
Skimming the list, looks like most extensions are for scraping or automating LinkedIn usage. Not surprising as there's money to be made with LinkedIn data. Scraping was a problem when I worked there, the abuse teams built some reasonably sophisticated detection & prevention, and it was a constant battle.
Looks like Firefox is immune. This works by looking for web accessible resources that are provided by the extensions. For Chrome, these are are available in a webpage via the URL chrome-extension://[PACKAGE ID]/[PATH] https://developer.chrome.com/docs/extensions/reference/manif... On Firefox, web accessible resources are available at "moz-extension:// /myfile.png" is not your extension's ID. This ID is randomly gener…
Doesn't the idea of swapping extension specific IDs to your browser specific extension IDs mean that instead of your browser being identifiable, you become identifiable?
I mean, it goes from "Oh they have X, Y , and Z installed" to "Oh, it's jim bob, only he has that unique set of IDs for extensions"