DEV Community: Michael Harris

Is ZoomInfo Safe on LinkedIn? I Read Its Extension's Source Code

Michael Harris — Fri, 16 Oct 2026 08:45:51 +0000

ZoomInfo's ReachOut extension is medium risk, but not for the reason people usually fear. Its session handling is confirmed clean: it does not read or upload your LinkedIn login, call Voyager or GraphQL, or automate LinkedIn actions. The tradeoffs are passive detectability and privacy scope—LinkedIn can identify the installed extension, its overlay appears to create a second page-level signal, and browsing context leaves for several ZoomInfo and analytics destinations.

I unpacked build v11.43.1 on 2026-06-05 and read the shipped source. The Chrome Web Store listing had been updated on 2026-05-19 and showed roughly 400,000 users. Here is what the extension declares and what each field means.

What ZoomInfo actually is

ZoomInfo is a type-1 local-scrape extension, although it is quieter than the usual example. It reads which profile or company page is open, then searches ZoomInfo's own contact database. It does not scrape that profile through LinkedIn's internal APIs.

That removes three important mechanisms: no API-only request-map anomaly, no vendor-cloud session running from a parallel IP, and no cloud browser with a fingerprint that differs from yours. It is not a cookie bridge, hosted LinkedIn login, or outreach engine.

Its extension ID is nevertheless on LinkedIn's hardcoded extension list:
text extension_id: fofjcndophjadilglgimelemjkjblgpf probe_file: index.html detected_by_linkedin: true removed: false

What this means for detection: LinkedIn page code can request chrome-extension://fofjcndophjadilglgimelemjkjblgpf/index.html; a successful response reveals installation before ZoomInfo does anything. The mechanism is commonly called AED, or Active Extension Detection. AED is not an official public LinkedIn name or a researcher's coinage: AedEvent is the label in LinkedIn's production JavaScript. BrowserGate, an independent 2025–26 investigation that reverse-engineered that production bundle, documented the system; LinkedIn has never publicly acknowledged it. General snapshots grew from 5,459 entries in December 2025 to 6,167 in February 2026. Those are list-wide figures, not a ZoomInfo-specific June count.

Where your session goes

Step 1 — the probe surface is public:

text web_accessible_resources: resources: [index.html, assets/*] matches: [<all_urls>]

What this means for detection: index.html supplies the exact reachable file LinkedIn's AED entry probes. assets/* is also exposed, but it is not listed as the probe target.

Step 2 — the content script starts broadly and early:

text content_scripts: js: [index.bundle.js] css: [styles.css] matches: [http:///, https:///] run_at: document_start

What this means for detection: the wildcard technically includes www.linkedin.com. This appears to create a Spectroscopy surface if the overlay renders a chrome-extension:// resource into the DOM. Spectroscopy is the list-free DOM scan described by BrowserGate and Linked Helper's security study, which statically inspected 16 extensions and live-tested 7 cloud tools. The shipped fields establish coverage, but this static read did not confirm that such a URI actually rendered, so the claim stays conditional.

Step 3 — generic cookie helpers run locally:

text document.cookie: 8 string occurrences cookies permission: not declared reads_li_at: false

What this means for detection: there is no independent signal here. The eight occurrences are static references across Angular/Zone.js bundles, not eight observed runtime reads. Without Chrome's cookies permission, a targeted li_at or JSESSIONID read is not possible through that permission grant.

Step 4 — the overlay synthesizes UI events:

text programmatic_click: 1 string occurrence synthetic_event: 2 string occurrences

What this means for detection: events created by .click() or dispatchEvent carry the read-only value isTrusted:false; human input carries true. These are static source counts, not three actions observed in a session, but the event property is a real machine-readable distinction.

Step 5 — lookups and telemetry leave the browser:

text fetch: 3 string occurrences xhr: 23 string occurrences
ZoomInfo: app.zoominfo.com, cex.zoominfo.com, ro.zoominfo.com Recruiting: recruiter-app.zoominfo.com, selfparser.zoominfo.com, resumes.indeed.com Telemetry / flags: api.eu.amplitude.com, api2.amplitude.com, LaunchDarkly

What this means for detection: none of these is a LinkedIn Voyager or GraphQL call, so the server-side request-map anomaly is not triggered. This is instead the central privacy finding: profile/company context, engagement events, product traffic, analytics, and feature-flag reads have multiple destinations.

Step 6 — the important absences are structural:

text has_cookies_permission: false reads_li_at: false Voyager calls: not found GraphQL calls: not found CSP: script-src 'self'; object-src 'self' LinkedIn action automation: not found

What this means for detection: there is no session upload, direct LinkedIn API pattern, remote-code path, or behavioral cadence from ZoomInfo itself. Three remote_script string hits resolved to Angular lazy-loading internals rather than remote src execution. This is why an AED hit proves installation, not prohibited activity.

Step 7 — other extensions can message the worker:

text externally_connectable: ids: [""] matches: [".zoominfo.com/", ".chorus.ai/*"]

What this means for detection: this has no LinkedIn-facing detection mechanism. It expands supply-chain scope: any co-installed extension can message ZoomInfo's background worker when the matching site context is open. That is a blast-radius observation, not an accusation that the channel is being abused.

Why there is no cloud or IP score

There is no cloud/IP test for ZoomInfo because there is no cloud-side LinkedIn session to measure. A reproducible IP test requires a vendor-hosted LinkedIn login with its own exit IP, ASN, timezone, and browser fingerprint. ZoomInfo provides no such login: its LinkedIn-facing work occurs in your Chrome, from your IP.
So there is no missing score and no basis for inventing one. The absence is a positive architectural result: parallel-IP/geolocation and 48-point browser-fingerprint mismatch signals do not arise because no vendor server replays the session.

Summary results

Finding	Meaning	Provenance
ID plus `index.html` on LinkedIn's list	Installation is visible through AED	Static cross-check, 2026-06-05
Broad content script at `document_start`	Appears to expose a DOM signal if an extension URI renders	Static declarations; conditional inference
1 click and 2 event patterns	Synthetic events expose `isTrusted:false`	Static string counts
No `cookie` permission, `li_at`, Voyager, or GraphQL	Session stays local; no API-map, parallel-IP, or fingerprint-mismatch vector	Code read
`ids:["*"]` external connectivity	Wider cross-extension message surface, not a LinkedIn signal	Static declaration
3 `fetch` and 23 `XHR` occurrences across named destinations	Privacy/data scope, not runtime request totals	Static string counts
`license` appears 80 times; four tier domains are present	Heavy feature gating; fully subscription-gated is an inference	Static count plus inference
No hosted LinkedIn login	No cloud exit IP exists to score	Inferred from confirmed architecture

What users are actually worried about

The user evidence is privacy-led, and every quote needs a boundary around what it proves.

"Automated processes are a violation of LinkedIn's terms of service, and will get your account locked."

That came from a verified 1-star Trustpilot review dated 2023-11-03. The reviewer identifies a real risk category but the wrong mechanism for this extension: ZoomInfo does not automate LinkedIn actions. Its listed ID and possible DOM footprint remain signals; the quote does not prove a lock from using ZoomInfo as designed.

"I identified the source of this being Zoominfo who I can only assume have scraped my data from LinkedIn without my knowledge or permission."

This 1-star Trustpilot complaint from 2026-03-27 concerns ZoomInfo's aggregated contact database, not the installed extension's session path. The two channels are distinct, and clean session handling does not answer how ZoomInfo originally obtained a non-user's professional data.

"Despite my explicit requests to have my data deleted, I have been contacted repeatedly via phone and email."

This 1-star Trustpilot review from 2026-02-24 turns “opt-out friction” into a concrete allegation: contact allegedly continued after deletion requests. It is user testimony, not a source-code finding, but it directly explains why removal and trust questions dominate searches.

"Potential privacy concerns, as ZoomInfo collects and aggregates personal contact information without the consent of individuals."

The counter-voice is unusually informative: a delighted 5-star G2 reviewer wrote this on 2024-08-22 while praising CRM integration and contact access. ZoomInfo's value and its privacy cost are the same capability viewed from buyer and data-subject seats; the destinations above make the installed-extension side concrete.

"ZoomInfo is selling my personal info scrapped from LinkedIn"

That is only the title of an r/privacy thread (1j0vnfc) surfaced in search results. I could not fetch its body to verify it, so I am not treating the title as first-hand-confirmed evidence. Its value here is narrower: it shows the exact anxiety people bring to the query.

It is a scoring model, not a tripwire. Detectable does not mean bannable, and that gap is unusually wide here because ZoomInfo sends no invitations, messages, or bulk visits. Trade press has speculated that ReachOut belongs to the same exposed category as Apollo and Seamless, but it has documented no specific ZoomInfo enforcement incident. ZoomInfo is inside the passive detection perimeter; it does not share their session-harvesting or bulk-action failure mode.

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

Snov.io Alternatives 2026: Collect, Enrich, Sequence, Hand Off

Michael Harris — Tue, 13 Oct 2026 14:58:04 +0000

Snov.io keeps the whole lead pipeline in one cloud suite: it finds and verifies business emails, runs drip campaigns with deliverability checks and tracks prospects in a lightweight sales CRM, while a Chrome extension, integrations and APIs handle enrichment. Its company page lists 2012 as the year it was founded and dates the launch of its Email Finder product to 2017. For the LinkedIn steps, a separate cloud-hosted add-on carries connection requests, messages and InMails, priced per connected account at $59–69/month.

That model stands in sharp contrast to dedicated desktop engines like Linked Helper, which keep the LinkedIn session strictly local and connect to Snov.io via webhooks. With Snov.io, plan size follows the credit tier, and finding and verifying may draw separate credits—meaning real spend tracks both data and verification volume. On the CRM side, HubSpot and Pipedrive have native two-way sync, with Close reachable via Zapier.

The pipeline, and where each tool sits

Think of LinkedIn lead work as four stages: collect profiles, enrich and verify contact data, sequence outreach, then hand records to a CRM. The four tools below occupy different slices of that chain.

Apollo.io: a structured contact database with email finding and verification, sequences and CRM sync. Its LinkedIn-facing piece is a local browser capture layer.

Linked Helper: LinkedIn collection from 13 sources, plus email finding, outreach and CRM handoff.

Instantly.ai: cold-email sending and mailbox operations. It has no native LinkedIn session and hands LinkedIn steps to third parties.
Kaspr: a per-profile contact reveal widget on LinkedIn pages that exports records onward.

Tool	Category	LinkedIn Data Sources	Built-in Email Finder	CRM Integrations	Price/mo	G2 ★	Architecture
Apollo.io	Contact database and sequences	0 (live profile capture only)	Yes	Adobe Marketo, HubSpot, Pipedrive, Salesforce, Zoho	$59/mo	4.7★ (7,884)	Local-scrape extension (cloud SaaS core)
Linked Helper	LinkedIn collection, outreach and CRM handoff	13 sources	Yes	HubSpot, Instantly, Pipedrive, Salesforce, Zoho (11 total)	$15/mo	4.56★ (142)	Desktop
Instantly.ai	Cold-email sending	0	Yes	HubSpot, Pipedrive (Salesforce via OutboundSync, Close via Zapier)	$47/mo	4.8★ (3,486)	Cloud
Kaspr	LinkedIn contact reveal widget	0 (per-profile reveal on LinkedIn, Sales Navigator and Recruiter pages)	Yes	Brevo, HubSpot, Pipedrive, Salesforce, Zoho	$65/mo	4.44★ (819)	Cookie-bridge / session-upload extension (hybrid widget + cloud backend)

Data as of July 2026, drawn from vendor product and pricing pages and public G2 ratings; architecture labels come from the extension source-code teardown.

1. Apollo.io: database first, LinkedIn capture second

Stage: collect (structured search), enrich/verify, sequence, CRM sync.

The LinkedIn-facing part of Apollo executes locally inside the user’s browser, so the session never reaches vendor servers. Search runs over a database of 230M+ contacts and 30M+ companies with 65+ filters, which makes it a structured data source rather than an arbitrary LinkedIn scraper. Pricing for the contact database and email sequences begins at $59/month.

The same product handles email finding and verification, and Waterfall multi-source verification checks the results. For handoff, Apollo offers native connectors for Adobe Marketo, HubSpot, Pipedrive, Salesforce, and Zoho. Free-tier credits lapse at the close of each billing cycle, and anything unused is gone rather than rolled over.

Reported tradeoffs for Apollo:

LinkedIn sequence steps in Apollo are manual at present; the automated ones were taken out around January 2026 and users complete them by hand.
Ratings split by platform: 4.7★ (7,884) on G2 against 3.24★ (1,076) on Trustpilot, with the last six months at 2.94★ (trending down) across 125 reviews.
Account controls: a December 2025 Trustpilot review reports that an account with 20+ seats was permanently banned mid-session for exceeding an undisclosed daily limit on adding companies.
On data freshness, one Reddit user wrote: "Apollo - huge database and easy UI, but the data's aging fast. Feels like 6-8 months behind in some industries."
Our extension teardown classes it as a "Local-scrape extension; it reads data inside the user’s browser and uploads only the results, so the LinkedIn login and IP stay local". The counts were 17 Voyager and 3 GraphQL signals, plus 80 synthetic-event signals and 28 programmatic clicks. LinkedIn’s hardcoded list of extension IDs, known as AED (Active Extension Detection), is probed on each visit, so the extension’s installed status is visible before Apollo performs an action. The browser component still presents several detection surfaces at once, so we put the extension exposure at Medium; local custody does not make it invisible.

2. Linked Helper: collection, enrichment and handoff in one place

Stage: collect, enrich, outreach, CRM handoff.

Linked Helper pulls from 13 LinkedIn sources and also does email finding, outreach, and CRM handoff, with pricing from $15/month. Credits pay for email finding and data enrichment, and each license covers one LinkedIn account. Collection is not limited to one search surface: besides groups, events, post engagement, companies, and relationship lists, it spans LinkedIn, Sales Navigator, and Recruiter.

For enrichment, the contact data enrichment help article describes a step that looks up email addresses, phone numbers, and messenger contacts where available; each result carries a freshness date, giving a way to flag potentially outdated records. Data Enrichment looks at the date first, so replacing contact data never lets an older result overwrite a newer email already on the profile. If an email cannot be found in Linked Helper’s own data source, that same email-finding step can use a connected Snov.io or Apollo.io account.
On the handoff side, the native CRM connectors include ActiveCampaign, Close.io, HubSpot, Instantly, Pipedrive, Salesforce, and Zoho. The mapping engine can match records by email, LinkedIn member ID, or public ID. The Instantly integration sends LinkedIn non-responders over to Instantly, and email execution stays in the specialist tool.
Whether bundled with a license or bought separately, Linked Helper’s Email Finder and Data Enrichment credits never expire. Only license-bundled AI credits expire with the license.
Being a desktop app and not a browser extension, it has no extension ID to check against LinkedIn’s probe list. It works in a standalone desktop browser, and the session stays on infrastructure the user controls, either their own computer or a VPS they manage, instead of in vendor cloud infrastructure. G2 shows 4.56★ (142).

3. Instantly.ai: the email-sequencing stage

Stage: sequence (mailboxes, warmup, reply handling) plus its own lead data.

Instantly.ai is cloud software for cold email, covering campaign and mailbox management. Natively, it neither scrapes LinkedIn, sends invitations, nor uses a LinkedIn session, so LinkedIn outreach needs another vendor. Within the Automation Builder, one action can hand leads to HeyReach, Aimfox, or Valley; those third parties, and not Instantly, carry out the LinkedIn steps.
On data, the SuperSearch and AI Enrichment waterfall charges roughly one credit when Instantly finds the address, and two or more when it comes from external partners. The product also includes a verification tool that can check discovered addresses before they enter a campaign. Because SuperSearch and enrichment are billed on their own meter, the plan price understates the full cost of prospecting at volume.
The Growth plan of Instantly.ai is $47/month, dropping to $37.60/month on annual billing, with a 14-day trial included. For CRM handoff it offers native integrations with HubSpot and Pipedrive. Salesforce requires OutboundSync, and Close uses a Zapier recipe.
Reviews: G2 shows 4.8★ (3,486) against 4.02★ (1,009) on Trustpilot, and the last six months, covering 110 reviews, average 3.78★ (trending down). No tested LinkedIn architecture or AED status is claimed here; the scope note from our teardown reads "I did not include Instantly.ai in this round's hands-on extension or cloud testing".

4. Kaspr: enrichment at the profile

Stage: enrich per profile, then export.

Kaspr sits on LinkedIn pages as a widget, working on Basic, Recruiter, and Sales Navigator profiles. For whichever profile is open, it reveals phone and email data and then exports the records to sales systems. Starter is $65/month, or $49/month when the annual plan is chosen. Credits meter usage, so spend follows reveal volume. Email finding and verification draw on the same pool. Both use Kaspr’s plan credits.
CRM connections: records go to Brevo, HubSpot, Pipedrive, Salesforce, and Zoho.
On sources, the 0 in the table reflects the absence of list-building sources, while Kaspr can collect leads from regular LinkedIn, Sales Navigator, and LinkedIn Recruiter. Starter is where Sales Navigator access begins, and Recruiter support is limited to Enterprise. More advanced sources such as post engagers or LinkedIn group members are not covered, which limits the audiences teams can turn into outreach lists. Kaspr covers per-profile European phone and email enrichment inside LinkedIn. Scope is the trade-off: list building and outreach automation still need another system.
Evidence and its limits: G2 shows 4.44★ (819), with no Capterra or Trustpilot sample for a cross-check. Our June 2026 source-code teardown rated Kaspr’s hybrid extension HIGH risk: it sends LinkedIn login cookies to Kaspr’s cloud, and it shows up on LinkedIn’s extension scanner. Account restrictions were also reported by four G2 reviewers. That does not establish the code as the cause, though it gives the teardown some user-reported context.

Questions to test on any of them

Nothing in the evidence reviewed supports calling one vendor the most accurate. Run the same representative prospect sample through each tool, count the found, valid, stale, and bounced addresses, and then compare cost per usable result.

A checklist to run against each tool:
Which sources on LinkedIn does it work with?
Is a freshness date attached to each email?
Are credits spent on searches that return nothing?
Does the unused balance carry into the next month?
The extension findings above come from our teardown. The teardown notes: "I did not inspect Snov.io in this teardown, so its extension behavior remains unverified." This article is published by Linked Helper.

Expandi Review and LinkedIn Automation Alternatives 2026

Michael Harris — Sat, 10 Oct 2026 08:11:39 +0000

Quick answer: Expandi is the stronger choice when you specifically need cloud-hosted conditional branching across LinkedIn and email, but that convenience puts your session on vendor infrastructure for $99/month per LinkedIn account. For most builders, Linked Helper is the right pick because it starts at $15/mo, keeps the session on your computer or self-managed VPS, and accepts simpler routing in exchange.

Where the session lives

With Expandi, the browser connector or a direct login transfers the LinkedIn session to Expandi's servers. The account can then run continuously from a dedicated country-based datacenter IP while your computer is off. That is a genuine operational advantage: there is no machine to keep awake and no VPS to administer. Teams also get a Global Inbox and 100+ permission settings.

It also changes the trust boundary. Session custody, execution, and the exit IP sit in vendor infrastructure rather than your normal environment. That does not prove LinkedIn will restrict an account; it means the account appears from a different class of network and you depend on the vendor's handling of the session.

Linked Helper takes the opposite approach. It is a desktop app with its own built-in browser, not a browser-based service. Run locally, and the session stays on your machine and uses the residential IP already associated with everyday activity. It can also run on your own VPS through built-in remote control, while optional cloud storage holds campaign data. The trade-off is simple: your device or VPS must remain running.

Datacenter exit IPs and how to check one

A basic reputation check asks whether an address looks like a proxy or VPN and whether recent abusive activity has been associated with it. In a July 2026 test, two Expandi accounts used different datacenter exit IPs from different French ISPs. One address scored 100/100 on IPQualityScore and was flagged for proxy use and recent abuse; the other came back clean. Expandi provides no user-facing way to test the assigned address.

That small test needs a large caveat. IPQualityScore measures general IP reputation, not LinkedIn's systems. A 100/100 result does not mean LinkedIn detected automation, and two observations—one clean—cannot support a claim that half of Expandi IPs are problematic. It is only a network-reputation signal of the kind detection systems are known to consider, regardless of the automation product.

Expandi does provide meaningful controls on every plan: configurable Daily Limit ranges with randomization, a one-click Safe Preset, Activity Schedule, and an Account Warm-Up sequence of 5 actions on day one, +3 every 2 days, up to 21/day.

Linked Helper offers an IP quality check before assigning custom user proxy to account and aligns the account time zone with that proxy's location. When it runs locally without a proxy, it simply uses the user's normal residential address.

API requests versus click emulation

There are two broad implementation families. One sends direct requests that reproduce application traffic; if their timing or shape is too mechanical, those requests can be easier to classify. The other drives a browser by moving the pointer, clicking controls, typing, and scrolling. Browser emulation has its own implementation details, including whether a click is treated as a genuine user event.

Expandi does not disclose how actions are performed in the cloud. It would therefore be inaccurate to label its engine as API-driven merely because the product is cloud-hosted.

Linked Helper states that it does not use LinkedIn's API. Its built-in browser performs interface actions, and each click reports isTrusted === true. That creates a different observable pattern, not immunity from enforcement. Architecture can change the risk profile; it cannot remove ToS or account-restriction risk.

if method_is_disclosed:
    evaluate(request_pattern_or_browser_events)
else:
    record("unknown") # do not infer API use from cloud hosting

Branching as a state machine

This is where Expandi clearly wins. Its Builder supports 9 IF-conditions × 11 post-condition actions, so campaign steps can behave like states and conditions can select different transitions. Available triggers include If connected, If followed you, and If email was opened. It also has campaign priority and workflow triggers.

state CONNECT_REQUEST
    If connected -> LINKEDIN_FOLLOW_UP
    otherwise    -> WAIT

state EMAIL
    If email was opened -> NEXT_BRANCH
    reply               -/-> STOP_EMAIL # transition is absent

LinkedIn and email can coexist in one native Expandi sequence through the user's SMTP account. The limitation matters, though: auto-stop-on-reply doesn't apply to the email steps. Its message-level IF-THEN-ELSE is also limited to one level, but the wider Builder still provides real routing rather than text substitution alone.

Linked Helper is deliberately more linear. Reply handling is binary (reply → pauses; no reply → continues). Its conditional templates choose message content: IF-THEN-ELSE varies message text, not workflow routing. A fair model is a pipeline with one reply guard and a conditional string at the send step:

for lead in sequence:
    if reply_received:
        pause_lead
    else:
        send(condition ? message_A : message_B)

Linked Helper adds a content filter that can stop a send when earlier messages contain specified words, and it offers 24 templates against Expandi's 11. But it has no campaign priority or workflow triggers. Cross-channel delivery is a Handoff template to a separate Snov.io drip campaign, not a unified sequence. Choose Expandi when complex native routing is the requirement; choose Linked Helper when a controlled, mostly linear pipeline is enough.

Rolling pool versus fixed daily caps

Expandi sets limits per action. Manual limits for invitations, messages, profile views, endorsements, likes, and follows caps them at 100 per day. Open InMails are roughly 25 per day, with free Open InMails capped at 800/mo. Its Activity Schedule applies at account level rather than giving each action type separate working hours.

Linked Helper uses a 150 actions/rolling-24h pool shared by action types, then applies narrower sub-limits. The published set includes URL navigation limit (40/24h), invitation limit (50/24h), Load LinkedIn search results (100/24h). A queue can therefore process invitations up to their sub-limit and URL navigation up to its own, while each completed item also draws from the shared pool.

window: rolling_24h
shared_pool: 150
invitations: 50/24h
url_navigation: 40/24h
load_search_results: 100/24h

Linked Helper further applies ±10% working hours randomization, campaign starts randomized within 15 minutes, per-action schedules, and a 4h auto-pause on suspicious errors. The same controls exist on both tiers. Although the pool permits more than 100 actions in a day, that level is not recommended.

What the trade-off costs

Expandi has one tier at $99/month per LinkedIn account, or $948/year per LinkedIn account ($79/month equivalent); VAT is added at checkout, and Hyperise image/GIF personalization costs extra. Its trial is 7 days, full features, card required, and it has no refund policy.

Linked Helper pricing is $8.25/mo Standard ($99/yr), $24.75/mo Pro ($297/yr), with local monthly plans at $15 and $45. Optional cloud storage can bring the total to $29.90/mo. Pro is about 55% cheaper than Expandi monthly, while Expandi is 3.2x more expensive yearly. The trial is 14 days, full Pro features, no card required.

The Verdict: Architecture Dictates the Choice

The comparison between Expandi and Linked Helper is not about which tool has more buttons; it is a fundamental architectural trade-off between cloud convenience and session custody.

Choose Expandi ($99/mo per account) if your workflow strictly requires hands-off 24/7 cloud execution without keeping hardware awake, and your outreach relies on complex, multi-branch conditional logic spanning both LinkedIn and email under a unified state machine. You are paying a premium for operational convenience while accepting third-party session custody and datacenter network profiles.
Choose Linked Helper ($15–$45/mo) if session security and network authenticity are your primary criteria. Keeping authentication keys on your local machine (or your own private VPS) guarantees your traffic originates from your genuine residential IP and device fingerprint. In exchange, you accept a more linear sequence model and the requirement to maintain your own execution environment.

Ultimately, automation safety on LinkedIn is not an absolute status—no software grants immunity from platform rules or algorithmic detection. But understanding whether your risks stem from routing limitations or network-level signals gives you control over the trade-offs you actually take on.

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

Michael Harris — Wed, 07 Oct 2026 14:18:55 +0000

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.

Open linkedin.com in a Chromium browser and open DevTools.
In Sources, search the loaded JavaScript bundles for AedEvent.
Search the same loaded bundles for hcdjjibhifjclfoblokahaacifcjpgfl.
If the surrounding code is readable, inspect the array entry and the chrome-extension:// fetch pattern rather than treating the string alone as enforcement.
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

4 Meet Alfred Alternatives Compared 2026: What Actually Matters Now

Michael Harris — Wed, 30 Sep 2026 13:34:14 +0000

When looking for an alternative to Meet Alfred in 2026, engineering an outbound engine usually means deciding between two starkly different design philosophies: cloud-hosted dashboards and browser-injected extensions (Expandi, Dripify, Waalaxy) versus local-first, desktop execution engines like Linked Helper. While cloud suites offer "set-and-forget" convenience by routing sessions through shared infrastructure, platforms built around local execution fundamentally change the security equation by keeping authentication credentials on hardware you actually control.

If your priority is eliminating third-party session handoffs, Linked Helper emerges as the standout pick: starting at $15/month (versus Meet Alfred's ~$59/month), it runs directly on your machine or private VPS, offers 11 native CRM integrations, and avoids the credential-exfiltration vectors native to cloud competitors.

The Comparison in Table

Tool	Architecture	Price (Entry / Mo)	Vendor Stores Session Token?	Channels	G2 Rating	Free Trial	Built-in CRM
Linked Helper	Standalone Desktop App	$15/mo ($8.25/mo annual)	No — stays on local hardware/VPS	LinkedIn-first	4.5★ (142)	14-day (No CC)	Yes (11 native syncs)
Expandi	Cloud + Connector Extension	$99/mo ($79/mo annual)	Yes — synced to `app.expandi.io`	LinkedIn + Email	4.1★ (98)	7-day	Yes
Dripify	Cloud (Direct Credential Login)	$59/mo ($39/mo annual)	Yes — stored in vendor cloud	LinkedIn + Email	4.5★ (267)	7-day (No CC)	Yes (Tags/Lists)
Waalaxy	Chrome Extension + Cloud Sync	$42/mo ($20.50/mo annual)	Yes — full cookie jar uploaded	LinkedIn + Metered Email	4.6★ (528)	14-day	Light

1. Linked Helper

Linked Helper functions entirely as a standalone desktop application rather than a Chrome extension or multi-tenant web application. Your LinkedIn session token (li_at) never leaves your physical device or private Virtual Private Server (VPS), which prevents vendor-side credential exposure and eliminates secondary logins from unfamiliar datacenter IPs.

Infrastructure & Operational Mechanics

Uptime Flexibility: Deploying Linked Helper on a dedicated VPS alongside its Web Version interface provides 24/7 autonomous scheduling without surrendering cookie ownership to external databases.
Pricing Efficiency: Entry begins at $15/month (or $8.25/month on an annual license)—undercutting Meet Alfred’s ~$59/month barrier to entry by nearly 75%.
Workflow Integrations: Ships with 11 native two-way CRM connectors (HubSpot, Salesforce, Pipedrive, ActiveCampaign, etc.) alongside Zapier and Make webhooks.
Granular Network Controls: Features per-account proxy assignment with a live, integrated IPQualityScore (IPQS) fraud check, randomized interval pacing, and AI ICP scoring to prune irrelevant leads before burning weekly connection limits.

The Trade-off: Linked Helper is intentionally built LinkedIn-first. It does not provide built-in SMTP/IMAP cold email mailboxes. Teams executing multi-channel sequences simply hand off unresponsive LinkedIn leads via API or webhook to dedicated email tooling.

2. Expandi

Expandi runs multichannel sequences across LinkedIn and email through a remote cloud dashboard starting at $99/month ($79/month billed annually), making it the most expensive baseline tool in the lineup.

Technical & Network Audit

Session Bridge: Connecting an account requires a lightweight extension whose primary objective is reading and uploading active authentication tokens (li_at) to app.expandi.io.
The IP Allocation Lottery: Live network audits reveal significant variance in proxy quality. In a controlled test of two accounts created within the same geo-region (France), one account received a clean residential IP, while the other was provisioned an address scoring a maximum 100/100 risk score on IPQS with active abuse history.
Proxy Lock-in: Operators cannot bring their own custom proxy configurations (BYO-proxy) to mitigate subnet blacklisting risks.

Expandi provides responsive customer support and intuitive visual campaign branching, but users must evaluate the higher price floor and vendor-managed IP allocation risks.

3. Dripify

Dripify operates purely via cloud infrastructure starting at $59/month ($39/month billed annually). It offers an intuitive visual drag-and-drop workflow builder, basic email sequencing, and a native pipeline view.

Technical & Network Audit

Infrastructure Footprint: Network analysis during technical evaluations revealed that multiple test profiles were routed through shared HostRoyale datacenter IP ranges (scoring 94/100 on IPQS fraud checks) residing within an identical /24 subnet. Furthermore, these sessions exhibited identical canvas/OS fingerprint parameters.
Anti-Fraud Anomaly: When multiple accounts broadcast identical machine fingerprints from the same datacenter block, anti-scraping and account-integrity filters can flag coordinated automation.
Feature Scope: While AI copywriting is actively highlighted on top-of-funnel landing pages, deeper product documentation lists advanced AI generation as a future release. Dedicated email-finder credits carry extra à la carte fees ($29–$99/pack).

4. Waalaxy

Waalaxy features one of the most streamlined onboarding experiences in the market and a competitive annual tier at $20.50/month ($42/month billed monthly). However, its underlying mechanics warrant closer examination.

The Chrome Extension Footprint

AED Detection Target: Waalaxy relies on a client-side Chrome extension that is indexed on LinkedIn's internal Active Extension Detection (AED) catalog. LinkedIn can register the presence of the extension locally via client-side DOM and resource queries before automated campaigns even begin.
Cookie Jar Upload: Rather than isolating authentication data locally, Waalaxy pulls the broader session cookie jar and transmits it to vendor servers to maintain continuous background execution.
Operational Nuances: The extension UI relies heavily on high-level gamification while masking granular request rates, per-action delays, and exact network headers.

For operators seeking rapid single-user campaign deployment, Waalaxy offers smooth UX, but organizations managing high-value personal profiles should weigh the detection footprint of browser extensions against isolated desktop architectures.

FAQ

Which Meet Alfred alternative carries the lowest architectural risk?
Linked Helper, because its standalone desktop client keeps session authentication data on your local hardware or private virtual server rather than delegating custody to a multi-tenant cloud environment.

How does Meet Alfred's pricing compare to alternatives at scale?
Meet Alfred starts around ~$59/seat/month. By contrast, Linked Helper starts at $15/month ($8.25/month annually), dramatically reducing overhead when operating 5, 10, or 20 seats across a sales team or agency.

Can automation software completely protect against LinkedIn account restrictions?
No automated tool can guarantee 100% immunity. Safe operation requires holistic controls: conservative connection volumes (under 100/week), randomized action delays, pristine residential proxy networks, clean recipient targeting, and immediate campaign cessation the moment a prospect responds. Architecture (desktop vs. cloud/extension) dictates how visible your automation footprint is to detection filters.

For full line-by-line source code audits, proxy test datasets, and network traffic analyses across these tools, review our security teardown series at safe-outreach.com.

Is EasyGen Safe on LinkedIn? I Read Its Extension's Source Code as well

Michael Harris — Mon, 28 Sep 2026 15:33:11 +0000

Most of our reverse-engineering audits on LinkedIn tooling focus on heavy automation and outreach platforms — evaluating how tools like Linked Helper protect sessions via local desktop custody, or tracing how cloud and extension-based platforms (such as Waalaxy, HeyReach, Expandi, and Skylead) route session cookies and tokens through external servers.

Today, we are looking at an entirely different category: AI content creation and post-writing assistants. Specifically, EasyGen.

Note: This is not Woodward easYgen, Easygenerator LMS, or the EasyGen video app.

Verdict up front: Low risk, with five named residuals. EasyGen never reads or exports your LinkedIn session. It is a local post-writing extension, not outreach automation: zero leads, zero connections, zero messages.

Two prominent reviews reached the same low-risk verdict while claiming there was no Chrome extension at all. There is one. The vendor homepage does not prominently showcase it either, which explains the confusion. The useful correction is not a scarier verdict; it is an objective analysis based on the extension code that actually ships.

What EasyGen Actually Is

I audited Manifest V3 build v2.0.10 in the 2026-06-28 audit round. Its store snapshot showed 10,000 users and a listing last updated 2025-08-14. Research and corpus cross-checks were conducted in August 2026.

EasyGen is a local extension that mounts a React panel directly into LinkedIn's post composer. It reads and writes post copy in the active browser tab. It does not scrape profiles, invoke Voyager or GraphQL endpoints, extract or upload cookies, log into LinkedIn from remote cloud servers, schedule bulk actions, or operate a background queue.

Its extension ID, however, is present on LinkedIn's extension-probe catalog:

Active Extension Detection (AED): AED is not an industry buzzword or third-party label; it is the exact internal term found in LinkedIn's production JavaScript, where client-side scan results dispatch as an AedEvent. LinkedIn has never publicly acknowledged its existence.
The Probe Target: The specific check on 2026-06-28 probed tabs/auth-page.html, one of three declared web-accessible resources in the extension.

The Static Code Audit: Step by Step

These are static code signals rather than runtime telemetry. Each artifact below details its LinkedIn-facing detection consequence.

Step 1 — Inject the Panel

content.883ade9e.js [https://www.linkedin.com/](https://www.linkedin.com/)* all_frames: true Post / Login / OTP

Detection consequence: Injection creates an inspectable surface for Spectroscopy (LinkedIn's recursive, list-free DOM scanner probing for chrome-extension:// resources) and server-side encrypted page snapshots. AED separately probes tabs/auth-page.html. all_frames: true ensures execution across embedded frames, not just the top-level document.

Step 2 — Read the Native Composer

.ql-editor[contenteditable='true'] .share-box .share-creation-state

The content script initializes a MutationObserver to synchronize EasyGen's React UI with LinkedIn’s native editor (content.883ade9e.js:7150-7158).

Detection consequence: Zero independent network signals. Observing a contenteditable node produces no external network request.

Step 3 — Write Generated Text Back

editor.innerHTML = …

Appears at content.883ade9e.js:7181 and :7279.

Detection consequence: None. Audited production code shows no active typing cadence or paste detection traps inside LinkedIn's composer.

Step 4 — Attach Media and Trigger Publication

new DragEvent("drop") 
dispatchEvent 
.share-box-footer__main-content 
.share-box-footer__primary-btn 
.click()

Detection consequence: These synthetic DOM events carry isTrusted: false. Unlike human interaction, extensions cannot toggle this read-only browser flag. However, the surface remains narrow: one media drop and one programmatic click per user-initiated action—no recurring loops or timers.

Step 5 — Persist Drafts in Supabase

uubmmfnuqfibbobcoxej.supabase.co
.eq("supabaseUserId", …)
.eq("accountId", …)
@plasmohq/storage local

The Supabase client authenticates with an anonymous key at content.883ade9e.js:14556.

Detection consequence: This is a data privacy vector, not a LinkedIn detection signal. Draft copy, generations, and EasyGen identifiers leave the browser for Supabase, but your LinkedIn credentials, session cookies, and profile metadata remain untouched.

Step 6 — Never Read the LinkedIn Session

permissions: ["storage"]
chrome.cookies      → 0 matches
li_at               → 0 matches
JSESSIONID          → 0 matches
li_a                → 0 matches
document.cookie     → 0 matches

The bundle’s single cookies string belongs to internal Supabase Auth warnings regarding its own server session (content.883ade9e.js:20005).

Detection consequence: Eliminates remote cloud-replay hazards entirely. No external server generates mismatched browser fingerprints (e.g., APFC/DNA), and no concurrent sessions appear from unfamiliar datacenter IPs.

Step 7 — Zero Authenticated LinkedIn API Calls

/voyager/           → 0 matches
GraphQL             → 0 calls
credentials:include → 0 matches
csrf-token          → 0 matches

Detection consequence: Eliminates out-of-order request-map anomalies. The extension never requests internal profile records in isolation from human page visits.

Step 8 — Native Telemetry Preserved

webRequest              → absent
declarativeNetRequest   → absent
telemetry_endpoints: []

Detection consequence: EasyGen does not intercept, inspect, or block LinkedIn tracking scripts, allowing platform telemetry to report normally.

Step 9 — Broad Host Permissions Grant

{
  "permissions": ["storage"],
  "host_permissions": ["https://*/*"]
}

Detection consequence: Trust and scope consideration. The codebase communicates strictly with Supabase and app.easygen.io, injecting only on www.linkedin.com. The wildcard host grant is overly broad for its functional scope, but creates no platform-side detection footprint.

Step 10 — No Automation Infrastructure

third_party_analytics: []
telemetry_endpoints: []
captcha_solvers: []
is_multi_mode: false
has_remote_control_queue: false
uploads_action_history: false

Detection consequence: No background workers, automated scrapers, captcha bypass modules, or external dispatch queues exist within the package.

Audit Summary: Findings & Detection Vector Matrix

Finding	Code Provenance	Detection / Safety Implication
AED Catalog Probe	Extension ID: `gbefjkkjhjcloofcbandphbododcebko`	Installation is visible to LinkedIn via client-side AED probes
All-Frames Script Injection	`all_frames: true` on `linkedin.com/*`	Spectroscopy DOM scans and page snapshots observe the UI layer
Zero Session Access	No cookie permissions; `li_at` search returned zero	Zero risk of fingerprint mismatch or foreign IP session overlap
No Internal API Use	No Voyager, GraphQL, or credentialed fetch routines	Zero request-map anomalies
Synthetic Event Hooks	`DragEvent("drop")` & programmatic `.click()`	Triggers `isTrusted: false`, strictly scoped to individual user clicks
Supabase Architecture	Outbound sync to `*.supabase.co`	Data privacy scope: drafts leave device; credentials stay local
Broad Host Permission	`"host_permissions": ["https:///"]`	Overly permissive manifest configuration; broad blast radius
Zero Automation Modules	No queues, schedulers, or captcha solvers	Zero automated behavior patterns or rate-limit triggers

What This Means for Your Account Safety

LinkedIn relies on cumulative anomaly scoring rather than single-event triggers. EasyGen exposes three minor signals:

An indexed extension ID on the AED catalog.
Injected DOM artifacts visible to page snapshotting.
Synthetic isTrusted: false share-box events.

It entirely avoids dangerous macro signals: session exfiltration, remote cloud execution, proxy rotation mismatches, background scrapers, and automated connection/messaging volume.

The Real Risk Factor: Distribution and AI Slop Policies

The primary operational risk with EasyGen is content visibility, not account restriction.

On May 20, 2026, LinkedIn announced algorithmic downranking of generic AI-generated content (claiming a 94% detection rate). Posts identified as synthetic lose distribution across second- and third-degree feeds while remaining visible to immediate connections. In July 2026, LinkedIn complemented this with a user-facing "Seems like AI slop" reporting tool.

EasyGen intentionally avoids hands-off auto-posting routines for this reason: unedited, automated AI content suppresses algorithmic reach.

Final Architecture Comparison

EasyGen deserves credit for architectural discipline: its extension never captures your LinkedIn session or offloads authentication tokens to a vendor cloud.

For users comparing this to lead-generation stacks, remember that tools operate on different layers:

If you are running active outreach, messaging, or scraping, browser extensions carry higher exposure due to DOM manipulation and AED probes.

Desktop engines like Linked Helper address this by running standalone outside Chrome extensions, preserving local session custody on your OS or private VPS with built-in proxy quality verification.

EasyGen stays strictly in its lane: it writes post drafts locally, syncs them to its private database, and leaves platform-level account actions entirely in your hands.

Full line-by-line code teardown and technical references here.

Waalaxy Alternatives: Tools With More Data Sources, Deeper Workflows, and Multi-Sender Campaigns

Michael Harris — Thu, 24 Sep 2026 14:24:10 +0000

Quick answer: Linked Helper emerges as the strongest technical pick among Waalaxy alternatives because it pairs 13 LinkedIn data sources with nested IF/THEN/ELSE conditional branching and an integrated CRM—workflow depth Waalaxy's 3-source, linear model cannot deliver. Starting at $15/month, it also keeps your LinkedIn session anchored locally on your machine rather than offloading tokens to a vendor cloud.

The Comparison Side by Side

Tool	Best For	Price (mo)	G2 Rating	Architecture	Vendor Stores Session?
Linked Helper	Deepest LinkedIn-first workflow engine	$15/mo	4.5★ (142)	Desktop (+ VPS / Web Version)	No (Local Custody)
Octopus CRM	Simple, budget-friendly solo prospecting	$9.99/mo	4.4★ (115)	Chrome Extension	No (Local, but AED-listed)
HeyReach	Multi-sender agency campaigns	$79/mo	4.6★ (21)	Cloud (Cookie-Bridge)	Yes (Vendor Cloud)

1. Linked Helper: Deep Multi-Source Workflows and Local Custody

Where Waalaxy restricts campaigns to three standard LinkedIn sources and linear execution steps, Linked Helper extracts from 13 distinct LinkedIn data sources:

Person and organization records
Post likers and commenters (post engagers)
LinkedIn event attendees
Group members
Full messaging and conversation history layers

For teams that rely on granular audience segmentation, this access gap directly impacts targeting fidelity.

Workflow Logic & Pipeline Management

Complex Branching: Supports nested IF/THEN/ELSE conditional sequences, spintax, and dynamic AI personalization. Campaigns dynamically adapt based on whether a lead accepted an invite, visited your profile, or meets designated custom criteria—logic Waalaxy’s flat sequences cannot execute.
Built-in CRM & Pipeline: Features a native CRM with a visual Kanban view. For external synchronization, it bundles 11 direct CRM connectors (ActiveCampaign, Capsule, Close.io, HighLevel, HubSpot, Instantly, Pipedrive, Salesforce, Streak, Zoho, and Zoho Recruit), backed by Zapier and Make webhooks.
Network & Account Operations: Includes per-account proxy support with a built-in proxy verification checker, plus flexible license switching between profiles.

Architecture & Commercials

Pricing starts at $15/mo (with a 14-day card-free trial). Operating continuously since 2016 with over 500,000 users, it avoids cloud token vulnerabilities: your authenticated session remains strictly on your local computer or private VPS.

The Trade-off: Linked Helper is strictly LinkedIn-first. It does not provide native cold email sequences—multichannel setups require integrating with specialized email platforms like Instantly or Woodpecker. The desktop architecture also requires keeping the host machine active or deploying to a VPS for 24/7 campaigns.

2. Octopus CRM: Low-Cost, Linear Automation

Octopus CRM sits on the entry-level side of the spectrum. It functions as a lightweight Chrome extension aimed at solo operators seeking simple automated connection requests, profile visits, mass messaging, skill endorsements, and follows without managing complex campaign trees.

At $9.99/mo ($6.99/mo billed annually) with a 7-day free trial, it carries the lowest starting price in this roundup.

Technical & Functional Profile

Local Processing: Runs entirely inside the local browser without uploading tokens to vendor infrastructure, and code reviews confirm zero cookie harvesting.
Extension Footprint: The extension ID is indexed on LinkedIn's Active Extension Detection (AED) list, and the tool injects scripts directly into LinkedIn pages.
Linear Constraints: Sequences are strictly linear. It offers no conditional branching, no behavioral triggers, no Kanban pipelines, and roughly three data source types. External connectivity is limited to Zapier and Make.
User Feedback: Solid review volume across platforms: G2 sits at 4.4★ (115), Capterra at 4.6★ (273), and Trustpilot at 4.23★ (202).

The Trade-off: Octopus CRM fits basic, budget-constrained outreach where instant setup matters most. However, it cannot accommodate conditional sequences or direct CRM syncs, and its AED footprint presents an observable browser signal.

3. HeyReach: Multi-Account Agency Infrastructure

HeyReach targets agency workflows, prioritizing centralized multi-account scaling. Its primary differentiator is sender rotation—distributing campaign volume across dozens of sender accounts, unifying replies in a centralized inbox, and providing white-label client dashboards.

Pricing starts at $79/mo ($59/mo billed annually) with a 14-day free trial.

Technical & Functional Profile

Cookie-Bridge Mechanism: HeyReach utilizes a companion extension to read the browser’s complete cookie jar (including li_at and JSESSIONID), transferring active session tokens directly to its API infrastructure. It also hooks into logout events.
Ecosystem & Routing: Features 31 native integrations, a built-in CRM, InMail credit protection, and custom proxy routing across 154 locations. Workspaces support reassignable seat licenses across three core LinkedIn data surfaces.
Network Audit Finding: In an independent June 2026 infrastructure audit, test accounts landed on Altinea SAS datacenter IPs in an identical /24 subnet. Both addresses registered an IPQualityScore (IPQS) fraud score of 100/100, tripping active flags for proxy, VPN, and past abuse.

The Trade-off: The platform requires complete cloud session custody, remains strictly LinkedIn-only with no native email sending, and its default network layer carries high datacenter risk scores. While agency rotation is valuable, solo operators will find lower risk profiles and higher data breadth elsewhere.

More Alternatives to Consider

La Growth Machine ($60/mo): Multichannel cloud engine (LinkedIn, email, Twitter/X) featuring 22 integrations and a native CRM, operating over vendor-hosted sessions.
Expandi ($99/mo): Cloud automation with conditional logic and 3 data sources, driven by an authenticated cookie-bridge extension.
Lemlist ($79/mo): Email-first multichannel platform pairing AI personalization with 3 LinkedIn data sources.
Dux-Soup ($14.99/mo): Hybrid architecture. Operates locally on lower plans across 3 data sources and 11 integrations, but routes sessions off-device on Cloud tiers.
Dripify ($59/mo): Cloud-credential platform featuring drip workflows and a built-in CRM.
Skylead ($100/mo): Bundles LinkedIn and email with spintax support, though lacking deep conditional branching logic.
PhantomBuster ($69/mo): Modular, recipe-based scraper and enrichment platform.
Salesflow ($99/mo): Agency-oriented platform offering conditional sequencing across multi-seat dashboards.
Meet Alfred ($59/mo): Multichannel tool spanning LinkedIn, email, and X via credential-based cloud infrastructure.
Closely ($49/mo): Lightweight cloud sender with AI messaging and 5 CRM connectors across ~2 data sources.
SalesRobot ($59/mo): Combines conditional sequence logic with AI copy drafting and 5 native integrations.

Frequently Asked Questions

Can Waalaxy alternatives integrate directly with Salesforce or HubSpot?

Yes. Linked Helper provides direct native connectors for both Salesforce and HubSpot (alongside 9 other platforms), avoiding third-party iPaaS middleware like Zapier for core pipelines. While other platforms offer connections via webhooks or selective native integrations, direct two-way connectors remain rare across the category.

Which Waalaxy alternatives combine cold email with LinkedIn outreach?

Platforms such as Skylead, Closely, La Growth Machine, and Lemlist natively orchestrate cold email alongside LinkedIn touchpoints within unified sequences. By contrast, tools like Linked Helper and HeyReach focus exclusively on LinkedIn infrastructure, requiring external tools (such as Instantly or Woodpecker) for multichannel campaigns.

Frequently Asked Questions

Can Waalaxy alternatives integrate directly with Salesforce or HubSpot?

Which Waalaxy alternatives combine cold email with LinkedIn outreach?

Why do some Chrome extension alternatives get detected by LinkedIn so quickly?

LinkedIn runs an internal client-side scanning routine known as Active Extension Detection (AED), which probes for known browser extension IDs upon page load. In addition, extensions often inject identifiable DOM markers or patch native browser objects. If an extension appears on LinkedIn's AED catalog (such as Octopus CRM or Waalaxy), the platform can flag its presence even before automated outreach actions begin.

Are daily action limits more restrictive on Waalaxy compared to alternatives?

Yes. Waalaxy enforces tiered daily quotas depending on subscription level, with starter/lower plans historically capped at roughly 11 invites per day. Standalone tools like Linked Helper do not artificially throttle feature access or daily volume by pricing tier; limits are configurable by the user to match human-like pacing and safety thresholds.

8 Expandi Alternatives Compared on the One Thing That Actually Matters: Session Safety

Michael Harris — Tue, 22 Sep 2026 13:39:13 +0000

Quick answer: When evaluating Expandi alternatives strictly through the lens of platform risk, architectural session custody is the primary factor that separates tooling. Most cloud and hybrid platforms require transferring authentication tokens or raw credentials to vendor servers. In this side-by-side comparison, Linked Helper stands out architecturally as the tool that keeps your LinkedIn session strictly local—executing on your machine or private VPS via your native IP, without an in-browser extension footprint. It enters at $15/month, compared to Expandi's $99/month baseline.

The Comparison, Side by Side

Tool	Starting Price /mo	Architecture	Stores Your LinkedIn Token?	Native Email / Multi-Channel	Free Trial	G2 Rating
Linked Helper	$15/month	Desktop app (+ VPS / Web Version)	No — stays on your machine	No (LinkedIn-only)	14-day free trial, no card	4.56
Waalaxy	$42/mo	Chrome extension + cloud	Yes — uploaded to Waalaxy's cloud	LinkedIn + email via integrations	Free tier + 14-day trial	4.0
Skylead	$100/mo	Cloud (credential login)	Yes — handed to Skylead's servers	Yes (email finder, warm-up built in)	7-day trial, card required	4.5
Lemlist	$79/mo	Cloud + Chrome extension	Yes	Yes (email + LinkedIn sequences)	14-day trial	4.5
Dux-Soup	$14.99/mo	Hybrid (local or cloud)	Depends on plan	No	Free tier	4.3
Meet Alfred	$59/mo	Cloud (credential login)	Yes	Yes (email + LinkedIn + X)	14-day trial	3.4
Salesflow	$99/mo	Cloud (credential login)	Yes	Yes (email + LinkedIn)	14-day trial	4.3
La Growth Machine	$60/mo	Cloud	Yes	Yes (LinkedIn + email + X + AI voice)	14-day trial	4.8

1. Linked Helper: Local Desktop Execution

Most cloud-based LinkedIn tools operate by routing your session token to remote multi-tenant infrastructure, which then initiates API requests on your behalf. When LinkedIn flags a datacenter IP range—or identifies identical hosting subnets handling thousands of user sessions simultaneously—every account sharing that gateway inherits the risk.

Linked Helper bypasses this vector by running as a standalone desktop engine directly on local hardware.

Session Custody: The authenticated LinkedIn session never leaves your local environment. There is zero token exfiltration, no credential handoff, and no shared datacenter IP pools. Requests leave through your genuine residential or office connection.
Persistent Uptime: For 24/7 campaigns without an active laptop, operators can host the software on a private VPS and interface via the Web Version, preserving hardware isolation without surrendering session custody to third parties.
Zero Extension Footprint: LinkedIn runs an internal Active Extension Detection (AED) routine scanning for known extension IDs upon page initialization. Because Linked Helper is a desktop binary rather than a browser extension, it presents zero extension IDs to the AED scanner.
Workflow Logic: Features deep nested IF/THEN/ELSE conditional branching and spintax messaging. Varying templates prevents LinkedIn’s duplicate-content algorithms from detecting bulk outbound patterns.
Integrations: Includes 11 direct CRM connectors (HubSpot, Salesforce, Pipedrive, etc.) eliminating middleware like Zapier for core pipelines.

Commercials & Metrics: Pricing starts at $15/month ($8.25/month billed annually) with a 14-day card-free trial. User sentiment: G2 4.56 (142 reviews), Capterra 4.9 (252 reviews), Trustpilot 4.91 (431 reviews).

The Trade-off: Linked Helper is strictly LinkedIn-first. It does not include a native cold-email delivery engine; multichannel outreach requires pairing it with an external email specialist.

2. Waalaxy: Chrome Extension + Cloud Bridge

Waalaxy pairs a client-side Chrome extension with a remote cloud infrastructure, introducing several distinct exposure surfaces:

AED Enumeration: Static audits show Waalaxy's extension ID indexed directly within LinkedIn's AED target list. LinkedIn can detect the presence of the tool upon browser launch before any messaging sequence executes.
Session Cookie Exfiltration: Enabling the cloud-processing pipeline routes your complete LinkedIn cookie jar to Waalaxy's cloud infrastructure.
Pacing Guardrails: Shipped client bundles show an absence of enforced hard daily limits in the underlying code, leaving limits largely to client-side discipline.

Waalaxy operates out of Montpellier, France, adhering to EU/GDPR guidelines. The entry plan sits at $42/mo ($20.50/mo annual) alongside a freemium tier and 14-day trial. Its "Waaly AI" assistant garners positive user feedback for automated reply detection and response drafting.

The Trade-off: Native CRM integrations are limited to HubSpot and Pipedrive; broader connectivity relies on webhooks or third-party iPaaS platforms (Zapier, Make, n8n). Customer reviews frequently reference billing and subscription cancellation friction, alongside occasional account restrictions from sustained invite volumes (40–50 requests/day).

3. Skylead: Direct Credential Cloud Infrastructure

Skylead bypasses the Chrome extension model completely by using cloud-side credential logins, promoting "Dedicated IPs" for all accounts. However, independent network routing tests reveal a different reality.

Shared Datacenter Posture: Live testing with two independent, clean Skylead accounts routed both through the exact same IP address.
IP Reputation Score: The assigned IP scored 100/100 on IPQualityScore (IPQS) fraud metrics, triggering active proxy, VPN, and recent-abuse telemetry. The subnet traced back to HostRoyale—the same hosting provider identified behind Dripify and We-Connect.
Custody Risk: While avoiding browser AED scans entirely, Skylead requires handing raw credentials directly to vendor-hosted cloud nodes.

Commercials & Metrics: Positioned at the high end at $100/mo ($83.33/mo annual) with a 7-day trial requiring credit card entry. It bundles an email finder, verification, email warm-up, and native white-label agency tools. Ratings: G2 4.5 (125 reviews), Capterra 4.8 (17 reviews), though external channels like Trustpilot skew negative (multiple 1-star reports citing unexpected campaign wipes).

More Alternatives to Consider

Lemlist ($79/mo): Comprehensive cold email platform with LinkedIn touchpoints and warm-up capabilities. However, its companion extension sits on LinkedIn's AED probe list, and sessions are uploaded to its cloud.
Dux-Soup ($14.99/mo): Hybrid architecture. Entry-level tiers keep sessions local, while the Cloud tier routes sessions off-device. The extension ID is indexed on the AED list regardless of tier.
Meet Alfred ($59/mo): Cloud-credential tool covering LinkedIn, email, and X. Live audits revealed exit IPs marked as "spam" by IPQS despite clean fraud numbers, with geographic routing options that did not hold up under network analysis (G2: 3.4★).
Salesflow ($99/mo): Cloud-hosted agency tool. Default exit IPs triggered proxy flags, with custom proxy configuration disabled by default and minimal safety throttling controls.
La Growth Machine ($60/mo): Multichannel cloud engine (LinkedIn, email, X, voice notes). Default infrastructure triggered proxy-detection flags in matrix audits, alongside public review logs noting unexpected sequence interruptions.

FAQ

What constitutes the safest architecture for LinkedIn automation?

Architectural safety is measured by attack surface reduction: minimizing foreign session access and client-side detection footprints. The lowest-risk posture keeps session tokens anchored locally (on user hardware or a private VPS), originates calls through a genuine residential IP, and uses native browser emulation rather than detectable Chrome extension IDs.

What is the difference between Cloud, Extension, and Desktop automation?

Cloud Platforms: Require surrendering credentials or session tokens to vendor servers, executing actions from remote datacenter subnets.
Chrome Extensions: Execute from your local browser IP, but expose your account to in-page DOM inspections and Active Extension Detection (AED) scans.
Desktop Engines: Run locally without injecting third-party extension IDs into LinkedIn, keeping session custody strictly on your machine while utilizing your genuine local IP.

Is Expandi safe to use?

Expandi provides automated warm-up routines and pacing settings. However, no behavioral limit completely mitigates the structural reality of a cookie-bridge architecture: your li_at token is stored on vendor cloud nodes, operating through shared IP pools that LinkedIn continually audits.

Evaluating outreach platforms requires looking beyond interface polish. When session security and account longevity are non-negotiable criteria, desktop engines like Linked Helper offer an isolated architectural alternative to multi-tenant cloud platforms, starting at $15/month with a 14-day card-free trial.

“Is GetProspect Safe?” Is the Wrong Question

Michael Harris — Fri, 18 Sep 2026 13:15:33 +0000

Asking whether a LinkedIn extension is simply "safe" or "unsafe" collapses three separate architectural layers into a single, misleading binary: session custody, platform detectability, and scraped-data governance.

GetProspect passes the session-security test while exposing its users to measurable LinkedIn detection signals. Separately, it transmits the professional data it gathers to third-party servers.

Below is a technical teardown of the shipped GetProspect Chrome extension (bhbcbkonalnjkflmdkdodieehnmmeknp, build v6.2.13, released 2026-05-29, audited 2026-06-11). The verdict is Medium Risk—defined not by an arbitrary score, but by how the code separates local credentials from external data flows.

1. Permissions: The False Reassurance

GetProspect’s host_permissions manifest key lists only:

https://*.getprospect.com/
http://localhost/*

LinkedIn is nowhere on the list. A shallow inspection of the permission dialog might lead an auditor to believe the extension cannot interact with LinkedIn.

json
// manifest.json extract
"content_scripts": [{
  "matches": ["https://*[.linkedin.com/](https://.linkedin.com/)*"],
  "js": ["foreground.bundle.js"],
  "run_at": "document_end"
}]

A declared content_scripts entry executes foreground.bundle.js directly within every LinkedIn page context. Furthermore:

externally_connectable enables cross-origin communication between GetProspect web properties (or localhost) and the extension.
An offscreen document supports background tasks without an open UI tab.

Neither setting constitutes an active detection signal on its own, but they demonstrate why reading host_permissions in isolation is a flawed audit shortcut.

2. The Layer GetProspect Clears: Local Session Custody

GetProspect avoids the credential-handling pitfalls common to cloud scrapers:

Zero Session Extraction: No cookies permission is requested, the li_at authentication cookie is never read or stored, and there is no cookie-jar harvest routing sessions to vendor servers.
Local CSRF Extraction: JSESSIONID is read via document.cookie purely to set the csrf-token header on same-origin requests dispatched from the user's active tab. Shipped source contains 9 JSESSIONID, 27 csrf, and 4 document_cookie occurrences (static string counts).
Native Fingerprinting: Because every request originates from the operator’s physical browser, the 48-point client browser fingerprint (APFC/DNA) aligns naturally with the connection. There is no parallel session, geographic jump, or headless browser mismatch.
No Telemetry Tampering: declarative_net_request is empty. The extension does not attempt to drop or block LinkedIn tracking calls, avoiding the self-exposure vector where silencing telemetry flags an incomplete blocklist.

Because no session is hosted on external infrastructure, a cloud exit-IP test is architecturally inapplicable. There is no vendor proxy pool, datacenter IP, or ASN mismatch to measure on LinkedIn's end.

3. The Detection Layer: Local Does Not Mean Invisible

While session custody is sound, the extension exposes multiple client-side inspection surfaces:

Active Extension Detection (AED)
GetProspect's extension ID (bhbcbkonalnjkflmdkdodieehnmmeknp) is a target entry in LinkedIn’s client-side AED scanner under the label "Email Finder - GetProspect".

As documented by BrowserGate and Linked Helper's security study (spanning static reviews of 16 extensions and live tests of 7 cloud engines), LinkedIn's production bundle silently fires probe requests on page load:

JavaScript
fetch("chrome-extension://bhbcbkonalnjkflmdkdodieehnmmeknp/assets/img/extension/icon16.png")

A successful response triggers an internal AedEvent telemetry log. While LinkedIn's probe list grew from 5,459 entries in December 2025 to 6,167 by February 2026 (~12 new additions daily), v6.2.13 declares zero web_accessible_resources (war_count: 0). Consequently, static analysis cannot confirm whether this specific asset probe currently succeeds.

However, LinkedIn's separate DOM-wide Spectroscopy scanner sweeps page elements for uncatalogued chrome-extension:// strings without relying on a target list.

Voyager Direct Calls & Request-Map Anomalies
The content script invokes LinkedIn's internal endpoints directly (foreground.bundle.js:2737, :2848), containing 30 voyager and 9 graphql string occurrences.

When a human views a profile, the browser loads stylesheets, images, tracking scripts, and prefetch assets alongside profile data. Direct programmatic calls to Voyager endpoints bypass this surrounding request ecosystem, creating a measurable request-map anomaly in LinkedIn's server-side logs.

Synthetic DOM Events (isTrusted: false)
The code includes 9 synthetic-event and 5 programmatic-click patterns (new MouseEvent, dispatchEvent, .click()).

In modern browsers, programmatic content-script dispatches produce events with isTrusted: false, which client-side JavaScript cannot forge without exposing yellow native debugger banners via chrome.debugger.

4. Automation Guardrails: What the Code Actually Enforces

Vendor marketing positions the extension as self-regulating:

"The extension enforces LinkedIn's daily limits automatically, stopping when the threshold is reached..."
"GetProspect protects the account from being banned."

The shipped code does not support this level of behavioral defense:

Controls Present: interval: 13 (unbounded), plus three fixed delays of 0ms, 160ms, and 320ms.
Controls Absent: No randomized delay distributions, no automated daily limits, no working-hours scheduler, and no gradual warm-up ramping.

GetProspect is not an outreach sender—it does not automate connection invites, direct messages, skill endorsements, or profile follows. The practical behavioral concern is raw Voyager query frequency rather than connection request volume.

5. Data Egress vs. Platform Detection

Data extraction logic routes scraped information off the machine:

Hardcoded constants at foreground.bundle.js:2737 point to https://api.getprospect.com and https://app.getprospect.com.
Names, company profiles, job titles, prospect lists, and retrieved corporate emails are POSTed to the vendor's API.

LinkedIn cannot monitor external outbound traffic to vendor endpoints, meaning data egress does not act as an account restriction trigger. Instead, this represents a governance and privacy boundary: candidate/prospect PII moves to a third-party processor, while bulk scraping remains governed by LinkedIn User Agreement 8.2.

Audit Vector Summary

Vector / Component	Classification	Operational Finding	Audit Verification
`li_at` Extraction	Clean / Low Risk	Zero token reads or remote exports	Source analysis (`manifest.json`, script bundles)
Fingerprint Mismatch	Clean / Low Risk	Identical client fingerprint (runs locally)	Direct origin tracing
Telemetry Suppression	Clean / Low Risk	`declarative_net_request` is null; pings unmodified	Manifest audit
AED Listing	Medium Risk	ID listed in LinkedIn production probe array	Cross-checked against Feb 2026 probe list
Direct API Writes	Medium Risk	Direct Voyager calls strip typical page-load telemetry	Static call-site analysis (`foreground.bundle.js`)
Event Trust Flag	Medium Risk	Programmatic clicks dispatch with `isTrusted: false`	Event construction review
Rate-Limiting Controls	Medium Risk	Fixed millisecond delays; missing dynamic daily caps	Configuration object review
Data Transmission	Compliance Risk	Scraped PII leaves browser for vendor infrastructure	API payload mapping

Practical Takeaway

GetProspect keeps the core session token local, avoiding the parallel-session flags and IP reputation mismatches that penalize cloud-hosted scrapers.

However, local session retention does not make an extension invisible. Running within the page context means interacting with LinkedIn's behavioral scoring models: AED indexing, synthetic DOM dispatches, and isolated Voyager queries contribute cumulative risk signals.

Auditing outreach tooling requires evaluating data-flow boundaries and execution contexts rather than relying on permission dialog summaries.

The full line-by-line audit is available at safe-outreach.com/is-getprospect-safe.

If this kind of teardown is useful, subscribe. I take apart a different tool each time.

Is Piwaa Safe on LinkedIn? A Source-Code Audit of an Abandoned Extension

Michael Harris — Wed, 16 Sep 2026 14:09:28 +0000

The original Chrome Web Store listing for Piwaa—mirrored by Extpose and chrome-stats as of September 7, 2026—made an explicit safety claim:

"Piwaa behaves exactly like the standard LinkedIn messaging, the difference is in the interface and additional functionality that does not generate suspicious behavior with LinkedIn."

Standard LinkedIn messaging never intercepts the platform's security telemetry. Piwaa’s shipped code did.

A line-by-line static audit of Piwaa’s final build (v1.0.30, updated 2021-09-03) confirms a split verdict: its session handling was clean, but its telemetry blocking, Active Extension Detection (AED) footprint, and raw API access created significant detection exposure.

1. The Critical Flaw: Incomplete Telemetry Suppression

Piwaa attempted to hide by canceling outgoing browser reporting requests in initProtection (background.js:82205-82226):

- Conditional CSP Drop: Cancelled Sales Navigator violation reports containing an "sn" parameter before LinkedIn received them (background.js:82206-82213).

- Unconditional Drops: Cancelled four specific URL patterns outright (background.js:82214-82226):

platform-telemetry/cspf=l
lite/contentsecurity
uas/js/TXbEYyrcV7m5DbGr
sc/h/br/*

The Detection Mechanism: BrowserGate (the independent 2025–2026 investigation reverse-engineering LinkedIn’s JavaScript) documented that suppressing reporting endpoints creates a self-exposure pattern. A blocklist remains invisible only as long as it is 100% exhaustive.

Because Piwaa was abandoned in 2021, modern telemetry endpoints (li/track, /platform-telemetry/li/apfcDf, /apfc/collect, /sensorCollect, and li.protechts.net) remained unblocked. When one active endpoint reports to LinkedIn that adjacent telemetry has gone silent, the block pattern itself becomes an anomaly signal.

2. Tracing the Data Flow: What Shipped vs. What Leaked

The runtime audit reveals where Piwaa protected user data and where it left architectural traces:

- No Credential Theft (li_at): Checked only whether the li_at cookie existed to set a login boolean (background.js:51967-51980, 52134-52144). It never read, extracted, or transmitted li_at values.
- Local CSRF Extraction: Read JSESSIONID from document.cookie solely to populate standard csrf-token headers for same-origin requests (contentscript.js:1671-1679).
- Voyager API Calls (Request-Map Anomaly): Fired direct calls against private /voyager/ endpoints (voyager appears 80 times in code). Bypassing typical UI navigation generates API calls stripped of normal DOM assets, stylesheets, and neighboring tracking pings—a visible server-side footprint.
- DOM Injection: Injected a single messenger-header badge (renderPiwaaBagde, contentscript.js:1580-1604), creating an artifact inspectable by LinkedIn’s recursive DOM scanner (Spectroscopy).
- Profile Extraction: Contrary to its listing claim ("We do not store any data"), the extension extracted profile data via /voyager/api/me, packaged the user’s ID/name into an edfp payload, and sent scraped conversation results to piwaa-api.herokuapp.com (background.js:51205-51217).
- Remote Command Bridge: Listened to an 8-action command array (get_contact_infos, mark_all_items_as_seen, etc.) dispatched via its backend, turning the local client into an externally driven queue.
- No Synthetic Input Flags: The single .click() call (contentscript.js:1686) merely triggered a local attachment; it did not fake human clicks.

Audit Vector Recap

Check / Vector	Risk Class	Detection Consequence	Evidence
`li_at` Session Handling	Clean / Low	None (value never accessed or uploaded)	Code read
Telemetry / CSP Blocking	High	Incomplete suppression alerts neighboring endpoints	Code read (`background.js`)
AED Extension Probe	High	LinkedIn detects installation before usage	Match on Feb 2026 probe list (`assets/32x32.png`)
Direct Voyager API Calls	Medium	Request-map anomaly in server logs	Code read (`voyager` string count: 80)
DOM Badge Injection	Low	Exposed to list-free Spectroscopy DOM sweeps	Code read (`contentscript.js`)
Profile & Message Upload	Privacy Risk	Data egressed to vendor backend (now deleted)	Code read (`background.js:51205`)
Remote Command Listener	Medium	Batch volume surges driven by external queue	Code read (`background.js:51560`)
Abandoned Origin	Critical	Extension retains privileges to dead Heroku domain	DNS / HTTP probes (Sept 2026)

Active Extension Detection (AED) Footprint

Piwaa’s extension ID (bkcibcjcbhgjoddeldfmgkbaipjkidpf) was placed on LinkedIn’s internal Active Extension Detection (AED) probe list.

LinkedIn’s silent in-page probe:

JavaScript

fetch("chrome-extension://bkcibcjcbhgjoddeldfmgkbaipjkidpf/assets/32x32.png")

A fulfilled response emits an internal AedEvent to LinkedIn's servers, logging the extension as installed before any messaging action occurs. By February 2026, this probe list contained 6,167 entries.

Current Status: Why You Must Uninstall It

Chrome Web Store delisted Piwaa in August 2026 citing a "Minor Policy Violation." As of late August 2026, chrome-stats still recorded roughly 1,000 active installations.

If the extension remains in your browser, it retains elevated permissions:

webRequest, webRequestBlocking, cookies, tabs
Host access across linkedin.com/* and piwaa.com/*
contentscript.js running on
Hardcoded communication channels to orphaned domains (app.piwaa.com, piwaa-api.herokuapp.com)

Because the vendor backend no longer resolves, retaining an unmaintained extension with wide intercept privileges is a standing security liability. Remove it directly via chrome://extensions.

Architectural Contrast: Browser Extensions vs. Standalone Desktop

Piwaa highlights the inherent trade-offs of browser extensions. While it successfully kept the core session token (li_at) local, it remained constrained by the Chrome extension model: exposing a detectable Store ID to AED, leaving DOM injection artifacts, and using brittle network interception.

Standalone desktop engines like Linked Helper address these structural weaknesses by operating outside the Chrome Web Store model entirely:

- No Extension Footprint: Eliminates chrome-extension:// paths and Web Store IDs, removing the AED surface.
- Native Interface Emulation: Instead of executing naked Voyager API calls or patching network requests, it navigates pages inside an isolated browser instance using real hardware events (isTrusted: true), human-like typing delays, and organic mouse paths.
- Zero Telemetry Suppression: Avoids touching LinkedIn's security or CSP endpoints, bypassing the self-exposure traps of incomplete blocklists.
- Controlled Cloud Alternative: For 24/7 campaign execution, users can deploy the desktop engine on a private VPS paired with its Web Version, keeping session tokens completely off third-party vendor servers.

A tool's safety claim is only a hypothesis. The permissions, manifest boundaries, and shipped request handlers are the only facts that prove what it actually touches.

Tracing Wiza Extension v0.3.45: From Page Injection to Session Export

Michael Harris — Fri, 11 Sep 2026 12:34:41 +0000

Verdict up front: I rate the Wiza build I examined HIGH risk. In v0.3.45, pulled from the Chrome Web Store on 2026-06-05, its service worker returned li_at, li_a, the whole linkedin.com cookie jar, and the extension version to a controller whose export flow ended at wiza.co, wiza.com, and plugin.wiza.co. That made it a cookie bridge with local scraping on top, not merely an in-browser contact extractor.

Wiza enriches contacts. Architecturally, the audited build was a cookie bridge: it scraped inside the browser the way a purely local tool does, and it also copied the login cookie itself out toward the vendor. Your LinkedIn login, in cookie form — whoever holds it can act as you. The retrieval ran in the browser. The login that made it possible did not stay there.

A necessary version boundary

What I did not re-test matters here. The audited build was v0.3.45, and I fetched its CRX on 2026-06-05. The Chrome Web Store showed v0.3.57, updated 2026-08-19, when rechecked on 2026-08-21; I did not pull or audit that build. Wiza's help centre now describes a materially narrower extension: it says the active-tab URL identifies the LinkedIn page type, page content and network responses are not read, and bulk export and multi-select are unavailable on LinkedIn, Sales Navigator, or Recruiter result pages. The findings below describe the June build, not today's.

Twelve releases separate the build I read from the one on the store today. Somewhere in that gap, either the help page was already describing an extension that had not yet shipped, or Wiza genuinely cut the extension down and the page caught up. I can't tell those apart from the outside, and I didn't pull the new CRX to try. One asymmetry is worth naming while I'm here: the narrowing language covers page content and network responses, and it says nothing about the service-worker cookie read I documented in v0.3.45, the CRX I pulled on 2026-06-05. That is a gap in the description, not evidence about the current build either way.

The June Build, in Execution Order

I mapped the runtime consequences against Linked Helper’s security benchmark (16 static extension audits plus live two-account tests across seven cloud tools). The findings below reflect a static code read of Wiza build v0.3.45 (CRX pulled 2026-06-05).

Step 1a: Inject Before Page Initialization

At document_start, interceptors.js injected into the page's MAIN execution world, overriding native networking primitives before LinkedIn’s scripts ran (interceptors.js:3-4):

// Minified line shape; local identifiers elided
XMLHttpRequest.prototype.open = ...
XMLHttpRequest.prototype.send = ...
window.fetch = ...

Detection Impact: Patching prototypes in the primary execution context leaves observable DOM artifacts. These are visible to LinkedIn’s uncatalogued DOM scanners ("Spectroscopy") and server-side page-snapshot workers.

Step 1b: Expose a Static Web Resource

The manifest declared nine web-accessible resources. Crucially, assets/style.css lacked dynamic URL hashing (use_dynamic_url: false):

"web_accessible_resources": [{
  "resources": ["assets/style.css"],
  "use_dynamic_url": false
}]

Because the path was fixed, LinkedIn's production code could probe installation on initial load via Active Extension Detection (AED):

fetch("chrome-extension://pjmlkdacmaejhkdcflncbpcpidkggoio/assets/style.css")

Detection Impact: A successful fetch silently fires an AedEvent telemetry ping during page load—confirming installation without user interaction, clicks, or profile exports.

Step 2: Intercept Existing In-Flight Traffic

The patched network layer passively monitored six Sales Navigator and Recruiter API families (interceptors.js:43-52):

Sales Navigator lead and account searches
People search and profile views
Account dashboards
Recruiter search hits and recommendations
Detection Impact: Zero at this stage. Reading responses already requested by the browser creates no external or abnormal network traffic.

Step 3: Call Private Voyager Endpoints Directly

Next, the script transitioned from passive interception to active execution. It extracted JSESSIONID from document.cookie for the csrf-token header, appended x-restli-protocol-version: 2.0.0, and issued credentialed GET requests (interceptors.js:211-224):

fetch(url, {
  method: "GET",
  credentials: "include",
  headers: {
    "csrf-token": jsessionId,
    "x-restli-protocol-version": "2.0.0"
  }
})

Detection Impact: Real human profile visits trigger a dense cascade of assets, telemetry, and prefetch calls. A naked API request strips away this surrounding traffic, creating an isolated "request-map" anomaly visible in LinkedIn's server logs.

Step 4: Package the Full Cookie Jar

The service worker read li_at, li_a, and the complete LinkedIn cookie jar, bundling them for the export controller (assets/background.ts-D9M8FI6v.js:3):

chrome.cookies.get({ url: "https://www.linkedin.com", name: "li_at" })
chrome.cookies.get({ url: "https://www.linkedin.com", name: "li_a" })
chrome.cookies.getAll({ url: "https://www.linkedin.com" })
// Returns: { li_at, li_a, wiza_version, cookies }

Detection Impact: Exporting live session credentials creates immediate exposure to parallel-session flags and browser fingerprint mismatches. Server infrastructure holding only the raw cookie cannot reproduce the 48-point client fingerprint generated by the local browser.

(Note: While static analysis confirms these tokens were extracted and prepared for export in v0.3.45, subsequent server-side processing remains an architectural inference rather than direct observation.)

What I could not test

I ran no live cloud/IP test for Wiza: no exit address, fraud score, connection_type, datacenter observation, proxy or abuse flag, browser fingerprint, or two-account isolation comparison exists. This article's Wiza evidence is extension code only.

That absence follows from the architecture, not a skipped measurement. A live two-account cloud test needs a hosted-login surface where two LinkedIn accounts enter a vendor web product and expose addresses that can be measured. A cookie bridge presents no such login: in v0.3.45 (CRX 2026-06-05) the local extension read a session and handed it over without a separate vendor-side login or cloud address for the tester to point at. Holding that build's li_at made off-machine access highly likely as a capability; I did not observe it happen.

What “not found” means

The absences matter as much as the findings, and one of them counts in Wiza's favour. The June build made no attempt to block LinkedIn's telemetry — no traffic rules, no suppression, nothing in the manifest — which is the right call, because blocking telemetry is itself a confession. I also went through v0.3.45 looking for remote code loading, hardcoded credentials, deliberate obfuscation and session-retention tricks, and found none of them.

That is a bounded result rather than a clean bill of health. The check ran the full eight-axis extension method, store identity through licensing and privacy, and of the 61 capabilities I check an extension against, 19 applied here — a single-purpose enrichment scraper simply touches far fewer of them than a full outreach sequencer does. “Not found” means absent from the files I audited on 2026-06-05, inside that scope: not a proof of impossibility, and not a statement about v0.3.57. De-minification restored behavior, not original names or authorial intent, and one build of one tool does not generalize to every cloud tool.

What users actually report

The 570 reviews I went through skewed positive: 321 delighted, 149 satisfied, 71 mixed, 16 furious, and 13 frustrated. Pricing and data quality dominated the negatives; only three reviews had any safety topic. The 17 Wiza-mentioning Reddit posts contained no ban thread. That is consistent with—not proof against—what the June 2026 code showed (v0.3.45, CRX 2026-06-05): a page-load probe and a session handoff are invisible in the UI, and a restriction weeks later is easily attributed to the user's most recent action. Users are reporting what they can see.

A five-star reviewer supplied a volume warning. It is useful precisely because it came from someone recommending the product:

"LinkedIn will lock your account if you overuse it."
— G2, 5★, 2024-09-11. The warning captures behavioral risk, and behavioral risk is real. But pacing cannot remove the page-load probe or change the session handoff I documented in v0.3.45, the build I pulled on 2026-06-05; both of those fire regardless of how much anyone exports.

The corpus contained one first-hand restriction account, framed as an incidental detail rather than a complaint:

"I used the business LinkedIn account first, and when that account got temporarily locked"
— G2, 4.5★, 2024-04-12. Read the shape of that sentence rather than the incident: a lock — temporary, not a ban — arrives as a subordinate clause, dropped in on the way to a different point. That is what a restriction looks like when the person it happened to never connects it to the tool, and one review told that way establishes no cause.

Another five-star reviewer described extension risk as hearsay:

"That is runs as a Chrom extention. That can be sometimes bad because I have heard that Linkedin does not like extentions"
— G2, 5★, CEO, 2024-06-26. The reviewer is right, and has the shape of it without the mechanism. What he heard as “LinkedIn does not like extensions” is, concretely, two things I found in v0.3.45 (CRX 2026-06-05): a fixed assets/style.css URL that answers a page-load probe, and two scripts injected into every LinkedIn page for a DOM scan to find.

The counter-voice matters too:

"Fast, Effective, user-friendly UI AND solid data quality" "Pricing models are built to drive sales to annual plans."
— G2, 4.5★, Senior Recruiting Manager, 2024-10-28. The tool can be very good at the job it advertises while the build I read on 2026-06-05, v0.3.45, still exposed the session-custody risk documented above; product quality and account surface are separate axes.

FAQ

Is Wiza safe on LinkedIn?
I rated the June build — v0.3.45, CRX 2026-06-05 — HIGH risk because the audited code combined a session handoff, a listed extension ID, page injection, direct Voyager access, and synthetic-event signals. Those add risk in a cumulative scoring model; none is an automatic restriction. I did not audit v0.3.57.

Can LinkedIn tell that I have Wiza installed?
For the extension ID and dated evidence checked, yes. In the build I pulled on 2026-06-05, v0.3.45, assets/style.css had a stable extension URL, and the target-list record noted v0.3.46 live on 2026-06-09. A page-load fetch could confirm installation without an export. I did not repeat the check against v0.3.57.

Does Wiza collect user data?
The concrete client-side payload in v0.3.45, downloaded 2026-06-05, included li_at, li_a, the entire LinkedIn cookie jar, and the Wiza version returned toward wiza.co, wiza.com, and plugin.wiza.co; scraped search and lead data such as names, profile identifiers, email addresses, and company fields; install/update events with the version string on browser start; Bugsnag error diagnostics; and enriched contacts sent to a connected CRM. The code established those outbound paths, not the vendor's later server-side handling.

Can Wiza get my LinkedIn account restricted?
Only LinkedIn restricts a LinkedIn account, and the four steps this teardown traced — inject, listen, call, hand the session over — are inputs to that decision, not the decision itself. Two of them — the page-load probe and the cookie handoff in v0.3.45, pulled 2026-06-05 — happened whether you exported ten contacts or ten thousand, which is why “just go slower” addresses half of what the June build did and no more. Nobody in the 570 reviews describes a ban pattern; that is worth knowing, and it is not the same thing as safety.

Is Wiza a Chrome extension or a cloud tool?
Both. In v0.3.45 (CRX 2026-06-05), an MV3 extension bridged the local LinkedIn session to Wiza's cloud, which handled export and enrichment. This was not a vendor-hosted LinkedIn login, and the product was not acting as an activity runner on the user's behalf.

How did Wiza get my personal information?
Wiza builds contact records from LinkedIn profile data. Seven of eight compliance-topic review mentions came from Trustpilot data subjects, but consent and the legality of bulk enrichment were not assessed through this code read, so I make no legal conclusion. Affected people should ask Wiza about access or removal and should not assume an outcome.

What's a safer alternative?
Architecturally, a standalone desktop app like Linked Helper removes the extension ID and page-injection surfaces and can keep the session on the user's machine. That is a smaller detection and custody surface, not immunity.

Is LinkedIn to Resume Safe? A Static Code Audit of Its Chrome Extension

Michael Harris — Tue, 08 Sep 2026 12:39:28 +0000

LinkedIn to Resume, by CVGist is Chrome extension, not advice about adding LinkedIn to a résumé. It is a cvgist.com product (store developer site: mycvcreator.com), with 10,000 users, v0.1.8, MV3, and a store listing updated 2025-12-02.

My August 2026 line-by-line read gives it a Low-risk verdict, with four residuals:

the ext_id is on LinkedIn's AED probe list, though the shipped build declares zero web-accessible resources, so the reachability of the probe file that listing names is inferred from the manifest, not observed;
a content script runs on every LinkedIn page, passive until the popup fires it;
three isTrusted=false programmatic clicks hit LinkedIn's own controls;
a full profile PDF crosses to cvgist.com, where this audit stops.
The important result is simpler: the extension never reads the LinkedIn session, and the session never leaves the browser.

The six-step code path

1. Load: declare two narrowly placed content scripts

text ://.linkedin.com/* https://cvgist.com/resume-from-profile/generating
The LinkedIn script loads on every LinkedIn page but remains passive until the popup triggers it; the other script is limited to CVGist's generating page.
What this means for detection: AED is the documented signal here; Spectroscopy and the page-snapshot worker are unavailable findings, because I found no injected element, script, style, iframe, or chrome-extension:// resource for either scanner to find.
AED, or “Active Extension Detection,” is not an official public name or my coinage: it is the label in LinkedIn's production JavaScript, where results ship as an AedEvent. BrowserGate, an independent 2025–26 investigation that took apart LinkedIn's production bundle, documented it, as did Linked Helper's security study, whose scope was static audits of 16 extensions plus live two-account sign-up tests of seven cloud tools. LinkedIn has never publicly acknowledged it.
The list grew from 38 entries in 2017 → ~461 in 2024 → 5,459 in December 2025 → 6,167 in February 2026, roughly 12 new entries per day. This ID is listed with icons/icon.png; however, v0.1.8 declares zero web-accessible resources, so I infer that this particular fetch should not resolve. I did not run LinkedIn's scanner. Presence on a list is a signal, not enforcement.

2. Read: parse the public vanity slug

js m.split("/in/")[1].split("/")[0]
That string split reads the public /in/your-name handle already in the address bar. It becomes the extension's userId; it is not a token.
What this means for detection: no independent detection signal at this step — a string split on a URL already in your address bar produces no request, no header, no traffic.

3. Click: drive LinkedIn's own control

js .click()
The shipped source contains three .click() call sites (content-scripts/linkedin.js:40, :42, :123) covering “More” and “Save to PDF.” These are occurrence counts, not observed events; there is no loop, queue, timer, invite, message, or generated profile visit.
What this means for detection: programmatic clicks have read-only isTrusted=false, unlike a human click; normal extension APIs cannot forge true, while chrome.debugger exposes a permanent debugging banner. Linked Helper's security study says this was not yet mass-enforced at the expert's last direct knowledge, but described wider use as “a matter of time.”

4. Intercept: catch LinkedIn's PDF

js fetch(n.url)
chrome.downloads.onCreated catches an application/pdf from LinkedIn, cancels the native download, re-fetches that issued URL, base64-encodes the blob, and stores it locally as linkedInProfilePDF alongside linkedinProfileId (background.js:48–55).
What this means for detection: no documented request-map-anomaly signal applies — the profile page and its surrounding traffic produced the PDF URL normally. A second GET is an oddity, but none of my sources identifies it as a detection vector.

5. Hand off: cross the vendor boundary

text chrome.storage.local window.postMessage
The worker opens https://cvgist.com/resume-from-profile/generating; its content script retrieves the PDF and public slug from local storage and posts them into that page.
What this means for detection: LinkedIn cannot observe a postMessage inside a CVGist tab; this is a privacy boundary, not a LinkedIn detection signal. What CVGist's web app does next is outside this audit.

6. What never happens

json "permissions": ["downloads", "storage", "tabs"]
There is no cookies permission, , externally_connectable, declarativeNetRequest, telemetry endpoint, WebSocket, XHR, sendBeacon, remote queue, or background timer. The only credentials:"include" occurrence belongs to React's generic module preloader, not LinkedIn.

What this means for detection: the unavailable vectors are the finding — no session replay means no APFC fingerprint or IP/parallel-session comparison, no API call means no request-map anomaly, and no injected artifact means no Spectroscopy or page-snapshot claim.
Here are the four reproducible searches I ran across the shipped, beautified source:
text rg "chrome\.cookies|browser\.cookies" → 0 matches rg "li_at|JSESSIONID|\bli_a\b" → 0 matches rg "document\.cookie" → 0 matches rg "csrf-token|x-restli|voyager" → 0 matches

These are static counts of pattern occurrences in shipped source, not a claim that I observed zero traffic at runtime; they foreclose session replay, direct LinkedIn API access, and the corresponding fingerprint/request-map vectors in this build.

The practical caveat starts with LinkedIn's own limits

Because this extension drives LinkedIn's first-party button, it inherits that button's constraints. LinkedIn says: “Profiles must be in English, and the member's language setting must also be English”; “This feature is not available on the LinkedIn mobile app”; “The Save to PDF option currently supports only English characters”; and “You're limited to 200 PDF downloads per month.” I fetched LinkedIn's Help Center page on 2026-08-31.

That ceiling is why there is no credible volume story here. The dependency is still qualitative: this is a first-party button LinkedIn has changed before.

No live IP test was run, and there is nothing for one to measure: there is no cloud tier, vendor login, or server-side session, hence no exit IP, ISP, ASN, or fingerprint comparison.

What this means for your account

It is a scoring model, not a tripwire. Each signal adds points; a listed extension ID and three synthetic click sites are two small additions, and safe daily limits do not offset a detectable architecture in either direction. What this build contributes is close to the floor: no connection requests, no messages, no profile-visit runs, no background timers, and a ceiling LinkedIn itself sets at 200 profile PDFs a month.

A smaller surface is still not immunity. This extension exposes less than almost anything else I have taken apart, and it still exposes something — an ID on a list and three clicks a page script can tell apart from yours. The behavioural layer also judges humans and robots alike: one job seeker had Easy Apply paused after five manual clicks, with no automation involved at all. No tool is unbannable.

What users say about the category

Checked 2026-08-31, the labeled corpus contains zero reviews and zero Reddit posts about this brand. The following are category-level voices about LinkedIn extensions and detection generally; this isn't about LinkedIn to Resume — it is about the category people file it under.

“stop using chrome extensions for scheduling. i've had multiple clients get banned using tools like Taplio. linkedin detects them and flags your account.”

— r/SaaS.

The author also plugs his own SaaS, so the claim has a conflict of interest. My narrower reaction: this product's ID is listed, but detection and enforcement are different facts.

“the mechanism matters less than the behavioral signature. i've seen standalone browser tools get accounts flagged within a week because someone ramped volume too fast - 0 to 150 actions/day doesn't look human regardless of what's driving it.”

— r/b2bmarketing.

He is partly right: clean architecture is not immunity. Here, however, LinkedIn's 200-PDF monthly ceiling removes his ramp-volume scenario, while AED membership remains.

“LinkedIn actively bans accounts caught using automation.”

— r/SaaS.

That flat belief is useful context, not evidence against this product. My read is a scoring model: listed presence and synthetic clicks add signals; neither is an automatic restriction.

FAQ

Is LinkedIn to Resume safe to use on LinkedIn?
My static read rates v0.1.8 Low risk, with the four residuals named at the top. It touches zero leads, connections, or messages.

Does it read my LinkedIn session cookie (li_at)?
No. It lacks cookies permission, and the session-related searches return zero occurrences.

Does LinkedIn to Resume collect user data?
The concrete payload is the full profile PDF plus the public /in/ vanity slug. The extension passes both into a cvgist.com page through local extension storage and postMessage; what that web app subsequently does is outside this audit.

Does LinkedIn detect it?
The ext_id is on AED's target list. Inferred nuance: v0.1.8 exposes no web-accessible resource, so the named icons/icon.png probe should not resolve; I did not test the live scanner.

Can it get my account restricted?
No tool can promise otherwise. This build adds two LinkedIn-facing signals—listed presence and synthetic clicks—but no automation cadence. Detection is not enforcement.

Are there usage limits?
Yes: English profile and language settings, desktop only, English characters only, and 200 PDF downloads monthly.

Does it scrape LinkedIn's API or send messages?
No. The API/CSRF searches return zero, and there is no queue or code for connections or messages.

Why might the result resemble LinkedIn's PDF?
Before CVGist processes it, it is LinkedIn's PDF. Aggregator summaries of store reviews mention resemblance to LinkedIn's export, unwanted AI rewriting, and omitted sections such as projects; those are summaries, not reviews I read.

The full line-by-line audit, with code citations, is here: https://safe-outreach.com/is-linkedin-to-resume-safe