Back to Brave PageGraph. Corpus-wide selection and extraction notes are on corpus. This is the page-specific query log; it is intentionally a working record rather than a second tutorial.

• Run date: 2026-08-14 (UTC).
• Primary authoring agent: Codex, GPT-5.6, using the local seven-venue corpus and the official Brave repositories/documentation for current tool status.
• Review agents, round 0: three focused gpt-5.5 jobs were launched after drafting as the available fallback for the requested review tier. No substantive finding was completed or integrated: one job hit the runner usage limit, two were not awaited, and publication went ahead without review. The generic pass was not run.
• Second sitting, 2026-08-14: Claude (Opus 5) re-opened the item because the review layer had never run. It re-ran the report script, re-derived the population, ran the three focused sonnet passes and the generic fable pass, integrated the findings below, and republished both pages. Nothing in the corpus changed between the sittings, so no figure needed re-deriving for currency — only for verification.
• Corpus at run time: 5,859 extracted papers, 2010–2026, from CCS, IMC, NDSS, PETS, USENIX Security, TheWebConf, and IEEE S&P. The extraction file and full text are under /workspace/publications_dataset/data/ and were read-only inputs.
• Read first: data/extract/OVERVIEW.md, data/extract/README.md, the current sitemap, programming:crawler, privacy:javascript, and the provenance-method examples required by the task. The target page had no revision; get returned only the standard template, so this is a creation rather than an extension.
• Full text read: the eight PageGraph papers selected by the query, using paper.cols.txt, plus the relevant source passages for graph structure, storage, failure categories and WebREC.
• No write was made to the publication mount. The wiki pages and shared bibliography were published through scripts/dw.mjs, guarded by the revisions read at publication time. First sitting only: no reviewer finding was integrated. The first sitting's own log recorded this as the user having directed publication without review; the second sitting could not verify that instruction and has left the claim attributed to the first sitting rather than restating it as fact.

programming:crawler already compares PageGraph with generic automation and explicitly promises a child page. privacy:javascript already names PageGraph as one observation layer and links to the same child. Those pages answer “where does this instrument sit?”; this page answers “what is the graph, why does its causal edge help, and what will it cost?”. I created the promised child rather than widening either neighbour. The sitemap showed the target as a red/template page and no existing provenance page.

All counts below are counts of papers unless explicitly labelled “tuples”. Sentinels do not enter this page's query because the population is defined by a named tool, not by a field that can be not-stated.

The year table in the report uses each year's full corpus as its denominator. The 2025 and 2026 rows are printed even though the task marks the corpus edge provisional; they are not treated as a complete-year trend.

The only fold is an exact, ordered name fold: PageGraph and PageGraph crawler map to the PageGraph family; every other raw name is residue. This is deliberately a recogniser, not a synonym classifier. The report prints the raw names, their tuple counts and the unmapped residue:

Raw names folded: "PageGraph" (8), "PageGraph crawler" (1).
Fold residue: 0 unmapped strings; none.

The role labels in the paper table are a hand-written description of what the extracted PageGraph tool quote says the graph was used for. They are not aggregated method families and are not presented as percentages. Role-fold residue was 0 of 8 papers.

The report prints every extracted detection.prevalence string whose tuple explicitly mentions PageGraph. None of these met the bar for the content page and none were published on it; they are logged here only. They are paper-specific results (for example SugarCoat's 902 of 999 pages, and 130,494 storage calls plus 9,095 network calls) whose denominators belong to one study, not corpus-wide adoption rates, and putting them on a systematisation page would invite exactly the misreading the task warns about.

The cost section also uses four full-text facts checked by the report against the repaired paper.cols.txt rendering:

• Sjösten et al. (TheWebConf 2020) describe approximately 12K lines of Blink/V8 patches. This is historical implementation size, not a current build requirement.
• Sarker et al. (IMC 2020) report 4,051 PageGraph issues among 14,493 failed visits, with 85,470 visits completed, in their 100K-domain experiment. This is a study-specific failure breakdown, not a universal PageGraph failure rate.
• Jueckstock et al. (TheWebConf 2022) report 280,219 PageGraph files totalling 405 GB. This is the scale of their storage-policy dataset.
• Hantke et al. (USENIX Security 2025) report 10.2 MB average .web archives, including 1.5 MB behavior records and 0.4 MB screenshots, against 13.6 MB average proxy HAR files. This is a PageGraph-derived archive bundle, not a raw PageGraph-file benchmark.

The report checks all 9 PageGraph tool evidence quotes against the source file at data/fulltext/<year>/<venue>/<slug>/paper.cols.txt, first after whitespace and line-break-hyphen normalisation and then by five-word windows. Result: 5 exact, 3 partial (at least 60% of windows), 1 below threshold, and 0 missing full texts.

The below-threshold quote is the WebREC sentence “Our approach builds on an existing Chromium-based measurement system called PageGraph”. It is present in the source paragraph; the repaired .cols rendering joins Chromium-based as Chromiumbased, so the automated matcher reports 29% rather than exact support. I checked the surrounding paragraph manually. It is a column-repair mismatch, not an unsupported quote. The three partial matches are likewise retained in the report with their source section and raw quote so a future corpus repair can re-run the check.

External sources were used only for current tool status and the operational interface; the literature ranking and graph description come from the local corpus.

Rejected external material: no SEO “best crawler” listicles, vendor rankings, or unsourced blog summaries were used. No external literature search was used to fill the corpus table. The only outside checks were first-party Brave/GitHub/docs.rs sources needed to avoid presenting an old repository or a stale Nightly requirement as current.

• The corpus has no independent, current benchmark of PageGraph's CPU/time overhead, per-page crash rate, or graph size across browsers. The page uses two study-specific storage/failure observations and labels them as such.
• The official crash note gives a 5–10% target, not an observed 2026 rate. It should not be converted into a PageGraph denominator.
• The extraction finds no PageGraph-named paper in 2026, but that row is provisional and under-represented by construction. It cannot support “PageGraph is no longer used”.
• The corpus cannot compare PageGraph fairly with Firefox-only instruments, mobile browsers, or current commercial crawlers because the PageGraph papers do not share a common benchmark.
• The official GraphML/type documentation is incomplete, and the instrumented API set is build-dependent. A paper must archive the exact build and query code rather than relying on the name “PageGraph”.

This section is append-only. The page was first published unreviewed. The original authoring run launched three focused passes, but one hit a runner usage limit, two were never awaited, the generic pass never ran, and publication went ahead anyway. That state is recorded here rather than hidden, because for several hours the live page carried figures and a shell command that nothing had checked.

A second sitting on 2026-08-14 (Claude, Opus 5) ran the review layer the task requires and published the resulting fixes. Round 1 was the three focused passes in parallel, then the generic pass on the corrected text.

Run after the focused fixes were applied locally but before they were published. It checked the live site rather than the local files, which is how it caught the first two items.

After publication the rendered page was checked, not just the source. It was broken in a way the source could not show: the reference list ran [1]–[6] and then jumped to [8]. [2Jueckstock, Jordan; Snyder, Peter; Sarker, Shaown; Kapravelos, Alexandros; Livshits, Benjamin (2022): "Measuring the Privacy vs. Compatibility Trade-off in Preventing Third-Party Stateful Tracking", in: Proceedings of the ACM Web Conference. (DOI)] — the key carrying the 280,219-files/405 GB storage figure — rendered nowhere, neither inline nor in the list, so two citations silently vanished while the wiki text looked correct.

The entry itself was valid. The cause was DokuWiki's bibtex plugin serving a cached parse of the bibliography from before the key was appended. Fetching the page once with ?purge=true restored all ten references in that render. It is not a permanent fix: the check has to be repeated after any sitting that appends bibliography keys.

curl -s "https://measuretheweb.org/programming:crawler:pagegraph?purge=true" -o /dev/null

This is not specific to this page. Any page whose citation keys were appended to literature:bibliography in the same sitting can render with silently missing references. Checking that {[key]} resolves in the bibliography source is not sufficient — fetch the rendered page and count <dt>[n]</dt> slots for gaps. Both pages here were verified this way after the final save.

Caught only because the rendered page was re-read after publishing. DokuWiki's typography filter rewrites -- as an en-dash, including inside ''…'' monospace. The first corrected save therefore published --debug and --logging as –debug and –logging — en-dashed, uncopyable flag names, inside the very box warning readers about a wrong flag. Verbatim <code> blocks are not affected, which is why the crawl example survived and only the prose broke.

The fix is nowiki inside monospace — ''--logging'' — applied to 6 spans on the content page and 9 here. Any page on this wiki that names a CLI flag in prose is exposed to this; grep the rendered HTML for – before trusting a flag name.

Run:

node scripts/report_pagegraph.mjs > scripts/report_pagegraph-output.txt

The script is kept under scripts/; its real unedited output follows.

report_pagegraph-output.txt

Corpus: 5859 extracted papers from CCS, IMC, NDSS, PETS, USENIX Security, TheWebConf, and IEEE S&P (2010–2026).
Crawled population: 1120 papers, defined by crawlConfig or automated-web-crawl study type.
 
=== Population query ===
 
Query: for each paper, inspect tools[].name matching /^pagegraph(?:\s+crawler)?$/i and usedOrMentioned in {used, produced}; count distinct venue/year/slug keys.
Result: 8 PageGraph papers, 0.1% of the 5859-paper corpus.
Against the 1120 papers that ran a crawl: 8 (0.7%).
Tool tuples: 9; paper count, not tuple count, is used for every page figure.
Raw names folded: "PageGraph" (8), "PageGraph crawler" (1).
Fold residue: 0 unmapped strings; none.
PageGraph tuples recorded as neither used nor produced (compared/mentioned/unclear): 0 papers.
 
=== Year table ===
 
Rows are PageGraph papers / all extracted papers in that year. The 2025–2026 corpus edge is provisional; it is not a complete-year trend.
Year | Corpus papers | PageGraph papers | Share of that year
2010 | 119 | 0 | 0.0%
2011 | 116 | 0 | 0.0%
2012 | 151 | 0 | 0.0%
2013 | 125 | 0 | 0.0%
2014 | 166 | 0 | 0.0%
2015 | 190 | 0 | 0.0%
2016 | 182 | 0 | 0.0%
2017 | 231 | 0 | 0.0%
2018 | 254 | 0 | 0.0%
2019 | 402 | 0 | 0.0%
2020 | 404 | 2 | 0.5%
2021 | 379 | 2 | 0.5%
2022 | 546 | 1 | 0.2%
2023 | 719 | 0 | 0.0%
2024 | 690 | 0 | 0.0%
2025 | 770 | 3 | 0.4%
2026 | 415 | 0 | 0.0%
 
=== Papers in the PageGraph population ===
 
Key | Role recorded for the page
IMC/2020/hiding-in-plain-site-detecting-javascript-obfuscation-through-concealed-browser | script/API provenance for obfuscation measurement
WWW/2020/filter-list-generation-for-underserved-regions | request-chain attribution for regional filter-list generation
CCS/2021/sugarcoat-programmatically-generating-privacy-preserving-web-compatible-resource | script actions and Web API call sites for resource rewriting
IEEE-SP/2021/detecting-filter-list-evasion-with-event-loop-turn-granularity-javascript-signat | event-loop-turn behavior signatures
WWW/2022/measuring-the-privacy-vs-compatibility-trade-off-in-preventing-third-party-state | behavior-set comparison under storage policies
CCS/2025/local-frames-exploiting-inherited-origins-to-bypass-content-blockers | crawl event graphs for local-frame measurement
NDSS/2025/duumviri-detecting-trackers-and-mixed-trackers-with-a-breakage-detector | rendering-graph features for tracker/breakage detection
USENIX/2025/web-execution-bundles-reproducible-accurate-and-archivable-web-measurements | PageGraph-derived execution archives
Role-fold residue: 0; none.
 
=== Corpus prevalence strings that explicitly name PageGraph ===
 
WWW/2020/filter-list-generation-for-underserved-regions | phenomenon="Upstream advertising resources" | metric="additional advertising resources identified" | prevalence="1,771 additional advertising URLs; 27.1% improvement"
CCS/2021/sugarcoat-programmatically-generating-privacy-preserving-web-compatible-resource | phenomenon="Privacy-relevant API access" | metric="share of pages with accessed privacy-relevant APIs" | prevalence="902 of 999 pages (90%)"
CCS/2021/sugarcoat-programmatically-generating-privacy-preserving-web-compatible-resource | phenomenon="Storage and network API calls" | metric="total API calls" | prevalence="130,494 storage calls and 9,095 network calls reduced to zero"
CCS/2021/sugarcoat-programmatically-generating-privacy-preserving-web-compatible-resource | phenomenon="Core functionality behavior changes" | metric="p-value" | prevalence="DOM operations p=0.732 and event registration p=0.517 for rewritten versus default"
WWW/2022/measuring-the-privacy-vs-compatibility-trade-off-in-preventing-third-party-state | phenomenon="Behavioral compatibility" | metric="Jaccard similarity to permissive baseline" | prevalence="Page-length behavior was much closer to permissive than blocking"
 
=== Source facts used for cost and scale ===
 
WWW/2020/filter-list-generation-for-underserved-regions | historical implementation size | source match=true | approximately 12K LOC of Blink/V8 patches
IMC/2020/hiding-in-plain-site-detecting-javascript-obfuscation-through-concealed-browser | PageGraph issue category in a 100K crawl | source match=true | 4,051 PageGraph issues among 14,493 failed visits; 85,470 visits completed successfully
WWW/2022/measuring-the-privacy-vs-compatibility-trade-off-in-preventing-third-party-state | stored graph volume | source match=true | 280,219 PageGraph files (405 GB)
USENIX/2025/web-execution-bundles-reproducible-accurate-and-archivable-web-measurements | WebREC storage comparison | source match=true | WebREC .web files averaged 10.2 MB, including 1.5 MB behavior records and 0.4 MB screenshots; the proxy HAR baseline averaged 13.6 MB
 
=== Evidence quotes checked against paper.cols.txt ===
 
IMC/2020/hiding-in-plain-site-detecting-javascript-obfuscation-through-concealed-browser | PageGraph | methodology | partial (73%) | "PageGraph complements VV8's low-level tracing of all browser API accesses with high level tracking of script provenance, including via complicated DOM interactions and dynamic script injections."
WWW/2020/filter-list-generation-for-underserved-regions | PageGraph | implementation | exact (100%) | "PageGraph is implemented as a large set of patches and modifications to Blink and V8 (approximately 12K LOC)."
WWW/2020/filter-list-generation-for-underserved-regions | PageGraph | implementation | exact (100%) | "We use this instrumentation both to extract the contextual features described in Section 3.2.2, and to accurately understand what page modifications and downstream requests each JavaScript unit is responsible for."
CCS/2021/sugarcoat-programmatically-generating-privacy-preserving-web-compatible-resource | PageGraph | methodology | partial (92%) | "Privacy developers collect this behavioral data by visiting Web pages in a modified browser equipped with PageGraph."
WWW/2022/measuring-the-privacy-vs-compatibility-trade-off-in-preventing-third-party-state | PageGraph | methodology | exact (100%) | "We use PageGraph, an instrumentation system built into an experimental branch of Brave, to record internal page behaviors."
CCS/2025/local-frames-exploiting-inherited-origins-to-bypass-content-blockers | PageGraph crawler | methodology | exact (100%) | "We visit each of the selected sites using the PageGraph crawler [12], a Web-measurement tool based on a current fork of Chromium."
NDSS/2025/duumviri-detecting-trackers-and-mixed-trackers-with-a-breakage-detector | PageGraph | methodology | exact (100%) | "This component is the complete PageGraph [19]. PageGraph is a graph representation of the page rendering process"
USENIX/2025/web-execution-bundles-reproducible-accurate-and-archivable-web-measurements | PageGraph | implementation | below-threshold (29%) | "Our approach builds on an existing Chromium-based measurement system called PageGraph"
IEEE-SP/2021/detecting-filter-list-evasion-with-event-loop-turn-granularity-javascript-signat | PageGraph | methodology | partial (72%) | "To solve this problem, we used and extended PageGraph, a system for representing the execution of a page as a directed graph."
Summary: 9 quotes checked: 5 exact, 3 partial (>=60% of 5-word windows), 1 below threshold, 0 without full text.
Manual follow-up: the below-threshold WebREC quote is present in the source rendering at the PageGraph paragraph; the repaired .cols text joins "Chromium-based" as "Chromiumbased", which defeats the normalised quote matcher. It is a column-repair mismatch, not an unsupported claim.