Live data from Hacker News

LinkedIn checks for 2953 browser extensions

github.com

141–150 of 263 posts

Re: LinkedIn checks for 2953 browser extensions

#141

Earlier quoted context omitted.

lol Let's go a step further and just iterate through them on the client. I plan on having this phone well past the heat death of the universe, so this is guaranteed to finish on my hardware. function* uuidIterator() { const bytes = new Uint8Array(16); while (true) { yield formatUUID(bytes); let carry = 1; for (let i = 15; i >= 0 && carry; i--) { const sum = bytes[i] + carry; bytes[i] = sum & 0xff; carry = sum > 0xff…

Free space heater

[deleted]

Re: LinkedIn checks for 2953 browser extensions

#142

Earlier quoted context omitted.

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.

LLMs scrape Wikipedia all the time, or at least attempt to. The data bundle doesn't help that at all.

That's true, the normal scraping would still happen, but it would eliminate this side business of trying to re-sell LinkedIn's data.

Re: LinkedIn checks for 2953 browser extensions

#144

Earlier quoted context omitted.

The webpage would have to scan the entire UUID space to create this fingerprint, which seems unlikely.

Just have a database of UUIDs. Seems pretty trivial to generate and sort as it's only 16 bytes each.

That's actually a bright idea! Have you ever thought about applying for VC funds?

Once you deliver that, you can also think about a database of natural numbers!

Re: LinkedIn checks for 2953 browser extensions

#146

Earlier quoted context omitted.

The webpage would have to scan the entire UUID space to create this fingerprint, which seems unlikely.

Just have a database of UUIDs. Seems pretty trivial to generate and sort as it's only 16 bytes each.

Relevant: https://news.ycombinator.com/item?id=42342382

Re: LinkedIn checks for 2953 browser extensions

#147
post #71
post #44

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…

And they said that using a browser with sub-5% market share would cause us to miss out on the latest and greatest in web technology!

The latest and greatest is not great for you, but for them.

Re: LinkedIn checks for 2953 browser extensions

#148

Chrome is the new IE6. Google set themselves up to be the next Microsoft and is "ad friendly" in all the creepy ways because that's what Google IS an ad company. All they've contributed to security is diminishing the capability of adblockers and letting malware to do bad things to you as consumers.

Chrome has become much worse than IE6. Microsoft was not in the business of tracking users and selling ads back then.

Re: LinkedIn checks for 2953 browser extensions

#149
post #81

Earlier quoted context omitted.

Maybe, but how long are the extension ids? And if they are random, how long to scan a trillion random alphanumeric ids, to find matches? I presume the extension knows when it wants to access resources of its own. But random javascript, doesn't.

The extension IDs are UUIDs/GUIDs, so 128 bits of entropy. No site is going to be able to successfully scan that full range.

And just in case the magnitude of that isn't obvious to people, that means there are 340,282,366,920,938,463,463,374,607,431,768,211,456 total possible UUIDs. Good luck.

Re: LinkedIn checks for 2953 browser extensions

#150

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

Looks like whatever LLM you used is not doing a very good job.
Post reply on HN