This contributing article does not reflect the views and opinions of BAMF Media, its subsidiaries, employees or its management. Its feature on the BAMF platform is to educate, inform, and help our users and clients.
BAMF Media Management
My name is Alexander Erin, I founded Linked Helper in October 2016 and was the sole developer and CEO of Linked Helper 1, a chrome extension, that I made completely on my own. Lately, I co-developed with 7 other guys Linked Helper 2, the standalone app which is a new web browser and not an extension.
I not only saw the early algorithm LinkedIn used to catch the Meet Alfred Chrome extension (one of our main rivals back then) but a year later, in a few weeks of August 2019 I successfully coped with the new LinkedIn detection algorithm. This was when some of the users of Linked Helper 1 reported getting warning messages from LinkedIn.
The article covers a lot of technical aspects of LinkedIn automation, which many of the readers may find somewhat complicated.
To make things a bit easier, and before we go into the ins-and-outs of it, I’ll begin by unveiling our key findings:
LinkedIn is known to use two main approaches to catch the use of automation tools:
This kind of analytics is looking at:
It is a common fallacy among many LinkedIn users, fueled by not-so knowledgeable LinkedIn coaches, that if you work on LinkedIn manually, you will never get banned.
We ran our own tests, and just like many other LinkedIn users who shared on Facebook and forums, found that it wasn't true.
If you want some proof, see for yourself:
1. Try sending 500 connection requests every day during a month, and you will soon – probably in 2 weeks’ time - find out that LinkedIn has restricted your profile and you must now enter a valid email address of every person you are trying to connect with.
2. Go to the LinkedIn search page, select the 2nd relationship level, then go through every page of the search results and keep adding people by clicking the “connect” button every 5 seconds. What happens next is LinkedIn kicks you out of the platform. Log in again, repeat what you did 3-4 times, and you will eventually get restricted on LinkedIn.
It is not only the number of actions that a user does that helps LinkedIn track the use of automation, but how they do it. By clicking Ctrl+Shift+I in your Chrome you will open the DevTools panel that shows what API-requests LinkedIn sends to its servers.
Here’s an example.
There are two ways to open a profile on LinkedIn:
On the surface of it, there’s no difference.
But LinkedIn hsd been looking at many automation tools and found that all of them were using the URL method. Clearly, you can’t block users after just a couple of profile openings via URL: this isn’t good evidence that they are using an automation tool.
But opening 50 profiles via URL within 12 hours is a good indicator, they think.
So, LinkedIn has now introduced this limitation, except for the Sales Navigator and Recruiter platforms.
Try opening every profile from the search result in a new tab, and you will likely get logged out before you reach the seventh page.
After you log back in, go on with this practice until you see a warning message from LinkedIn saying that they suspect you of using an automation tool.
At Linked Helper 2 we chose the second, name-search method of opening profiles, as it is naturally used by many people when they browse LinkedIn without any automation tools.
The main metric you should care about is your acceptance rate – what percent of your sent invitations get accepted.
Given that for many users LinkedIn limits how many invitations they can send per week, you would benefit if you focus on the quality of your connection requests and learn how to write highly-converting ones.
We recommend the following strategy for increasing the acceptance rate for our users:
LinkedIn is also known to analyze how many people click “Dismiss” when they receive your connection request.
In other words, even if you can boast an 80 percent acceptance rate, but you send as many as 400 invitations every day, chances are, that because of your scope, you’ll end up having too many ‘Dismiss’ clicks from the crowd in absolute numbers and, as a result - restriction of your profile.
Therefore, our general recommendation is to keep your pace at about 50-70 invites daily and don’t forget to clear 3-weeks-old pending invitations. https://linkedhelper.zendesk.com/hc/en-us/articles/360015365379-How-to-cancel-sent-pending-invites-
The less critical yet existing threat is parallel access to your LinkedIn account. LinkedIn knows the IP of your machine and its geolocation.
No wonder why if you access your account from 2 countries at the same time, you’ll raise suspicion.
We’ve seen examples when LinkedIn blocked accounts in such cases until they received an explanation of how this could have happened, claiming they did it to protect users’ accounts.
The scenario is possible when:
We believe this is not a serious cause for concern anyway.
We haven’t heard - in 4 years - that someone ever lost their account because they gave control to their assistant. Most likely, you’ll be reminded of the Terms of Use and its part, in particular, that prohibits to hand your account to third parties.
That said, we recommend at least making sure your assistant enters your account from the same country as you do.
By the way, it’s quite difficult to find a reliable service that offers a proxy linked to a specific town. Next time, when you hear that another LinkedIn automation tool is safe because they promise unique proxies for your account, remember that in fact the access might be from a different city and LinkedIn can see it.
To draw a line under this big section, we want to remind that behavioral tactics LinkedIn uses are not just a pain in the neck for the automation tools, but is something to be aware of for everyone who uses LinkedIn today even manually.
As you may have guessed from the name, this approach does not deal with your manual work on LinkedIn. Here we will be looking at how the biggest social platform for business is trying to catch automation tools on a technical level.
There are 3 types of automation tools out there:
Creating a chrome extension is not a big deal of work. I spent 2 days on creating the first, chrome extension, version of Linked Helper 1 having zero experience in making extensions for Chrome and some initial knowledge of JavaScript.
That was the time necessary to architect 2 simple functions – auto-inviting and auto-messaging. Such low cost of market entry explains why very quickly about 100 similar extensions sprung up like mushrooms.
Chrome Store’s role was the distributor and payment processor. Few extensions out of that hundred, however, became a major success like Linked Helper.
In the times when we were a chrome extension, if you typed “LinkedIn” in the Chrome Web Store, you’d see us #1 in the search results with the 80-thousand audience, followed by 2 official plug-ins from LinkedIn and Dux-Soup in the 4th place.
Chrome extensions are very popular because by concept they are an add-on for this or that website, and they are easy to start with.
Sadly, Chrome extensions aren’t 100% safe, and below I will explain why. But first, let’s turn to the algorithms that are currently used to detect extensions-based automation tools.
The earliest detection algorithm was 100% client-based. This means it worked inside your browser, looked for traces of extensions and sent to LinkedIn’s server the list of extensions it caught.
It searched for elements of the interface that were specific of a given extension, though it was a rather superficial check. The algorithm also sent local HTTP requests to unique extension’s resources since it was known which files were used by each extension and their IDs in Chrome store. Linked Helper 1 had already been partly protected by that time: we used random HTML tags and got rid of unique resources.
Instead, the biggest part of the code was loaded from the cloud. Another thing we did to bypass that earliest detection efforts were to block the part of LinkedIn’s API that ran the search for extensions and reported it to LinkedIn.
This algorithm very quickly caught the use of Meet Leonard, a fast-growing new tool at the time, just in the middle of their promo campaign on App Sumo. We can’t say with confidence that it killed the product, but I know for a fact that their work was then paralyzed.
Martin Martinez, the founder of Meet Leonard, made the right decision and built Meet Alfred as a standalone app. As I understand, it is a decent browser-based solution. Though I haven’t checked how good it is from the safety point of view.
After a while, LinkedIn came up with a more sophisticated algorithm for detecting extensions. At random times, the so-called Web Worker (JS code which runs in the background of the main program code of the page) would launch.
It scanned for tags without text-like content, pulled script- and style- tags and its content, then encrypted whatever was found, and sent it to the LinkedIn’s server where that piece was inspected to find traces of extensions.
That second algorithm succeeded in breaking through Linked Helper 1 protection shield in early August of 2019, when users started to report they were caught using Linked Helper 1.
This happened in big part because my team and I’s efforts were fully focused towards the development of Linked Helper 2 app at the time, rather than defending our extension.
To me, it was already clear that no chrome extension for LinkedIn can be 100% safe. Although this was a serious punch from LinkedIn, in 3 days we managed to somehow cope with that hole in our security.
Then it took us another 2 weeks to duly test and release the improved version, but by then we had lost 30% of clients. After the changes I made, every user of Linked Helper 1 had a unique extension.
Now if LinkedIn sent the footprint of the page to its servers, it wouldn’t have been able to find any common signs. Largely because Chrome store’ policies are becoming more and more strict; it is challenging for extensions to respond to LinkedIn’s detection measures. We were forced to leave the Chrome store and started to distribute our product through zip files.
To date, Linked Helper 1 is still alive and working, though the major part of our users has switched to Linked Helper 2 standalone app.
We have survived two detection campaigns from LinkedIn. Why do we still think that Chrome or browser-based extensions aren’t 100% safe?
For two reasons.
One. The screenshot below shows fragments of program code by one of the top Chrome extensions for LinkedIn automation. They block some of LinkedIn’s API which participates in tracking extensions. The bad news is that Chrome continues to limit its API for Chrome extensions, and soon it is likely to force all extensions to use manifest v3. When it happens, the use of such code would be impossible:
Two. Even older extensions’ API of any browser do not allow to fully imitate human-like actions. Moreover, in all modern browsers there’s a technical possibility for web pages to establish by whom or by what an event was triggered (click, input, mouse move) – by human or by program code[АЕ1] . Events and actions made by human will have ‘isTrusted===true` attribute, while those originating from extensions - ‘isTrusted===false’.
Luckily for many extensions now LinkedIn isn’t using this approach, but clearly it is a matter of time. If you click on the ‘Connect’ button, let’s say, they track whether the click originates from a program, and then signal that you are using an automation tool.
Fairly simple.
Such types of solutions are easy to create. It includes automating work with certain LinkedIn API end-points, like retrieving profile data. This is used for tasks where you need to extract profiles from a list of URLs the user gives. Other API end-points are used for sending messages and invites.
There are plenty of solutions on the market that claim they are safe because they run in the cloud. It is super easy for LinkedIn to detect them, though they aren’t doing it now. The thing is such tools mimic only part of LinkedIn processes, but to repeat everything is nearly impossible
Thus, LinkedIn can simply compare the API-requests map of a typical user with that generated by a cloud solution, if they sign up for a trial. Or it is even easier by introducing special detect-requests with random API endpoints to destroy such tools with one shot.
Not every cloud solution for LinkedIn automation works with LinkedIn API. There are browser-based solutions, too.
An example is Phantombuster. This is the only cloud tool I know, who admit publicly and proves in their API documentation that this is a browser-based tool and is built on https://pptr.dev/ Puppeteer and headless Chrome.
In other cases, unfortunately, only LinkedIn and the developers of the solution itself can know the exact type of this or that Cloud solution. We certainly expect that after reading this article, all other Cloud solutions will claim to be implemented on headless Chrome.
Browser-based desktop apps are represented by Linked Helper 2 and Meet Alfred. Both solutions are built on the Chromium engine, which is used in Chrome itself.
Unfortunately, even if you know for a fact that a certain tool is browser-based, you can’t be fully confident it is safe to use. Here’s why:
The best answer is: the solution where professional developers spend more effort and hours on the security matters, always beats others.
If we were to compare two types:
| Cloud | Desktop | |
| Core is well-protected against detection | - (refer to the Puppeter section above) | + |
| How LinkedIn developers can launch tests to capture the use of automation | + (need to publish their code on the Production server) | - (can roll-out locally) |
| Protection from fingerprinting issue and unique proxy | - (Requires protection as all LinkedIn accounts run on the same server) | + (protection is a good-to-have option, but not mandatory, as all users work on their own different machines) |
Thanks for reading such a lengthy piece, which I hope gave you the whole picture of the safety aspect of LinkedIn automation. The key points, if you remember, were given at the beginning for your convenience.
BAMF Expert Guest Post: LinkedIn Automation Safety (Insights from the Developer of an Automation Tool That Was Detected) 