[kodablah]

Ah, as an anti-scraper/anti-bot method, every user has all these local network requests made? Maybe it's the true reason, maybe not. Transparency is key here to assume anything more than the worst. Of course any of the rest of us with a modicum of smarts would just side load a custom extension via CLI args (or we'd just browser automate, headless if not detected). Even given the most generous justification, it reeks of careless decision makers playing whack-a-mole (likely fruitlessly) with the users in the crossfire.

[Buge]

I think it's a cat and mouse game. The more that Linkedin publishes about their anti-spam techniques, the more information spammers have to try to evade those anti-spam techniques.

[vidarh]

I know one company at least that sets up a proxy physically near their clients use to obscure that they have a team on the Philippines manually assisting clients with their LinkedIn profiles.

Ultimately they need to police actual negative behaviour, not the mechanics of how people are doing it. But that means potentially restricting engagement of some of their most active users as well.

[kodablah]

It can seem that way with server-side anti-scraping techniques with brute force detection and the like. But at some point you have to accept that playing the game on the client-side needs to stop escalating once you're making dozens of local extension resource requests in a user's browser. It makes me want to publish and maintain a legit scraper for LinkedIn that replicates human interaction. They'd DMCA the repo I'm sure, but it goes to show who fights against the open web. I see a "get X, Y, and Z features for free when you use LinkedIn Desktop instead of the website" coming.

[userbinator]

I see a "get X, Y, and Z features for free when you use LinkedIn Desktop instead of the website" coming.

...and then the scrapers replicate interaction with that app instead. UI automation isn't hard these days.

[crankylinuxuser]

Why do we accept this argument of obscurity, when discussing security vulnerabilities proper doesn't elicit the same response?

Why is obscurity OK in these situations? Wouldn't we all benefit with removing scammers if everyone legitimate worked together in the public? Its easy to defeat a single adversary. Its mighty hard to defeat a cooperating team.

[jsnell]

Security vulnerabilities tend to be pretty binary. Either the vulnerability is there and it's exploitable, or it isn't. And once there's a fix, deploying that fix will permanently solve that problem.

Fighting abuse is different. The abusers are using the same request endpoints that the real users are, but just in a way that the service provider doesn't approve of. (Whether it's sending spam, payment fraud, scraping, or something else). There's no single hole to plug, unless you block all the requests outright which also affects real users. Instead you have to classify the incoming traffic, find out the abusive subset, and then act on it appropriately. But unlike with vulnerabilities this doesn't solve the problem permanently.

The moment attackers find out which signals are used by a site, they can start faking them or working around the signals. As a simple example, early email spam classifiers worked by simple matching against a blacklist of highly spammy terms. So the spam adapted to using creative mis-spellings like "v1agra".

[derefr]

LinkedIn doesn’t publish anything about their anti-spam techniques. This was published by a third party, because it was a client-side feature that third parties could discover. Most of LinkedIn’s anti-bot logic is on the backend and completely opaque.