See what every third-party script on your page actually does

The idea

A DevTools panel that answers one question: which third-party script caused this? It attaches to your page, watches every outbound request, cookie write, and localStorage key, walks the initiator stack back to the script that triggered it, and groups the results by vendor. Instead of a flat waterfall of 240 requests you get a table: Segment made 9 requests and set 3 cookies, an ad tag you forgot about loaded four more scripts from domains nobody approved, and the chat widget is writing 180KB into IndexedDB on every page view.

Why build this

Every marketing team adds tags. Nobody removes them. Six months later the site loads a dozen vendors, half of them loaded dynamically by other vendors, and no one on the engineering side can say what any of them touch. That matters in three ways at once: performance budgets blow up from scripts nobody owns, consent-mode audits under GDPR and the EU's cookie rules require you to actually name what sets each cookie, and a compromised tag is a supply-chain incident with no paper trail.

The existing options don't fit. Lighthouse tells you third-party JS costs 1.2 seconds but not which vendor set which cookie. Tag managers only report on tags they know about, which by definition excludes the ones a vendor injected on its own. Consent platforms scan on a schedule from a crawler that never logs in, so anything that only loads for authenticated users goes unseen. A developer-side extension sees the real page, in the real session, with the real consent state.

The technical piece that makes this newly practical is that chrome.debugger gives an extension the same Chrome DevTools Protocol access DevTools itself has — Network.requestWillBeSent carries a full initiator stack frame, so attribution is a lookup rather than a guess.

Stack sketch

• Chrome MV3 extension, TypeScript, built with wxt — it handles MV3 manifest generation and HMR for the panel, which is otherwise miserable.
• chrome.debugger attached to the inspected tab, using CDP Network, Storage, and Debugger domains. Network.requestWillBeSent.initiator.stack gives the call frames; resolve the topmost non-first-party scriptId to a URL via Debugger.scriptParsed.
• chrome.devtools.panels.create for the UI, so it lives next to Network rather than in a popup.
• Panel UI in Preact with @tanstack/table — the dataset is a few thousand rows and needs grouping and virtualization, not a framework.
• Vendor identification from the DuckDuckGo Tracker Radar dataset (permissive license, maps domains to owning companies), with a local override file for internal hostnames.
• Export to JSON and a Markdown summary; persist sessions in IndexedDB via idb so you can diff two runs.

Scope for v1

In:

• Attach/detach to the current tab, record a session, stop.
• Requests grouped by resolved vendor, with initiator script and byte counts.
• Cookies and localStorage/sessionStorage writes attributed to a vendor.
• Flag dynamically injected scripts — a vendor loading another vendor is the finding people care about most.
• Markdown export for pasting into a ticket.

Out:

• Firefox and Safari. MV3 debugger access differs enough that porting is its own project.
• Any cloud component. No accounts, no upload, no dashboard.
• Blocking or rewriting. Read-only, so it never becomes something you have to keep out of production.
• Automated consent-mode compliance verdicts. Report the facts; let the lawyers judge.

Where it could go

The obvious next step is CI. The same attribution logic runs under Playwright headless against a set of URLs, writes a JSON baseline, and fails the build when a new vendor appears or an approved one starts setting cookies it didn't set last week. That turns a one-off audit into a standing guardrail, and it's the version a security team will actually pay for.

From there, two directions open up. One is consent verification: run the same trace twice, once with consent granted and once denied, and diff them — anything that fires in both is a finding with a regulatory price tag. The other is budget enforcement per vendor, where each tag gets an allowance in kilobytes and requests, and the report names whoever is over. Both reuse the v1 recorder unchanged.

Watch out for

chrome.debugger shows a persistent "extension is debugging this browser" banner and detaches whenever real DevTools attaches to the same target — plan the UX around that conflict rather than fighting it. Attribution also degrades on bundled or heavily minified tags, where several vendors share one script file; be honest in the UI about confidence instead of inventing a clean answer.