Inside LinkedIn’s extension detection

While browsing LinkedIn, I noticed repeated chrome-extension://invalid/ failures in Chrome DevTools. Following a request’s initiator first led to a wrapper around window.fetch. Inspecting its arguments and callers revealed something more specific: the page was testing known extension IDs and resource paths.

I used breakpoints, result logging, and prototype inspection to connect the requests to the detection code, then exported its target catalogue. The 175 retained probe records all match the export. The full count of 4,934 comes from the catalogue and source loops.

The two functions obtain their signals differently. Neither provides a complete inventory of installed extensions.

Positive active results feed AedEvent; passive results feed SpectroscopyEvent. Both call sites check that the result is an array with at least one item before emitting browserExtensionIds. In the recorded executions, both arrays were empty, so neither guard would emit its extension event.

An empty result does not establish that no extensions were installed. Chrome restricts resource access by default; origin rules, resource changes, and dynamic IDs can prevent a fixed-ID probe from succeeding. The passive scan has its own coverage limits. No positive-control experiment was retained, so this study does not measure detection accuracy.

From fireTrackingPayload, I followed the shared tracking client through event envelopes, route selection, queues, request packaging, and the final fetch helper. Runtime lookups assigned both extension event names to normal-priority. Separate feature flags can still select legacy handling, the newer route, or both; a destination lookup alone does not prove that an event used it.

The inspected request manager had a batch size of 30 and a flush debounce of 10,000 ms. The transport helper tried fetch with keepalive enabled and retried without it on rejection. Despite the name beaconFunc higher in the chain, this path reached fetch, not evidence of navigator.sendBeacon.

At the final transport step, I inspected a real request containing LixTreatmentsEvent, with JSON packaging and gzip configuration. This provided a runtime example of the shared transport carrying a different event.

The export contains one resource path for each of 4,934 unique IDs and 2,487 distinct paths. It contains no product names, versions, installation counts, or reasons for inclusion. I analyzed the JSON offline with Python and kept direct measurements separate from tentative filename hints.

PNG files account for almost half the targets. The most frequent exact path is icons/icon16.png, used 407 times. Generic paths cannot reliably tell us an extension’s purpose, and a JavaScript target does not mean that script was executed by this detector.

The research package associates ten deliberately selected IDs with public product listings; the other 4,924 identities remain unresolved. That small sample is not representative. I did not turn filename matches into estimates of how many targets serve a particular purpose.

My privacy concern is the information a positive result could reveal about someone’s software choices. An extension’s purpose may suggest interests or working habits, but does not establish personal traits or why it was installed. That is a potential implication of the mechanism, not an observed use of the data. It makes the scope of collection, retention, and access worth examining.

The difficult part was keeping each step’s meaning intact: a target is not a detection, a detection is not an emitted event, and a configured route is not proof of delivery. Moving past the first wrapper, inspecting inherited methods, and connecting source code to recorded runtime values made the system understandable without overstating the result.

This is a client-side investigation of my own signed-in session, documented on 12 September 2026. I conducted the DevTools work with AI-assisted guidance; AI also assisted with source tracing, catalogue analysis, and drafting. I checked the analysis against the retained artifacts. Antoine Vastel’s January 2026 analysis at Castle describes prior work on this mechanism; I make no claim of first discovery.

The record has no complete HAR, controlled positive result, or backend access. It cannot establish retention, profiling, sharing, or the reason a particular extension was targeted. Those remain questions for the operator. What it does demonstrate is a reproducible catalogue analysis and a traceable account of the client’s conditional reporting design, including the negative result.