{"id":"225854b7-359a-49af-8e9d-2cf80e1cc73f","arxiv_id":"2509.09950","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"ByteDefender uses a Transformer trained on V8 bytecode to label individual JavaScript functions as fingerprinting or not, claiming function-level detection with 4% page-load overhead.","lead":"A new system called ByteDefender reads the low-level bytecode that Chrome's V8 engine generates for JavaScript functions, and learns to spot functions that look like browser fingerprinting before they run. It reports high accuracy on 100,000 sites and adds about 4% to page load time, but its ground-truth labels come from predefined API patterns, so the result is only as strong as those patterns.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Ground truth for FP labels relies on four heuristics over high-entropy API traces; functions with no matching trace are labeled non-FP, so headline metrics may measure agreement with the heuristic, not real fingerprinting.","rationale":"The reader's weakest assumption is exactly the heuristic ground truth and the exclusion of anonymous/eval-loaded functions. My reading agrees: the strongest advertised numbers are all measured against a label source that is itself derived from the high-entropy API patterns the system claims to detect. The paper is well organized, with careful deduplication and train/test separation, and the idea of analyzing V8 bytecode at function level is plausible and worth pursuing. But the accuracy, precision, and recall figures cannot be interpreted as detection quality unless the labels are independently validated. The bytecode representation deliberately drops operands, so the model has no direct access to API names; it must rely on opcode-sequence correlations that are learned from the heuristic labels. If those labels misclassify actual fingerprinting functions as non-FP because traces are incomplete or heuristics are too narrow, the reported metrics may reflect the heuristic's definition rather than real-world fingerprinting. This is a correctable empirical issue, not a fundamental flaw, so the conditional verdict remains appropriate. The proposed test—independent labeling of a stratified test-set sample—directly measures label quality and would settle whether the concern lands.","tokens_in":25772,"tokens_out":4237,"duration_ms":48158,"concrete_test":"Take a stratified random sample of 1,000 functions from the held-out test set (500 labeled FP, 500 labeled non-FP). Independently determine true fingerprinting status by inspecting the original source and/or replaying the page with an independent, complete instrumenter that wraps every high-entropy API getter/method from Table 5 and records full call stacks (e.g., Puppeteer + CDP Runtime instrumentation), rather than relying on the paper's tracing filter. Recompute precision, recall, and accuracy against these independent labels. If the non-FP sample contains a substantial fraction of functions that call high-entropy APIs in fingerprint-like patterns, the trace capture or heuristics are incomplete and the headline metrics are not trustworthy.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim—function-level fingerprinting detection at 98.9% accuracy—rests entirely on labels produced in §3.4–§3.5. Labels are assigned only when a function's trace matches one of four hand-written heuristics (Canvas, Canvas Font, Audio, WebRTC); every function with no matching trace is labeled non-FP. Two failure modes make this unsafe. (1) Trace capture is limited to CDP events for Chromium's 'high entropy' API list (§3.2); any high-entropy call not captured—due to tracing start/stop, lazy compilation, indirect/reflected calls, or eval—leaves the function with no trace and therefore a negative label. (2) The four heuristics omit entire fingerprinting families (e.g., WebGL, matchMedia, font enumeration) and require strict call-order patterns, so real fingerprinting functions can be silently labeled negative. Since the bytecode representation strips operands (§3.1), the transformer cannot see API names or string constants; it can only learn opcode-sequence correlations with these heuristic labels. If labels are noisy, the reported 98.9%/99.7% numbers are not evidence about real-world fingerprinting detection. The paper admits heuristic bias (§6.2) and anonymous-function exclusion (§6.1), but never quantifies label error; 2,905 of 7,595 initially positive functions are anonymous and discarded, further biasing the training set.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":26062,"tokens_out":2375,"duration_ms":27556,"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":[{"comment":"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","section":"§3.4, §3.5"},{"comment":"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.","section":"§5.3, Table 4"},{"comment":"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.","section":"§4.2, §6.1"},{"comment":"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.","section":"§4.2, §5.1"}],"minor_comments":[{"comment":"Listing 3 contains 'GetNamedProprty', a typo for 'GetNamedProperty'.","section":"§3.1, Listing 3"},{"comment":"The caption reads 'Mixed Scrips' instead of 'Mixed Scripts.'","section":"§4.3, Figure 3"},{"comment":"'Transf.' in the Embed. Model column is ambiguous; spell out 'Transformer'.","section":"§5.1, Table 2"},{"comment":"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?).","section":"§3.4"},{"comment":"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.","section":"§4.3"}],"recommendation":"major_revision","confidential_remarks":"The paper is a solid engineering contribution with a plausible methodology, but the central evaluation is currently circular with respect to the heuristic labels. The reviewer's stress-test concern is confirmed by the paper's own text: §6.2 admits the heuristics are precision-oriented and may miss novel behaviors, and §5.3 shows obfuscation robustness requires augmentation. I would not accept as-is, but a major revision that quantifies label noise, validates on anonymous functions, and reframes the robustness claims would make the contribution suitable for a security venue. The inconsistency between §4.2 and §5.1 on the sampling ratio suggests a need for a reproducibility pass."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"I read ByteDefender with genuine interest. The core idea is new: nobody has used V8 bytecode at function granularity for fingerprinting detection. Prior work did script-level bytecode and dynamic context graphs, but this is the first static, pre-execution, function-level bytecode classifier for fingerprinting. The authors also did a serious crawl—100k sites, hundreds of millions of functions—and they show real care in data hygiene: duplicate removal, URL filtering, train/test separation, and they report precision and recall, not just accuracy. That is real work and worth crediting.\n\nThe problem is the ground truth. The labels come from four hand-written heuristics over high-entropy API traces; any function with no matching trace is labeled non-fingerprinting. The bytecode representation strips operands, so the model can only learn opcode-sequence correlations with these heuristic labels. The headline numbers—98.9% function-level accuracy, 99.7% script-level—are agreement with the heuristic, not evidence about real-world fingerprinting detection. The paper acknowledges heuristic bias (§6.2) and the anonymous-function exclusion (§6.1), but never quantifies label error. If the heuristics miss WebGL, matchMedia, or any less-documented vector, or if trace capture misses calls due to lazy compilation, indirect calls, or eval, the labels are silently wrong. This is load-bearing.\n\nObfuscation robustness is also weaker than advertised. The model trained only on real-world scripts gets 0.1% recall on JavaScript-Obfuscator re-obfuscated scripts; only after training on those same obfuscators does recall jump. That is not inherent robustness, it is learning the obfuscator's fingerprint. The on-device signature matching evaluation measures only page-load latency, never detection or breakage with the signatures. Minor issues: the sampling ratio is stated as 1:20 in one place and 1:10 in another, the public code release is unverified, and there are no confidence intervals.\n\nIf I were the editor, I would send this to reviewers. The technique is promising, the scale is impressive, and the limitations are at least acknowledged. But it needs a major revision: re-anchor or validate the ground truth, evaluate obfuscation without training on the same obfuscator, measure signature matching's actual detection accuracy, and fix the small inconsistencies. The paper deserves serious referee time; it just isn't ready as-is.","headline":"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.","tokens_in":26608,"tokens_out":2390,"would_cite":true,"duration_ms":23713,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"V8 bytecode alone can identify browser fingerprinting functions before they execute, yielding 98.9% function-level accuracy and 99.7% script-level accuracy.","keywords":["browser fingerprinting","V8 bytecode","function-level detection","transformer classifier","JavaScript obfuscation","privacy","web tracking","content blocking"],"falsifier":"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.","tokens_in":25607,"feed_emoji":"🛡️","tokens_out":9436,"duration_ms":87626,"temperature":0.7,"pith_summary":"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.","feed_headline":"V8 bytecode identifies fingerprinting functions at 98.9% accuracy","feed_subtitle":"Function-level blocking adds only 4% page-load latency and survives obfuscation, unlike source-based filters.","key_machinery":"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","core_discovery":"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","pith_inferences":["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."],"forward_implications":["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."],"fun_headline_variants":["V8 bytecode pinpoints fingerprinting functions at 98.9%","Bytecode reveals obfuscated fingerprinting functions","V8 bytecode spots fingerprinting pre-run, adds 4% latency","Obfuscation-resistant fingerprinting detection with V8 bytecode"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["V8 bytecode pinpoints fingerprinting functions at 98.9%","Bytecode reveals obfuscated fingerprinting functions","V8 bytecode spots fingerprinting pre-run, adds 4% latency","Obfuscation-resistant fingerprinting detection with V8 bytecode"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001017,"raw_usage":{"total_tokens":4147,"prompt_tokens":777,"completion_tokens":3370,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":521,"completion_tokens_details":{"reasoning_tokens":3294}},"tokens_in":521,"tokens_out":3370,"duration_ms":27845,"temperature":1.0,"reasoning_tokens":3294,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-04T18:23:59.524115+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[],"review_version":1}