Known-service catalog and validation fixtures

Search the service catalog

This is the effective catalog used for report labels. It is maintained in-repository and does not import a competitor tracker dataset. Functional categories are review prompts, not privacy grades.

Reference scope: an official page identifies the named entity or product only. It is not presented as a citation for every suffix or as support for the maintainer-assigned category. The mapping and category remain reviewable project assertions; report evidence should always be checked in context.

Catalog hand-curated-2026.08 · provenance catalog-review-v3 · effective digest e94970de235fc80254de8ed99b94316a252e52aa1c2e748c8fbfc3c093b908f4 · provenance digest a2ad26d212fdb7a8c6812b95967e017a95f8506acae0329cebe7ebcfe26acbae

Detector validation fixture coverage

The matrix below is generated from exact, source-controlled cases in the repository test suite: one positive, one negative, and one adversarial or failure-boundary case for every detector. 5 selected cases run in real Chromium; the others test deterministic detector logic.

This is an acceptance-fixture inventory, not a representative labeled web corpus. It does not support a precision, recall, accuracy, or “all trackers detected” claim. The limitations shown for each detector remain part of the result even when every fixture passes.

Calibration status: committed studies exist, but none is eligible against this exact release. The repository contains 1 committed calibration study, of which 0 are eligible under the current release identity, carrying 0 eligible labeled cases; a further 15 labeled cases in ineligible studies support no rate. Eligibility is re-derived on every build against the exact current release identity, so a study bound to an earlier build, catalog, or filter-list revision demotes itself automatically. A preselected, release-bound, independently labeled case corpus with a declared sampling frame, immutable artifacts, and complete planned denominator is still required.

The published detector-calibration-study.v3 JSON Schema keeps acceptance fixtures outside the calibration denominator. Eligibility requires the exact build commit, detector implementation and registry digests, methodology, normalization, tracker-catalog revision, Brave-list revision, and an independently pinned runtime-identity digest. Every complete case requires immutable prediction, evidence, and label artifacts plus at least two distinct labeler ids and an independent precommitted blind-tiebreaker identity.

Matrix detector-fixture-matrix-v1 · registry node-detectors-v6 · digest f348b52b2573b10d5eb9e651480ae591b69a245a087cd02d45c7051e3dfb129b · build 2e207cdbc60ef9e74a18d16996126c9e5043bc3d

What this scanner does not measure

Coverage is only a meaningful claim if its edges are stated. These are the privacy-relevant things a report never rules out, so a quiet report is not read as an all-clear. The list is grouped by why each one is absent, because a surface we have not built is a different fact from one we decline to build and from one no page visit can see.

10 of these 20 entries are enforced against the scanner source by a test: if that surface is ever instrumented, the build fails until this page is corrected. The rest rely on review, and are marked accordingly.

Boundary coverage-boundary-v1