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.
Leonard for Linkedin
Loxo Social import
LinkMatch for zoho CrM
LinkMatch for zoho recruit
inkMatch for CatS
LinkMatch for PCrecruiter
LinkMatch for Pipedrive
LinkMatch for Greenhouse
Spider for Linkedin
Sales Lead Multiplier
Linkedin assistant Lily
auto Connect tools Lily
instant data Scraper
Lusha (FireFox Extension)
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 a malware, isn't it?
That's pretty ballsy to bring up in a defense of LinkedIn.
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.
...and then the scrapers replicate interaction with that app instead. UI automation isn't hard these days.
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
I am fine with huge GDPR fines to teach companies that data is a liability as well as an asset, and needs to be protected appropriately (which this measure doesn't seem to do, since it is trivial to bypass).
I'm not so sure I'm OK with you probing my browser to detect ToS violations/scraping, but not transparently mentioning it makes it worse.
Of course the website does. But the website does it to provide revenue for the website, whereas the extensions probably do it to avoid generating revenue for the website.
LinkedIn is infamous for its dark patterns. They probably do this to protect their revenue model. That in this case it involves protecting the privacy of their users, makes for nice PR.
Though for that matter, their users (which include me) have at least chosen to share their information with LinkedIn. LinkedIn may scam them into sharing more data than they want (which also happened to me), which is absolutely questionable, but at least the users have chosen to do something with LinkedIn, and haven't chosen to do something with the scrapers.
To use rape as an analogy: it's the difference between a guy you wanted to have safe sex with puncturing the condom, and a stranger jumping from the bushes to pull you from your bike. Both are rape, but in very different ways.
Was I trying to defend LinkedIn here? I guess it's different shades of very dark grey.
Apart from campaigning for GDPR-style protections, there are enough other solutions. For example, GitHub has a nice email forwarding feature to preserve user's privacy/email address.
LinkedIn could provide a similar option where when I opt-in, my email address is replaced by an address they provide. They could even go a step further and make it look like a real email address. Any emails to that address are forwarded to my real address, and after the initial forwarding I could reply from my real email address. Meanwhile LinkedIn could do analysis of who is sending what to these email canaries (like they transparently said they would when you opt in), and catch scrapers that way. For users, if I'm getting too much spam, I can simply request a new canary email address from them.
This is what a user-focussed solution would look like. Not some weird semi-legal hack they are doing now.
1. I haven't read their robots.txt, but nothing I've read in GDPR remotely suggests "Right to be forgotten" features that attempt to erase data internet-wide.
Otherwise LinkedIn would just fix the holes and not bother blocking extensions.
The first item from the block list is "Daxtra", who make a very widely used ATS.
Please could you explain the difference from Microsoft's GDPR perspective from when a recruiter accesses this information via a normal browser and manually enters the data into Daxtra vs when someone with the Daxtra plugin accesses it, and uses that to pull the data over?
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?
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.
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!
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?
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?