The WASM Cloak: Evaluating Browser Fingerprinting Defenses Under WebAssembly based Obfuscation

A H M Nazmus Sakib; Igor Bilogrevic; Joseph Spracklen; Mahsin Bin Akram; Murtuza Jadliwala; Raveen Wijewickrama; Sahan Kalutarage

REVIEW 1 major objections 6 minor 69 references

The WASM Cloak: Evaluating Browser Fingerprinting Defenses Under WebAssembly based Obfuscation

T0 review · 1 major / 6 minor · reviewed 2026-08-05 · deepseek-v4-flash

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

Pith's one-line read Translating fingerprinting JavaScript to WebAssembly evades research detectors but not browser-level defenses.

desk verdict First systematic test of WASM conversion as a fingerprinting-evasion trick; the core observation is plausible, but the headline numbers rest on functional-equivalence checks that are only rigorous on the controlled dataset. read the letter →

arxiv 2508.21219 v1 pith:IU75YZLP submitted 2025-08-28 cs.CR cs.ETcs.PL

A H M Nazmus Sakib , Mahsin Bin Akram , Joseph Spracklen , Sahan Kalutarage , Raveen Wijewickrama , Igor Bilogrevic , Murtuza Jadliwala This is my paper

classification cs.CRcs.ETcs.PL

keywords browserfingerprintingWebAssemblyobfuscationdetectionevasionJS-to-WASMconversionanti-fingerprintingdefensesAPI-levelinterceptionstaticanalysisdetectorsdynamic

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

This paper asks whether an adversary can hide browser fingerprinting by translating ordinary JavaScript fingerprinting scripts into WebAssembly (WASM), a low-level binary format that browsers execute alongside JavaScript. The authors build an automated pipeline that converts real-world fingerprinting scripts into functional WASM-obfuscated variants and test those variants against detectors from the research literature and against commercial in-browser defenses. They find a sharp split: research detectors that analyze JavaScript source code become fragile or completely inoperable, while browser extensions and built-in browser protections remain fully effective because they intercept at the API level rather than reading code. The paper also shows that a fully WASM-native fingerprinting technique, which avoids typical fingerprinting APIs, bypasses even those API-level defenses. If this holds, detection research must shift from JavaScript syntax toward WASM-aware and behavior-level monitoring; otherwise the next generation of tracking code may hide in plain sight.

What carries the argument

The load-bearing mechanism is the conversion pipeline: a JavaScript AST is recursively traversed, thirteen translation rules match general constructs (literals, loops, arrays, function definitions, control flow) and fingerprinting-specific patterns (canvas API calls, screen property accesses, sensitive functions like eval), and each match is replaced with AssemblyScript code compiled to a WASM binary plus JS glue that instantiates the module and binds exports back into the script. A greedy strategy maximizes how much of the original code moves into WASM; one rule uses an LLM to translate arbitrary JS function definitions into AssemblyScript. On the defense side, the key mechanism is API-leve

What would settle it

Take a sample of the real-world fingerprinting scripts that the pipeline converted, execute the original and converted versions in the same instrumented browser, and compare the fingerprint attributes each one collects and the fingerprint hash each one produces; if a large fraction of converted scripts return missing or different values, the evasion results reflect broken conversions, not effective obfuscation.

Watch

Extended reading notes

Core claim

The central claim is that WASM-based obfuscation of JavaScript fingerprinting creates a divergence in defense effectiveness: feature-based detectors from the literature are vulnerable, while API-level defenses are not. On the deep-learning static detector, recall on its own test set dropped from 77.78% to 44.44% after conversion; on the hybrid static-dynamic detector, the crawler used an old Firefox build with WASM disabled, so converted scripts were never processed at all. Retraining with balanced, category-aware WASM-converted samples restored the static detector to 98.12% accuracy on both JS and WASM test sets. All ten tested browser extensions and all five browser configurations remained

Load-bearing premise

The conversion pipeline preserves fingerprinting functionality in the real-world corpus: for controlled scripts the authors verify hash-output equivalence, but for the 10,742 real-world scripts they only check that the modified code parses and runs without exceptions, so if many converted scripts silently stop fingerprinting, the reported evasion would be an artifact of broken code rather than successful obfuscation.

Editorial extensions

If this is right

If a tracker converts fingerprinting scripts to WASM with the pipeline's ~85% success rate, research detectors that rely on JS source features can be degraded or disabled, depending on their training data and toolchain.
Balanced retraining that includes WASM-converted fingerprinting and non-fingerprinting scripts can restore a static detector's accuracy on both JS and WASM variants, suggesting the vulnerability is partially data, not just architecture.
Browser extensions and built-in defenses that spoof or block fingerprinting APIs stay effective against JS-to-WASM conversion, making API-level interception a more durable defense than source analysis.
A WASM-native fingerprinting technique that avoids canvas, WebGL, and other monitored APIs can bypass all tested API-centric defenses, meaning API-level defenses alone are insufficient against lower-level timing side channels.
No single conversion rule causes evasion; the combined effect of multiple rules is required, which justifies treating obfuscation as a holistic transformation rather than a single patch.
The one-shot conversion cost is amortized because fingerprinting scripts are reused across many users, so the attack is economically practical for real trackers.

Reading between the lines

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

A feature-aware adversary would likely outperform the greedy conversion: the paper's own feature-importance analysis shows which AST signals drive detection, and a targeted conversion that only hides those signals could achieve evasion with less code churn and less risk of breaking functionality.
The real-world conversion 'success' metric only checks parsing and execution, not fingerprint output equivalence; before claiming real-world evasion, one should measure whether converted scripts still return the same attribute values and API call sequences as their JS originals.
The robustness of API-level defenses is conditional on fingerprint signals flowing through JS-visible APIs; the success of native WASM timing fingerprinting suggests the next defensive layer should monitor WASM module instantiation, imported function boundary crossings, and execution timing rather than source syntax.
The paper's balanced-retraining result hints that future research detectors can be made WASM-aware cheaply, but no public model currently does this; a simple test is whether adding WASM-converted examples to training sets of other detectors generalizes beyond DeepFPD's features.

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.

Desk Editor's Note

read the letter

This is the first paper to systematically test JS-to-WASM conversion as a way to evade browser fingerprinting defenses. The underlying observation is probably right: feature-based academic detectors keyed to JS syntax are vulnerable to this kind of translation, while API-level defenses are structurally immune. The authors built a real conversion pipeline, released two datasets (a 124-script controlled set with paired JS/WASM variants and a large real-world crawl), and ran a broad evaluation across academic detectors, extensions, and browsers. The attribute-delta analysis showing why DeepFPD's features stop firing is a genuinely useful root-cause contribution, and the CDP-based dynamic detector proof-of-concept points in a sensible direction. Credit where due: the controlled dataset uses SHA-256 hash equivalence to verify conversions, which is the right way to do it.

The soft spots are mostly around how much the headline claims can actually bear. The biggest one is the functional-equivalence check on the real-world corpus. The paper verifies conversion only by "compiles, parses, executes without exceptions" for the 10,742 real-world scripts; it does not check that the converted scripts still perform fingerprinting. If a meaningful fraction silently break—no more canvas.toDataURL calls, no navigator reads—then the recall drops in Experiment 2 reflect broken inputs, not obfuscation. This is load-bearing, and the stress-test note has it right. The DeepFPD test-set drop (78% to 44%, on 18 fingerprinting scripts, so roughly six flips) is exactly where this matters. A small manual validation sample on real-world conversions would substantially fix this.

Second, DeepFPD is not actually DeepFPD. The paper reimplements it as a Random Forest using DeepFPD's features, because the original deep pipeline couldn't be reproduced. That is an honest and understandable choice, but it means the paper is not evaluating the published detector. The "state-of-the-art detectors show moderate vulnerability" claim is therefore weaker than the abstract suggests. Similarly, FP-Inspector's failure is a toolchain incompatibility—it runs on Firefox 52 without WASM support—not a successful evasion. That is a valid finding about detector maintenance, but it shouldn't be counted as evidence of WASM obfuscation working.

The "completely effective" conclusion for extensions also overstates. uBlock Origin, Privacy Badger, and Disconnect were never triggered in the local test setup; they do domain blocking, so the test doesn't exercise them. The tables are honest about this, but the abstract is not. Finally, there's no JS-only obfuscation baseline. Without one, we can't tell whether the evasion is WASM-specific or just obfuscation-generic.

Who is this for? People building fingerprinting detectors and anyone studying web obfuscation. It deserves a serious referee, but with major revisions: verify conversions, add a JS-obfuscation baseline, and recalibrate the claims in the abstract. I'd engage with it as a conditional, not a reject.

Referee Report

1 major / 6 minor

Summary. The paper proposes an automated JS-to-WASM conversion pipeline (13 translation rules, including LLM-based function translation) and uses it to construct obfuscated variants of real-world and controlled fingerprinting scripts. It introduces a newly crawled corpus of 7.5M JS scripts, of which 10,742 are heuristically labeled as fingerprinting, plus a controlled paired dataset of 124 scripts. The evaluation measures how two research detectors (DeepFPD and FP-Inspector), ten browser extensions, and five built-in browser defenses cope with WASM-obfuscated and native-WASM fingerprinting. The central claim is a divergence: research feature-based detectors are moderately vulnerable to WASM obfuscation (e.g., DeepFPD recall on its test set drops from 77.78% to 44.44%; FP-Inspector becomes unusable), while API-level extensions and browser defenses remain effective, except for a native WASM timing-based fingerprinting technique.

Significance. If the central empirical claim holds, the paper makes a useful contribution: it is among the first systematic studies of JS-to-WASM obfuscation against fingerprinting defenses, it releases a large-scale corpus and a controlled dataset, and it provides a root-cause feature-importance analysis. The finding that API-level interception is more robust than source-level feature analysis is credible and practically relevant. The paper also includes a proof-of-concept dynamic analysis detector, which strengthens the claim that modern dynamic instrumentation can complement static analysis. However, the strength of the evidence is currently limited by two load-bearing issues: functional equivalence is not verified for the real-world converted corpus, and the evaluated 'DeepFPD' is a Random Forest approximation rather than the originally proposed deep model. These issues need to be addressed before the divergence claim can be accepted as stated.

major comments (1)

[Table VII] The ablation study reports that no single rule changes DeepFPD classification metrics, but the individual success rates are low (9.70%–54.10%) and coverage is often near zero (e.g., 0.0004% for replace_with_regex). This means the ablation may be underpowered: most single-rule conversions do not meaningfully perturb the script. The conclusion that 'successful evasion requires a comprehensive obfuscation strategy' is not fully established by these data; it is also consistent with the interpretation that the rules only work when enough of the script is actually converted. Please discuss this alternative interpretation or add a coverage-threshold analysis.

minor comments (6)

[§IV-C, Table VIII] The text says the controlled dataset contains '32 JS scripts of 7 different types,' but the Introduction and Table VIII describe a controlled dataset of 124 scripts. Please clarify the relationship between base scripts and variants.
[Table II] The 'Mean ± SD' row reports success rate as 85.76% ± 1.26; use percentage points or add a note to avoid ambiguity.
[Table V] For Disconnect, Privacy Badger, and uBlock Origin, the 'Affected by WASM Conversion?' column says 'No,' but the notes state the tools were not triggered in the locally hosted setup. These should be labeled 'Not triggered in local setup' rather than 'No,' since the experiment cannot distinguish immunity from non-exercise.
[Figure 5] The axis label '1 0 flips' appears to be a typo for '10 flips.'
[§IV-B, Rule 9] LLM-generated AssemblyScript is validated only by compilation and execution. A short statement in the limitations that semantic equivalence of LLM-translated functions is not individually verified would be helpful.
[General] The paper does not include an explicit data/code availability statement. Given the emphasis on releasing a corpus and pipeline, please state whether the code, converted datasets, and detection implementations will be made available.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity; the paper is an empirical measurement study with independent test sets and no load-bearing self-citations.

full rationale

This is an empirical measurement study, not a derivation, so the circularity burden is low. The central claim that WASM conversion lowers DeepFPD's recall on its own test set from 77.78% to 44.44% is an experimentally measured result, not a quantity forced by construction: DeepFPD was trained on its original dataset and evaluated on independently labeled or manually constructed test sets, and the conversion rules were not fitted to DeepFPD's parameters. The real-world corpus is labeled using FP-Inspector heuristics, but FP-Inspector is not scored against that same label set; its failure in Experiment 2 is reported as a toolchain incompatibility (Firefox 52 ESR without WASM support), not as a self-referential detection result. The retraining augmentation was tuned post hoc, which is a selection/overfitting concern rather than circular reasoning. The functional-equivalence gap for real-world conversions—hash verification only on the controlled dataset, parse/execute checks elsewhere—is a threat to validity and is explicitly acknowledged in Section IV-C, but it does not make any prediction equivalent to its inputs. Citations to Wobfuscator and Guri et al. are external prior work used as motivation or technique, not as proof of the paper's own results, and no uniqueness theorem or self-citation chain is load-bearing. Therefore no circular step meets the evidentiary standard.

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

This is an empirical systems paper, so the ledger captures design choices and assumptions rather than fitted physical parameters. The main free parameter is the post hoc balanced augmentation composition that made retraining succeed; the main ad hoc assumptions are semantic preservation of LLM-translated functions and of the whole greedy conversion on real-world scripts. No invented entities such as new particles or forces are introduced.

free parameters (2)

Balanced augmentation composition = 414 Canvas, 537 AudioContext, 190 WebRTC, 525 non-fingerprinting
Post hoc configuration chosen after category-wise augmentation impaired accuracy; the reported retraining result depends on this exact balance.
Random Forest vocabulary size = 5000
Bounded bag-of-words features for the DeepFPD reimplementation; changes the feature space and could affect evasion outcomes.

assumptions (4)

domain assumption WebAssembly.instantiate behaves per spec in modern browsers
The conversion pipeline's IIAFE wrapper and async instantiation rely on standard WASM APIs; assumed functional in the Chrome/Firefox test environments.
domain assumption FP-Inspector heuristic labels of fingerprinting scripts are accurate
Real-world corpus labeling uses FP-Inspector's heuristics (Section IV-C); if labels are noisy, training and test sets inherit errors.
ad hoc to paper LLM-translated AssemblyScript preserves original JS function semantics
Rule 9 uses Qwen2.5-Coder-14B to translate function bodies; correctness is validated only by runtime execution without exceptions, not by output equivalence on real-world scripts.
ad hoc to paper Execution without runtime exceptions implies functional preservation
The three-stage validation in Section V-A checks compilation, parsing, and execution, but does not compare fingerprint outputs for real-world scripts.

how reviews work

0 comments

Cite this review

Pith. "Pith review of The WASM Cloak: Evaluating Browser Fingerprinting Defenses Under WebAssembly based Obfuscation." pith.science (2026). https://pith.science/paper/IU75YZLP

@misc{pith2026250821219,
  author       = {Pith},
  title        = {Pith review of: The WASM Cloak: Evaluating Browser Fingerprinting Defenses Under WebAssembly based Obfuscation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/IU75YZLP}},
  note         = {Machine review of arXiv:2508.21219}
}

read the original abstract

Browser fingerprinting defenses have historically focused on detecting JavaScript(JS)-based tracking techniques. However, the widespread adoption of WebAssembly (WASM) introduces a potential blind spot, as adversaries can convert JS to WASM's low-level binary format to obfuscate malicious logic. This paper presents the first systematic evaluation of how such WASM-based obfuscation impacts the robustness of modern fingerprinting defenses. We develop an automated pipeline that translates real-world JS fingerprinting scripts into functional WASM-obfuscated variants and test them against two classes of defenses: state-of-the-art detectors in research literature and commercial, in-browser tools. Our findings reveal a notable divergence: detectors proposed in the research literature that rely on feature-based analysis of source code show moderate vulnerability, stemming from outdated datasets or a lack of WASM compatibility. In contrast, defenses such as browser extensions and native browser features remained completely effective, as their API-level interception is agnostic to the script's underlying implementation. These results highlight a gap between academic and practical defense strategies and offer insights into strengthening detection approaches against WASM-based obfuscation, while also revealing opportunities for more evasive techniques in future attacks.

Figures

Figures reproduced from arXiv: 2508.21219 by the authors.

**Figure 2.** Conversion pipeline. the compiled WASM module in place of the original code. 3) The artifacts from all matched rules are aggregated: AssemblyScript snippets are merged into a single file and compiled into a WASM binary; import object entries are unified into a single import object; and glue code snippets are inserted into the original JS at their respective positions. Overlapping replacements are filtered out to p… view at source ↗

**Figure 3.** Conversion performance by fingerprinting category [PITH_FULL_IMAGE:figures/full_fig_p009_3.png] view at source ↗

Figures from the paper (5 more)

**Figure 4.** Figure 4: Classification metrics for DeepFPD dataset for JS and [PITH_FULL_IMAGE:figures/full_fig_p010_4.png]

**Figure 5.** Figure 5: Aggregated delta plot of feature contribution changes. [PITH_FULL_IMAGE:figures/full_fig_p011_5.png]

**Figure 7.** Figure 7: Change in DeepFPD feature contributions for repre [PITH_FULL_IMAGE:figures/full_fig_p017_7.png]

**Figure 8.** Figure 8: Confusion matrices for DeepFPD predictions on orig [PITH_FULL_IMAGE:figures/full_fig_p017_8.png]

**Figure 6.** Figure 6: Running mean and 95% confidence intervals of conversion metrics on the real-world dataset. [PITH_FULL_IMAGE:figures/full_fig_p018_6.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

69 extracted references · 68 canonical work pages

[1]

Beauty and the beast: Diverting modern web browsers to build unique browser fingerprints,

P. Laperdrix, W. Rudametkin, and B. Baudry, “Beauty and the beast: Diverting modern web browsers to build unique browser fingerprints,” in 2016 IEEE Symposium on Security and Privacy (SP) , 2016

work page 2016
[2]

The web never forgets: Persistent tracking mechanisms in the wild,

G. Acar, C. Eubank, S. Englehardt, M. Juarez, A. Narayanan, and C. Diaz, “The web never forgets: Persistent tracking mechanisms in the wild,” in 2014 ACM SIGSAC Conference on Computer and Com- munications Security (CCS) , 2014

work page 2014
[3]

Alexa Top Websites — Last Save before it was closed — expired- domains.net,

“Alexa Top Websites — Last Save before it was closed — expired- domains.net,” https://www.expireddomains.net/alexa-top-websites/, [Accessed 21-07-2025]

work page 2025
[4]

Fingerprinting the fingerprinters: Learning to detect browser fingerprinting behaviors,

U. Iqbal, S. Englehardt, and Z. Shafiq, “Fingerprinting the fingerprinters: Learning to detect browser fingerprinting behaviors,” inIEEE SP. IEEE, 2021

work page 2021
[5]

Browser fingerprinting market size and forecast,

“Browser fingerprinting market size and forecast,” verified Market Research, 2023. [Online]. Available: https://www.verifiedmarketresearc h.com/product/browser-fingerprinting-market/

work page 2023
[6]

Online tracking: A 1-million-site measurement and analysis,

S. Englehardt and A. Narayanan, “Online tracking: A 1-million-site measurement and analysis,” in 2016 ACM SIGSAC Conference on Computer and Communications Security (CCS) , 2016

work page 2016
[7]

Cookieless monster: Exploring the ecosystem of web-based device fingerprinting,

N. Nikiforakis, A. Kapravelos, W. Joosen, C. Kruegel, F. Piessens, and G. Vigna, “Cookieless monster: Exploring the ecosystem of web-based device fingerprinting,” in 2013 IEEE Symposium on Security and Privacy (SP), 2013

work page 2013
[8]

Fpdetective: Dusting the web for fingerprinters,

G. Acar, M. Juarez, N. Nikiforakis, C. Diaz, S. G ¨urses, F. Piessens, and B. Preneel, “Fpdetective: Dusting the web for fingerprinters,” in 2013 ACM SIGSAC Conference on Computer & Communications Security (CCS), 2013

work page 2013

Show all 69 references

[9]

Bringing the web up to speed with webassembly,

A. Haas, A. Rossberg, D. L. Schuff, B. L. Titzer, M. Holman, D. Gohman, L. Wagner, A. Zakai, and J. Bastien, “Bringing the web up to speed with webassembly,” in 38th ACM SIGPLAN conference on programming language design and implementation , 2017

2017
[10]

Wobfuscator: Obfuscating javascript malware via opportunistic translation to we- bassembly,

A. Romano, D. Lehmann, M. Pradel, and W. Wang, “Wobfuscator: Obfuscating javascript malware via opportunistic translation to we- bassembly,” in 2022 IEEE Symposium on Security and Privacy (SP) , 2022

2022
[11]

Webassembly usage statistics,

“Webassembly usage statistics,” can I Use, accessed 2024. [Online]. Available: https://caniuse.com/?search=WebAssembly

2024
[12]

Browser-based cpu finger- printing,

L. Trampert, C. Rossow, and M. Schwarz, “Browser-based cpu finger- printing,” in European Symposium on Research in Computer Security , 2022

2022
[13]

Audio-aware applications at the edge using in-browser webassembly and fingerprinting,

D. Pisan `o and A. Servetti, “Audio-aware applications at the edge using in-browser webassembly and fingerprinting,” in 2023 4th International Symposium on the Internet of Sounds , 2023

2023
[14]

The finger in the power: How to fingerprint pcs by monitoring their power consumption,

M. Botvinnik, T. Laor, T. Rokicki, C. Maurice, and Y . Oren, “The finger in the power: How to fingerprint pcs by monitoring their power consumption,” in International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment , 2023

2023
[15]

Browser fingerprinting using webassembly,

M. Guri and D. Fibert, “Browser fingerprinting using webassembly,”
[16]

How unique is your web browser?

P. Eckersley, “How unique is your web browser?” in Privacy Enhancing Technologies, 2010

2010
[17]

”any person. . . a pamphleteer

J. R. Mayer, “”any person. . . a pamphleteer” internet anonymity in the age of web 2.0,” https://dataspace.princeton.edu/handle/88435/dsp01nc 580n467, [Accessed 26-10-2024]

2024
[18]

Fingerprinting information in javascript implementations,

K. Mowery, D. Bogenreif, S. Yilek, and H. Shacham, “Fingerprinting information in javascript implementations,” 2011. [Online]. Available: https://api.semanticscholar.org/CorpusID:6066432

2011
[19]

Fast and reliable browser identification with javascript engine fingerprinting,

M. Mulazzani, P. Reschl, M. Huber, M. Leithner, S. Schrittwieser, and E. R. Weippl, “Fast and reliable browser identification with javascript engine fingerprinting,” 2013. [Online]. Available: https: //api.semanticscholar.org/CorpusID:497284

2013
[20]

Shpf: Enhancing http(s) session security with browser fingerprinting,

T. Unger, M. Mulazzani, D. Fr ¨uhwirt, M. Huber, S. Schrittwieser, and E. Weippl, “Shpf: Enhancing http(s) session security with browser fingerprinting,” in 2013 International Conference on Availability, Reli- ability and Security , 2013

2013
[21]

Web browser finger- printing using only cascading style sheets,

N. Takei, T. Saito, K. Takasu, and T. Yamada, “Web browser finger- printing using only cascading style sheets,” in 2015 10th International Conference on Broadband and Wireless Computing, Communication and Applications (BWCCA) , 2015

2015
[22]

Pixel perfect : Fingerprinting canvas in html 5,

K. Mowery and H. Shacham, “Pixel perfect : Fingerprinting canvas in html 5,” 2012. [Online]. Available: https://api.semanticscholar.org/Corp usID:1399943

2012
[23]

The web never forgets: Persistent tracking mechanisms in the wild,

G. Acar, C. Eubank, S. Englehardt, M. Juarez, A. Narayanan, and C. Diaz, “The web never forgets: Persistent tracking mechanisms in the wild,” in 2014 ACM SIGSAC Conference on Computer and Com- munications Security , 2014

2014
[24]

Hardware fingerprinting using html5,

G. Nakibly, G. Shelef, and S. Yudilevich, “Hardware fingerprinting using html5,” ArXiv, vol. abs/1503.01408, 2015. [Online]. Available: https://api.semanticscholar.org/CorpusID:1520368

2015 arXiv
[25]

(cross-)browser fingerprinting via os and hardware level features,

Y . Cao, S. Li, and E. Wijmans, “(cross-)browser fingerprinting via os and hardware level features,” in Network and Distributed System Security Symposium , 2017. [Online]. Available: https://api.semanticsc holar.org/CorpusID:8297353

2017
[26]

Online tracking: A 1-million-site measurement and analysis,

S. Englehardt and A. Narayanan, “Online tracking: A 1-million-site measurement and analysis,” in Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security , 2016

2016
[27]

Fingerprinting web users through font metrics,

D. Fifield and S. Egelman, “Fingerprinting web users through font metrics,” in Financial Cryptography , 2015. [Online]. Available: https://api.semanticscholar.org/CorpusID:42777664

2015
[28]

The leaking battery - a privacy analysis of the html5 battery status api,

L. Olejnik, G. Acar, C. Castelluccia, and C. D ´ıaz, “The leaking battery - a privacy analysis of the html5 battery status api,” in DPM/QASA@ESORICS, 2015. [Online]. Available: https://api.semantic scholar.org/CorpusID:2843450

2015
[29]

Canvas defender,

“Canvas defender,” https://addons.mozilla.org/en-US/firefox/addon/no-c anvas-fingerprinting/, [Accessed 26-10-2024]

2024
[30]

Cross-browser fingerprinting test 2.0 — fingerprint.pet-portal.eu,

G. G. f.-p. K. Boda, ´A.M. F¨oldes, “Cross-browser fingerprinting test 2.0 — fingerprint.pet-portal.eu,” https://fingerprint.pet-portal.eu/?menu=6, [Accessed 26-10-2024]

2024
[31]

The effectiveness of privacy enhancing technologies against fingerprinting,

A. Datta, J. Lu, and M. C. Tschantz, “The effectiveness of privacy enhancing technologies against fingerprinting,” CoRR, 2018. [Online]. Available: http://arxiv.org/abs/1812.03920

2018 arXiv
[32]

Fingerprinting Protection Mode — github.com,

“Fingerprinting Protection Mode — github.com,” https://github.com/b rave/browser-laptop/wiki/Fingerprinting-Protection-Mode, [Accessed 27-10-2024]

2024
[33]

The Design and Implementation of the Tor Browser [DRAFT] — 2019.www.torproject.org,

“The Design and Implementation of the Tor Browser [DRAFT] — 2019.www.torproject.org,” https://2019.www.torproject.org/projects /torbrowser/design/#fingerprinting-defenses, [Accessed 27-10-2024]

2019
[34]

Privacy Badger — eff.org,

P. Badger, “Privacy Badger — eff.org,” https://www.eff.org/privacybad ger, [Accessed 27-10-2024]

2024
[35]

Disconnect — disconnect.me,

Disconect, “Disconnect — disconnect.me,” https://disconnect.me/tracke rprotection, [Accessed 27-10-2024]

2024
[36]

Fp-radar: Longitudinal measurement and early detection of browser fingerprinting,

P. N. Bahrami, U. Iqbal, and Z. Shafiq, “Fp-radar: Longitudinal measurement and early detection of browser fingerprinting,”Proceedings on Privacy Enhancing Technologies , 2021. [Online]. Available: https://api.semanticscholar.org/CorpusID:244896504

2021
[37]

Fprobe: The flow-centric detection and a large-scale measurement of browser fingerprinting,

R. Zhao, “Fprobe: The flow-centric detection and a large-scale measurement of browser fingerprinting,” 2023 32nd International Conference on Computer Communications and Networks (ICCCN) ,

2023
[38]

Deepfpd: Browser fingerprinting detection via deep learning with multimodal learning and attention,

W. Qiang, K. Ren, Y . Wu, D. Zou, and H. Jin, “Deepfpd: Browser fingerprinting detection via deep learning with multimodal learning and attention,” IEEE Transactions on Reliability , 2024

2024
[39]

From asm.js to webassembly,

B. Eich, “From asm.js to webassembly,” brendaneich.com/2015/06/fr om-asm-js-to-webassembly/, [Accessed 27-10-2024]

2015
[40]

An empirical study of real- world webassembly binaries: Security, languages, use cases,

A. Hilbig, D. Lehmann, and M. Pradel, “An empirical study of real- world webassembly binaries: Security, languages, use cases,” in Pro- ceedings of the web conference 2021 , 2021

2021
[41]

Assemblyscript - typescript to webassembly compiler,

A. Contributors, “Assemblyscript - typescript to webassembly compiler,” https://www.assemblyscript.org/, 2025, accessed: 2025-01-09

2025
[42]

Webassembly,

M. Contributors, “Webassembly,” 2024, accessed: 2024-12-23. [Online]. Available: https://developer.mozilla.org/en-US/docs/WebAssembly

2024
[43]

Client Challenge — pypi.org,

“Client Challenge — pypi.org,” https://pypi.org/project/pyesprima/, [Accessed 22-07-2025]

2025
[44]

Qwen2. 5-coder technical report,

B. Hui, J. Yang, Z. Cui, J. Yang, D. Liu, L. Zhang, T. Liu, J. Zhang, B. Yu, K. Dang et al., “Qwen2. 5-coder technical report,” arXiv preprint arXiv:2409.12186, 2024

2024 arXiv
[45]

GitHub - zakird/crux-top-lists: Downloadable snapshots of the Chrome Top Million Websites pulled from public CrUX data in Google Big- Query. — github.com,

“GitHub - zakird/crux-top-lists: Downloadable snapshots of the Chrome Top Million Websites pulled from public CrUX data in Google Big- Query. — github.com,” https://github.com/zakird/crux- top- lists, [Accessed 31-07-2025]

2025
[46]

GitHub - Daninet/hash-wasm: Lightning fast hash functions using hand- tuned WebAssembly binaries — github.com

“GitHub - Daninet/hash-wasm: Lightning fast hash functions using hand- tuned WebAssembly binaries — github.com.”
[47]

Random sampling with a reservoir,

J. S. Vitter, “Random sampling with a reservoir,” ACM Transactions on Mathematical Software (TOMS) , 1985

1985
[48]

JShelter (chrome extension),

“JShelter (chrome extension),” https://chromewebstore.google.com/deta il/ammoloihpcbognfddfjcljgembpibcmb, version 0.20.2; 10,000 users; accessed 29 Jul 2025

2025
[49]

Trace – Online Tracking Protection (chrome extension),

“Trace – Online Tracking Protection (chrome extension),” https://chro mewebstore.google.com/detail/njkmjblmcfiobddjgebnoeldkjcplfjb, 20,000 users; accessed 29 Jul 2025

2025
[50]

Chameleon (firefox extension),

“Chameleon (firefox extension),” https://addons.mozilla.org/en-US/firef ox/addon/chameleon-ext/, 8,436 users; accessed 29 Jul 2025

2025
[51]

CanvasBlocker – Fingerprint Protect (firefox extension),

“CanvasBlocker – Fingerprint Protect (firefox extension),” https://addons .mozilla.org/en-US/firefox/addon/canvasblocker/, version 1.11; 39,075 users; accessed 29 Jul 2025

2025
[52]

Canvas Fingerprint Defender (chrome extension),

Yubi, “Canvas Fingerprint Defender (chrome extension),” https://chrome webstore.google.com/detail/lanfdkkpgfjfdikkncbnojekcppdebfp, version 0.2.2; 80 000 users; accessed 29 Jul 2025

2025
[53]

Random User-Agent (Switcher) (chrome extension),

“Random User-Agent (Switcher) (chrome extension),” https://chromewe bstore.google.com/detail/einpaelgookohagofgnnkcfjbkkgepnp, 100,000 users; accessed 29 Jul 2025

2025
[54]

Privacy Badger (chrome extension),

Electronic Frontier Foundation, “Privacy Badger (chrome extension),” https://chromewebstore.google.com/detail/pkehgijcmpdhfbdbbnkijodmd jhbjlgp, 1,000,000 users; accessed 29 Jul 2025

2025
[55]

Browser Fingerprint Protector (chrome extension),

“Browser Fingerprint Protector (chrome extension),” https://chromewe bstore.google.com/detail/kcklikpoajnpdpjgamjfepagpdkhahpn, 2,000 users; accessed 29 Jul 2025

2025
[56]

Disconnect (chrome extension),

“Disconnect (chrome extension),” https://chromewebstore.google.com/ detail/jeoacafpbcihiomhlakheieifhpjdfeo, 400,000 users; accessed 29 Jul 2025

2025
[57]

uBlock Origin (chrome extension),

R. Hill, “uBlock Origin (chrome extension),” https://chromewebstore.g oogle.com/detail/cjpalhdlnbpafiamejdnhcphjbkeiagm, 20,000,000 users; accessed 29 Jul 2025

2025
[58]

Brave browser, version 1.80.124,

“Brave browser, version 1.80.124,” https://brave.com/latest/, stable release 1.80.124, 23 Jul 2025; accessed 30 Jul 2025

2025
[59]

Google chrome browser, version 138.0.7204.183,

Google, “Google chrome browser, version 138.0.7204.183,” https://chro mereleases.googleblog.com/2025/07/stable-channel-update-for-desktop .html, stable channel update 29 Jul 2025; accessed 30 Jul 2025

2025
[60]

Microsoft edge browser, version 138.0.3351.109,

Microsoft, “Microsoft edge browser, version 138.0.3351.109,” https://le arn.microsoft.com/en-us/deployedge/microsoft-edge-relnote-stable-cha nnel, stable release 25 Jul 2025; accessed 30 Jul 2025

2025
[61]

Firefox web browser, version 141.0,

Mozilla, “Firefox web browser, version 141.0,” https://www.firefox.com /en-US/firefox/141.0/releasenotes/, stable release 141.0, 22 Jul 2025; accessed 30 Jul 2025

2025
[62]

Opera browser, version 120.0.5543.93,

O. Software, “Opera browser, version 120.0.5543.93,” https://blogs.op era.com/desktop/2025/07/opera-120-0-5543-93-stable-update/, stable release 17 Jul 2025; accessed 30 Jul 2025

2025
[63]

Client Challenge — pypi.org,

“Client Challenge — pypi.org,” https://pypi.org/project/treeinterpreter/, [Accessed 30-07-2025]

2025
[64]

Chrome DevTools Protocol — chromedevtools.github.io,

“Chrome DevTools Protocol — chromedevtools.github.io,” https://chro medevtools.github.io/devtools-protocol/, [Accessed 31-07-2025]. APPENDIX A. Remainder of Translation Rules Rule 3 – Replace Integer and Float Arrays: This rule identifies array declarations initialized exclusi...

2025
[67]

Conversion Metrics: Figure 6 shows the running mean and 95% confidence intervals for four key metrics; Success Rate, Conversion Coverage, Mean Conversion Time, and Size Change for real-world dataset
[68]

Figure 8 provides confusion matrices comparing classification outcomes on JS vs

DeepFPD Model Analysis: We visualize the shift in feature attribution scores for representative samples from the DeepFPD test set in Figure 7. Figure 8 provides confusion matrices comparing classification outcomes on JS vs. W ASM- obfuscated scripts under the DeepFPD model. TA...
[69]

Conversion Performance by Category: Table IX reports pipeline-level performance (e.g., coverage and success rate) across different fingerprinting categories in our dataset. 2 4 6 8 10 Iteration 85 86 87Success Rate (%) Success Rate (%) 2 4 6 8 10 Iteration 22 24 26Conversion C...
[2023]

Available: https://api.semanticscholar.org/CorpusID: 261434721

[Online]. Available: https://api.semanticscholar.org/CorpusID: 261434721
[2025]

Available: https://arxiv.org/abs/2506.00719

[Online]. Available: https://arxiv.org/abs/2506.00719

arXiv

Pith tools

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

[1] [1]

Beauty and the beast: Diverting modern web browsers to build unique browser fingerprints,

P. Laperdrix, W. Rudametkin, and B. Baudry, “Beauty and the beast: Diverting modern web browsers to build unique browser fingerprints,” in 2016 IEEE Symposium on Security and Privacy (SP) , 2016

work page 2016

[2] [2]

The web never forgets: Persistent tracking mechanisms in the wild,

G. Acar, C. Eubank, S. Englehardt, M. Juarez, A. Narayanan, and C. Diaz, “The web never forgets: Persistent tracking mechanisms in the wild,” in 2014 ACM SIGSAC Conference on Computer and Com- munications Security (CCS) , 2014

work page 2014

[3] [3]

Alexa Top Websites — Last Save before it was closed — expired- domains.net,

“Alexa Top Websites — Last Save before it was closed — expired- domains.net,” https://www.expireddomains.net/alexa-top-websites/, [Accessed 21-07-2025]

work page 2025

[4] [4]

Fingerprinting the fingerprinters: Learning to detect browser fingerprinting behaviors,

U. Iqbal, S. Englehardt, and Z. Shafiq, “Fingerprinting the fingerprinters: Learning to detect browser fingerprinting behaviors,” inIEEE SP. IEEE, 2021

work page 2021

[5] [5]

Browser fingerprinting market size and forecast,

“Browser fingerprinting market size and forecast,” verified Market Research, 2023. [Online]. Available: https://www.verifiedmarketresearc h.com/product/browser-fingerprinting-market/

work page 2023

[6] [6]

Online tracking: A 1-million-site measurement and analysis,

S. Englehardt and A. Narayanan, “Online tracking: A 1-million-site measurement and analysis,” in 2016 ACM SIGSAC Conference on Computer and Communications Security (CCS) , 2016

work page 2016

[7] [7]

Cookieless monster: Exploring the ecosystem of web-based device fingerprinting,

N. Nikiforakis, A. Kapravelos, W. Joosen, C. Kruegel, F. Piessens, and G. Vigna, “Cookieless monster: Exploring the ecosystem of web-based device fingerprinting,” in 2013 IEEE Symposium on Security and Privacy (SP), 2013

work page 2013

[8] [8]

Fpdetective: Dusting the web for fingerprinters,

G. Acar, M. Juarez, N. Nikiforakis, C. Diaz, S. G ¨urses, F. Piessens, and B. Preneel, “Fpdetective: Dusting the web for fingerprinters,” in 2013 ACM SIGSAC Conference on Computer & Communications Security (CCS), 2013

work page 2013