Pith. sign in

REVIEW 4 major objections 5 minor 66 references

Byte by Byte: Unmasking Browser Fingerprinting at the Function Level Using V8 Bytecode Transformers

T0 review · 4 major / 5 minor · reviewed 2026-08-04 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read V8 bytecode alone can identify browser fingerprinting functions before they execute, yielding 98.9% function-level accuracy and 99.7% script-level accuracy.

desk verdict Function-level bytecode fingerprinting is a genuinely new idea with a strong crawl behind it, but the evaluation only measures agreement with heuristic labels; send it to review, expect major revision. read the letter →

arxiv 2509.09950 v1 pith:KP24RLOI submitted 2025-09-12 cs.CR

Pouneh Nikkhah Bahrami , Dylan Cutler , Igor Bilogrevic This is my paper
classification cs.CR
keywords browserfingerprintingV8bytecodefunction-leveldetectiontransformerclassifierJavaScriptobfuscationprivacywebtrackingcontentblocking
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper sets out to show that a browser can tell a fingerprinting function from an ordinary one simply by reading the low-level bytecode V8 produces when it compiles JavaScript, before the function runs. It introduces ByteDefender, a Transformer classifier trained on bytecode instruction sequences with operands stripped away, and reports 98.9% accuracy, 84.0% precision and 85.1% recall at function level on data gathered from 100,000 real websites. The same bytecode representation also yields compact signatures that a modified Chromium can match during compilation with about 4% average page-load overhead. At script level, the approach reaches 99.7% accuracy and clearly outperforms AST-based classification, particularly on obfuscated code. If these results hold, fingerprinting could be blocked precisely and proactively—removing only the offending function rather than the whole script—while resisting URL tricks and source obfuscation.

What carries the argument

The central object is the V8 bytecode sequence: the ordered list of opcode mnemonics (for example LdaGlobal, GetNamedProperty, CallProperty1) that V8's Ignition interpreter emits from a parsed JavaScript function, with operands, offsets and literal values stripped away. This sequence is produced at compile time, before execution, and is paired with metadata (script URL, script ID, function name) so that it can be joined to execution traces. The machinery that carries the argument is a Transformer encoder which reads these token sequences and learns order-sensitive, context-dependent embeddings for classification, plus a signature variant that hashes the opcode list for lightweight in-engine

What would settle it

Take a random sample of functions from the 100k-site crawl that the heuristics labelled non-fingerprinting but that do call at least one high-entropy API, manually inspect them for fingerprinting behaviour, and compare that ground truth with ByteDefender's predictions; if a substantial share turn out to be fingerprinting, the reported 98.9% accuracy is measuring the heuristic, not real-world detection. A cheaper check is to run ByteDefender on the anonymous functions excluded from training (2,905 trace-identified fingerprinting functions): the paper leaves that generalisation unverified.

Watch

Extended reading notes

Core claim

On the paper's own terms, the central discovery is that the ordered list of V8 bytecode opcodes inside a JavaScript function is a sufficient static signal to recognise fingerprinting behaviour. A Transformer trained on these sequences labels functions as fingerprinting or not with 98.9% accuracy, 84.0% precision and 85.1% recall; a script-level version reaches 99.7% accuracy and 96.9% recall. Because only opcode names are kept—constants, property names, offsets and operands are discarded—the representation is deliberately blind to the syntactic surface that obfuscation changes, yet still captures the operational structure of canvas, audio, font and WebRTC fingerprinting. The same bytecode re

Load-bearing premise

All training and test labels come from four heuristics applied to execution traces of Chromium's high-entropy APIs; any function whose trace matches none of them is labelled non-fingerprinting, so if these heuristics miss a fingerprinting technique, the model inherits that blind spot and the reported accuracy reflects agreement with the heuristics rather than true detection.

Editorial extensions

If this is right

  • Browsers could block or neutralise individual fingerprinting functions at compile time, leaving legitimate functions in the same script untouched, which matters because the paper finds every fingerprinting script in its 100k-site crawl is mixed-purpose.
  • URL-based evasion—CNAME cloaking, path randomisation, domain shuffling—becomes ineffective because classification never consults the script's origin.
  • Common obfuscation (variable renaming, string encoding, control-flow flattening) no longer hides fingerprinting: adding obfuscated scripts to the training set raises recall on heavily obfuscated inputs from near zero to 92% in the paper's script-level test.
  • The 4% average page-load overhead measured on 1,000 sites indicates that per-function bytecode hashing is cheap enough to run in the browser's normal compilation path.
  • AST-based fingerprinting detection appears to miss a large share of real-world fingerprinting: a reimplemented AST classifier reaches 80.0% script-level recall versus 96.9% for the bytecode model.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The opcode-sequence representation is not fingerprinting-specific; the same training recipe could plausibly flag other stateless tracking or abusive behaviours (session replay, crypto-mining) that leave distinctive operational footprints, though the paper does not test this.
  • The heuristics cover only four fingerprinting families, so the model's true coverage in the wild is likely narrower than the accuracy figures suggest; a natural next step is deploying ByteDefender and manually auditing the functions it flags that the heuristics called non-fingerprinting.
  • Signature matching hashes the opcode sequence exactly, so any V8 version change that alters an opcode name or encoding could invalidate the signature library; the paper acknowledges the need for retraining but does not quantify how often this would occur.
  • The 4% overhead was measured with a fixed signature list; as the list grows, hash-lookup cost may rise, and the paper leaves that scaling behaviour unmeasured.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. ByteDefender proposes the first function-level browser fingerprinting detector based on V8 bytecode, using a Transformer trained on bytecode instruction sequences with labels derived from heuristic analysis of high-entropy API execution traces. The paper reports 98.9% accuracy, 84.0% precision, and 85.1% recall at the function level, 99.7% accuracy at the script level, and a 4% average page-load overhead for on-device signature matching. If these results hold, the contribution is significant: function-level, pre-execution detection of fingerprinting that is robust to source-level obfuscation and URL manipulation, addressing a real gap between script-level blockers and dynamic analysis. However, the evaluation's validity depends critically on the quality of the heuristic ground truth and on the generality of the function-level model to anonymous and eval-loaded code, both of which are acknowledged but not quantified in the manuscript.

Significance. The paper attacks a real problem—detecting fingerprinting at function granularity before execution—and introduces a novel feature representation (V8 bytecode opcode sequences) that is well-motivated and plausibly more robust to source-level obfuscation than ASTs. The large-scale crawl of 100k sites, the instrumented V8 pipeline, and the reproducible release of code are strengths. The central empirical claim, however, is only as strong as the automatically generated labels. Since the bytecode representation strips operands (§3.1), the classifier cannot see API names or string constants; it can only learn correlations between opcode patterns and the heuristic labels from §3.4. If those labels are noisy, the headline 98.9%/99.7% numbers measure agreement with the heuristic, not detection of real fingerprinting. The paper also shows that obfuscation robustness is not inherent: unaugmented recall is 0.1% (§5.3, Table 4). These issues are load-bearing and need to be addressed before the claims can be accepted.

major comments (4)
  1. [§3.4, §3.5] The ground-truth labels are generated by four hand-written heuristics over high-entropy API traces; any function with no matching trace is labeled non-fingerprinting. Because the bytecode representation omits operands and API names (§3.1), the classifier can only learn opcode-sequence patterns that correlate with these heuristic labels. Two concrete failure modes: (1) trace capture (§3.2, §3.3) is limited to CDP events; lazy compilation, indirect calls, eval, or tracing start/stop can cause a function's high-entropy API call to be missed, producing a false negative label. (2) The four heuristics cover only Canvas, Canvas Font, Audio, and WebRTC, omitting entire fingerprinting families such as WebGL, matchMedia, and font enumeration (as acknowledged in §6.2). Both failure modes affect training and test labels identically, so the reported 98.9% and 99.7% accuracy (Tables 2, 3) cannot be in
  2. [§5.3, Table 4] The obfuscation robustness claim is not supported by the unaugmented results. The first row of Table 4 shows that a model trained only on real-world scripts achieves recall of 0.1% (JavaScript Obfuscator) and 2.8% (Google Closure) on re-obfuscated inputs. Only after training on obfuscated samples does recall rise to 92.1%/78.0%. This directly contradicts the Abstract's claim of 'inherent resilience' to common code obfuscation, and the same limitation applies to the function-level model, which is not evaluated on obfuscation at all. The paper should either reframe the robustness claim as requiring obfuscation-aware training or evaluate the function-level model on obfuscated inputs without such augmentation.
  3. [§4.2, §6.1] A large fraction of the potential fingerprinting instances are discarded: the cleaning step removes 6.6M anonymous functions that invoked high-entropy APIs, including 2,905 that were eventually labeled fingerprinting, leaving only 4,670 named fingerprinting functions. As §6.1 admits, the model's generalization to anonymous and eval-loaded functions 'remains unverified.' Given that many real-world fingerprinting snippets are anonymous IIFEs, the deployment claim that ByteDefender can detect such functions 'if their bytecode exhibits patterns learned from named functions' is speculative. Please provide at least a targeted evaluation on a held-out set of anonymous functions (e.g., by matching via line/column or an alternative key) to support the deployment claim.
  4. [§4.2, §5.1] There is an internal inconsistency in the reported training-set construction. Section 4.2 states the training undersampling ratio is approximately 1:20 (FP:non-FP), while Section 5.1 states 'the training set was balanced by undersampling the non-fingerprinting class to a 1:10 ratio (FP:non-FP) after oversampling positive examples.' This discrepancy makes the reported metrics unreproducible. Please clarify the exact procedure and report the actual class distribution used in each experiment.
minor comments (5)
  1. [§3.1, Listing 3] Listing 3 contains 'GetNamedProprty', a typo for 'GetNamedProperty'.
  2. [§4.3, Figure 3] The caption reads 'Mixed Scrips' instead of 'Mixed Scripts.'
  3. [§5.1, Table 2] 'Transf.' in the Embed. Model column is ambiguous; spell out 'Transformer'.
  4. [§3.4] The heuristics are stated as text; a formal specification (e.g., pseudo-code or threshold definitions) would improve reproducibility. Specifically, the Canvas Font heuristic's 'more than 20 different font values' is not defined precisely (set of font.set values?).
  5. [§4.3] The paragraph on bytecode length says 'around 90% of non-fingerprinting functions have fewer than 100 bytecode instructions' and '90% of fingerprinting functions have bytecode lengths ranging between approximately 100 and 1,000.' These are observations, not controlled for function size; consider whether they indicate a length-based confound in the classifier.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: ByteDefender is a standard supervised-learning pipeline whose reported metrics measure agreement with heuristic-derived labels; this label-validity limitation is acknowledged in the paper, but no step reduces to its own input by construction.

full rationale

The paper's derivation is a standard supervised-learning pipeline: instrumented V8 collects function bytecode, a Chrome extension captures CDP execution traces of high-entropy API calls (§3.1–§3.3), hand-written heuristics label functions from those traces (§3.4), labels are mapped to bytecode by script URL/ID/function name (§3.5), and a Transformer is trained on the labeled bytecode (§3.6–§3.7). Evaluation (§5.1) is on a held-out, deduplicated test set, so the reported 98.9% accuracy is not a fitted parameter renamed as a prediction. The classifier does not reduce to the labeling heuristics by construction: it sees only opcode mnemonics with operands stripped (§3.1), while labels come from execution traces, so whether opcode sequences predict the heuristic labels is an empirical question; the model in fact misses some positives (recall 85.1%). The claim that this equals real-world fingerprinting is limited by the heuristic ground truth, which the paper explicitly acknowledges in §6.2 ('our reliance on predefined heuristics introduces an inherent bias'), and by the exclusion of anonymous/eval-loaded functions, whose generalization is admitted to be 'unverified' in §6.1. These are label-validity and generalization threats, not circular reductions. The only self-citations ([3], [49]) are contextual or limitation references and are not load-bearing; there is no imported uniqueness theorem and no ansatz smuggled in via citation. Accordingly, no circular step can be exhibited, and the circularity score is 0.

Assumptions & free parameters 4 free parameters · 6 assumptions · 0 invented entities

The paper introduces no new physical or formal entities. Its load-bearing assumptions are the heuristic ground-truth proxy, the negative-label rule for unmatched functions, the sufficiency of stripped opcode sequences, and the representativeness of named functions. These assumptions, rather than any fitted physical parameter, determine what the accuracy numbers mean.

free parameters (4)
  • Canvas fingerprinting text length threshold = None (hand chosen, >=10 characters)
    Section 3.4: a function is canvas-fingerprinting only if fillText text length is at least 10 characters and no save, restore, or addEventListener is called.
  • Canvas font measureText count threshold = None (hand chosen, >=20 calls)
    Section 3.4: a function is labeled canvas-font fingerprinting only if measureText occurs at least 20 times in the trace.
  • Canvas font distinct font values threshold = None (hand chosen, >20 font values)
    Section 3.4: more than 20 different font values must be set within the function trace for the font-fingerprinting heuristic.
  • Training undersampling ratio for non-FP class = Stated as 1:20 in Section 4.2 and 1:10 in Section 5.1
    The class balance is a construction choice that changes the learned model and the reported precision/recall; the inconsistency is a concrete flag.
assumptions (6)
  • domain assumption High-entropy API trace patterns are a faithful proxy for fingerprinting behavior.
    Section 3.4 builds all labels from Chromium's high-entropy API list and four fingerprinting heuristics; if this proxy is wrong, labels and metrics are wrong.
  • domain assumption Absence of a high-entropy API trace implies the function is non-fingerprinting.
    Section 3.5 labels unmatched functions as non-FP; this is a strong negative-label assumption with no independent verification.
  • domain assumption V8 opcode sequences without operands carry enough semantic signal to distinguish fingerprinting functions.
    Section 3.1 strips operands, property names, and constants; the paper asserts behavioral structure remains, but this is not independently proven.
  • domain assumption Named functions are representative of fingerprinting functions, including anonymous and eval-loaded code.
    Section 4.2 excludes anonymous and eval-loaded functions, and Section 6.1 admits that classifier generalization to them is unverified.
  • domain assumption Chrome CDP Tracing captures all relevant high-entropy API calls made during the crawl.
    Section 3.2 relies on the Tracing domain for ground-truth evidence; missing or dropped events would silently mislabel functions.
  • domain assumption The held-out crawl is representative of future web code.
    The model is evaluated on a split of the crawled data; the paper does not validate on a later crawl or a different time period.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Byte by Byte: Unmasking Browser Fingerprinting at the Function Level Using V8 Bytecode Transformers." pith.science (2026). https://pith.science/paper/KP24RLOI

@misc{pith2026250909950,
  author       = {Pith},
  title        = {Pith review of: Byte by Byte: Unmasking Browser Fingerprinting at the Function Level Using V8 Bytecode Transformers},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/KP24RLOI}},
  note         = {Machine review of arXiv:2509.09950}
}
read the original abstract

Browser fingerprinting enables persistent cross-site user tracking via subtle techniques that often evade conventional defenses or cause website breakage when script-level blocking countermeasures are applied. Addressing these challenges requires detection methods offering both function-level precision to minimize breakage and inherent robustness against code obfuscation and URL manipulation. We introduce ByteDefender, the first system leveraging V8 engine bytecode to detect fingerprinting operations specifically at the JavaScript function level. A Transformer-based classifier, trained offline on bytecode sequences, accurately identifies functions exhibiting fingerprinting behavior. We develop and evaluate light-weight signatures derived from this model to enable low-overhead, on-device matching against function bytecode during compilation but prior to execution, which only adds a 4% (average) latency to the page load time. This mechanism facilitates targeted, real-time prevention of fingerprinting function execution, thereby preserving legitimate script functionality. Operating directly on bytecode ensures inherent resilience against common code obfuscation and URL-based evasion. Our evaluation on the top 100k websites demonstrates high detection accuracy at both function- and script-level, with substantial improvements over state-of-the-art AST-based methods, particularly in robustness against obfuscation. ByteDefender offers a practical framework for effective, precise, and robust fingerprinting mitigation.

Figures

Figures reproduced from arXiv: 2509.09950 by the authors.

Figure 1
Figure 1. , raw JavaScript source code is first parsed into an Abstract Syntax Tree (AST), which represents the code’s syntactic structure. V8’s interpreter, Ignition, then compiles this AST into bytecode – a platform-independent, intermediate representation optimized for quick generation and execution. This bytecode serves as the input for further stages, including interpretation or Just-In-Time (JIT) compilation into optimi… view at source ↗
Figure 2
Figure 2. ByteDefender: (1) Web crawling is performed using a Chromium browser with an instrumented V8 engine to extract [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Cumulative distribution of the number of functions [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Comparative distribution of bytecode lengths for functions (a) and scripts (b). [PITH_FULL_IMAGE:figures/full_fig_p010_4.png]
Figure 5
Figure 5. Figure 5: CDF plot comparing page load times of the baseline [PITH_FULL_IMAGE:figures/full_fig_p012_5.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

66 extracted references · 10 linked inside Pith

  1. [1]

    Martín Abadi, Ashish Agarwal, Paul Barham, Eugene Brevdo, Zhifeng Chen, Craig Citro, Greg S Corrado, Andy Davis, Jeffrey Dean, Matthieu Devin, et al

  2. [2]

    Abdul Haddi Amjad, Shaoor Munir, Zubair Shafiq, and Muhammad Ali Gulzar

  3. [3]

    Pouneh Nikkhah Bahrami, Umar Iqbal, and Zubair Shafiq. 2021. Fp-radar: Lon- gitudinal measurement and early detection of browser fingerprinting.arXiv preprint arXiv:2112.01662(2021)

    arXiv 2021

  4. [4]

    Fingerprinting Protection Mode

    bravemitigations 2018. Fingerprinting Protection Mode. https://github.com/ brave/browser-laptop/wiki/Fingerprinting-Protection-Mode

    2018

  5. [5]

    Elie Bursztein, Artem Malyshev, Tadek Pietraszek, and Kurt Thomas. 2016. Pi- casso: Lightweight device class fingerprinting for web clients. InProceedings of the 6th Workshop on Security and Privacy in Smartphones and Mobile Devices. 93–102

    2016

  6. [6]

    Javier Cabrera Arteaga, Martin Monperrus, and Benoit Baudry. 2019. Scalable comparison of JavaScript V8 bytecode traces. InProceedings of the 11th ACM SIGPLAN International Workshop on Virtual Machines and Intermediate Languages. 22–31

    2019

  7. [7]

    Dell Cameron. 2018. Apple Declares War on Browser Fingerprinting, the Sneaky Tactic That Tracks You in Incognito Mode. https://gizmodo.com/apple- declareswar-on-browser-fingerprinting-the-sneak-1826549108. Accessed: 2025

    2018

  8. [8]

    Yinzhi Cao, Song Li, and Erik Wijmans. 2017. (Cross-) browser fingerprinting via OS and hardware level features. InProceedings 2017 Network and Distributed System Security Symposium. Internet Society

    2017

Show all 66 references
  1. [9]

    Ha Dao, Johan Mazel, and Kensuke Fukuda. 2021. CNAME cloaking-based track- ing on the web: Characterization, detection, and protection.IEEE Transactions on Network and Service Management18, 3 (2021), 3873–3888

    2021

  2. [10]

    Anupam Das, Gunes Acar, Nikita Borisov, and Amogh Pradeep. 2018. The web’s sixth sense: A study of scripts accessing smartphone sensors. InProceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security. 1515–1532

    2018

  3. [11]

    Amit Datta, Jianan Lu, and Michael Carl Tschantz. 2018. The effectiveness of privacy enhancing technologies against fingerprinting.arXiv preprint arXiv:1812.03920(2018)

    2018 arXiv

  4. [12]

    Jacob Devlin. 2018. Bert: Pre-training of deep bidirectional transformers for language understanding.arXiv preprint arXiv:1810.04805(2018)

    2018 arXiv

  5. [13]

    Yana Dimova, Gunes Acar, Lukasz Olejnik, Wouter Joosen, and Tom van Goethem

  6. [14]

    Disconnect tracking protection lists

    Disconnect 2024. Disconnect tracking protection lists. https://disconnect.me/ trackerprotection. Accessed: 2025

    2024

  7. [15]

    Antonin Durey, Pierre Laperdrix, Walter Rudametkin, and Romain Rouvoy. 2021. FP-Redemption: Studying browser fingerprinting adoption for the sake of web security. InDetection of Intrusions and Malware, and Vulnerability Assessment: 18th International Conference, DIMV A 2021, V...

    2021

  8. [16]

    Peter Eckersley. 2010. How unique is your web browser?. InInternational Sym- posium on Privacy Enhancing Technologies Symposium. Springer, 1–18

    2010

  9. [17]

    Steven Englehardt and Arvind Narayanan. 2016. Online tracking: A 1-million-site measurement and analysis. InProceedings of the 2016 ACM SIGSAC conference on computer and communications security. 1388–1401

    2016

  10. [18]

    esprima_parsing [n. d.]. Syntactic Analysis (Parsing). https://docs.esprima.org/ en/latest/syntactic-analysis.html. Accessed: 2025

    2025

  11. [19]

    David Fifield and Mia Gil Epner. 2016. Fingerprintability of webrtc.arXiv preprint arXiv:1605.08805(2016)

    2016 arXiv

  12. [20]

    firefoxAntiFingerpriting [n. d.]. How to block fingerprinting with Firefox. https: //blog.mozilla.org/firefox/how-to-block-fingerprinting-with-firefox. Accessed: 2025

    2025

  13. [21]

    Roy Frostig, Matthew James Johnson, and Chris Leary. 2018. Compiling machine learning programs via high-level tracing.Systems for Machine Learning4, 9 (2018)

    2018

  14. [22]

    Mohammad Ghasemisharif and Jason Polakis. 2023. Read between the lines: Detecting tracking javascript with bytecode classification. InProceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security. 3475– 3489

    2023

  15. [23]

    Yoav Goldberg. 2014. word2vec Explained: deriving Mikolov et al. ’s negative- sampling word-embedding method.arXiv preprint arXiv:1402.3722(2014)

    2014 arXiv

  16. [24]

    google_closure [n. d.]. Google Closure compiler. https://developers.google.com/ closure/compiler. Accessed: 2025

    2025

  17. [25]

    high_entropy_apis [n. d.]. High Entropy APIs flagged by chromium. https://github.com/chromium/chromium/blob/ aae7191b27cef1f097b23e7742afb4895ec6a9d3/docs/privacy_budget/privacy_ budget_instrumentation.md?plain=1#L196. Accessed: 2025

    2025

  18. [26]

    Franziska Hinkelmann. 2017. Understanding V8’s Bytecode. https://medium. com/dailyjs/understanding-v8s-bytecode-317d46c94775. Accessed: 2025

    2017

  19. [27]

    Umar Iqbal, Steven Englehardt, and Zubair Shafiq. 2021. Fingerprinting the fingerprinters: Learning to detect browser fingerprinting behaviors. In2021 IEEE Symposium on Security and Privacy (SP). IEEE, 1143–1161

    2021

  20. [28]

    Armand Joulin, Edouard Grave, Piotr Bojanowski, and Tomas Mikolov. 2016. Bag of tricks for efficient text classification.arXiv preprint arXiv:1607.01759(2016). CCS ’25, October 13–17, 2025, Taipei, Taiwan Pouneh Bahrami, Dylan Cutler, and Igor Bilogrevic

    2016 arXiv

  21. [29]

    Timofey Kachalov. [n. d.]. Javascript obfuscator tool. https://obfuscator.io/. Accessed: 2025

    2025

  22. [30]

    Faezeh Kalantari, Mehrnoosh Zaeifi, Yeganeh Safaei, Marzieh Bitaab, Adam Oest, Gianluca Stringhini, Yan Shoshitaishvili, and Adam Doupé. 2024. Browser Polygraph: Efficient Deployment of Coarse-Grained Browser Fingerprints for Web-Scale Detection of Fraud Browsers. InProceeding...

    2024

  23. [31]

    Jacob Devlin Ming-Wei Chang Kenton and Lee Kristina Toutanova. 2019. Bert: Pre-training of deep bidirectional transformers for language understanding. In Proceedings of naacL-HLT, Vol. 1

    2019

  24. [32]

    Diederik P Kingma. 2014. Adam: A method for stochastic optimization.arXiv preprint arXiv:1412.6980(2014)

    2014 arXiv

  25. [33]

    Pierre Laperdrix, Nataliia Bielova, Benoit Baudry, and Gildas Avoine. 2020. Browser fingerprinting: A survey.ACM Transactions on the Web (TWEB)14, 2 (2020), 1–33

    2020

  26. [34]

    Zengrui Liu, Jimmy Dani, Yinzhi Cao, Shujiang Wu, and Nitesh Saxena. 2025. The First Early Evidence of the Use of Browser Fingerprinting for Online Tracking. InTHE WEB CONFERENCE 2025

    2025

  27. [35]

    Tomas Mikolov, Kai Chen, Greg Corrado, and Jeffrey Dean. 2013. Efficient estimation of word representations in vector space.arXiv preprint arXiv:1301.3781 (2013)

    2013 arXiv

  28. [36]

    Marvin Moog, Markus Demmel, Michael Backes, and Aurore Fass. 2021. Statically detecting javascript obfuscation and minification techniques in the wild. In 2021 51st Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). IEEE, 569–580

    2021

  29. [37]

    Keaton Mowery and Hovav Shacham. 2012. Pixel perfect: Fingerprinting canvas in HTML5.Proceedings of W2SP2012 (2012)

    2012

  30. [38]

    Ray Ngan, Surya Konkimalla, and Zubair Shafiq. 2022. Nowhere to hide: Detecting obfuscated fingerprinting scripts.arXiv preprint arXiv:2206.13599(2022)

    2022 arXiv

  31. [39]

    Tom Ritter Nick Doty. 2025. W3C Fingerprinting Guidance. https://w3c.github. io/fingerprinting-guidance/. Accessed: 2025

    2025

  32. [40]

    Fabian Pedregosa, Gaël Varoquaux, Alexandre Gramfort, Vincent Michel, Bertrand Thirion, Olivier Grisel, Mathieu Blondel, Peter Prettenhofer, Ron Weiss, Vincent Dubourg, et al . 2011. Scikit-learn: Machine learning in Python.the Journal of machine Learning research12 (2011), 2825–2830

    2011

  33. [41]

    Victor Le Pochat, Tom Van Goethem, Samaneh Tajalizadehkhoob, Maciej Kor- czyński, and Wouter Joosen. 2018. Tranco: A research-oriented top sites ranking hardened against manipulation.arXiv preprint arXiv:1806.01156(2018)

    2018 arXiv

  34. [42]

    privacybadger [n. d.]. Privacy Badger. https://www.eff.org/privacybadger. Ac- cessed: 2025

    2025

  35. [43]

    Gaston Pugliese, Christian Riess, Freya Gassmann, and Zinaida Benenson. 2020. Long-term observation on browser fingerprinting: Users’ trackability and per- spective.Proceedings on Privacy Enhancing Technologies(2020)

    2020

  36. [44]

    Alec Radford, Karthik Narasimhan, Tim Salimans, and Ilya Sutskever. 2018. Im- proving language understanding by generative pre-training.OpenAI blog(2018)

    2018

  37. [45]

    Andreas Reiter and Alexander Marsalek. 2017. WebRTC: your privacy is at risk. InProceedings of the Symposium on Applied Computing. 664–669

    2017

  38. [46]

    2018.Machine Learning Approaches for Automatic Detection of Web Fingerprinting

    Valentino Rizzo. 2018.Machine Learning Approaches for Automatic Detection of Web Fingerprinting. Ph. D. Dissertation. Politecnico di Torino

    2018

  39. [47]

    Muhammad Fakhrur Rozi, Sangwook Kim, and Seiichi Ozawa. 2020. Deep neural networks for malicious javascript detection using bytecode sequences. In2020 International Joint Conference on Neural Networks (IJCNN). IEEE, 1–8

    2020

  40. [48]

    selenium [n. d.]. Selenium WebDriver. https://www.selenium.dev/ documentation/webdriver/. Accessed: 2025

    2025

  41. [49]

    Asuman Senol, Alisha Ukani, Dylan Cutler, and Igor Bilogrevic. 2024. The double edged sword: identifying authentication pages and their fingerprinting behavior. InProceedings of the ACM Web Conference 2024. 1690–1701

    2024

  42. [50]

    Philippe Skolka, Cristian-Alexandru Staicu, and Michael Pradel. 2019. Anything to hide? studying minified and obfuscated code in the web. InThe world wide web conference. 1735–1746

    2019

  43. [51]

    Nitish Srivastava, Geoffrey Hinton, Alex Krizhevsky, Ilya Sutskever, and Ruslan Salakhutdinov. 2014. Dropout: a simple way to prevent neural networks from overfitting.The journal of machine learning research15, 1 (2014), 1929–1958

    2014

  44. [52]

    Brave Privacy Team. 2020. Fingerprint randomization. https://brave.com/privacy- updates/3-fingerprint-randomization/. Accessed: 2025

    2020

  45. [53]

    V8 team. 2017. Launching Ignition and TurboFan. https://v8.dev/blog/launching- ignition-and-turbofan. Accessed: 2025

    2017

  46. [54]

    tormitigations [n. d.]. Fingerprinting Defenses in The Tor Browser. https://2019. www.torproject.org/projects/torbrowser/design/#fingerprinting-defenses. Ac- cessed: 2025

    2019

  47. [55]

    tracing_CDP [n. d.]. Tracing domain in Chrome DevTools protocol. https:// chromedevtools.github.io/devtools-protocol/tot/Tracing/. Accessed: 2025

    2025

  48. [56]

    Tim van Zalingen and Sjors Haanen. 2018. Detection of Browser Fingerprinting by Static JavaScript Code Classification

    2018

  49. [57]

    Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, and Romain Rouvoy. 2018. {Fp-Scanner}: The privacy implications of browser fingerprint inconsistencies. In27th USENIX Security Symposium (USENIX Security 18). 135–150

    2018

  50. [58]

    Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N Gomez, Łukasz Kaiser, and Illia Polosukhin. 2017. Attention is all you need.Advances in neural information processing systems30 (2017)

    2017

  51. [59]

    w3mitigations [n. d.]. Mitigating Browser Fingerprinting in Web Specifica- tions. https://www.w3.org/TR/fingerprinting-guidance/?utm_source=chatgpt. com#narrow-scope-availability. Accessed: 2025

    2025

  52. [60]

    Weihang Wang, Yunhui Zheng, Xinyu Xing, Yonghwi Kwon, Xiangyu Zhang, and Patrick Eugster. 2016. Webranz: web page randomization for better advertisement delivery and web-bot prevention. InProceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Softwa...

    2016

  53. [61]

    webkitBlocking [n. d.]. Tracking Prevention in WebKit. https://webkit.org/ tracking-prevention/. Accessed: 2025

    2025

  54. [62]

    Mike West. 2024. Combating Fingerprinting with a Privacy Budget Explainer. https://github.com/bslassey/privacy-budget. Accessed: 2025

    2024

  55. [63]

    Shujiang Wu, Song Li, Yinzhi Cao, and Ningfei Wang. 2019. Rendered private: Making{GLSL} execution uniform to prevent{WebGL-based} browser finger- printing. In28th USENIX Security Symposium (USENIX Security 19). 1645–1660. A List of high entropy APIs The following table lists ...

    2019

  56. [2015]

    TensorFlow: Large-scale machine learning on heterogeneous systems

  57. [2021]

    https://api.semanticscholar.org/CorpusID:231951672

    The CNAME of the Game: Large-scale Analysis of DNS-based Tracking Evasion.Proceedings on Privacy Enhancing Technologies2021 (2021), 394 – 412. https://api.semanticscholar.org/CorpusID:231951672

    2021

  58. [2024]

    InProceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security

    Blocking Tracking JavaScript at the Function Granularity. InProceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security. 2177–2191

    2024

Pith tools

Reviewed August 4, 2026 · model on record in the stance chip above.