This is an old revision of the document!

Tracker Radar Collector

The Tracker Radar Collector (TRC) is DuckDuckGo's modular, multithreaded Chromium crawler. It is a Puppeteer program that uses the Chrome DevTools Protocol (CDP) to collect requests, cookies, JavaScript API activity, targets, screenshots and consent-manager observations, depending on which collectors are enabled. It is the collection half of DuckDuckGo's Tracker Radar pipeline, not the Tracker Radar dataset itself. [1DuckDuckGo, (2026): "Tracker Radar Collector". GitHub repository. Source and README checked at main commit 8b64006691a1ce3929cfdfeeb425e7cc64be6543 on 2026-08-14 (Link)]

Do not use Tracker Radar, Tracker Radar Wiki, Tracker Radar Entity Map or Tracker Radar Detector as synonyms for the Collector. The Collector produces per-site crawl records; Detector processes those records into the domain and entity data shipped by Tracker Radar. The corpus has all of these names, and counting them together makes a dataset or a classifier look like a crawler.

What it is, and what is current

TRC first appears in this corpus in 2021. The public repository is still active: at the 2026-08-14 check, its main branch was at commit 8b64006691a1ce3929cfdfeeb425e7cc64be6543, declared Node.js >= 18 and Puppeteer ^24.7.1. That makes it a current, available Chromium instrument when those versions and that commit are recorded. It is not a published measurement standard, and the corpus contains no matched-sample study showing that TRC supersedes OpenWPM or a plain Playwright crawl. [1DuckDuckGo, (2026): "Tracker Radar Collector". GitHub repository. Source and README checked at main commit 8b64006691a1ce3929cfdfeeb425e7cc64be6543 on 2026-08-14 (Link)]

The literature signal is useful for locating examples, not for estimating field share. In the CRAWLED population of 1,120 papers, 10 papers have a used/produced automation tuple naming the Collector. The report finds 1 of 75 crawling papers in 2021, 1 of 110 in 2022, 1 of 125 in 2023, 3 of 110 in 2024, 3 of 129 in 2025, and 1 of 69 in 2026. The 2021–2024 series is complete for the selected venue-years; 2025–2026 are provisional. See the paper-level examples and the query definition.

Use OpenWPM when its Firefox/WebExtension instrumentation is the surface you need, and use this page when you need to reason about a Chromium/CDP crawl or the Tracker Radar data pipeline. Comparison of Crawling Libraries is the broader choice page.

What it captures relative to OpenWPM

The useful comparison is the capture surface, not the library name. A TRC crawl is Chromium-centred and CDP-native; OpenWPM is an unbranded Firefox platform whose privileged WebExtension records browser events. The same paper-level result can therefore differ because the browser, instrumentation point, state, or consent action differed.

Surface	Tracker Radar Collector	OpenWPM	Measurement consequence
Browser and control	Chromium through Puppeteer and CDP; current TRC attaches to pages, frames and worker/service-worker targets	Firefox driven through Selenium, with a privileged WebExtension	The engine, browser defaults and automation fingerprint are not held constant. A cross-tool comparison is also a cross-browser comparison unless you design it otherwise.
Requests and responses	The RequestCollector records URL, method, resource type, status, size, remote IP, selected response headers, timing, redirect links, initiators and optionally a response-body hash. WebSocket events are represented by the request collector. The current default record does not contain raw response bodies, request headers or request bodies.	`http_instrument` records request/response headers, redirects, POST bodies, resource type, third-party flags and triggering/loading origin; `save_content` stores selected response bodies	TRC is good for a compact per-request trace and deduplication hash. If the question is about sent headers, POST contents, or response bytes, inspect the selected TRC fork/collector or use an instrument that records them; do not infer their presence from a URL log.
Cookies	CookieCollector queries the final browser cookie jar through CDP. Its normalized record contains `name`, `domain`, `path`, `expires`, `session` and `sameSite`; it omits the cookie value, `HttpOnly`, `Secure` and size	`cookie_instrument` records cookie changes from JavaScript and HTTP responses in `javascript_cookies`	TRC's default cookie output is a final-state snapshot, not a set-event history and not a value-based identifier dataset. For creation timing, setter provenance or values, add instrumentation and state exactly what it records.
JavaScript and browser APIs	APICallCollector produces per-source `callStats` and optional `savedCalls` with the source, description and arguments. It uses CDP conditional breakpoints/TrackerTracker and only observes APIs configured for collection	`js_instrument` uses Firefox-side instrumentation for configured objects and properties; the default fingerprinting collection is a different surface	Neither “JavaScript captured” nor “API calls captured” is a sufficient methods description. Publish the collector configuration and API list.
Targets, frames and navigation	TargetCollector records target URL/type; the current collector attaches to page, iframe, worker and service-worker targets	OpenWPM's navigation and tab/window records are WebExtension events	A frame or worker can be the source of a request without being the top-level page. Report whether the analysis retained target/frame identity.
Consent and interaction	CookiePopupsCollector can record Consent-O-Matic/autoconsent CMP observations; the CLI has `optIn`/`optOut` actions. The conductor also supports mobile emulation, scrolling/interaction in forks, and inner-page traversal in forks	Consent handling is implemented by command sequences and browser/profile configuration	“Before consent” is not a browser default. Record the action, rule/version and wait/interaction sequence.
State and filtering	The CLI can use a fresh context, mobile emulation, a region code, a proxy and `–only-3p`. The latter filters by eTLD+1 in the crawler	OpenWPM exposes stateful/stateless profiles, third-party-cookie policy and command sequences	TRC's first-party filter is not an entity or ownership judgment. CNAMEs and organization-level first parties are handled later by Detector, with separate configuration.

TRC therefore overlaps OpenWPM on request, cookie and JavaScript observations but does not emit the same records. In particular, a final cookie jar cannot answer the same question as OpenWPM's cookie-change table, and a response-body hash cannot substitute for a retained body. Conversely, CDP breakpoints and target attachment make TRC a convenient base for narrowly targeted Chromium experiments. The corpus shows many such forks, but no same-sites, same-browser, same-question head-to-head benchmark. [2Englehardt, Steven; Narayanan, Arvind (2016): "Online Tracking: A 1-million-site Measurement and Analysis", in: Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pp. 1388–1401. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)]

Output schema

The crawler writes one JSON result per site. At the top level the current result object is:

Field	Meaning
`initialUrl`	URL supplied to the crawl
`finalUrl`	URL reached after navigation/redirects
`timeout`	Whether the crawl hit its timeout path
`testStarted`, `testFinished`	Crawl timestamps
`data`	Object keyed by the selected collectors

The exact contents of data depend on –data-collectors. The current collector modules expose these principal shapes:

`data` key	What to expect	What to retain or report
`requests`	An array of request/response observations: URL, method, type, status, size, remote IP, selected response headers, response-body hash when enabled, failure/redirect fields, initiators and time	Whether first-party traffic was filtered; whether hashes, headers, WebSockets and initiators were kept; and whether a fork added request headers, POST bodies or response bodies
`cookies`	An array of final cookie-jar entries with name, domain, path, expiry, session and same-site status	The fact that values and set events are absent by default; profile reset and crawl-end timing
`apis`	`callStats` grouped by source URL and API description, plus `savedCalls` when configured breakpoints save arguments	The API/breakpoint configuration, because an empty or partial list is a result of configuration rather than proof of no API use
`targets`	Target URL and target type	Whether iframes, workers and service workers were included in the analysis
`screenshots`	Screenshot data in the in-process result; the CLI writes JPEG files and replaces the field with a path	Browser viewport/device mode, timing and whether screenshots were used as evidence
`cookiepopups`	CMP detections, performance information and scraped frames from the consent collector	Consent action and autoconsent/rule version
`trace`	Chrome trace data when the trace collector is selected	Trace configuration and whether it was sampled or retained

The CLI also writes a metadata.json file. The current schema records startTime, endTime, a result summary, stats (URLs, skipped, successes and failures), config (crawler count, collector list, first-party filter, proxy, region and mobile emulation) and environment (project version, hostname, CPU count and username). Treat hostname and username as data to redact before sharing a crawl archive. The current repository README documents a default maximum page-load window of 30 seconds, with an additional short execution window; forks often change both. Record the actual values rather than inheriting the README default. [1DuckDuckGo, (2026): "Tracker Radar Collector". GitHub repository. Source and README checked at main commit 8b64006691a1ce3929cfdfeeb425e7cc64be6543 on 2026-08-14 (Link)]

The schema is a versioned implementation detail, not a stable interchange standard. Pin the repository commit and inspect the collector source when a field is load-bearing. A “TRC JSON” without the commit, collector list and metadata is not enough to reproduce a measurement.

How Tracker Radar is built from it

The public repositories make the pipeline legible:

Collect. Run TRC over a declared site list, region and browser configuration. Write one per-site result and the crawl metadata. The raw record is about what this crawl observed; it is not yet a tracker label.
Process. Tracker Radar Detector reads those site files (or its configured database), processes requests, cookies and apis, resolves CNAMEs and groups domains into entities. Its code has a minSites threshold, defaulting to 2, so a request seen once is not automatically emitted as a common tracker. The threshold and first-party settings belong in your reproduction record. [3DuckDuckGo, (2026): "DuckDuckGo Tracker Radar Detector". GitHub repository. README and build scripts checked at main commit 0f6eb7db39bbf7cf7357db7279535941e1c0eb4b on 2026-08-14 (Link)]
Aggregate. Detector counts the sites in which a domain/request is observed, derives cookie prevalence and API-fingerprinting evidence, and combines those observations with ownership/entity data. Its prevalence denominator is the set of sites successfully processed under that run's configuration, not all websites on the Internet and not all domains in the final JSON.
Build. The build step emits region-specific domain files and generated maps such as domain_map.json, entity_map.json, domain_summary.json and data_by_site.json. Domain records can carry resources and regex rules, owner/source, prevalence, fingerprinting score, cookies, performance, CNAMEs, nameservers and example sites. Resource records can carry cookie/API/fingerprinting observations, response hashes, CNAMEs and first-party-cookie fields. [4DuckDuckGo, (2026): "DuckDuckGo Tracker Radar". GitHub repository and data model. README and docs/DATA_MODEL.md checked at main commit a1d894db2312f3fdeea06d6c784739b97eb727c8 on 2026-08-14 (Link)]

Tracker Radar describes itself as a dataset of common third-party domains and their observed behavior, not as a complete blocklist. A domain's presence is conditional on the site list, region, browser, consent action, crawl date, minSites, first-party/CNAME policy and the Detector version. Do not turn a Tracker Radar domain entry into a universal claim that every request from that domain tracks, or that absence means absence of tracking.

The two first-party decisions must not be collapsed. TRC's –only-3p option uses eTLD+1 while collecting; Detector's processing has its own first-party, entity and CNAME options. If you enable both, publish both settings. If you want to study CNAME cloaking or first-party cookies, disabling an early filter may be necessary. [1DuckDuckGo, (2026): "Tracker Radar Collector". GitHub repository. Source and README checked at main commit 8b64006691a1ce3929cfdfeeb425e7cc64be6543 on 2026-08-14 (Link)] [3DuckDuckGo, (2026): "DuckDuckGo Tracker Radar Detector". GitHub repository. README and build scripts checked at main commit 0f6eb7db39bbf7cf7357db7279535941e1c0eb4b on 2026-08-14 (Link)]

What the corpus shows

The all-paper population in the refreshed corpus is 5,859 papers from seven venues. A broad Tracker Radar name match occurs in 21 papers, but 11 of those are names for the dataset, entity map, wiki or a general service rather than a Collector automation tuple. The page's adoption count therefore uses the narrower query: a tool name matching the Collector, an automation category, and a used/produced status. That gives 10 papers in the 1,120-paper CRAWLED population; the 10 are also the complete TRC-user set returned by this query.

Year	CRAWLED papers in that year	TRC users	TRC users / CRAWLED papers	Status
2021	75	1	1.3%	complete venue-years in the selected corpus
2022	110	1	0.9%	complete venue-years in the selected corpus
2023	125	1	0.8%	complete venue-years in the selected corpus
2024	110	3	2.7%	complete venue-years in the selected corpus
2025	129	3	2.3%	provisional
2026	69	1	1.4%	provisional

The 2021–2024 window contributes 6 users; the provisional 2025–2026 slice contributes 4. The latter is a useful current-use signal, not a complete trend: CCS and IMC 2026 have not been held, while IEEE S&P and WWW 2026 are under-selected by construction.

The papers use TRC as an extensible base, not as a fixed black-box instrument:

Year	Paper and extension	What the paper added or used
2021	`The CNAME of the Game`	Modified TRC's Puppeteer/CDP crawler to capture HTTP-request cookies, POST data, `document.cookie` assignments and the scripts setting cookies; used a fresh profile, a wait and a reload. [5Dimova, Yana; Acar, Gunes; Olejnik, Lukasz; Joosen, Wouter; Van Goethem, Tom (2021): "The CNAME of the game: Large-scale analysis of DNS-based tracking evasion", Proceedings on Privacy Enhancing Technologies 2021:394–412. (DOI) (Link)]
2022	`Leaky Forms`	Built an interactive crawler on TRC; added inner-page discovery, email/password filling, Fathom and Consent-O-Matic, browser-API/cookie/request collection, CDP breakpoints with JavaScript stacks, WebSocket capture and POST/input observations. [6Senol, Asuman; Acar, Gunes; Humbert, Mathias; Zuiderveen Borgesius, Frederik (2022): "Leaky Forms: A Study of Email and Password Exfiltration Before Form Submission", in: 31st USENIX Security Symposium (USENIX Security 22). (Link)]
2023	`Is Your Wallet Snitching on You?`	Used TRC for popular-site crawls and added wallet-API breakpoints/simulation alongside request and cookie observations. [7Ferreira Torres, Christof; Willi, Fiona; Shinde, Shweta (2023): "Is Your Wallet Snitching On You? An Analysis on the Privacy Implications of Web3", in: 32nd USENIX Security Symposium (USENIX Security 23). (Link)]
2024	`Johnny Still Can't Opt-out`	Reused TRC code for non-invasive breakpoints on DOM cookie methods, JavaScript stacks and parameter values; this is a targeted reuse of the Collector surface, not evidence that the unmodified CLI records those fields by default. [8Aziz, Muhammad Abu Bakar; Wilson, Christo (2024): "Johnny Still Can't Opt-out: Assessing the IAB CCPA Compliance Framework", in: Proceedings on Privacy Enhancing Technologies. (DOI)]
2024	`Targeted and Troublesome`	Extended TRC with ad and fingerprint collectors while retaining request, target, cookie and CMP observations; also used anti-bot and mobile settings. [9Moti, Zahra; Senol, Asuman; Bostani, Hamid; Zuiderveen Borgesius, Frederik J.; Moonsamy, Veelasha; Mathur, Arunesh; Acar, Gunes (2024): "Targeted and Troublesome: Tracking and Advertising on Children's Websites", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)]
2024	`The Double Edged Sword`	Forked TRC to identify authentication pages and measure their fingerprinting behavior. [10Senol, Asuman; Ukani, Alisha; Cutler, Dylan; Bilogrevic, Igor (2024): "The Double Edged Sword: Identifying Authentication Pages and their Fingerprinting Behavior", in: Proceedings of the ACM Web Conference 2024. (DOI)]
2025	`Canvassing the Fingerprinters`	Modified TRC to save Canvas API arguments, return values, script source and timestamps, with anti-bot handling, scrolling and consent automation. [11Luo, Elisa; Ritter, Tom; Savage, Stefan; Voelker, Geoffrey M. (2025): "Canvassing the Fingerprinters: Characterizing Canvas Fingerprinting Use Across the Web", in: Proceedings of the ACM Internet Measurement Conference. (DOI)]
2025	`Referrer Policy`	Extended TRC with inner-page links, Referer/Referrer-Policy and POST-body observations, the page's `referrerPolicy` value and API collection. [12Zagi, Luqman; Moti, Zahra; Acar, Gunes (2025): "Referrer Policy: Implementation and Circumvention", in: Proceedings on Privacy Enhancing Technologies. (DOI)]
2025	`Sheep's Clothing, Wolfish Intent`	Used the tracker-radar-collector framework to collect advertisements for automated evaluation. [13Roongta, Ritik; Jose, Julia; Habib, Hussam; Greenstadt, Rachel (2025): "Sheep's Clothing, Wolfish Intent: Automated Detection and Evaluation of Problematic 'Allowed' Advertisements", in: Proceedings on Privacy Enhancing Technologies. (DOI)]
2026	`Bridges to Self`	Customized TRC for mobile web-to-app tracking, including anti-bot handling, WebSocket frames, WebRTC APIs and Priv-Accept observations. [14Vlummens, Tim; Girish, Aniketh; Weerasekara, Nipuna; Zuiderveen Borgesius, Frederik; Acar, Gunes; Vallina-Rodriguez, Narseo (2026): "Bridges to Self: Silent Web-to-App Tracking on Mobile via Localhost", in: Proceedings of the USENIX Security Symposium. (Link)]

The examples support a practical rule: TRC's value is its CDP/collector architecture, but the paper's measurement surface is the fork and configuration actually run. Cite the upstream Collector for the base and describe every added collector, breakpoint, filter, consent action and interaction.

Measurement checklist

Before collecting, decide what the output is supposed to answer. Then record at least:

the TRC repository commit, package-lock state, Node.js, Puppeteer and Chromium versions (or the explicit –chromium-version);
the site list, its source/version/date, URL selection and whether the crawl visits only a homepage or follows inner links;
crawl dates, region/vantage/IP conditions, proxy, success/timeout policy, concurrency, maximum load time and post-load wait;
fresh versus reused browser context/profile, one profile per site or shared state, viewport/user agent, mobile emulation and anti-bot injection;
the exact collector list and any custom collector, breakpoint, API list, WebSocket/body/header capture or response-hash setting;
consent action (none, opt-in, opt-out), autoconsent/rule version, banner interaction and the time at which collection begins;
first-party filtering at collection time, and the later Detector settings for minSites, keepFirstParty, treatCnameAsFirstParty, entity data and included pages;
raw-archive retention/redaction, especially cookies, response bodies, screenshots, hostname and username in metadata; and
the denominator for every prevalence number: attempted sites, successful sites, sites with a relevant response, or sites retained by Detector.

Anti-bot measures and consent automation are interventions, not harmless crawler options. They can change the page, requests and cookies. A result from –only-3p is conditioned on an eTLD+1 filter; it is not a result about ownership, entity prevalence or CNAME cloaking.

Use in Publications

TRC is a sensible choice when the measurement needs Chromium/CDP access, target-level attachment, conditional JavaScript breakpoints, or a modular path into the Tracker Radar pipeline. It is not automatically the right choice for a Firefox-user result, a cookie-set event history, or a raw-body archive. In all cases, report the capture surface rather than only “we used Tracker Radar Collector”.

At minimum, a methods paragraph should let a reader reconstruct the chain:

browser: Chromium build, Puppeteer/TRC commit, viewport/device mode and anti-bot settings;
crawl: site-list version, dates, region/proxy, concurrency, navigation depth, waits, retries and failure rule;
state/consent: profile/context reset, consent action and autoconsent version;
capture: collector list and custom changes, including whether cookie values, event timing, request headers/bodies, response bodies, API arguments, WebSockets and target/frame identity were available; and
analysis: first-party filter, domain/entity/CNAME mapping, Detector commit and every denominator used for prevalence.

Do not report “number of trackers” without naming whether that means requests, domains, resources, entities, sites with a request, or Tracker Radar records. Those are different units.

Methodology and limitations of these figures

The corpus figures above come from the current data/extract/run1 extraction: 5,859 papers, seven venues (CCS, IMC, NDSS, PETS, USENIX Security, TheWebConf and IEEE S&P), with 1,120 in the CRAWLED population. The 2025–2026 venue-years are provisional. Names were folded only for the Collector automation query, and the excluded Tracker Radar residue is printed in the report rather than silently discarded. The report counts papers for adoption figures; its raw-name audit counts tuples only to expose the mapping residue.

The reproducible report is scripts/report_tracker_radar_collector.mjs in the working corpus checkout. The complete query log, real script output, source-quote checks, external-source verification and judgement calls are on the page provenance record. Dataset-wide extraction and retrieval caveats are on the corpus provenance page.

This page does not claim that TRC is faster, more complete or more accurate than OpenWPM, nor that its 10-paper corpus count is a market-share estimate. The repositories were checked separately for maintenance and schema; the corpus was used to find research use and concrete extensions. The current repository is evidence that TRC remains available, not evidence that every deployed Tracker Radar crawl uses the exact public defaults.

References

[1]: DuckDuckGo, (2026): "Tracker Radar Collector". GitHub repository. Source and README checked at main commit 8b64006691a1ce3929cfdfeeb425e7cc64be6543 on 2026-08-14 (Link)
[2]: Englehardt, Steven; Narayanan, Arvind (2016): "Online Tracking: A 1-million-site Measurement and Analysis", in: Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pp. 1388–1401. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)
[3]: DuckDuckGo, (2026): "DuckDuckGo Tracker Radar Detector". GitHub repository. README and build scripts checked at main commit 0f6eb7db39bbf7cf7357db7279535941e1c0eb4b on 2026-08-14 (Link)
[4]: DuckDuckGo, (2026): "DuckDuckGo Tracker Radar". GitHub repository and data model. README and docs/DATA_MODEL.md checked at main commit a1d894db2312f3fdeea06d6c784739b97eb727c8 on 2026-08-14 (Link)
[5]: Dimova, Yana; Acar, Gunes; Olejnik, Lukasz; Joosen, Wouter; Van Goethem, Tom (2021): "The CNAME of the game: Large-scale analysis of DNS-based tracking evasion", Proceedings on Privacy Enhancing Technologies 2021:394–412. (DOI) (Link)
[6]: Senol, Asuman; Acar, Gunes; Humbert, Mathias; Zuiderveen Borgesius, Frederik (2022): "Leaky Forms: A Study of Email and Password Exfiltration Before Form Submission", in: 31st USENIX Security Symposium (USENIX Security 22). (Link)
[7]: Ferreira Torres, Christof; Willi, Fiona; Shinde, Shweta (2023): "Is Your Wallet Snitching On You? An Analysis on the Privacy Implications of Web3", in: 32nd USENIX Security Symposium (USENIX Security 23). (Link)
[8]: Aziz, Muhammad Abu Bakar; Wilson, Christo (2024): "Johnny Still Can't Opt-out: Assessing the IAB CCPA Compliance Framework", in: Proceedings on Privacy Enhancing Technologies. (DOI)
[9]: Moti, Zahra; Senol, Asuman; Bostani, Hamid; Zuiderveen Borgesius, Frederik J.; Moonsamy, Veelasha; Mathur, Arunesh; Acar, Gunes (2024): "Targeted and Troublesome: Tracking and Advertising on Children's Websites", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)
[10]: Senol, Asuman; Ukani, Alisha; Cutler, Dylan; Bilogrevic, Igor (2024): "The Double Edged Sword: Identifying Authentication Pages and their Fingerprinting Behavior", in: Proceedings of the ACM Web Conference 2024. (DOI)
[11]: Luo, Elisa; Ritter, Tom; Savage, Stefan; Voelker, Geoffrey M. (2025): "Canvassing the Fingerprinters: Characterizing Canvas Fingerprinting Use Across the Web", in: Proceedings of the ACM Internet Measurement Conference. (DOI)
[12]: Zagi, Luqman; Moti, Zahra; Acar, Gunes (2025): "Referrer Policy: Implementation and Circumvention", in: Proceedings on Privacy Enhancing Technologies. (DOI)
[13]: Roongta, Ritik; Jose, Julia; Habib, Hussam; Greenstadt, Rachel (2025): "Sheep's Clothing, Wolfish Intent: Automated Detection and Evaluation of Problematic 'Allowed' Advertisements", in: Proceedings on Privacy Enhancing Technologies. (DOI)
[14]: Vlummens, Tim; Girish, Aniketh; Weerasekara, Nipuna; Zuiderveen Borgesius, Frederik; Acar, Gunes; Vallina-Rodriguez, Narseo (2026): "Bridges to Self: Silent Web-to-App Tracking on Mobile via Localhost", in: Proceedings of the USENIX Security Symposium. (Link)

You could leave a comment if you were logged in.

Measure The Web

Table of Contents