Detecting a LinkedIn restriction without crying wolf
The word 'captcha' appears on every healthy LinkedIn page. Here is how we learned to detect a real challenge instead of matching a string.
When a tool watches for LinkedIn restrictions, the obvious approach is to search the page for warning words. It does not work. This is the story of how we found that out, because the failure mode is instructive and it decides whether a safety feature helps or hurts.
The obvious version
The first implementation matched a short list of phrases on the page: "invitation limit", "unusual activity", "security verification", and "captcha". If any appeared, the tool latched a restriction, stopped acting, and asked a human to clear it. Straightforward.
Then we tested it against a real, signed-in, completely healthy account showing a normal home feed, and it latched. The word "captcha" was on the page — in ordinary post text, in aria-labels, and in LinkedIn's own hidden bot-detection markup. There was no challenge on screen. The account was fine.
Why a false alarm is the worse error
It is tempting to treat a false positive as the safe direction: better to stop unnecessarily than to keep sending through a block. That reasoning is backwards for a latch.
A latch is durable by design — it survives restarting the app, so a restriction cannot be silently forgotten. But that same durability means a false alarm stops the customer's outreach entirely until they notice and clear it. A tool that halts a healthy account is broken in the way that matters most, and worse, it teaches the customer to clear restriction warnings reflexively. That habit is exactly what you do not want on the day the warning is real.
What we tried, and why each failed
- Match a captcha iframe. Fails: LinkedIn keeps a captcha iframe present on ordinary pages as part of its own bot detection.
- Require the iframe to have a non-zero bounding box. Fails: it can be laid out while still positioned off-screen or behind the feed.
- Require it to pass a visibility check including opacity and CSS. Still fails: it can be opaque, visible and oversized while not actually in front of the user.
Each rule was tested live against the same healthy session, and each one latched. The progression matters: every version was more careful than the last, and each still produced a false positive.
What actually works
A real challenge takes over the page. It is large and it covers the middle of what the user is looking at. So the final rule requires the captcha iframe to be genuinely visible AND at least 200 by 100 pixels AND to cover the centre of the viewport. Anything less is not a challenge worth alarming a customer about.
The trade-off is explicit and accepted: this will occasionally miss a challenge that presents unusually. That is the right call, because a missed detection is caught by the next action failing — something is wrong within seconds. A false latch has no such backstop; it just quietly stops working.
The general lesson
Page text is not a signal. It is a signal only if you can show that it appears when the condition holds and does not appear when it does not — and that requires testing against a healthy account, not only a restricted one. If your safety check has only ever been tested in the positive case, you do not know whether it works; you know whether it fires.