Continuing my series analyzing popular LinkedIn extensions, their source code, and what they actually execute behind the scenes. Following up on my recent teardowns of Kaspr, Wiza, and Aimfox, here is a breakdown of another tool in the wild: Profile Scraper for LinkedIn.

I audited this extension expecting to find another cloud cookie bridge. Instead, the session finding came back remarkably clean. In build v1.3.2 (published 2026-06-07), li_at is never touched, and nothing is exfiltrated to a vendor server. It operates as a local-scrape Chrome extension with no vendor backend: profile data is written directly to a CSV file stored locally on your machine. Nothing executes outside your own hardware, eliminating the cloud exit-IP anomalies that live proxy testing usually looks for.

The false positives of automated regex scanning

Before reading the source manually, I ran an automated pattern scanner over the shipped bundle. Most output held up against the code: the extension-detection entry, declared probe resources, permission inventory, LinkedIn-only host scope, Manifest V3 structure, and analytics hosts.

However, automated scanners generated six notable false positives across three distinct areas:

• The li_at hit: The scanner flagged a suspected session upload because it matched the string li_at. In reality, that hit was a minified token inside a bundled Vue / FontAwesome UI library—a framework dependency, not cookie extraction. The only LinkedIn cookie this code actually queries is JSESSIONID, which it passes legitimately as an anti-CSRF token on internal Voyager calls. Confusing JSESSIONID (XSRF token) with li_at (session credential) is how false accusations get published.
• The "cookie harvest" warning: The automated report flagged a full cookie-jar extraction. Looking at the code, there is no chrome.cookies.getAll, no enumeration loop, and no outbound cookie POST. Similarly, flagged "synthetic clicks" were simply internal Vue runtime events and the extension clicking its own generated CSV download blob—not automated clicks against LinkedIn's live DOM.
• Ghost backends: The scanner listed eight external vendor backends. These turned out to be static documentation links and font repository strings bundled inside open-source libraries rather than active network endpoints.

Pattern scanners over-report credential harvesting, cannot distinguish between bundled UI dependencies and active exfiltration sinks, yet nail the detection surface. Relying on automated reports without manual code validation almost led to publishing false conclusions about a clean codebase.

Session safety vs. account safety: The structural footprints

Even with zero token leaks, session safety is not account safety. The extension still presents clear detection surfaces:

1. The AED probe list on page load The extension ID (kipefhbblcjblnkcnclpmlpfcflghooh) is present in the internal target array probed by LinkedIn's client-side JavaScript. The manifest explicitly exposes one web-accessible asset:

Plaintext

plasmo-inline.6e038a4b.css 

Because LinkedIn's page scripts probe for declared web-accessible files, a successful fetch returns "installed" before a user ever clicks a button. In LinkedIn’s front-end code, this fires an AedEvent (Active Extension Detection, documented by the independent BrowserGate reverse-engineering project). That target array was tracked at 6,167 entries by February 2026. A clean session model does not alter this page-load signal.

2. List-free DOM injection Removing the ID from the list wouldn't completely solve visibility. The extension mounts an export button directly into LinkedIn's people-search interface. LinkedIn runs a secondary client-side scan that checks the DOM for elements served from chrome-extension:// paths—no hardcoded ID registry required.

3. Machine-paced Voyager API calls The export traverses LinkedIn's internal Voyager GraphQL endpoints at automated intervals. Fetching raw profile JSON without generating the surrounding asset, style, and telemetry requests of a human page visit creates an access pattern visible in standard server logs. While requests originate from your authentic browser fingerprint and local IP, they remain automated hits against private internal endpoints. On the plus side, the extension is purely read-only—it sends no messages, connection requests, or DOM write actions.

4. Permissions scope The manifest requests storage, Google sign-in, cookie access, and scoped access strictly to linkedin.com—with no wildcard host permissions. While Chrome's cookies permission broadens capability, v1.3.2 restricts usage to a single named token on one domain.

The audit limits

I found no public restriction threads, forum complaints, or negative reviews tied to this extension. However, that silence largely reflects its niche install base (a few thousand users) rather than guaranteed immunity.

This analysis is based strictly on a static read of build v1.3.2. I did not log live traffic at volume, nor do I know what features run behind paid licenses. Furthermore, the Chrome Web Store listed v1.4.0 as of late August 2026 (updated 2026-07-04), which has not been unpacked here.