They Didn't Hack Your Browser. They Inventoried It.

They did not break anything. They just ran an asset inventory against people who never agreed to be assets.

I closed out my last cybersecurity series with three posts about one shape of failure: nothing gets hacked, something gets trusted that should not have been. I thought I was done with it for a while. Then the biggest professional network on earth turned out to be running the one tool I know better than any other, pointed at everyone who visits.

So this one sits between my two arcs on purpose. The mechanism is a cyber story, the kind I wrote in “They Didn't Give the AI Your Endpoints”. The motive, once you look at the timeline, is a Leveragism story straight out of “It Was Never a Dream. It Was a Subscription.” Same machine. Different room.

The Trick, Stripped Down

Chrome extensions can declare certain internal files as “web accessible,” meaning a normal web page is allowed to load them. Icons, popup HTML, a script here and there. That is by design, and it is usually harmless.

It also means a web page can ask: does the file popup.html exist at chrome-extension://<32-character extension ID>/? If the extension is installed, the request succeeds. If it is not, Chrome refuses. One request, one yes-or-no answer.

Now do that 6,000 times.

That is BrowserGate. According to the Fairlinked write-up, LinkedIn's production JavaScript bundle (a roughly 2.7 MB Webpack chunk they identify as chunk.905) carries a hardcoded list of 6,222 Chrome extension IDs, each paired with a known file path to probe. Fairlinked calls the system Spectroscopy, which is also the name of one of the tracking events it fires. On page load it sends the requests, either all at once or staggered on a timer so the burst does not stand out in a network monitor, and it can defer the whole thing until your browser goes idle so you never feel a hitch.

You do not have to take that on faith. Here is the loop, in production, on my machine. A for loop over a list of { id, file } pairs. A fetch() at chrome-extension://${n}/${i}. A try block wrapped around it with a completely empty catch (e) {}. A staggerDetectionMs timer and a useRequestIdleCallback flag controlling the pacing. And at the bottom, the payoff: fireTrackingPayload("AedEvent", { browserExtensionIds: n, ... }).

Click to enlarge

That empty catch (e) {} is the part people get wrong, including my own first draft of this post. It does not make the scan invisible. It swallows the JavaScript exception, so LinkedIn's own code never trips over a failed probe, but Chrome's network layer still reports every single miss on its own. Open the console on a LinkedIn page and you will watch it fill with thousands of identical failures. The scan is not hidden. It is just boring enough, and buried in enough noise, that nobody looks.

The IDs that answered “yes” get packaged into that tracking event and sent to LinkedIn's telemetry endpoint at linkedin.com/li/track. That is scan number one. Scan number two is the second function in the screenshot above: it walks your entire page DOM, checking text nodes and element attributes for the string chrome-extension://, which catches extensions that modify the page even if they are not on the list.

On top of both sits a 48-feature device fingerprint: CPU cores, memory, screen, timezone, fonts, canvas and audio hashes, battery, whether you are in incognito, and, per Fairlinked, your Do Not Track setting, which gets recorded and then excluded from the fingerprint hash so it does not interfere with tracking you. Everything is RSA-encrypted before it leaves, so even if you are watching the Network tab you cannot read the payload. Then the encrypted fingerprint rides along as a header on every API call for the rest of your visit.

No malware. No exploit. No zero-day. Just first-party JavaScript on a site you chose to visit, asking your browser questions it is technically allowed to ask.

The Part I Recognize, Because I Built It

Here is where I stop being a reader and start being a witness.

For nearly 30 years my day job has been endpoint management. Nearly 15 of those were exclusively in endpoint management and security using BigFix for Fortune 500 organizations and Federal agencies. The core of that job, the thing every Fortune 500 shop paid me to make work, is software inventory: enumerate every machine, discover what is installed on it, tie the result to a user and a business unit, and ship the whole picture to a central server so someone can act on it. Patch this. License that. Flag the unauthorized thing on the VP's laptop.

Read BrowserGate's mechanism again with that lens. A hardcoded list of known software. A per-item existence probe. Results keyed to an identified user and their employer. Batched, encrypted, shipped to a collector. Fed into an analytics tier. That is not “like” an inventory scan. That is an inventory scan. I could rebuild it in BigFix relevance language in an afternoon.

And I have done it, hundreds of times, at scale. The difference is that every single time, someone signed something first. A statement of work. An acceptable-use policy the employees acknowledged on day one. A change ticket. Inventory is a powerful thing precisely because it strips the guesswork out of “what is on this machine,” and that is exactly why every place I have ever done it treated the authorization as the load-bearing part.

LinkedIn's authorization is a clause in a privacy policy. I will get to that. But first, the part that is genuinely fair to them.

Anti-Scraping Is Legitimate. Then the List Kept Growing.

I am not going to pretend this technique is unique to LinkedIn, because it is not. Probing web-accessible resources to detect extensions is a well-known fingerprinting trick, and anti-bot vendors across the industry use versions of it to spot automation. LinkedIn's stated reason, catching scrapers who vacuum up member profiles with browser add-ons, is a real problem that actually harms real people. If the list were a few dozen known scraping tools, this would be a footnote.

Here is the timeline that turns the footnote into a post. Fairlinked's numbers; people dispute what they mean, but nobody has disputed the counts:

That is 708 new entries in roughly ten weeks. Twelve a day, every day, in the final stretch they measured.

Now line that up against the other thing that happened to LinkedIn. On September 6, 2023, the European Commission named its first six “gatekeepers” under the Digital Markets Act. Microsoft was one of them, with LinkedIn as one of its two regulated products, and the compliance obligations took effect on March 6, 2024. The DMA requires gatekeepers to give business users and authorized third parties real access to the data generated on the platform, which is, on its face, a legal opening for exactly the kind of third-party LinkedIn tools the company has spent years suing, suspending, and threatening out of existence.

Fairlinked's argument is that the scan list exploded in the window after those obligations landed, and that the list now contains over 200 products competing directly with LinkedIn's own sales tools, naming Apollo, Lusha, and ZoomInfo among them. Because LinkedIn knows every user's employer, scanning for a competitor's extension across a company's staff tells you which companies are evaluating or running the rival product. That is not fraud prevention. That is a customer list.

I sat in the meetings, at HCL and before, where lock-in got called “stickiness.” I told you that in the Subscription post. What I did not have then was an example of stickiness enforced by client-side JavaScript, running an inventory of your toolbar to find out which competitors you are cheating on the platform with. Now I do.

What Holds Up and What Does Not

My rule from the gas-prices and grill-brush posts applies here twice as hard: I am describing architecture, not alleging a conspiracy, and I do not let anyone grade their own case, including the accusers.

Verified independently

• The scan exists and is running. BleepingComputer tested it and observed a randomly named JavaScript file checking for 6,236 browser extensions. I checked it myself, on my own machine, and both screenshots in this post are mine.
• LinkedIn does not deny scanning. The company told reporters it looks for extensions that scrape data without consent or otherwise violate its terms. Separately, LinkedIn Senior Engineering Manager Milinda Lakkam acknowledged the extension detection work in a sworn affidavit filed in German proceedings in February 2026, framing it as anti-abuse infrastructure.

Click to enlarge

Still the accuser's framing

• What LinkedIn does with the data. BleepingComputer confirmed the scan but wrote plainly that it could not verify Fairlinked's claims about how the data is used or whether it is shared with third parties. The “customer list” argument is an inference from what is on the list, not evidence of a report someone ran.
• The count, and a real dissent. The bundle carries 6,222 IDs, but that is the size of the list, not the size of the catch. Tyler Reguly, associate director of security research and development at Fortra, sampled roughly 10% of the list and estimates only about 2,000 of those extensions could actually be detected this way. He also found plenty of genuinely bad actors in his sample, and he thinks the story is overblown: in his view this is a simple, well-known JavaScript detection technique, not a scan of your computer and not malicious code. His verdict is “a giant nothingburger.” I disagree with him on the conclusion and I think he is right about the mechanics, and you should hear both before you decide. Treat 6,222 as a ceiling, not a headline.
• The source. Fairlinked is an association of commercial LinkedIn users and tool makers. Its board includes the founder of Teamfluence, a LinkedIn tool whose accounts LinkedIn suspended for scraping, and a German tribunal has since found that Teamfluence violated LinkedIn's user agreement and that the suspensions were justified. They have skin in the game. That does not make them wrong. It means you weight their inferences the way you would weight any vendor grading its own breach.

And LinkedIn's defense, which is real but thin

LinkedIn called the lawsuits “a house of cards built entirely upon a fabrication,” and says it discloses the extension scanning in its Privacy Policy to detect abuse and protect site stability. The policy language it points to says the company may get information about your network and device, giving as examples your IP address, proxy server, operating system, web browser, and add-ons. The company also says explicitly that it does not use this data to infer sensitive information about members. That denial is on the record and it deserves to be read alongside everything above.

But that word, “add-ons,” is doing a lot of work. The two class actions filed April 6, 2026 in the Northern District of California, brought by named plaintiffs Jeff Ganan and Nicholas Farrell, argued that no reasonable person reads a generic parenthetical about add-ons as consent to thousands of silent probes tied to their identity. They asserted claims under the Federal Wiretap Act and California's wiretapping and computer fraud statutes, and sought statutory damages of $5,000 per violation.

On September 8, 2026, Judge Vince Chhabria dismissed both. Not on the merits. On standing: Ganan never alleged he had any extensions installed at all, and Farrell said he had several but never alleged that one of his own leaked anything private. Then the judge went further. He agreed with LinkedIn's argument that people install extensions voluntarily, and that extensions by their nature expose data to websites, and said he doubted the plaintiffs could ever plead a privacy violation, “much less prevail at the end of the day.” He gave them until September 22 to try again. Ganan chose to appeal instead: judgment was entered in his case on September 16, and he filed a notice of appeal to the Ninth Circuit the next day.

Read that ruling from the inventory chair. The court just said the endpoint consented by existing. No court has ruled the scan legal, and no court has ruled it illegal. What exists right now is a federal judge signaling that “you installed it, so it's fair game to enumerate” is a reasonable place to start.

If I had put “we may collect information about add-ons” in a statement of work and then enumerated 6,000 specific products against every user in the company without a change ticket, I would have been walked out. Under current law, LinkedIn gets a dismissal. That gap is the whole argument for the levee.

The Target List Should Bother You

Anti-scraping tools I understand. Here is what else Fairlinked found on the list, and this part you can check yourself against their searchable database:

• 509 job-search extensions. On the one website where your current employer, your recruiter, and your entire professional history live in the same profile. Whether or not LinkedIn ever runs that query, the data to answer “which of this company's employees are quietly looking” is now sitting in a telemetry store. I am job hunting right now, because 3D Nomadic does not yet pay all the bills and a post-Chapter 7 bank account does not care about your principles. I do not love being a row in that table.
• Extensions that signal politics, religion, and neurodivergence. Fairlinked names examples on all three: extensions with explicit political positions in the title, extensions that filter content by religious rule, and accessibility and reading aids used heavily by neurodivergent people. Under GDPR those touch special categories that require explicit consent, and the DOM walk does not care what is on the list, it catches anything that touches the page. LinkedIn says it does not use the data to infer sensitive information. Collection and inference are two different questions, and only one of them has been answered.
• Over 200 competitors to LinkedIn's own sales products, which is the Leveragism half of the story.

Diplomats have security teams. The rest of us have a Chrome profile with a grammar checker and a coupon finder on it, and a professional identity we cannot really opt out of.

I Refuse to Leave You in the Dark

Same split as always. Structural fixes that move the needle, and personal moves that get you through the week. Do not confuse the two.

The levee (what we should be demanding)

• Treat client-side probing as access, legally. Enumerating what is installed on someone's machine is an inventory scan. Inventory scans require authorization, and “add-ons” buried in a parenthetical is not authorization. A federal court just signaled that installing an extension means you accepted being enumerated. Consent law needs to say plainly that it does not.
• DMA enforcement with teeth. A gatekeeper cannot be allowed to comply with an interoperability mandate on paper while running a scan built to identify and shut down the third parties the mandate protects. The Commission has the complaint. It needs to act on it.
• Close the hole at the browser. Chrome's extension platform already lets developers hide resources behind dynamic, per-install URLs. Make that the default, and make static web-accessible paths the exception that requires justification. Firefox assigns each installed extension a random per-install identifier, which is why the list probe does not work there. Chromium can do the same.
• Disclosure that a human can read. If a site runs an inventory of your software, it says so in a sentence, not a clause. “We check for 6,000 extensions on every page load” is a sentence. Print it.

The sandbags (what you can do Monday)

• Give LinkedIn its own browser. Firefox defeats the extension list probe outright. The DOM walk can still spot an extension that writes into the page, so the cleanest setup is a dedicated LinkedIn-only profile, in any browser, with zero extensions installed. That gives both scans nothing to find.
• Audit yourself. Open the searchable database and check your own extensions against the list. Ten minutes. You will learn something, and it will probably be the job-search one you forgot you installed.
• Verify it with your own eyes. This is the one I actually want you to do. Open LinkedIn, hit F12, click Console, and reload. You are looking at my second screenshot. Then open Sources and search the bundle for AedEvent and you are looking at my first. Do not take my word for it. Do not take theirs. The code is right there, and it took me under two minutes.
• Treat “for your security” like “urgency.” In my last series, urgency was the tell. Here the tell is a security justification that quietly expanded a hundredfold. Legitimate anti-abuse scans do not need a competitor list.

Be clear-eyed: a separate browser profile is a sandbag. It protects you. It does not stop the scan running on a billion other people, and it does nothing about the data already collected. Only organized people fix the levee.

Why I'm Telling You This

Because for nearly 30 years I have been the guy running the inventory, and I have never once run it without permission, and I want you to understand how much that permission was worth.

The technique is not evil. Software inventory is one of the most useful tools in enterprise IT. It is what lets you patch a zero-day across 80,000 laptops before lunch. Every good thing it does is downstream of one boring fact: somebody agreed to it, in writing, with the scope spelled out.

BrowserGate is what that tool looks like with the agreement torn off. Same probes, same list, same central collector, same identified users. Just pointed outward, at everyone, with a clause where the contract should be. And once you see the list growing in lockstep with a law meant to open the platform up, the “security” label starts to look like the “entrepreneur” label from my Sanders post: a friendlier word bolted over the same thing, so nobody checks the access list underneath.

I know this one from the inside. I built the inventory. I am telling you it needs a signature.

Watch your console. Then get loud with me.

Sources & Further Reading

• BrowserGate / Fairlinked e.V.: Executive Summary, How It Works, the searchable extension database, and the Evidence Pack (timestamped bundle archive and the Lakkam affidavit). Source for the mechanism, the growth table, the 6,222 count, the 509 job-search figure, the 48-feature fingerprint, and the DMA argument. Fairlinked is an association of commercial LinkedIn users and tool makers with a direct stake in the outcome.
• BleepingComputer, “LinkedIn secretly scans for 6,000+ Chrome extensions, collects data” (bleepingcomputer.com): the independent test that observed the scan checking 6,236 extensions, the explicit statement that they could not confirm the data-use or third-party-sharing claims, and LinkedIn's statement.
• SecurityWeek, “BrowserGate: Claims of LinkedIn ‘Spying’ Clash With Security Research Findings” (securityweek.com): the dissent. Tyler Reguly of Fortra on his 10% sample, his roughly 2,000 detectable estimate, and his “giant nothingburger” verdict.
• PCMag via Yahoo Tech, “LinkedIn Hit With Class-Action Lawsuits Over Browser-Extension Scanning” (tech.yahoo.com): LinkedIn's “house of cards” statement, the privacy-policy “add-ons” language, and the named plaintiffs.
• BrowserGate, “US Class Action Suit over BrowserGate Filed” (browsergate.eu): the Northern District of California filing, the Federal Wiretap Act and California statutory claims, and the $5,000 per violation demand.
• Bloomberg Law, “LinkedIn Beats Privacy Suits Over Anti-Scraping Browser Searches” (news.bloomberglaw.com): the September 8, 2026 standing dismissal.
• MediaPost, “Judge Sides With LinkedIn In Suits Over Browser Scans” (mediapost.com): Judge Chhabria's reasoning and the September 22 deadline to amend.
• Gizmodo (reporting Ars Technica), “LinkedIn Gets ‘Browsergate’ Proposed Class Actions Thrown Out” (gizmodo.com): the plaintiffs' possible next steps and the Teamfluence background.
• Computerworld (computerworld.com): coverage of the dismissal order, including the with-prejudice condition if no amended complaint was filed.
• CourtListener, Ganan v. LinkedIn Corporation (N.D. Cal. docket, Ninth Circuit docket): the April 6, 2026 filing date, the September 16 judgment, and the September 17 notice of appeal.
• The Next Web, “LinkedIn is secretly scanning your browser for 6,000 extensions” (thenextweb.com): the competitor-tool angle and the fingerprint summary.
• Tech Times, May 2026 update (techtimes.com): the European Commission complaints and the DMA compliance review.
• EU Digital Markets Act, Regulation (EU) 2022/1925 (eur-lex.europa.eu): the gatekeeper data-access obligations. Microsoft, with LinkedIn, was designated a gatekeeper on September 6, 2023, with obligations effective March 6, 2024.
• Chrome Extensions documentation, web_accessible_resources (developer.chrome.com): the platform feature the probe relies on, and the dynamic-URL option that defeats it.

Sourcing note: I verified the scan on my own workstation on September 11, 2026, before writing this, and both screenshots are mine and unedited except for cropping. The mechanism comes from Fairlinked's write-up and BleepingComputer's independent confirmation. Everything about what LinkedIn does with the data after collection is Fairlinked's inference, LinkedIn disputes it, and I have labeled it that way above. The 6,222 figure is the size of the list in the bundle; Fortra's Tyler Reguly estimates the number actually detectable is closer to 2,000, and I have quoted his dissent rather than bury it. The two US class actions were dismissed on standing on September 8, 2026, with leave to amend, and Ganan has appealed to the Ninth Circuit; no court has ruled on whether the scan itself is lawful, and nothing here is a finding of fact by any court. I am not a lawyer and nothing here is legal advice. Verify anything you plan to repeat.

Connect with Casey

If this resonated, or if there's a topic you want me to take on next, reach out. I read everything.

Casey writes about economic policy, nomadic life, cybersecurity, chronic pain, and navigating the world as a late-diagnosed AuDHD adult. New posts drop on my professional website.