To WASM or Not to WASM: Evaluation of Browser Fingerprinting Defenses Under WASM based Obfuscation

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

To WASM or Not to WASM: Evaluation of Browser Fingerprinting Defenses Under WASM 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 ↗ Review JSON

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 v2 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 · ORCID

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

Signed reviews

No signed human review yet.

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 To WASM or Not to WASM: Evaluation of Browser Fingerprinting Defenses Under WASM based Obfuscation." pith.science (2026). https://pith.science/paper/IU75YZLP

@misc{pith2026250821219,
  author       = {Pith},
  title        = {Pith review of: To WASM or Not to WASM: Evaluation of Browser Fingerprinting Defenses Under WASM 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.