How LinkedIn detects browser extensions
github.com
github.com
I'm not convinced this is LinkedIn spying on users... rather, it's them protecting its users from the spammy people using these extensions. There's not a single extensions on that list that doesn't result in someone getting an unsolicited email.
daxtra
SalesloftProspector
SalesLoftCadence
discoverly
Ecquire
Ebstabullhorn
EbstaSalesforce
ProspectHive
talentbin
Entelo
Nimble
amazinghiring
colabo extension
StepWells(colabo)
found.ly
datananas
Linkedin-Hubspot Connector
dux-soup(fixed)
data Scraper
aevy
Lusha
Lead Generator
Candidate.ai
Email Hunter
Prospectify
iMacros
Prophet
Leadiq
HirEtuaL
Contact Out
Prospect.io
saleslift.io
Skrapp
Slik
CleverStaff
Linked Helper
Get Email
Sourcehub
Salestools
SellHack
Sourcebreaker
turboHiring
LinMailPro
LinMailNavigator
Leonard for Linkedin
LinkeLead
Loxo Social import
Jlenty
Social2Sugar
Emply
Linkedroid
eLink Pro
LinkMatch for zoho CrM
LinkMatch for zoho recruit
inkMatch for CatS
LinkMatch for PCrecruiter
LinkMatch for Pipedrive
LinkMatch for Greenhouse
Snapaddy Grabber
ramper
Linklead.io
alore.io
Hr-Skyen
SeekOut
Leadkedin
icebreaker
Spider for Linkedin
recruiterNerd
Crelate
EyeMail
Sales Lead Multiplier
Email Finder
Linkedin assistant Lily
auto Connect tools Lily
adapt Prospector
Leadconnect
Linkedbot
People.camp
instant data Scraper
LinkMe tool
adorito
gay2sms
Lusha (FireFox Extension)
LinkedPro
LeadGibbon
Socialbff
And here's the code you can run yourself: https://pastebin.com/Ux684VtLThat's a malware, isn't it?
Nimble is just a CRM. Their extension does not crawl for email addresses, as far as I remember. Why does linkedIn need to "protect its users" from it? Isn't it rather to protect itself against the competition?
That's pretty ballsy to bring up in a defense of LinkedIn.
...and then the scrapers replicate interaction with that app instead. UI automation isn't hard these days.
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.
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.
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".
Other companies are making money with these extensions on LinkedIn's website and LinkedIn is not happy about it
But that said, LinkedIn never agreed to your ToS.
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.
This is besides the fact that many sites (LinkedIn included) aren't very upfront about what exactly they collect. Also, after a certain point, it gets impractical to have to make this decision for each and every site you visit.
Here's a video for one of the extensions https://www.youtube.com/watch?v=2XvtuZjblCc (Warning: loud music)
No, most appear to be plugins for ATS/CRMs, which allow recruiters -- having found a lead on LinkedIn -- to then add them to their CRM. This is profoundly differently.
I found this video for one of the extensions that is a good example of what I'm talking about https://www.youtube.com/watch?v=2XvtuZjblCc (Warning: Loud music)
Someone from BuzzFeed reached out to me asking questions about it and then later that day wrote an article claiming that LinkedIn had asked me to take it down (until that point they hadn't). That night I received a cease and desist letter, so I took it down.
There were many valid reasons to ask for my extension to be removed, but I never got the impression that they were doing it to protect the users whose age was being augmented or at least it didn't feel that was their angle.
It felt more like "this data is ours, so back-off". Just to be clear, I'm not saying that they were rude in their communications or anything like that. But the C&D letter focused a lot on the techniques and uses of my extension and not so much on the "this violates user's privacy" or "this is not representing accurate data".
I just think that in general LinkedIn doesn't like people poking around and trying to scrape data in any way. In the end, that's their most valuable asset (users' data).
For anyone curious, I still have the website: http://www.whoisjuan.me/age-insight-linkedin/
That said, I have no idea of the reasons LinkedIn sent you a C&D. It could well be any of the proposed options, or something else entirely. I'm just highlighting that the language in a C&D will rarely give any indication of intent, at least not "well written" ones anyway.
Some might say it's their only valuable asset...
I'm going to take the top ten from the list as an example:
daxtra -- Nothing like what you've described, plugin for a CRM
SalesloftProspector/SalesLoftCadence -- I don't see any crawling capability at all
discoverly -- Nothing like what you've described -- more like rapportive
Ecquire -- Nothing like what you've described, plugin for a CRM
Ebstabullhorn / EbstaSalesforce -- Nothing like what you've described -- plugins for Bullhorn and Salesforce CRMs only
ProspectHive -- apparently defunct, no idea
talentbin -- this is a social media aggregator
Entelo -- ATS plugin
Extensions can choose if their assets are public or private, and if they reference the asset from injected code - it needs to be public.
It sounds like a better solution might be to track the injected / modified code, and only allow it to read the assets. But I'll bet there is some tradeoff i've no clue about preventing that from happening.
It seems that extensions like ad blockers that are explicitly targeted by such detection methods have ways for work around that (see https://github.com/gorhill/uBlock/blob/master/src/web_access...). I honestly would have expected for that to be the enforced default behavior.
A script doesn’t really inject an image, it injects an image tag which contains a reference to the image. As the image gets loaded there is no check who created the tag.
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?
Got the dropbox extension, show an option to upload your resume from dropbox directly. etc.
Blocking ads, show integrated ads through a secondary channel.
I only created a linkedin account to stop all the email invites... and even then, refuse to install their app (links pervasive in mobile web) and only accept connections to those I've met personally, and very few recruiters.
That's a funny story. But I have a funnier one. Not long ago, maybe the last time LinkedIn came up on HN, I created a test LinkedIn account as Mirimir. Or at least, I attempted to. Given that I use VPNs, I got a cellphone text authentication prompt. But Mirimir doesn't have a cellphone, so I blew it off.
And here's the funny part. A few days later, Mirimir received email from LinkedIn, inviting him to join Mirimir's network on LinkedIn!
Negative view: they're blocking people from circumventing their paid features
Positive view: they're protecting their other users from getting spammed
If LinkedIn offered API access to messaging in a way that let CRMs work with them instead of feel forced to circumvent them I think most who want to use it legitimately would be perfectly happy to have LinkedIn impose various usage limits and peotections even if paid.
They should see this as revenue potential: there are lots of potential to get companies with legitimate reasons for more integration than the current API to upsell their customers on paid LinkedIn features if they are able to offer it in an approved way, and I bet many would be happy to let LinkedIn monitor how it's used.
If they try to block access instead, they'll find more and more companies keep offering the same, but manually.
How would I e.g inject an extension-provided image into a web page without using web accessible resources?
The only ways I can think of would be copying the image to a blob or drawing it on a canvas - both seem significantly more complex than just injecting an IMG tag and would still be detectable as side effects.
I think you could still use them for side-effect detection (watch for images/scripts/etc with a known data uri suddenly appearing in your DOM) - but at least you couldn't actively query it without the extension doing anything.
Yesterday I went back to Linkedin to reconfigure a new email address, and found that the account settings now incorporate a setting to hide your email address to anyone (inactive by default...). I've enabled it and changed again to a new dedicated email address, to see if it is true. I hope this time Linkedin did things right.
Is the detection result reported back to LinkedIn?
In their [Privacy Policy](https://www.linkedin.com/legal/privacy-policy#your_device_an...) they do mention they collect information on "web browser and add-ons".
This reminds me of similar approaches used in other environments. For example in the game industry, anti-cheat techniques of detecting the running software in mobile devices to flag users. How do you think this differs?