PageGraph is a page-execution recorder, not a browser automation library and not a graph-neural-network classifier. It patches Brave's Blink and V8 engines so that the browser records a directed, attributed graph of what happened while a page ran: which parser, script, DOM element, frame, resource, or Web API action caused the next event. The practical entry point is pagegraph-crawl, and the output is normally queried after the crawl with pagegraph-query. PageGraph extends the graph representation introduced by AdGraph [1Iqbal, Umar; Snyder, Peter; Zhu, Shitong; Livshits, Benjamin; Qian, Zhiyun; Shafiq, Zubair (2020): "AdGraph: A Graph-Based Approach to Ad and Tracker Blocking", in: 2020 IEEE Symposium on Security and Privacy (SP), pp. 763-776. (DOI)], improving event attribution and capturing more page behaviours [2Siby, Sandra; Iqbal, Umar; Englehardt, Steven; Shafiq, Zubair; Troncoso, Carmela (2022): "WebGraph: Capturing Advertising and Tracking Information Flows for Robust Blocking", in: 31st USENIX Security Symposium (USENIX Security 22), pp. 2875-2892. USENIX Association, Boston, MA. (Link)], and it is the branch of that line that is still maintained; Javascript is the place for the classification questions that sit on top of this trace.

The unit to keep in mind is an actor–action–actee triple. A script is an actor; a DOM insertion, storage access, or request is an action; the inserted element, storage/API node, or network resource is the actee. The exact node and action vocabulary depends on the Brave build and the APIs enabled in it, so record that configuration with the graph.

The original PageGraph description gives the useful concrete cases: a script-to-element edge can mean “this script changed the element”, and an element-to-resource edge can mean “this element's src caused the fetch” [3Sjösten, Alexander; Snyder, Peter; Pastor, Antonio; Papadopoulos, Panagiotis; Livshits, Benjamin (2020): "Filter List Generation for Underserved Regions", in: Proceedings of the ACM Web Conference. (DOI)]. SugarCoat's extension makes the model especially clear for privacy work: it records the scripts on the JavaScript stack at a Web API access, the source location of each, and then traverses insertion and execution edges to find scripts injected downstream [4Smith, Michael; Snyder, Peter; Livshits, Benjamin; Stefan, Deian (2021): "SugarCoat: Programmatically Generating Privacy-Preserving, Web-Compatible Resource Replacements for Content Blocking", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)]. The event-loop-turn work uses the ordering metadata to extract a subgraph for one script's deterministic activity, rather than treating the whole page as one undifferentiated trace [5Chen, Quan; Snyder, Peter; Livshits, Ben; Kapravelos, Alexandros (2021): "Detecting Filter List Evasion with Event-Loop-Turn Granularity JavaScript Signatures", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)].

In a simple dependency chain, the graph can retain something like:

HTML parser -> script A -> inserted script element -> script B
script B -> inserted image element -> image request to C

That is the distinction from a table of requests. The table tells you that C was requested; the graph lets you ask which element, script and upstream insertion led to it, and whether the request arose in a child frame. PageGraph's current documentation lists script execution, most resource requests, DOM changes, Shields/filter-rule effects, timestamps, remote frames, and GraphML export as supported features.¹⁾

Request-level measurement tends to start at the wrong end of the causal chain. A URL, a timestamp, a response, or even a referrer does not reliably say which code unit caused the browser to make the request: referrer policy can change the referrer, and the request may have been made by a DOM element that a different script inserted. The WebREC paper demonstrates the practical consequence: understanding third-party requests requires on-page activities, because a basic request record otherwise has to infer initiators with heuristics [6Hantke, Florian; Snyder, Peter; Haddadi, Hamed; Stock, Ben (2025): "Web Execution Bundles: Reproducible, Accurate, and Archivable Web Measurements", in: Proceedings of the USENIX Security Symposium. (Link)].

PageGraph moves the observation point into the renderer. It connects:

• the parser or script that created an element;
• the element or script that triggered a resource request;
• the script stack and source location at a Web API access; and
• the upstream chain that brought a script, frame, or resource into the page.

This is why the 2020 PageGraph paper reports better attribution than its AdGraph predecessor for cases such as JavaScript in an element attribute (onerror=…) and timer callbacks that reset the ordinary JavaScript stack [3Sjösten, Alexander; Snyder, Peter; Pastor, Antonio; Papadopoulos, Panagiotis; Livshits, Benjamin (2020): "Filter List Generation for Underserved Regions", in: Proceedings of the ACM Web Conference. (DOI)]. It also broadens the observed event set to include, among other examples, image requests initiated by CSS or prefetch, modifications in local subdocuments, and failed requests [3Sjösten, Alexander; Snyder, Peter; Pastor, Antonio; Papadopoulos, Panagiotis; Livshits, Benjamin (2020): "Filter List Generation for Underserved Regions", in: Proceedings of the ACM Web Conference. (DOI)]. The 2025 Local Frames crawl describes the current measurement-facing output in the same terms: salient events plus the HTML element or JavaScript unit responsible for each event, one graph per measured website [7Ukani, Alisha; Haddadi, Hamed; Snoeren, Alex C.; Snyder, Peter (2025): "Local Frames: Exploiting Inherited Origins to Bypass Content Blockers", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security, pp. 1349-1363. (DOI)].

The graph does not prove that an actor intended a purpose, nor does it follow arbitrary values through JavaScript variables. A script can be the causal actor for a request without the graph telling you whether the request carried an identifier. For tracking classification, combine the graph with a filter list, a label source, or manual review, and state which of those supplied the label. For data-flow questions, use a taint-tracking instrument instead.

PageGraph is included in Brave builds from version 1.46 onward, but it is off unless the browser is launched with the right command-line arguments. Brave's wiki does not enumerate them and instead directs you to pagegraph-crawl, which sets them for you — so in practice you only need the flags if you are launching Brave yourself. Recording built-in JavaScript APIs requires a Brave Nightly build, because the stable/beta builds omit that instrumentation for performance reasons; which Web APIs are instrumented is fixed at build time by a interface.py file, and adding more means rebuilding Brave.²⁾ Do not silently substitute “Brave” for “PageGraph”: report the exact browser channel and build, and which API set was enabled.

The usable pieces are:

The minimal crawl shape documented by pagegraph-crawl is:

npm install
npm run build
npm run crawl -- \
  -b /path/to/Brave\ Browser\ Nightly \
  -u https://example.org \
  -t 30 \
  -o output/ --logging verbose

The -t value is the dwell time in seconds and is a measurement decision, not a harmless default: a short visit sees a different execution path from a visit that waits for consent interaction, scroll, login, or delayed work. The crawler repository's warning is important for study design: PageGraph does not track Puppeteer/DevTools automation scripts, and changing the document through that automation while recording can fail.³⁾ If the research question requires scripted interaction, document exactly when it happened, test whether the resulting graph remains valid, and report the interaction itself separately from page-caused events.

PageGraph's price is a patched browser, a larger recording, and a version-maintenance obligation.

• Engineering and browser drift. The first corpus description reported approximately 12K lines of Blink/V8 patches [3Sjösten, Alexander; Snyder, Peter; Pastor, Antonio; Papadopoulos, Panagiotis; Livshits, Benjamin (2020): "Filter List Generation for Underserved Regions", in: Proceedings of the ACM Web Conference. (DOI)]. Those patches are now carried in Brave, which removes the need to maintain a private fork for a basic run, but it does not remove Chromium/Brave version drift. Extending the instrumented API set can still require a rebuild. The graph format itself is under-documented: Brave's wiki says of the type documentation it points to that it “is incomplete and being built up as we go”, and the page it points to belongs to the now-archived pagegraph-rust.⁴⁾ Budget time for reading GraphML output rather than a specification.
• Storage. In the 2022 storage-policy study, 280,219 PageGraph files occupied 405 GB [8Jueckstock, 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)]. A later PageGraph-derived archive, WebREC, reports 10.2 MB per .web archive on average, of which 1.5 MB was behavior data and 0.4 MB a screenshot; its proxy-HAR comparison averaged 13.6 MB [6Hantke, Florian; Snyder, Peter; Haddadi, Hamed; Stock, Ben (2025): "Web Execution Bundles: Reproducible, Accurate, and Archivable Web Measurements", in: Proceedings of the USENIX Security Symposium. (Link)]. The latter is an archive bundle, not a raw PageGraph-file benchmark, but it is a useful planning scale.
• Crashes and incomplete pages. In the 2020 Alexa-100K experiment, the PageGraph issue category accounted for 4,051 of 14,493 failed visits; 85,470 visits completed successfully [9Sarker, Shaown; Jueckstock, Jordan; Kapravelos, Alexandros (2020): "Hiding in Plain Site: Detecting JavaScript Obfuscation through Concealed Browser API Usage", in: Proceedings of the ACM Internet Measurement Conference. (DOI)]. That is a study-specific failure breakdown, not a current universal failure rate. Brave's documentation explicitly prefers crashing over writing an uncertain graph and gives a 5–10% target for crash rate on real sites; treat that as a design goal, not as a measured guarantee.⁵⁾ Count attempted, valid, invalid, timed-out, and retried pages separately.
• Runtime and analysis cost — no published benchmark. The graph is built during browser execution, then parsed and indexed. Neither the corpus nor Brave's documentation gives a current per-page slowdown figure, a crash rate measured in 2026, or a graph-size distribution, so pilot a few hundred pages on your own hardware before committing to a population size; do not budget from the numbers below, which are all study-specific. A post-hoc query is cheap compared with a second crawl, but retaining every graph, source file and response can dominate storage. Compress only after validating that the query tool can still read the result, and retain the browser build and query version beside the archive.

The official “Known Limitations” list had nine entries when checked on 2026-08-14, and it is worth reading in full rather than trusting this summary: no WebSocket tracking, no worker tracking, request headers not recorded (response headers are), no CSS style= attribution, some JavaScript URLs unhandled, no attribution of requests caused by CSS rules, no tracking of CSS @import, incomplete HSTS/URL-change handling, and large streamed request bodies not recorded.⁶⁾ WebREC found and reported a PageGraph limitation around event handlers inside SVG elements, later addressed upstream [6Hantke, Florian; Snyder, Peter; Haddadi, Hamed; Stock, Ben (2025): "Web Execution Bundles: Reproducible, Accurate, and Archivable Web Measurements", in: Proceedings of the USENIX Security Symposium. (Link)]; keep a versioned regression test for any event class your result depends on.

The extraction finds 8 papers that used or produced PageGraph, out of the 1,120 papers that ran a crawl in the corpus (0.7%). It finds 9 tool tuples because one paper records PageGraph twice; every figure here counts papers. The corpus is the seven venues listed on corpus, not the whole web-measurement literature.

The starred years are provisional: 2025 is thin at the edges and 2026 is incomplete by construction. Do not read the zero in 2026 as evidence that PageGraph stopped being used. The 2025 entries are the useful currency signal in this corpus: three papers use it for a crawl, a breakage/tracker detector, or a reproducible execution archive. The corpus supports “PageGraph is current and still being used”; it does not support a claim that it is the dominant crawler.

The historical ordering matters. AdGraph and WebGraph are useful baselines for graph-derived blocking, but their classifier results are not a current PageGraph installation recipe. For a new measurement, read Sjösten for the attribution problem, Chen for extracting stable behavior units, SugarCoat for script/API graph queries, and Hantke for the current archive and maintenance argument. Then read Jueckstock if your outcome is storage policy or compatibility rather than tracker prevalence.

At minimum, report:

• the Brave/Chromium channel, exact version or commit, operating system and architecture, and whether Nightly was required for the API set;
• the PageGraph build/configuration, enabled Web APIs, GraphML/query-tool version, and the validation result for every graph retained;
• the population list and snapshot, visit duration, navigation/consent/authentication actions, headful/headless mode, user-agent and vantage point, cache/storage profile, and retry/timeout policy;
• counts of attempted, completed, invalid/crashed, timed-out and discarded pages, with reasons; never silently drop a PageGraph issue;
• the Brave Shields / filter-list state during the crawl, and whether filter-rule effect edges were counted or excluded — this changes what “the page did” means and is the easiest way to make a prevalence figure incomparable;
• the graph unit you count (script code unit, resource, frame, action, event-loop-turn, or page), and whether a paper can contribute more than one unit;
• the attribution rule and its unknown cases: parser-caused, script-caused, cross-frame, CSS-caused, or unassigned; and
• the filter-list/database/manual source used for labels, its version/date, the validation sample, and the query code or enough GraphML examples to reproduce the classification.

If the result is a prevalence claim, keep the denominator at the same unit as the graph query: “sites with at least one matching script” is not “requests”, “actions”, or “graphs”. If the result is a script-classification claim, say whether PageGraph supplied only provenance or also the label. The graph is an instrumented observation of the executed path, not a census of code that could execute.

• The audit script is scripts/report_pagegraph.mjs; its unedited output, every query, every paper key, the fold residue, source-fact checks, and quote checks are on the provenance page. Corpus-wide selection and extraction caveats are on corpus.
• The population query folds only the two raw tool names PageGraph and PageGraph crawler with an ordered exact regex. It counts used and produced tool tuples, then deduplicates by paper. The unmapped residue is empty in this run and is printed as empty rather than hidden.
• The 2025–2026 rows are provisional, and the seven-venue corpus omits EuroS&P, ACSAC, RAID, AsiaCCS, CHI and SOUPS. The table is a finding about this corpus, not an adoption survey.
• Nine PageGraph evidence quotes were checked against paper.cols.txt: 5 exact, 3 partial after the dataset's five-word-window check, and 1 below threshold. The one below-threshold quote was manually confirmed; a column-repair hyphenation joined “Chromium-based” in the source rendering.

• Javascript — classifying the JavaScript that the graph observes.
• Requests — request-level filter lists and their attribution limits.
• Crawler — generic automation and other specialised crawlers.
• OpenWPM — in-page instrumentation through an unbranded Firefox.
• Traffic files — capture and archive formats that PageGraph-derived graphs can complement.

[1]

Iqbal, Umar; Snyder, Peter; Zhu, Shitong; Livshits, Benjamin; Qian, Zhiyun; Shafiq, Zubair (2020): "AdGraph: A Graph-Based Approach to Ad and Tracker Blocking", in: 2020 IEEE Symposium on Security and Privacy (SP), pp. 763-776. (DOI)

[2]

Siby, Sandra; Iqbal, Umar; Englehardt, Steven; Shafiq, Zubair; Troncoso, Carmela (2022): "WebGraph: Capturing Advertising and Tracking Information Flows for Robust Blocking", in: 31st USENIX Security Symposium (USENIX Security 22), pp. 2875-2892. USENIX Association, Boston, MA. (Link)

[3]

Sjösten, Alexander; Snyder, Peter; Pastor, Antonio; Papadopoulos, Panagiotis; Livshits, Benjamin (2020): "Filter List Generation for Underserved Regions", in: Proceedings of the ACM Web Conference. (DOI)

[4]

Smith, Michael; Snyder, Peter; Livshits, Benjamin; Stefan, Deian (2021): "SugarCoat: Programmatically Generating Privacy-Preserving, Web-Compatible Resource Replacements for Content Blocking", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)

[5]

Chen, Quan; Snyder, Peter; Livshits, Ben; Kapravelos, Alexandros (2021): "Detecting Filter List Evasion with Event-Loop-Turn Granularity JavaScript Signatures", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)

[6]

Hantke, Florian; Snyder, Peter; Haddadi, Hamed; Stock, Ben (2025): "Web Execution Bundles: Reproducible, Accurate, and Archivable Web Measurements", in: Proceedings of the USENIX Security Symposium. (Link)

[7]

Ukani, Alisha; Haddadi, Hamed; Snoeren, Alex C.; Snyder, Peter (2025): "Local Frames: Exploiting Inherited Origins to Bypass Content Blockers", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security, pp. 1349-1363. (DOI)

[8]

Jueckstock, 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)

[9]

Sarker, Shaown; Jueckstock, Jordan; Kapravelos, Alexandros (2020): "Hiding in Plain Site: Detecting JavaScript Obfuscation through Concealed Browser API Usage", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[10]

Shuang, He; Zhao, Lianying; Lie, David (2025): "Duumviri: Detecting Trackers and Mixed Trackers with a Breakage Detector", in: Proceedings of the Network and Distributed System Security Symposium. (Link)