PanoptiChrome is a patch set against V8 that propagates taint through JavaScript objects inside Chromium. A value returned by an instrumented browser API is marked at the point the interpreter produces it, the mark follows the value through explicit flows (assignment) and implicit ones (control dependence), and when a marked value is passed to an instrumented sink the browser appends a line to a log file naming the sink, the origin and the list of source APIs the value came from. It adds “roughly 7,000 lines of code to the existing V8 engine” and confines its changes to V8's Ignition interpreter, which is the design claim the paper is built on: “all the changes are limited to the V8 engine's Ignition module (interpreter part) only” [1Kanyal, Rahul; Sarangi, Smruti R. (2024): "PanoptiChrome: A Modern In-browser Taint Analysis Framework", in: Proceedings of the ACM Web Conference. (DOI)].¹⁾ It is not a crawler and ships no automation layer at all.

It matters for what it is the only public instance of. Project Foxhound tracks taint through strings in Firefox and records explicit flows only; PanoptiChrome keys taint on runtime objects, claims implicit flows as well, and runs in Chromium. If your question genuinely requires any of those three, there is nothing else public and runnable to reach for — but read the next table before assuming your question does.

The paper links its artifacts behind the bare anchor text “here” — four anchors carrying seven distinct URLs, two of them code and five of them result data — which is why the corpus extraction records availability: none-mentioned and codeUrl: null for this paper — the URLs exist only as PDF link annotations, not in the text layer. Recovered from the PDF's /Annots, they all point at one repository: github.com/therahulkanyal/PanoptiChrome, MIT-licensed since February 2025, 10 stars, 5 forks, last pushed 2025-05-05.³⁾

It contains no browser and no build system. It contains this:

The original patch is incomplete, and a third party finished it. panoptichrome_patches.diff contains #include “json.hpp” but does not ship src/json.hpp; it also ships no compiled-in source, sink or WebIDL data. The 2025 “fixed” patch adds exactly those four files — src/json.hpp (+24,766 lines, a vendored nlohmann/json), src/execution/panoptichrome-data/idl_data.hpp (+25,428), sources.hpp (+1,056) and sinks.hpp (+95) — and touches no file the original did not.⁴⁾ eleumasc is Samuele Casarin, an author of the independent evaluation [2Calzavara, Stefano; Casarin, Samuele; Focardi, Riccardo (2025): "Dynamic Security Analysis of JavaScript: Are We There Yet?", in: Proceedings of the ACM Web Conference. (DOI)]. In other words: the only people known to have got this browser to build outside the authors' lab are the people who evaluated it, and the buildable artifact upstream exists because they contributed it back. Their own prebuilt binary was committed on 2024-10-07, seven months before the upstream commit, and their harness sets LOG_DIR — a feature only the completed patch has — so the published evaluation figures were measured on the completed build, not on the broken original. Whether the patch that landed upstream in May is byte-identical to the binary they measured is not established anywhere.

Route 1 — apply the patch to V8 and build Chromium. The README pins the base exactly, which is the one thing this artifact does better than most:⁵⁾

V8 commit:   e29c028f391389a7a60ee37097e3ca9e396d6fa4
V8 version:  11.6.189.2 (cherry-pick)
Chrome:      116.0.5845.78 (stable)

Two things follow. First, the paper and the artifact disagree about the version: the paper says “The crawling process utilizes the latest Chromium browser (version 117.0) compiled with our custom V8 engine (PanoptiChrome)” [1Kanyal, Rahul; Sarangi, Smruti R. (2024): "PanoptiChrome: A Modern In-browser Taint Analysis Framework", in: Proceedings of the ACM Web Conference. (DOI)], and the README pins 116. If your method section needs a version, take it from the patch you actually applied, and say which. Second, M116 reached stable on 2023-08-09; Chrome stable on the day this page was written is 151.0.7922.137.⁶⁾ That is 35 major versions, and it is a measurement-validity problem, not only an engineering one: the browser announces itself as Chrome 116 in its user agent, three years of Blink features are absent, and a site that serves modern Chrome a different code path will serve you the fallback.

Route 2 — take the prebuilt binary from the evaluation's toolset. eleumasc/DynSecAnJS-tools ships a built PanoptiChrome as a split zip (panoptichrome.chunk.z01 + panoptichrome.chunk.zip, ~163 MB, reassembled by its build.sh) alongside a built Foxhound. Targets Ubuntu 22.04. The repository has no repository-level LICENSE, but it does ship a licenses/ directory carrying each bundled tool's own terms, and licenses/PanoptiChrome.txt is the MIT licence, “Copyright © 2025 Rahul Kanyal” — so the binary is redistributable on the upstream terms.⁷⁾ This is much the faster route, and it is the build the published evaluation numbers were measured on: the binary was committed 2024-10-07, seven months before the completed patch reached upstream.

Three operational facts you will otherwise discover the hard way, all read out of the patch source:

• It reads its configuration by relative path, at isolate construction, and calls exit(1) if a file is missing. The patch does loadDatabase(sources_database, “sources.json”), loadDatabase(sinks_database, “sinks.json”) and parseIDL(“idl_data.json”). You must launch the browser with its working directory set to wherever those three JSON files live. In the “fixed” patch they are compiled in as headers instead, which removes the trap and also removes your ability to change sources and sinks without a rebuild — the opposite of the paper's stated selling point that they are “dynamic configuration files (user-defined)” changeable at runtime. So decide which trade you want before you build. Either edit src/execution/panoptichrome-data/sources.hpp and sinks.hpp and rebuild for each policy, or apply the original patch and supply the four files it is missing yourself — src/json.hpp from nlohmann/json, and the three data headers, whose contents are the repository's sources.json, sinks.json and idl_data.json — to keep runtime JSON configuration.
• Logs go to the current working directory unless you use the fixed patch, which adds std::getenv(“LOG_DIR”).
• You must disable the JIT. The evaluation runs it with --js-flags="--jitless" plus --no-sandbox, --disable-gpu and eleven other flags, and attributes the 36.7× overhead to “the authors' recommendation to disable certain optimizations in the JavaScript engine, including the JIT compiler, which would otherwise prevent the tool from running” [2Calzavara, Stefano; Casarin, Samuele; Focardi, Riccardo (2025): "Dynamic Security Analysis of JavaScript: Are We There Yet?", in: Proceedings of the ACM Web Conference. (DOI)]. Jitless Chromium is a different performance regime from the browser your subjects use; if you are measuring anything timing-sensitive, this instrument has already changed the answer.

The shipped configuration is not a curated list of privacy-relevant APIs. It is everything:

Two consequences a reviewer will ask about.

Storage is a sink here, not a source. Document.cookie, localStorage and sessionStorage are in sinks.json. The default policy therefore answers “did an API value get written into storage or onto the network”, and not “did a stored identifier get exfiltrated” — which is the question most web-tracking work asks, and the question Foxhound's default source set is built for. To ask it in PanoptiChrome you must add storage reads as sources yourself and say so. The independent evaluation had to do exactly this to make the tools comparable [2Calzavara, Stefano; Casarin, Samuele; Focardi, Riccardo (2025): "Dynamic Security Analysis of JavaScript: Are We There Yet?", in: Proceedings of the ACM Web Conference. (DOI)].

“Everything is a source” is a real policy choice with a cost. The paper reports it as expressiveness — “PanoptiChrome provides the same expressiveness as OpenWPM [22] for specifying the sources and sinks with the ability to selectively choose/reject specific properties or methods of an object” (its [22] is [5Englehardt, 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)]) — but the configuration as shipped exercises none of that selectivity, and the resulting numbers are dominated by DOM plumbing: of the 675 APIs it saw leak, 269 are DOM manipulation and 55.58% of per-site leaks are in the DOM category. The published false_positive_apis.md (42 entries: Blob.size, CSSRule.cssText, Element.animate, Window.getSelection, …) is the authors' own acknowledgement of the noise floor. Report your source and sink files verbatim in an appendix, and report what you excluded, because with this default the exclusion list is the method.

Not a database and not an event stream — plain text log files, one per V8 isolate, in the browser's working directory. The paper is explicit that this is VisibleV8's design: “We log all the data for each isolate separately in a different file similar to Visible V8 [27]; hence, the problem of inter-process synchronization is solved by design” [1Kanyal, Rahul; Sarangi, Smruti R. (2024): "PanoptiChrome: A Modern In-browser Taint Analysis Framework", in: Proceedings of the ACM Web Conference. (DOI)], where its [27] is [3Jueckstock, Jordan; Kapravelos, Alexandros (2019): "VisibleV8: In-browser Monitoring of JavaScript in the Wild", in: Proceedings of the ACM Internet Measurement Conference. (DOI)]. The patch shows it is not merely similar — VisibleV8's logging code is carried in verbatim, identifiers included (visv8_out_key, VisV8TlsData, a comment reading RAII “handle” to VV8 per-thread context).⁸⁾ Files are named rk_taint_path-<epoch_ms>-<pid>-<tid>-<threadname>.<n>.log and roll over by size.

Three consequences for your pipeline:

• The unit is the isolate, not the page. Cross-origin iframes get their own isolate and therefore their own file. Reassembling a per-page or per-site view is your job, and it is the same reason the paper's headline denominator is 12,846 unique origins rather than a site count.
• You will write your own parser. The only published one is a ~50-line file in the evaluation harness built around a single regex, and it handles exactly one sink: it matches ORIGIN@“…” lines to set the current origin, then SINKPC${Window}:“fetch”:“…” followed by LEAK$<n>:{Window}:“fetch”:<comma-separated sources>, and looks for Document.cookie or the pair Storage.getItem + Window.localStorage among the sources.⁹⁾ Anything else — sendBeacon, postMessage, WebSocket, IndexedDB — you parse yourself.
• There is no operation chain. A leak line names the sink and the set of source APIs. Unlike a Foxhound taint report it does not tell you which functions the value passed through, so sanitiser-style questions are out of reach, and neither is there a per-character range, so you cannot tell “the whole identifier was sent” from “one constant character matched”.

The most immediately usable part of this artifact is its data, and it reconciles with the paper exactly, which is more than most artifacts manage. Counting unique API names in the published tables:

Every entry in every sub-list is also in all_leaked_apis.md, and the four sub-lists partition 673 of the 675 (two are unassigned).¹⁰⁾ So the 362-API candidate fingerprinting surface is downloadable, checkable and citable without touching the browser — a useful complement to the API sets in [6Su, Junhua; Kapravelos, Alexandros (2023): "Automatic Discovery of Emerging Browser Fingerprinting Techniques", in: Proceedings of the ACM Web Conference. (DOI)] and [7Iqbal, Umar; Englehardt, Steven; Shafiq, Zubair (2021): "Fingerprinting the Fingerprinters: Learning to Detect Browser Fingerprinting Behaviors", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)]. Two warnings before you use it as ground truth: the labels are the authors' own manual judgement with no second coder and no agreement statistic (the corpus extraction records three ad-hoc annotation passes of 1,246, 252 and 186 APIs, all annotatorType: authors, all agreementMetric: null), and no file marks which 208 were “previously unreported”, so that claim is not reproducible from the artifact.

The paper's measurement is secondary to its systems contribution, and its denominators need care. From a Tranco top-20,000 seed accessed 2023-10-11, crawled from a residential ISP in India, landing pages only, stateless, one visit each, 180-second fixed timeout:

• 12,846 origins is not 12,846 sites. It exceeds the number of sites that returned 200 because iframes contribute their own isolates and therefore their own origins. Any “% of sites” computed against it is a different quantity from a “% of sites” in an OpenWPM-style paper; the page-level figures (“DOM-related APIs are leaked on 33.84% of the sites”) and the origin-level ones are not interchangeable.
• A 61.9% reachability rate is low, and it is a property of the instrument and vantage point as much as of the sites. The smaller comparison crawl against BFAD [6Su, Junhua; Kapravelos, Alexandros (2023): "Automatic Discovery of Emerging Browser Fingerprinting Techniques", in: Proceedings of the ACM Web Conference. (DOI)] is worse still: only 608 of 1,000 Tranco sites were reachable from the same vantage point. Compare with the evaluation's 6,921 of Tranco's top 10,000 reachable in stock Chrome [2Calzavara, Stefano; Casarin, Samuele; Focardi, Riccardo (2025): "Dynamic Security Analysis of JavaScript: Are We There Yet?", in: Proceedings of the ACM Web Conference. (DOI)]. If you replicate, report reachability with your own definition of it.
• The headline count is inconsistent within the paper. The abstract, results and conclusion all say 208 APIs “were previously not reported by state-of-the-art tools”; the introduction's fifth contribution says “We identify 164 hitherto undiscovered APIs that are potentially fingerprinting”. Both strings are in the published PDF. Cite 208 if you cite either, and note the discrepancy.
• “We do not use any automation framework.” The paper says so explicitly, framing it as evasion: “this makes our approach as indistinguishable as possible from a regular user accessing the site”, with “The driver script closes the browser after a preset time of 180 seconds and then starts another instance” [1Kanyal, Rahul; Sarangi, Smruti R. (2024): "PanoptiChrome: A Modern In-browser Taint Analysis Framework", in: Proceedings of the ACM Web Conference. (DOI)]. This is why the evaluation's compatibility figure is so much worse than the paper's own experience: a fixed timeout cannot tell a page that finished from a browser that hung, so an unresponsive instrument still produces a log file and still counts as a visit. Fixed-timeout crawling hides exactly the failure mode this instrument has. Whatever you drive it with, record a positive completion signal per page and report the fraction that failed to produce one.

A full-text sweep of /panopti[ -]?chrome/i over all 5,859 papers in the corpus returns 4:

Papers that used PanoptiChrome to measure something else: zero. Starred years are provisional (see corpus), but that does not soften this one: two years after publication, with a public MIT-licensed artifact, its only third-party use in these venues was an evaluation of the tool itself. The wider picture is the same — OpenAlex records 5 citing works as of 2026-08-17: that evaluation, the CCS 2025 robots.txt paper's reference list, an ASE 2025 related-work mention, and the same non-peer-reviewed article indexed twice. None is a measurement study that ran it.¹¹⁾

For context, the same sweep over the whole corpus for the other in-engine instruments — mention counts, so an upper bound, not usage:

The pattern the evaluation names is the one to internalise before you commit a year to a browser fork: “out of ten tools based on browser modifications considered for evaluation, we just managed to run three, two of which are very recent” [2Calzavara, Stefano; Casarin, Samuele; Focardi, Riccardo (2025): "Dynamic Security Analysis of JavaScript: Are We There Yet?", in: Proceedings of the ACM Web Conference. (DOI)]. In-engine taint trackers do not outlive their papers. Foxhound is the exception because a company maintains it. PanoptiChrome's repository has 14 commits in total, 6 of them on the day it was created; since the conference (2024-05-13) there have been 5: two creating the README, one adding the JSON configuration, one adding a licence, and one adding the completed patch. No tags, no releases, a single master branch.

Calzavara et al. screened 18 information-flow tools, ran six on 6,921 live Tranco domains, and measured four properties [2Calzavara, Stefano; Casarin, Samuele; Focardi, Riccardo (2025): "Dynamic Security Analysis of JavaScript: Are We There Yet?", in: Proceedings of the ACM Web Conference. (DOI)]. The full table is on the Foxhound page; the PanoptiChrome row and its Foxhound comparator are:

What it settles: at the configuration and scale a web measurement needs, this instrument will lose you half your scripts and slow you by an order of magnitude and a half. The 50% is a liveness failure, not a parsing one — “it achieves only a 50% compatibility rate in practice, mainly because the tool becomes unresponsive when analyzing complex websites” — and the paper is explicit that the authors did not hit it “likely because they operated the tool manually without an automation framework”.

What it does not settle. It measured one policy — storage sources to a fetch sink — chosen because every tool could express it, which is the policy PanoptiChrome's shipped configuration is least suited to (storage is a sink there, so the policy had to be added). It measured landing pages with no interaction, at one point in time, on one build. And it did not test either of the two axes on which this design differs in kind from Foxhound's — implicit flows, and what object-level taint does across a type conversion — because there is no ground truth for either on live sites. A replication with a source set the tool was designed for, and a synthetic implicit-flow benchmark, is an open and comparatively cheap piece of work; the ''IsSmi'' guard suggests the conversion result will be less flattering than the architecture implies. Note that re-running it “on the fixed patch” is not the gap, because the figures were already measured on a completed build.

1. The patch file and the commit, not “PanoptiChrome”: panoptichrome_patches.diff and panoptichrome_patches_fixed.diff are different instruments and the repository has no tags.
2. The Chromium and V8 version you built, and that it is a 2023 browser. If your subject population serves modern Chrome differently, that belongs in limitations.
3. Your sources.json and sinks.json, in full. The shipped defaults taint 1,052 interfaces and treat storage as a sink; almost any real study changes both, and the change is the method.
4. Whether the JIT was on. It almost certainly was not. Say so, and say what that does to any timing-derived quantity.
5. The unit and its denominator: isolates, origins, pages or sites — and how you mapped isolate log files back to pages. State whether subframe origins are inside your denominator.
6. A positive per-page completion signal and the failure rate, not a fixed timeout. On this browser that number is the headline limitation, and reporting it is what distinguishes your crawl from the original.
7. How you separated implicit from explicit flows, or that you could not — the log does not distinguish them.
8. How the leaked-API list was validated. If you inherit the paper's 362-API labels, inherit its caveat: single-coder manual labelling with no agreement statistic.

PanoptiChrome is a real, public, MIT-licensed artifact with a more exactly pinned base than most of this corpus manages, and it has still been used by nobody. That gap is the thing worth calibrating on, because it is not visible from the paper, the abstract or a search. The corpus can tell you a tool exists; only opening the artifact tells you that the published patch does not compile, that the person who completed it did so while evaluating it head-to-head against the alternative, that the shipped configuration answers a different question from the one most web-privacy work asks, and that the one independent test put it an order of magnitude and a half behind the alternative.

None of that makes it a bad piece of engineering — 7,000 lines of taint propagation inside V8's interpreter, without touching the garbage collector, is a hard thing to do, and the evaluation's own conclusion is that browser modification is the architecture that works. It makes it an unfinished one. If you need Chromium or implicit flows, this page is the shortest path to a working browser and an honest limitations section. If you do not, use Foxhound.

• Corpus figures. scripts/report_panoptichrome.mjs produces every corpus number here with its denominator, from a full-text sweep rather than the extraction schema — the schema finds 2 of the 4 papers and misses both citation-only ones, which are the finding. External figures. scripts/panoptichrome_probe.sh re-fetches every repository, patch, version and API-list count from a primary source. Quotes. scripts/pc_quotecheck.py checks all 28 quoted sentences against paper.pdf and paper.cols.txt (28/28 located verbatim; neither rendering alone suffices, because these two-column ACM PDFs defeat the two extractions on different sentences). All three scripts, their unedited output, every query, every rejected source and every judgement call are on panoptichrome; corpus-level caveats are on corpus.
• The corpus is seven venues (CCS, IMC, NDSS, PETS, USENIX Security, TheWebConf, IEEE S&P), 2010–2026. AsiaCCS, EuroS&P, ACSAC, RAID, CHI and SOUPS are absent — including AsiaCCS 2026, where the same authors published a further modified-Chromium tool, StealthDev, which is a stealthy-DevTools framework rather than a taint tracker and does not extend PanoptiChrome.¹²⁾ Every count on this page is a lower bound.
• No fold was needed. PanoptiChrome is one token with no synonyms and no homographs in this corpus; the sweep regex allows a space or hyphen and the residue is empty by construction. This is unusual — see Use in Publications for what folding costs when a name is ambiguous.
• Nothing here is a benchmark we ran. We did not build the browser. Every performance and compatibility figure is Calzavara et al.'s, on landing pages, on their hardware, on their own completed build of the patch. The artifact reconciliation, patch anatomy, version deltas and repository state are ours and are reproducible from the probe script.
• What we could not establish: whether object-level taint actually survives the numeric round trip that defeats Foxhound (nobody has tested it); which 208 APIs the paper counts as previously unreported (no published list); and whether the fixed patch changes any of the evaluation's four measured properties (it postdates the evaluation and nobody has re-run it).

• Crawler — the automation layers, and the specialised crawlers compared side by side.
• Foxhound — the instrument you should reach for first, and the source of the head-to-head table.
• PageGraph — causal attribution in a shipped browser, when you want “which script”, not “which value”.
• Javascript — classifying the JavaScript whose flows this browser records.
• Fingerprinting — where the 362-API list is the kind of artifact you would otherwise rebuild.
• Stateful stateless — statefulness, which decides whether storage has anything in it to leak.

[1]

Kanyal, Rahul; Sarangi, Smruti R. (2024): "PanoptiChrome: A Modern In-browser Taint Analysis Framework", in: Proceedings of the ACM Web Conference. (DOI)

[2]

Calzavara, Stefano; Casarin, Samuele; Focardi, Riccardo (2025): "Dynamic Security Analysis of JavaScript: Are We There Yet?", in: Proceedings of the ACM Web Conference. (DOI)

[3]

Jueckstock, Jordan; Kapravelos, Alexandros (2019): "VisibleV8: In-browser Monitoring of JavaScript in the Wild", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[4]

Calzavara, Stefano; Casarin, Samuele; Squarcina, Marco; Maffei, Matteo (2026): "From Syntactic Matching to Taint Tracking and Back: A Comparative Study of Web Tracking Detection Techniques", in: Proceedings on Privacy Enhancing Technologies. (Link)

[5]

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)

[6]

Su, Junhua; Kapravelos, Alexandros (2023): "Automatic Discovery of Emerging Browser Fingerprinting Techniques", in: Proceedings of the ACM Web Conference. (DOI)

[7]

Iqbal, Umar; Englehardt, Steven; Shafiq, Zubair (2021): "Fingerprinting the Fingerprinters: Learning to Detect Browser Fingerprinting Behaviors", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)

[8]

Sabino, Nuno; Cassel, Darion; Abreu, Rui; Adão, Pedro; Bauer, Lujo; Jia, Limin (2026): "DOM-XSS Detection via Webpage Interaction Fuzzing and URL Component Synthesis", in: Proceedings of the Network and Distributed System Security Symposium. (Link)