Is Jobin.cloud safe? It Keeps Your Session Local but LinkedIn Can Still See the Automation

Jobin.cloud, the LinkedIn sourcing and outreach platform, is an extension (local-scrape, vendor-orchestrated over WebSocket).

Jobin.cloud does not read your LinkedIn session cookie. Linked Helper's static audit of the shipped v0.4.97 source found zero occurrences of li_at in executable JavaScript, and the manifest requests no cookies permission that could expose it.

The only li_at=AQED… strings sit in .js.map debug artefacts as captured-request examples, not in executable harvest code. A targeted check for chrome.cookies calls across the bundles returned zero. This is a static absence check, not a runtime observation.

Linked Helper's security study — static audits of 16 extensions plus live two-account tests of seven cloud tools—traced Jobin.cloud and recorded the locations below. I read that record and checked it for internal consistency; I did not inspect the extension source myself.

The audit read v0.4.97. When I opened the Chrome Web Store listing on 2026-08-26 it was serving v0.4.98, “Updated July 29, 2026” — one patch between what was traced and what installs today.

“My session never leaves my browser” is not the same as “my account will not be restricted.” Jobin.cloud earns the first, not the second.

What the Permission List Contains—and What It Does Not

The manifest's permission block sits at manifest.json:9-19 and holds five entries:

text
storage alarms activeTab scripting webRequest

There is no sixth. cookies is absent, which means chrome.cookies.* is not merely unused but unavailable to this extension at the browser level — the decisive session fact, and the thing that turns the missing li_at from an omission into a structural one.

What this means for detection: nothing in this list is itself visible to LinkedIn — a manifest is a Chrome-side declaration, not something a page can read. Two entries matter because of what they let the extension go on to do: scripting is what puts code inside a real LinkedIn tab, and that injected markup is what a DOM-wide scan can find. The absent entry matters for the opposite reason: with cookies unavailable, the session-theft vector is foreclosed at the permission layer rather than merely unexercised in the code.

The Content Security Policy allows connect-src * (manifest.json:29). That broad capability permits any host; it is not evidence of behaviour or intent.

What JSESSIONID Actually Is

Module 3578 reads JSESSIONID with js-cookie, throws "Missing XSRF" when absent, and returns a csrf-token key (linkedin-all-content-script.js:6604-6612; library at linkedin-all-content-script.js:24289):

JSESSIONID "Missing XSRF" { "csrf-token": <value> }

What this means for detection: nothing fires here, and that is the finding. JSESSIONID is LinkedIn's XSRF token, not the authenticated session; no session is replayed elsewhere, and LinkedIn sees the real device fingerprint from the user's own machine.

The value is a header on same-origin calls to www.linkedin.com, including connectionsSummary (linkedin-all-content-script.js:28072). The browser attaches li_at automatically; the extension never sees it. JSESSIONID never enters a vendor request body.

The document_cookie x15 figure is a count of how many times that string appears in the shipped source, not a count of reads that happened. The two relevant occurrences are third-party code: js-cookie (linkedin-all-content-script.js:24289) and axios's XSRF helper (linkedin-all-content-script.js:19235-19238). Neither shows Jobin.cloud harvesting cookies.

Parallel-session detection needs the same session presented from somewhere else, and that never happens here. LinkedIn's 48-signal device fingerprint — assembled by LinkedIn's own page code and injected into every API request — can expose a server replaying a session it did not originate, but no server replays anything in this architecture. LinkedIn receives the genuine fingerprint of the machine the user is sitting at.

The Pivot: Three Things Are Still True

1. The extension announces itself before you click

“Active Extension Detection” (AED) is not marketing language, and it is not a name anyone in security research made up: it is the term LinkedIn ships inside its own production page code, where the result is emitted as an AedEvent. The page silently fetch()es chrome-extension://<id>/<file> from a hardcoded array; a fulfilled response means installed. It runs on every visit, before the tool does anything. LinkedIn has never said a word about it in public.

BrowserGate is the independent 2025–26 investigation that took apart LinkedIn's production bundle and published line references and excerpts. The list grew from 38 entries in 2017 to roughly 461 in 2024, 5,459 in Dec 2025, and 6,167 in Feb 2026—about 12 additions daily. A literal userAgent.indexOf("Chrome") check limits scanning to Chromium browsers: Chrome, Edge, Brave, Opera, and Arc.

For Jobin.cloud the audit carries the two strings that make the probe work — the ID LinkedIn asks about and the file it asks for. It carries no dated snapshot and no entry count for that brand-specific check, so I will not supply one:

hcdjjibhifjclfoblokahaacifcjpgfl linkedin-add-note.867bdadb.svg

What this means for detection: install state is observable on every page load, ahead of any user action. Being listed is not a ban, a flagged account, or enforcement; it is one input, and it gains weight only once the same tool starts sending batch invitations from the same browser.

There is a second, list-free route. Jobin.cloud injects content scripts into /talent/, /sales/, the rest of linkedin.com/, and its own jobin.cloud/ context (manifest.json:39-74). It also injects an iframe panel from my.jobin.cloud/extension with the marker jobin-extension (linkedin-all-content-script.js:32142; linkedin-all-content-script.js:21113).

/talent/ /sales/ [linkedin.com/](https://linkedin.com/) jobin.cloud/ my.jobin.cloud/extension jobin-extension

What this means for detection: a DOM-wide scan for the chrome-extension:// substring, across page text and attributes, needs no target list at all. The ID probe answers a question about installation; the DOM scan answers a question about activity. Jobin.cloud gives LinkedIn an affirmative answer to both, and it gives them before and during the automation rather than after it.

2. It performs private-Voyager write operations

The strongest risk finding in the record is not a read. Linked Helper's audit places:

• a batch-invitation POST at linkedin-all-content-script.js:32944 (voyager/api/growth/normInvitations?action=batchCreate),
• message sends at linkedin-all-content-script.js:2244, linkedin-all-content-script.js:33284 and linkedin-all-content-script.js:33294(voyager/api/messaging/conversations),
• and invitation operations at linkedin-all-content-script.js:15321 and linkedin-all-content-script.js:15324 (voyager/api/relationships/invitations).

These are calls into a private, undocumented LinkedIn API that LinkedIn does not publish for third-party use, and they are the account doing things rather than the extension looking at things.

What this means for detection: each write lands in two places at once. In the request map it is an API action with none of the page loads, scrolling, hovering, prefetches or telemetry that human work drags along behind it. In the behavioural record it is volume, pacing, and an acceptance rate attached to an account.

What reaches LinkedIn's servers when the queue fires is a single authenticated write that creates a set of invitations at once, and around that write the ordinary residue of a person doing the same work — the searches that surfaced the profiles, the profile loads that followed, the scroll and hover telemetry, the prefetches the page issues on its own — is simply not in the record. Nothing has to trip client-side for that to be visible, because the log LinkedIn already keeps is where the shape shows up.

Skipping synthetic clicks removes exactly one vector: isTrusted, the flag LinkedIn's page code reads to tell a real user gesture from a scripted one. Jobin.cloud does not need that vector, because it never touches the UI — it addresses LinkedIn's private API directly, which puts the automation in front of a different set of checks entirely: the shape of the request itself, the headers it carries, and whether the surrounding page traffic a human would have generated is there or missing. Clean on one vector is not the same as quiet.

The calls originate in the user's own browser, carrying the real device fingerprint and the user's own IP, which removes the parallel-session and replayed-device mismatches a vendor-hosted tool creates. It does not remove the request-map mismatch, because that one is generated by the call itself rather than by where the call came from. These writes add risk; they do not imply an automatic ban.

3. The vendor pushes the work queue

A socket.io connection reaches my.jobin.cloud/extension on the path /realtime-subscription-service/socket.io, over the websocket transport, carrying an auth token and a query field holding userLinkedinUrl (linkedin-all-content-script.js:32142-32147).

The token is a Jobin.cloud JWT, and userLinkedinUrl is the public LinkedIn profile URL resolved by L() at linkedin-all-content-script.js:32102. Neither is a LinkedIn credential: the first authenticates the user to Jobin.cloud, and the second is the same string anyone can copy off a public profile page. The events the server pushes back down that socket include:

• runLinkedinOperation
• completion notices such as autoImportLinkedinProfileResult and enrichmentCompletedNotifyJobin
• a state event named multiple_sessions_active (linkedin-all-content-script.js:32165)

What this means for detection: no LinkedIn-side vector sees this WebSocket. The downstream consequence is behavioural: the timing, batching, and volume of the local private-API operations are highly likely to be settled by whatever the vendor's queue decides to push, and merely executed by the code in the browser.

That is an inference from the architecture, not an observation of the queue itself. What a static read can establish is where the decision about pacing lives, and it does not live on the user's machine.

Scraped profile and campaign results go through Apollo to https://my.jobin.cloud/api/graphql (linkedin-all-content-script.js:28620). Its tokenName:"token" is a Jobin.cloud JWT, and credentials:"include" sends Jobin.cloud's own cookies to Jobin.cloud (linkedin-all-content-script.js:28630). Commands arrive from my.jobin.cloud/extension, LinkedIn calls stay same-origin, and crash and error telemetry goes to Google Cloud Error Reporting. No LinkedIn session cookie enters a vendor payload.

What this means for detection: nothing on LinkedIn's side sees any of this. A third-party GraphQL upload and a Google error-reporting call are invisible to LinkedIn; they are a privacy question — how much of your sourcing output ends up sitting on a vendor's server — rather than a detection one. It is worth separating the two, because the rest of this piece is about the detection half.

Check This Yourself

This check demonstrates LinkedIn's scanning and telemetry. It does not reproduce the static trace of Jobin.cloud's extension.

1. Open linkedin.com in a Chromium browser and open DevTools.
2. In Sources, search the loaded JavaScript bundles for AedEvent.
3. Search the same loaded bundles for hcdjjibhifjclfoblokahaacifcjpgfl.
4. If the surrounding code is readable, inspect the array entry and the chrome-extension:// fetch pattern rather than treating the string alone as enforcement.
5. Switch to Network, filter for li/track, and navigate around LinkedIn. The continuing requests are the observable half of the finding that Jobin.cloud does not block telemetry.

What This Means for Your Account

Nothing in that list is a switch. LinkedIn's enforcement runs on accumulated evidence, and every one of these findings sits well below the threshold on its own; what moves an account is several of them arriving together and repeating. A clean answer to the session question does not settle the account question.

Nobody has published a Jobin.cloud ban story. I went looking in the places people usually vent about a restricted account, and came back with nothing quotable in either direction. That was a bounded search, not an exhaustive sweep of the internet, and the absence is weak evidence either way. The Chrome Web Store listing I checked on 2026-08-26 showed roughly 6,000 users and 4.6 stars from only 26 ratings; 26 ratings cannot support a reputation verdict, and restrictions are under-reported everywhere.

With no legitimate counter-quote, the balance comes from the engineering record itself:

• Session handling is genuinely clean, but LinkedIn restrictions are not handed out because a vendor stored a cookie; they follow detectable activity and behaviour.
• Jobin.cloud does not fake clicks, but it replaces DOM automation with private-API writes that expose a different request pattern.
• Jobin.cloud does not block LinkedIn's telemetry, but the listener proving that is still an observer reading request URLs.

The vendor's own pages sharpen the distinction. Its security page, fetched 2026-08-26, leads with:

“Enterprise-grade security, transparency, and control.”

SSL/TLS, EU-only hosting, ISO 27001, SOC 2, CSA STAR, and PCI L1 are real certifications. They cover the data centre — where records live, which auditors signed off — and none of them describes how the linked extension behaves inside a LinkedIn account.

A second vendor post is blunter:

“The only way to consistently avoid restrictions is to bypass them entirely.” — Jobin.cloud, “How to avoid LinkedIn Restrictions”, published 2025-12-10, updated 2026-03-28

That supplies the intent behind the mechanism. The same post advertises reading profiles “without ever viewing or opening them in the first place” — the missing page visits are the product, sold as the feature, and they are the same missing page visits a request-map comparison reads as a mismatch.

The vendor's page titled “How to Bypass LinkedIn Invitations Limits”, published 2025-07-18 and updated 2026-03-28, states:

“LinkedIn limits your connection requests to 100/week regardless of subscription.”

The number proves nothing about enforcement. What it shows is that the code and the stated goal line up: batch writes step around a counter the user can see, and that counter is not the whole of what LinkedIn records.

You can see full line-by-line teardown: https://safe-outreach.com/is-jobin-safe