{"id":"22e83d74-4574-404b-8ec2-8ec77127b3d0","arxiv_id":"2508.21219","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"WebAssembly-obfuscated fingerprinting scripts evade some academic detectors but not API-level browser defenses.","lead":"A security study converts real-world JavaScript fingerprinting scripts into WebAssembly variants and tests whether current detection tools still catch them. It finds academic source-code detectors are weakened, while browser-level API defenses largely hold up.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Unverified functional equivalence of converted real-world scripts confounds the main evasion result; if conversions break fingerprinting, detector drops are not evidence of obfuscation.","rationale":"The reader's weakest_assumption identifies the same load-bearing concern: functional equivalence is only verified for the controlled dataset, while the real-world corpus and the DeepFPD test set rely on weaker 'executes without exception' checks. This is indeed the most critical threat to the paper's main claim. If conversion breaks scripts, the detection drops in Experiment 2 are trivial, and the 'moderate vulnerability' conclusion collapses. The paper's controlled dataset hash verification is a strong positive, but it does not cover the scripts used in the key Scenario 1 result. The proposed concrete test directly checks functionality preservation on the actual evaluation inputs, which would settle whether the concern lands. I agree with the reader's conditional verdict because the paper's core direction is credible but the evidence is incomplete; adding this verification could strengthen it substantially.","tokens_in":24010,"tokens_out":5163,"duration_ms":52244,"concrete_test":"Take the 18 fingerprinting scripts from DeepFPD's test set used in Scenario 1 and the 400 real-world fingerprinting scripts from one evaluation subset. For each script, execute the original JS and its WASM-converted version in a headless Chromium with CDP breakpoints on fingerprinting APIs (navigator, screen, canvas.toDataURL, AudioContext). Compare (a) the set of fingerprinting APIs invoked and (b) the fingerprint output (e.g., canvas hash, navigator properties) between original and converted versions. If any converted script fails to invoke the same APIs or produce the same output as its original, flag it as broken. If >5% of sampled scripts are broken, the Experiment 2 recall drops are confounded and the evasion claim requires re-evaluation with only functionally equivalent pairs.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim that WASM conversion evades feature-based detectors rests on Experiment 2, where DeepFPD recall drops from 77.78% to 44.44% on its test set (Table III). This comparison is only meaningful if the converted scripts still perform fingerprinting. The paper verifies functional equivalence via SHA-256 hash outputs only for the 124-script controlled dataset (Section IV-C). For the 10,742 real-world scripts and the DeepFPD test set, success is defined as compiling, parsing, and executing without runtime exceptions (Section V-A). Such checks cannot detect silent functional breakage: a converted script may no longer call canvas.toDataURL or navigator APIs, yet still execute without errors. Since 75% of the original JS remains unconverted (mean coverage 25.01%, Table II), the pipeline may also introduce glitches in the converted portions, especially via LLM-generated Rule 9 translations, which are not deterministic. If a substantial fraction of converted scripts silently stop fingerprinting, the observed detection drop reflects broken inputs, not obfuscation. This is load-bearing because the abstract's 'moderate vulnerability' claim is primarily supported by that drop.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":24284,"tokens_out":4932,"duration_ms":53017,"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":[{"comment":"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.","section":"Table VII"}],"minor_comments":[{"comment":"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.","section":"§IV-C, Table VIII"},{"comment":"The 'Mean ± SD' row reports success rate as 85.76% ± 1.26; use percentage points or add a note to avoid ambiguity.","section":"Table II"},{"comment":"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.","section":"Table V"},{"comment":"The axis label '1  0 flips' appears to be a typo for '10 flips.'","section":"Figure 5"},{"comment":"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.","section":"§IV-B, Rule 9"},{"comment":"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.","section":"General"}],"recommendation":"major_revision","confidential_remarks":"The paper has a solid empirical core and the controlled dataset is a valuable asset. However, the central 'divergence' claim is currently supported by (a) a Random Forest approximation of DeepFPD, (b) an FP-Inspector result that is better characterized as toolchain incompatibility than evasion, and (c) real-world conversions whose functional preservation is not verified. These are fixable with additional experiments and more careful framing, but they are load-bearing, so I recommend major revision rather than acceptance at this stage."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","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.\n\nThe 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.\n\nSecond, 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.\n\nThe \"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.\n\nWho 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.","headline":"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.","tokens_in":24771,"tokens_out":2567,"would_cite":true,"duration_ms":28524,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Translating fingerprinting JavaScript to WebAssembly evades research detectors but not browser-level defenses.","keywords":["browser fingerprinting","WebAssembly obfuscation","fingerprinting detection evasion","JS-to-WASM conversion","anti-fingerprinting defenses","API-level interception","static analysis detectors","dynamic analysis"],"falsifier":"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.","tokens_in":23932,"feed_emoji":"🕶️","tokens_out":4663,"duration_ms":49105,"temperature":0.7,"pith_summary":"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.","feed_headline":"WASM obfuscation blinds research detectors, not browser defenses","feed_subtitle":"Automated JS-to-WebAssembly conversion degrades or disables source-based detectors, while API-level blocking holds.","key_machinery":"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","core_discovery":"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","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Shows that selective JS-to-WASM translation can evade malware detectors; several of the paper's conversion rules are inspired by this approach.","marker":"[10]"},{"why":"Supplies the hybrid static-dynamic detector evaluated here and the heuristic pipeline used to label real-world fingerprinting scripts.","marker":"[4]"},{"why":"Supplies the feature-extraction pipeline (AST tokens, control-flow graphs) on which the paper builds its static detector, plus the original training and test sets.","marker":"[38]"},{"why":"Documents the only known native WASM fingerprinting technique, which the paper tests against all browser defenses.","marker":"[15]"},{"why":"The AssemblyScript compiler used to turn generated TypeScript-like snippets into WASM binaries.","marker":"[41]"},{"why":"The LLM used by the function-definition translation rule to convert arbitrary JS functions into AssemblyScript.","marker":"[44]"},{"why":"Provides the May 2025 CrUX Top-1M snapshot from which the real-world JavaScript corpus is crawled.","marker":"[45]"},{"why":"Supplies the WASM hashing library used to build one of the controlled obfuscation variants.","marker":"[46]"},{"why":"Chrome DevTools Protocol underpins the proof-of-concept dynamic detector that catches both original and WASM-converted scripts at the engine level.","marker":"[64]"}],"fun_headline_variants":["WASM obfuscation blinds research detectors, not browser defenses","JS-to-WASM conversion evades research detectors, API-level holds","WASM fingerprinting bypasses academic tools; browsers stay immune","WASM obfuscation exposes detector blind spot in research"],"cache_read_input_tokens":2688,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["WASM obfuscation blinds research detectors, not browser defenses","JS-to-WASM conversion evades research detectors, API-level holds","WASM fingerprinting bypasses academic tools; browsers stay immune","WASM obfuscation exposes detector blind spot in research"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.00026,"raw_usage":{"total_tokens":1428,"prompt_tokens":750,"completion_tokens":678,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":494,"completion_tokens_details":{"reasoning_tokens":601}},"tokens_in":494,"tokens_out":678,"duration_ms":6673,"temperature":1.0,"reasoning_tokens":601,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-05T14:27:25.810354+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"Wobfuscator: Obfuscating javascript malware via opportunistic translation to we- bassembly,","cited_arxiv_id":null,"evidence_quote":"Shows that selective JS-to-WASM translation can evade malware detectors; several of the paper's conversion rules are inspired by this approach."},{"cited_title":"Fingerprinting the fingerprinters: Learning to detect browser fingerprinting behaviors,","cited_arxiv_id":null,"evidence_quote":"Supplies the hybrid static-dynamic detector evaluated here and the heuristic pipeline used to label real-world fingerprinting scripts."},{"cited_title":"Deepfpd: Browser fingerprinting detection via deep learning with multimodal learning and attention,","cited_arxiv_id":null,"evidence_quote":"Supplies the feature-extraction pipeline (AST tokens, control-flow graphs) on which the paper builds its static detector, plus the original training and test sets."},{"cited_title":"Browser fingerprinting using webassembly,","cited_arxiv_id":null,"evidence_quote":"Documents the only known native WASM fingerprinting technique, which the paper tests against all browser defenses."},{"cited_title":"Assemblyscript - typescript to webassembly compiler,","cited_arxiv_id":null,"evidence_quote":"The AssemblyScript compiler used to turn generated TypeScript-like snippets into WASM binaries."},{"cited_title":"GitHub - zakird/crux-top-lists: Downloadable snapshots of the Chrome Top Million Websites pulled from public CrUX data in Google Big- Query. — github.com,","cited_arxiv_id":null,"evidence_quote":"Provides the May 2025 CrUX Top-1M snapshot from which the real-world JavaScript corpus is crawled."},{"cited_title":"GitHub - Daninet/hash-wasm: Lightning fast hash functions using hand- tuned WebAssembly binaries — github.com","cited_arxiv_id":null,"evidence_quote":"Supplies the WASM hashing library used to build one of the controlled obfuscation variants."},{"cited_title":"Chrome DevTools Protocol — chromedevtools.github.io,","cited_arxiv_id":null,"evidence_quote":"Chrome DevTools Protocol underpins the proof-of-concept dynamic detector that catches both original and WASM-converted scripts at the engine level."}],"review_version":1}