Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How LinkedIn detects browser extensions

github.com

Post reply on HN
Print view View original

81–90 of 113 posts

Re: How LinkedIn detects browser extensions

#81

Post by tanilama »

enriquto wrote: post #67
tanilama wrote: post #33

> LinkedIn violates their own users' privacy in an effort to detect the usage of browser extensions. At the time of writing this, LinkedIn is scanning visitors for 38 different browser extensions. No it is defending against malicious actors from abusing its API.

> No it is defending against malicious actors from abusing its API. I do not really understand the concept of "abusing an API". If an API is amenable to a "bad" use, it seems entirely to be the fault of the API designers, not of its users. The designers built an API that enabled an usage that they did not want. That is their fault, how could it be otherwise?

That is exactly what LinkedIn is doing, they are preventing bad actors from calling their API essentially blacklist them. They cant be blacklisted via IP since they are scattered across the internet, so they are banning them productively. Simple and easy.

Re: How LinkedIn detects browser extensions

#82

Post by newsbinator »

feanaro wrote: post #80
tylerhou wrote: post #51

Earlier quoted context omitted.

Extensions have the same auth rights as your logged-in account (the ability to see people who are out of network, for example). It’s against LinkedIn’s ToS to scrape data.

This should go both ways. It is against my ToS for LinkedIn to scrape which extensions I have installed.

I'm on the anti-LinkedIn side of this scraping debate.

But that said, LinkedIn never agreed to your ToS.

Re: How LinkedIn detects browser extensions

#83

Post by newsbinator »

tanilama wrote: post #33

> LinkedIn violates their own users' privacy in an effort to detect the usage of browser extensions. At the time of writing this, LinkedIn is scanning visitors for 38 different browser extensions. No it is defending against malicious actors from abusing its API.

Why not simply rate-limit everyone reasonably?

Re: How LinkedIn detects browser extensions

#85

Post by feanaro »

newsbinator wrote: post #82
feanaro wrote: post #80

Earlier quoted context omitted.

This should go both ways. It is against my ToS for LinkedIn to scrape which extensions I have installed.

I'm on the anti-LinkedIn side of this scraping debate. But that said, LinkedIn never agreed to your ToS.

True, and I accept this is a potentially good legal refutation of this kind of argument. However, I do consider ToS-es untenable and unjust because of this power asymmetry.

If my computing node is interacting with your computing node, we should either both be able to put restrictions on the use of obtainable information or neither.

Re: How LinkedIn detects browser extensions

#86

Post by [deleted] »

feanaro wrote: post #85
newsbinator wrote: post #82

Earlier quoted context omitted.

I'm on the anti-LinkedIn side of this scraping debate. But that said, LinkedIn never agreed to your ToS.

True, and I accept this is a potentially good legal refutation of this kind of argument. However, I do consider ToS-es untenable and unjust because of this power asymmetry. If my computing node is interacting with your computing node, we should either both be able to put restrictions on the use of obtainable information or neither.

[deleted]

Re: How LinkedIn detects browser extensions

#87

Post by tnolet »

tylerhou wrote: post #51
tnolet wrote: post #41

Earlier quoted context omitted.

But how is this data accessible to the extension? I ‘m not an expert, but it seems that this data has to publicly available for an extension to find and parse it. Extensions don’t have magic Auth rights or credentials.

Extensions have the same auth rights as your logged-in account (the ability to see people who are out of network, for example). It’s against LinkedIn’s ToS to scrape data.

Yes, I get that the extension operates within the user's auth realm. But still it should not be able to access data you as a user cannot access. Maybe this is already enough to do damage though.

Re: How LinkedIn detects browser extensions

#88

Post by userbinator »

Changing the name of the extension resources and any extra elements they add to the page would be enough to stop this. (It reminds me of another "trick" pages like to use: randomising the element IDs. Easily defeated by searching for other properties of the desired element.) Just like DRM, it's a stupid cat-and-mouse game, and the mice will always win...

Re: How LinkedIn detects browser extensions

#89

Post by userbinator »

kodablah wrote: post #24
Buge wrote: post #23

Earlier quoted context omitted.

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.

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…

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.

Re: How LinkedIn detects browser extensions

#90

Post by disiplus »

eastendguy wrote: post #55
Buge wrote: post #22

Earlier quoted context omitted.

iMacros is a legit extension. But yeah, I guess there are recruiters using it to spam people.

Agree. iMacros is a completely fine macro recorder. Similar extensions like Kantu and Selenium IDE are not in the list.

well iMacros looks like another scraping tool, while those others look like testing tools that can be used for scraping.
Post reply on HN