BAMF Expert Guest Post: LinkedIn Automation Safety (Insights from the Developer of an Automation Tool That Was Detected)

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

Who am I?

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.

The TL;DR

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:

1. Even if you work manually on LinkedIn, Even if you work manually on LinkedIn, this isn’t a guarantee by any means that your account won’t be restricted or banned, or you won’t receive a warning message from LinkedIn one day, saying you might be using an automation tool.
2. If you trust an assistant or a cloud-based solution to manage your LinkedIn account on your behalf, you should know that LinkedIn analyzes the IP and location of your machine. If it finds that you access your account from different countries, they may restrict it, and you’d need to explain how comes one entry was registered from the Philippines and the second one – from the United States on the same day.
3. Even if you stick to very low activity limits, but are using a sloppy LinkedIn automation tool, you are still under the risk of getting restricted or banned on LinkedIn.
4. Chrome or browser extension tools can never be 100% safe due to extensions’ technical limitations.
5. Cloud API based solutions are as safe as extensions (hint: they aren’t safe)
6. Browser-based or cloud browser-based solutions are the safest on the market so far. Having said that, only LinkedIn developers or developers of a given tool can attest to the security of that tool.
7. If you work on LinkedIn manually or use the safest automation tool, don’t ignore the safety rules: stick to the daily activity limits (send only 50-70 invites), cancel pending unaccepted invites every 3 weeks, and keep an eye on your invites’ conversion rate. 

Behavioral and technical detections

LinkedIn is known to use two main approaches to catch the use of automation tools:

• behavioral
• technical

Behavioral approach

This kind of analytics is looking at:

1. How many actions of some kind do you usually make?
2. How exactly do you make these actions?
3. How do your prospects react to your actions?
4. Parallel access to your account

How many actions of some kind do you usually make?

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 2^nd 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.

How exactly do you do these actions?

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:

1. Paste the profile’s URL link into the browser address bar and hit Enter
2. Type the name of the person you are looking for on LinkedIn and select the right contact among options that start to appear.

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.

How do your prospects react to your actions?

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:

1. Visit a profile
2. Like 2-3 recent posts or articles (read how to automate https://linkedhelper.zendesk.com/hc/en-us/articles/360018627020-Like-posts-and-articles)
3. Wait 24 hours and follow profiles (https://linkedhelper.zendesk.com/hc/en-us/articles/360016777979-Profiles-Auto-Follower)
4. In another 24 hours’ time send your connection requests with a personal message
5. Once your request was accepted, send several follow up messages until a person writes you back.

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-

Parallel access to your LinkedIn account

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:

1. You handed over your account to an assistant or a lead generation expert.
2. You use a cloud-based automation tool, and they took the wrong proxy.
3. You use a VPN on your machine.

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. 

Technical approach

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:

1. Chrome or browser extensions. Those are plug-ins that you install in your browser.
2. Cloud solutions which work via LinkedIn API
3. Browser-based solutions (desktop apps or cloud)

Chrome or browser extensions

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 4^th 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. 

1^st extensions detection algorithm

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. 

2^nd extensions detection algorithm

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.

Cloud solutions that work via LinkedIn API

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.

Browser-based solutions (cloud or desktop apps)

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:

1. Puppeter with headless chrome aren’t designed for 100% non-detectable automation. [АЕ1] If you google “Puppeter detected as bot”, you will find quite a number of guides showing how to detect or how to avoid being detected. Some even went further to offer a paid service for finding such bots: https://datadome.co/
2. For some time in the past Puppeter had been wired in such a way to click on the center of a button, and wouldn’t allow copying random ways the clicking is done by real users. What user would click strictly in the centre of a button?
3. We at Linked Helper 2 and Meet Alfred do not use Puppeter. That said, we can’t say how far Meet Alfred’s team has gone in hiding all holes and weaknesses, and how well their tool can pretend it is a human because how the tool works is hidden from users’ eyes. Linked Helper 2 isn’t just browser-based, it is a browser in fact, with a navigation panel. So, when it’s performing, you can see what is going on the screen.
4. In theory, developers of browser-based tools could in some parts resort to the ease of using LinkedIn’s API or insert JavaScript code into the LinkedIn JS environment.
5. Speaking of cloud solutions, if you manage multiple LinkedIn accounts with such tools, they usually run on the same server. Part of the machine, such as your graphics card or the unique footprint of your audio card https://amiunique.org/fp, is visible to LinkedIn. As a user, you can only hope that the cloud solution you are using has taken care of such aspects. It is realistic to do but takes time. Working on Linked Helper 2 our team spent 3 whole weeks to create a unique fingerprint for each LinkedIn account, in case users run multiple LinkedIn accounts on one machine.

Which one is safer: Cloud browser-based or Desktop browser-based solutions?

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:

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.