Methodology
How a scan works
Every report is built from one or two controlled, automated browser visits, and every number in it is an observation from those visits, not a general claim about the site. This page describes the measurement: what the visit does, what is recorded, and where the honest limits are. Terms are defined in the glossary; how scan data is handled is on the privacy page.
The visit
The scanner loads the page in a headless Chromium browser with a fixed profile: en-US locale, UTC timezone, a desktop or mobile viewport, and a disclosed egress network. It does not scroll, click, or log in, with exactly two bounded exceptions described below. The visit ends after a capped duration, and the report records the scan conditions (browser version, viewport, timezone, locale, GPC state, catalog version, egress) so the result is reproducible for that configuration. Sites can behave differently for real users, regions, accounts, or network locations, so results are evidence to check, not a verdict.
The scanner never disguises itself: it is an honest automated browser. Sites that block automation are reported as failed loads rather than being scanned through evasion, because a report gathered under a disguised identity would misdescribe its own conditions.
What is recorded
- Network requests (URL, domain, method, resource type, status), classified first/third party.
- Curated service labels from a hand-maintained, US-biased catalog of recognizable services.
- Cookies and local/session storage keys as an end-of-visit snapshot (values redacted).
- High-entropy browser API calls and behavioral fingerprinting heuristics (canvas, WebGL, audio, WebRTC, listener coverage).
- Advertising-pixel events (Meta, TikTok, X) and whether their identifier fields carried values.
- DNS CNAME-uncloaking of first-party subdomains that alias to known trackers.
- A privacy-policy cross-check: the site's own policy text compared against the observed evidence.
Counts are lower bounds. Activity inside Web or Service Workers and WebSocket traffic is not observed, storage keys are read from the top frame only, and trackers that load only after interaction or consent are not seen by a passive visit.
The two bounded interactions
First, the input probe: the scanner types a synthetic, non-personal test value into up to a handful of visible form fields, never submits, and watches whether that value leaves to a third party in plain, encoded, or hashed form. Second, in consent comparison mode only, the scanner clicks one accept-all or reject-all control on the cookie banner's first layer (known consent-platform controls first, then a conservative whole-label match). Every report discloses exactly what was typed into or clicked, or that nothing was.
A consent click is dispatched, not verified: the scanner clicks the control but cannot assume the site registered the choice, and each visit's recording covers traffic from before and after its click. Report wording never attributes traffic to the choice for that reason. When the registered-state readback is enabled on a deployment, the scanner additionally reads the site's consent-platform state (and may reload the page once, disclosed in the report, with the requests observed during that reload phase excluded from the counts) so a future report generation can distinguish a dispatched click from a registered choice.
Comparisons
A comparison is two sequential visits that differ in one declared condition: Global Privacy Control off versus on, no blocking versus Brave-list block simulation, or an accept-all versus reject-all consent click. The two visits run in randomized (counterbalanced) order so time-ordered site behavior cannot load systematically onto one arm, and each report discloses which visit ran first. Before any comparative wording is used, an eligibility gate checks that both visits completed, hit no recording caps, and held the non-compared conditions constant; ineligible pairs render as two independent visits with the reasons stated. Differences between two visits can still reflect timing, experiments, caching, consent state, or bot detection, so comparison wording stays descriptive: it reports what differed between the visits, never that the compared setting caused the difference.
The Brave-list blocking simulation
Blocking evidence uses Brave's own ad-block engine (the open-source adblock-rust crate compiled to WebAssembly) with the default-enabled Brave Shields filter lists, vendored as a pinned snapshot. Matching requests are aborted in this scanner's browser: a simulation of Brave's default list blocking, not a live Brave-browser visit. Each request is matched with its actual HTTP method against the document that initiated it, network rules only (no cosmetic rules). Blocked counts are a close lower-bound approximation of Brave's default Shields for that page load, and the report separately states filter-list matches, engine-blocked requests, and the total third-party reduction, which are three different measurements.
Publication and redaction
Reports cross a default-deny sanitizer before anything is stored or shared: query strings and fragments are stripped in the browser before a scan is even submitted, and stored reports keep only reviewed, exact literals for paths, query keys, subdomain labels, cookie names, and storage keys, generalizing everything else. Report warnings come from a closed scanner vocabulary, so page-controlled text cannot impersonate the scanner. Shared reports live behind unguessable IDs and expire; reports published into the public corpus are deliberately permanent evidence.
The corpus and percentiles
Findings like "more third-party domains than about 90% of sites scanned so far" rank a report against the measured public corpus: one data point per distinct site, using only fully measured visits (failed and recording-capped visits are excluded from the distributions). The corpus is a curated set of popular sites plus a diversity seed list, not a random sample of the web, and the wording says so. Site history pages compare a site only against its own earlier reports with a compatible method, browser, device, and filter snapshot; retention alone never makes two reports comparable.
Reproducibility
The scanner, catalog, eligibility gates, and report UI are open source (AGPL-3.0-or-later), every report embeds its scan conditions and methodology identity, and the evidence is exportable as sanitized JSON and CSV. The public corpus, its percentile statistics, and the researcher export are regenerated from the same committed report files this site renders, so the numbers cannot disagree with the evidence behind them.