🛡️
Safe Outreach

Is Block Party safe on LinkedIn in 2026?

No — LinkedIn detects Block Party (we checked it ). Block Party's extension ID is on LinkedIn's AED detection list (Nov 2026 snapshot), and LinkedIn's page code checks for Block Party on every visit by requesting chrome-extension://hefhjoddehdhdgfjhpnffhopoijdfnak/full-screen-modal/index.html — a file that exists only if Block Party is installed. Our automated scan of Block Party 2.30.3 found code that references LinkedIn's session cookie li_at (2 matches in 1 files); whether Block Party sends that cookie anywhere needs a manual dataflow review.

Updated · LinkedIn AED snapshot Nov 2026

ID: hefhjoddehdhdgfjhpnffhopoijdfnak

Does LinkedIn detect Block Party? What we found in its code

Detected by LinkedIn

This browser extension is actively compiled into LinkedIn's frontend detection lists. LinkedIn's scripts can detect when this is active on your browser.

LinkedIn requests: chrome-extension://hefhjoddehdhdgfjhpnffhopoijdfnak/full-screen-modal/index.html
DETECTED

What this means: detection isn't an instant ban — it's one input to LinkedIn's risk score. But it's a standing signal: it stacks with your behavior (volume, programmatic clicks) and device fingerprint, and this is just the AED list — one of LinkedIn's three detection systems (see how it works).

What our automated scan found in Block Party's code

We downloaded Block Party version 2.30.3 from the Chrome Web Store on and searched its 18 code files for the patterns below. Each line shows the first place we found it.

  • Block Party's code references li_at — LinkedIn's session cookie, the one that keeps you logged in. 2 matches in 1 file — first at background/background-script.js:32.
  • Block Party's code references JSESSIONID — LinkedIn's CSRF cookie, needed to call LinkedIn's internal API as you. 2 matches in 1 file — first at background/background-script.js:32.
  • Block Party's code calls paths of LinkedIn's internal Voyager API (voyager/api). 1 match in 1 file — first at background/background-script.js:29.
  • Block Party uses the Chrome cookies API (chrome.cookies), which reads cookies of every site it has access to. 29 matches in 10 files — first at background/background-script.js:15.
  • Block Party reads or writes document.cookie inside pages. 30 matches in 10 files — first at background/background-script.js:29.
  • Block Party creates synthetic clicks or keystrokes (dispatchEvent / MouseEvent) — LinkedIn can tell these from real input (isTrusted=false). 48 matches in 10 files — first at background/background-script.js:15.
  • Block Party runs code built at runtime (eval / new Function). 30 matches in 5 files — first at entry-points/DashboardEntryPoint.js:386.
  • Block Party makes its own network requests (fetch / XHR / WebSocket). 183 matches in 10 files — first at background/background-script.js:29.
  • Block Party's code mentions linkedin.com. 454 matches in 11 files — first at background/background-script.js:29.
Permissions Block Party asks for
alarmscookiesnotificationsscriptingstoragewebRequesthttps://*.blockpartyapp.com/*

What this scan is — and isn't. It is an automated static search of the shipped package, not a full teardown: a match means the pattern is in the code, not that Block Party misuses it, and no match doesn't prove absence (minified or runtime-built code can hide it). We haven't traced where Block Party sends data. How we test

How LinkedIn checks for Block Party: the AED probe

That verdict isn't a guess. This is what LinkedIn's own page code does on every visit — simplified from its production bundle, which the BrowserGate investigation reverse-engineered line by line:

// LinkedIn's page bundle — simplified from BrowserGate's teardown
const hits = [];
for (const { id, file } of AED_LIST) // 4,934 ids incl. this one
try { await fetch("chrome-extension://" + id + "/" + file); hits.push(id); }
catch {} // not installed → silently swallowed
fireTrackingPayload("AedEvent", { browserExtensionIds: hits }); // → POST /li/track
// this extension is probed at:
// chrome-extension://hefhjoddehdhdgfjhpnffhopoijdfnak/full-screen-modal/index.html
On LinkedIn’s AED list
Yes
1 of 4,934 · snapshot Nov 2026
URL LinkedIn requests
chrome-extension://hefhjoddehdhdgfjhpnffhopoijdfnak/full-screen-modal/index.html
the extension's ID + a file bundled inside it
Store status
Live on the Web Store
Source
LinkedIn bundle
ℹVerify it yourself: on linkedin.com open DevTools → Sources and search the page bundle for hefhjoddehdh… or AedEvent; or Network → filter li/track to watch the verdict ship. The scan runs even in Incognito. Below — the full code-level teardown.
Block Party — marketed on the Chrome Web Store, detected by LinkedIn
Vendor's own Chrome Web Store screenshot — this extension is on LinkedIn's detection list.

How LinkedIn fingerprints your browser while you use Block Party

Even after a cookie is copied out, LinkedIn keeps one more receipt on every request that follows — a 48-point snapshot of the exact machine making it. Faking it convincingly means reproducing that machine's quirks, not just editing a string.

Click any signal above for what it means. These are illustrative values — this demo never reads your actual device.

Your 48-point fingerprint — RSA-encrypted, attached to every API call in this session, not just login

This extension runs inside your real browser, so its requests always carry your real fingerprint — that isn't something it controls, it's simply where its code executes.

Verified against LinkedIn source-code, Nov 2026 snapshot.Read full study

Similar LinkedIn tools we checked

Same architecture and risk as Block Party — each with its own code audit.

All extension checks