Pith. sign in

REVIEW 4 major objections 4 minor 1 cited by

Browser Fingerprinting Using WebAssembly

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

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

Pith's one-line read This paper claims that timing ratios between WebAssembly setter and getter operations identify Chromium-based browsers with a false-positive rate below 1%, even when the user-agent string is spoofed.

desk verdict A plausible but narrowly-scoped Wasm timing signal is buried under unsupported claims about returning-device identification and a false-positive rate that the paper's own counts contradict. read the letter →

arxiv 2506.00719 v1 pith:IZ7SZOHO submitted 2025-05-31 cs.CR

Mordechai Guri , Dor Fibert This is my paper
classification cs.CR
keywords browserfingerprintingWebAssemblyChromiumdetectiontimingsidechanneluseragentspoofingJavaScriptAPIprivacysetter
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 claims that subtle timing differences in how browsers execute WebAssembly functions can reveal whether a browser is Chromium-based, even when the browser reports a faked user-agent string. The method measures the time to run WebAssembly-backed property setters relative to a getter baseline, and classifies a browser as Chromium when both ratios clear fixed thresholds (3.05 and 3.10). Across 158 browser instances on desktops, phones, and virtual machines, the authors report that all Chromium instances exceed the thresholds while only one Firefox instance does, for a false-positive rate below 1%. If correct, this gives web servers a spoof-resistant signal for fraud detection and personalization, and it adds a new privacy concern to WebAssembly's security profile.

What carries the argument

The central object is the ratio between two WebAssembly timing measurements: 'wasm-scripted-setter-1' or 'wasm-scripted-setter-2' in the numerator, and 'wasm-scripted-getter-0' in the denominator. A scripted setter is a JavaScript property setter defined with Object.defineProperty whose set function is an exported WebAssembly function. These ratios expose differences in how browser engines handle the JavaScript-to-WebAssembly boundary: Chromium engines pay a large overhead for scripted setters, while non-Chromium engines do not. The classification is a two-threshold rule on these ratios, which makes the fingerprint cheap to compute and independent of user-agent strings.

What would settle it

Run the two-ratio rule with thresholds fixed at 3.05 and 3.10 on a fresh holdout of browser instances that were not used to choose the thresholds, across the same device and OS mix, and count how many non-Chromium browsers clear both thresholds; a false-positive rate above 1% would refute the headline claim. A second check is to revisit the same Chromium instance under different CPU load or with a different browser version and see whether either ratio ever falls below 3.05.

Watch

Extended reading notes

Core claim

The paper's central discovery is that the ratio of WebAssembly setter timing to WebAssembly getter timing is a stable marker of the browser engine family. In Chromium-based browsers, the tests 'wasm-scripted-setter-1' and 'wasm-scripted-setter-2' run far slower than 'wasm-scripted-getter-0', while Firefox and Safari do not show this gap. The authors set thresholds at ratios of 3.05 and 3.10 and classify a browser as Chromium-based only if both ratios meet or exceed those values; on the collected data this rule misses none of the Chromium instances and misclassifies one of the 55 Firefox instances. The signal holds across Intel, AMD, and ARM processors, across Windows, macOS, Linux, Android, and iOS, and inside VMWare, KVM, VirtualBox, and Hyper-V virtual machines.

Load-bearing premise

The load-bearing premise is that the setter-versus-getter timing ratios for a given browser engine stay stable across different hardware, operating systems, and virtual machines, so the thresholds chosen from the observed Chromium minimums will still separate engines on unseen clients and on repeat visits.

Editorial extensions

If this is right

  • Websites can detect Chromium-based browsers even when privacy tools spoof the user-agent string, since the signal comes from engine timing rather than reported headers.
  • The two-ratio threshold rule is simple enough to run as a small script on any page, needing no training data or stored profile once the thresholds are fixed.
  • The reported signal spans bare-metal PCs, Android and iOS phones, and four virtualization platforms, so the fingerprint is not limited to one hardware or OS setting.
  • The paper's mitigation, which injects random delays into Object.defineProperty setters, raises Firefox's ratios from about 1.6 to over 71, showing that browser vendors or extensions can blur this signal.
  • Privacy defenses for WebAssembly must consider timing ratios at the JavaScript-to-WebAssembly boundary, not only user-agent and network-level identifiers.

Reading between the lines

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

  • The reported false-positive rate is in-sample: the thresholds are the minimum Chromium ratios observed in the same dataset used for evaluation, so a holdout or repeat-visit experiment would be the natural next test of stability.
  • The same setter-versus-getter ratio may distinguish Chromium versions or engine configuration details, since the overhead likely tracks engine-internal call paths rather than raw CPU speed.
  • A defense that normalizes setter-versus-getter ratios rather than adding large random delays could neutralize the attack with less performance cost than the paper's mitigation.
  • If CPU frequency scaling or background load shifts the ratios, the fixed thresholds may need per-environment calibration; the paper does not report a revisit experiment across load conditions.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 4 minor

Summary. The paper proposes a browser fingerprinting method based on 20 WebAssembly-to-JavaScript timing tests, focusing on two ratios (wasm-scripted-setter-1 / wasm-scripted-getter-0 and wasm-scripted-setter-2 / wasm-scripted-getter-0) to distinguish Chromium-based browsers from non-Chromium-based browsers. The authors report a 99.29% classification success rate and claim a false-positive rate below 1%, even when the User-Agent is spoofed. They evaluate the method on 158 browser instances running on diverse hardware, operating systems, and virtualized environments, and additionally propose mitigations based on injecting random delays into setter functions.

Significance. The empirical observation that WebAssembly scripted setter operations are substantially slower in Chromium-based browsers than in Firefox/Safari is interesting and could be a useful contribution to the browser-fingerprinting literature. The breadth of measured environments (Windows, macOS, Android, iOS, multiple hypervisors, Intel/AMD/ARM) is a strength. However, the paper's central quantitative claims are not supported by the presented evidence: the thresholds are fitted to the same data on which accuracy is reported, the reported false-positive rate is contradicted by the paper's own counts, and the claimed capability to identify returning devices across sessions is never measured. The paper does not provide reproducible code, a holdout evaluation, or a repeated-session study, so the headline results cannot be taken as evidence of generalization.

major comments (4)
  1. [Section IV-5, Table IV] The classification thresholds SS1Threshold=3.05 and SS2Threshold=3.10 are selected from the same data used to compute the 99.29% success rate, as stated explicitly: "From these statistics, we set the threshold values." The reported accuracy is therefore a training-set accuracy that describes the fitted rule rather than an independent estimate. No holdout set, cross-validation, or repeat-visit evaluation is presented, and the chosen thresholds coincide with the minimum observed Chromium ratios. This is load-bearing because the abstract and conclusion rely on the <1% false-positive claim, which cannot be established from an in-sample fit.
  2. [Section IV-5 and Section V] The claim of a false-positive rate below 1% is contradicted by the paper's own counts. The text reports "only one misclassified Firefox instance out of 55." Treating a false positive as a non-Chromium instance classified as Chromium, this is 1/55 = 1.82%, not less than 1%. The 99.29% figure is the overall accuracy (141/142), not a false-positive rate. The abstract and conclusion repeat the incorrect false-positive claim, so the manuscript's central numeric assertion is internally inconsistent.
  3. [Abstract and Section V] The paper claims the ability to "identify returning devices—such as smartphones, tablets, laptops, and desktops across different browsing sessions" and to "identify returning devices." No experiment in Section IV tracks a device or browser instance across repeated visits; all measurements appear to be single-session instances from 158 distinct configurations. The evaluation only distinguishes Chromium-based from non-Chromium-based browsers. The device-identification claim is therefore unsupported by the presented data and must either be backed by a longitudinal experiment or removed from the claims.
  4. [Figure 3, Section IV, and Table IV] The dataset size is inconsistent. Section IV and Figure 3 state that 158 browser instances were evaluated, but Table IV reports counts of 55 Firefox and 87 Chrome+Edge instances, totaling 142. The 16 missing instances are unexplained. If any instances were excluded from the analysis, the criteria and impact on the reported rates must be described; otherwise the reported accuracy and false-positive counts cannot be audited.
minor comments (4)
  1. [Section IV-5 and Figure 10] The text says that Firefox with mitigation has ratios "closer to those of Chromium-based browsers," but the reported ratios for mitigated Firefox (71.38 and 71.85) are much larger than the natural Chrome/Edge ratios (25.42/26.00 and 24.93/25.66). The qualitative claim should be reworded, e.g., to say that the ratios exceed the classification threshold rather than being closer to Chromium values.
  2. [References] Reference [56] points to wasmtime.dev rather than the Fuzzm paper, and the DOI in reference [57] is a placeholder (10.14722/madweb.2021.23xxx). These citations are incomplete and should be fixed.
  3. [Throughout] There are numerous typographical and formatting issues, including "VMWare" instead of "VMware," inconsistent naming of the scripted-setter tests ("wasm-scripted-setter" vs. "wasm-scripted-setter-1/2"), and a missing period at the end of the sentence in Section III.C. A careful proofreading pass is needed.
  4. [Algorithm 1] The pseudocode in Algorithm 1 contains text-corruption artifacts (e.g., "f p←f loat[]of sizeN") that make it hard to read; the algorithm should be typeset cleanly.

Circularity Check

1 steps flagged · score 6.0 of 10

The claimed <1% false-positive rate is an in-sample evaluation of thresholds fitted to the same 142 instances, not a prediction on unseen data.

  1. fitted input called prediction [Section IV-5 'Chromium Based Browser Identification', Table IV and Algorithm 3]
    "From these statistics, we set the threshold values at SS1Threshold= 3.05 and SS2Threshold= 3.10. Using these thresholds, all Chromium-based browsers exceeded the threshold values, while less than 5% of Firefox instances did. This configuration resulted in a classification success rate of 99.29%, with only one misclassified Firefox instance out of 55."

    The thresholds are chosen from Table IV, which summarizes the same 142 instances later used to report accuracy. SS1Threshold=3.05 is exactly the minimum observed SS1/SG0 ratio for Chrome+Edge, and SS2Threshold=3.10 is taken from the same distribution (it equals the Firefox 95th percentile for SS2/SG0). Algorithm 3 then classifies those same instances, so the 99.29% success rate and the abstract's 'false-positive rate of less than 1%' are in-sample descriptions of the fitted rule, not independent predictions. No holdout set, cross-validation, or revisit experiment is presented. Moreover, the paper's own count gives FPR = 1/55 ≈ 1.82%, contradicting the '<1%' claim.

full rationale

The paper's core evaluation is not circular in the sense that the browser-family distinction is derived from the definitions of the tests; the setter/getter timing difference is an empirical observation. However, the headline quantitative claim is circular as a prediction: Algorithm 3's thresholds are set in Section IV-5 from the descriptive statistics of the same 142-instance matrix (Table IV), and the reported success rate and misclassification count are computed on those same instances. No holdout set, cross-validation, or repeated-session experiment is reported, so the accuracy figure is a re-description of the fitted decision rule on its training data. Additionally, even the in-sample arithmetic conflicts with the abstract: one misclassified Firefox instance out of 55 is a false-positive rate of about 1.82%, not less than 1%. The underlying timing phenomenon may well be real, and there is no load-bearing self-citation or imported uniqueness theorem, but the central statistical prediction as stated is not supported by an independent evaluation.

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

The central prediction depends on two thresholds extracted from the same data used to report accuracy (Section IV-5, Table IV). No external benchmark, no holdout set, and no longitudinal data are provided. The method also assumes timing stability and engine-family equivalence to device identity, both untested. No new entities are introduced.

free parameters (2)
  • SS1Threshold = 3.05
    Ratio of wasm-scripted-setter-1 to wasm-scripted-getter-0; chosen post hoc from Table IV's observed Chromium minimum after evaluating the data.
  • SS2Threshold = 3.10
    Ratio of wasm-scripted-setter-2 to wasm-scripted-getter-0; selected from the same in-sample data to keep all Chromium instances above the threshold.
assumptions (3)
  • domain assumption Timing measurements from performance.now() (or equivalent) reflect stable engine behavior rather than OS scheduling, thermal throttling, or browser anti-fingerprinting timer jitter.
    The classification method relies entirely on timing ratios; Section III-D and Section IV do not test repeatability under load or timer precision mitigations.
  • domain assumption The 20 Mozilla timing tests are valid and stable proxies for engine implementation differences across all hardware, OS, and VM configurations in the evaluation.
    Table II attributes the suite to Mozilla but provides no per-test source, no feature analysis, and no validation that each test is discriminative.
  • ad hoc to paper Chromium versus non-Chromium classification is a meaningful proxy for the claimed ability to identify returning devices across sessions.
    The abstract and conclusion claim device identification, but Section IV only measures engine family on single visits; this equation is introduced by the authors without evidence.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Browser Fingerprinting Using WebAssembly." pith.science (2026). https://pith.science/paper/IZ7SZOHO

@misc{pith2026250600719,
  author       = {Pith},
  title        = {Pith review of: Browser Fingerprinting Using WebAssembly},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/IZ7SZOHO}},
  note         = {Machine review of arXiv:2506.00719}
}
read the original abstract

Web client fingerprinting has become a widely used technique for uniquely identifying users, browsers, operating systems, and devices with high accuracy. While it is beneficial for applications such as fraud detection and personalized experiences, it also raises privacy concerns by enabling persistent tracking and detailed user profiling. This paper introduces an advanced fingerprinting method using WebAssembly (Wasm) - a low-level programming language that offers near-native execution speed in modern web browsers. With broad support across major browsers and growing adoption, WebAssembly provides a strong foundation for developing more effective fingerprinting methods. In this work, we present a new approach that leverages WebAssembly's computational capabilities to identify returning devices-such as smartphones, tablets, laptops, and desktops across different browsing sessions. Our method uses subtle differences in the WebAssembly JavaScript API implementation to distinguish between Chromium-based browsers like Google Chrome and Microsoft Edge, even when identifiers such as the User-Agent are completely spoofed, achieving a false-positive rate of less than 1%. The fingerprint is generated using a combination of CPU-bound operations, memory tasks, and I/O activities to capture unique browser behaviors. We validate this approach on a variety of platforms, including Intel, AMD, and ARM CPUs, operating systems such as Windows, macOS, Android, and iOS, and in environments like VMWare, KVM, and VirtualBox. Extensive evaluation shows that WebAssembly-based fingerprinting significantly improves identification accuracy. We also propose mitigation strategies to reduce the privacy risks associated with this method, which could be integrated into future browser designs to better protect user privacy.

Figures

Figures reproduced from arXiv: 2506.00719 by the authors.

Figure 1
Figure 1. Euclid’s GCD algorithm implemented in C and its [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. The proposed browser fingerprinting process [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 4
Figure 4. Timing results of WebAssembly tests on bare-metal [PITH_FULL_IMAGE:figures/full_fig_p006_4.png] view at source ↗
Figures from the paper (6 more)
Figure 3
Figure 3. Figure 3: Overview of 158 browser instances, each running 20 [PITH_FULL_IMAGE:figures/full_fig_p006_3.png]
Figure 6
Figure 6. Figure 6: Timing results of WebAssembly tests for VMs running [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]
Figure 7
Figure 7. Figure 7: Timing results of WebAssembly tests for Android [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]
Figure 8
Figure 8. Figure 8: Timing results of WebAssembly tests for iOS smart [PITH_FULL_IMAGE:figures/full_fig_p007_8.png]
Figure 9
Figure 9. Figure 9: A browser with reported spoofed Firefox 33.0 user [PITH_FULL_IMAGE:figures/full_fig_p008_9.png]
Figure 10
Figure 10. Figure 10: WebAssembly timing test results of Chrome, Edge, [PITH_FULL_IMAGE:figures/full_fig_p009_10.png]

Discussion (0). Sign in to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

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

    cs.CR 2025-08 conditional novelty 6.0 of 10

    WebAssembly-obfuscated fingerprinting scripts evade some academic detectors but not API-level browser defenses.

Reference graph

Works this paper leans on

59 extracted references · 55 canonical work pages · cited by 1 Pith paper

  1. [1]

    Deep fingerprinting: Undermining website fingerprinting defenses with deep learning,

    P. Sirinam, M. Imani, M. Juarez, and M. Wright, “Deep fingerprinting: Undermining website fingerprinting defenses with deep learning,” 2018

    work page 2018

  2. [2]

    Effective attacks and provable defenses for website fingerprinting,

    T. Wang, X. Cai, R. Nithyanand, R. Johnson, and I. Goldberg, “Effective attacks and provable defenses for website fingerprinting,” inProceedings of the 23rd USENIX Security Symposium, 2014

    work page 2014

  3. [3]

    Markov chain fingerprinting to classify encrypted traffic,

    M. Korczy ´nski and A. Duda, “Markov chain fingerprinting to classify encrypted traffic,” inProceedings - IEEE INFOCOM, 2014

    work page 2014

  4. [4]

    (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,” inProceedings 2017 Network and Distributed System Security Symposium. Reston, V A: Internet Society, 2017. [Online]. Available: https://www.ndss-symposium.org/ndss2017/ndss-2017-programme/ cross-browser-fingerprinting-os-and-hardware-level-features/

    work page 2017

  5. [5]

    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,” inProceedings - IEEE Symposium on Security and Privacy, 2013, pp. 541–555

    work page 2013

  6. [6]

    Fingerprinting web users through font met- rics,

    D. Fifield and S. Egelman, “Fingerprinting web users through font met- rics,” inLecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 2015

    work page 2015

  7. [7]

    Tracking Mobile Web Users Through Motion Sensors: Attacks and Defenses,

    A. Das, N. Borisov, and M. Caesar, “Tracking Mobile Web Users Through Motion Sensors: Attacks and Defenses,” 2017

    work page 2017

  8. [8]

    Clock Around the Clock: Time-Based Device Fingerprinting,

    I. Sanchez-Rola, I. Santos, and D. B. Eurecom, “Clock Around the Clock: Time-Based Device Fingerprinting,” 2018. [Online]. Available: https://doi.org/10.1145/3243734.3243796

    arXiv 2018

Show all 59 references
  1. [9]

    nmap - free security scanner for network exploration and security audits

    Fyodor. nmap - free security scanner for network exploration and security audits. [Online]. Available: http://nmap.org

  2. [10]

    Hershel: Single-packet OS fingerprinting,

    Z. Shamsi, A. Nandwani, D. Leonard, and D. Loguinov, “Hershel: Single-packet OS fingerprinting,” inPerformance Evaluation Review, 2014

    2014

  3. [11]

    IoT SENTINEL: Automated Device-Type Identification for Security Enforcement in IoT,

    M. Miettinen, S. Marchal, I. Hafeez, N. Asokan, A. R. Sadeghi, and S. Tarkoma, “IoT SENTINEL: Automated Device-Type Identification for Security Enforcement in IoT,” inProceedings - International Conference on Distributed Computing Systems, 2017

    2017

  4. [12]

    Kumar and S

    U. Kumar and S. Gambhir, “Device Fingerprint and Mobile Agent based Authentication Technique in Wireless Networks Authentication View project Device Fingerprint and Mobile Agent based Authentication Technique in Wireless Networks,”International Journal of Future Generation Com...

  5. [13]

    Automatic fingerprinting of vulnerable BLE IoT devices with static uuids from mobile apps,

    C. Zuo, Z. Lin, H. Wen, and Y . Zhang, “Automatic fingerprinting of vulnerable BLE IoT devices with static uuids from mobile apps,” in Proceedings of the ACM Conference on Computer and Communications Security, 2019

    2019

  6. [14]

    Performance issues and optimizations in javascript: An empirical study,

    M. Selakovic and M. Pradel, “Performance issues and optimizations in javascript: An empirical study,” inProceedings of the 38th International Conference on Software Engineering, ser. ICSE ’16. New York, NY , USA: Association for Computing Machinery, 2016, p. 61–72. [Online]. A...

    2016

  7. [15]

    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. F. Bastien, “Bringing the web up to speed with WebAssembly,”ACM SIGPLAN Notices, 2017

    2017

  8. [16]

    Man-in-the-middle-attack: Understanding in simple words,

    A. Mallik, “Man-in-the-middle-attack: Understanding in simple words,” Cyberspace: Jurnal Pendidikan Teknologi Informasi, vol. 2, no. 2, pp. 109–134, 2019

    2019

  9. [17]

    Hacking techniques in wireless,

    P. Mateti, “Hacking techniques in wireless,”Handbook of Information Security, Threats, Vulnerabilities, Prevention, Detection, and Manage- ment, vol. 3, p. 83, 2006

    2006

  10. [18]

    Transport and application protocol scrubbing,

    G. R. Malan, D. Watson, F. Jahanian, and P. Howell, “Transport and application protocol scrubbing,” inProceedings IEEE INFOCOM 2000. Conference on Computer Communications. Nineteenth Annual Joint Conference of the IEEE Computer and Communications Societies (Cat. No. 00CH37064)...

    2000

  11. [19]

    Smartphones vs. laptops: Comparing web browsing behavior and the implications for caching,

    I. Papapanagiotou, E. M. Nahum, and V . Pappas, “Smartphones vs. laptops: Comparing web browsing behavior and the implications for caching,” inPerformance Evaluation Review, vol. 40, no. 1 SPEC. ISS. New York, New York, USA: ACM Press, 2012, pp. 423–424. [Online]. Available: h...

    2012

  12. [20]

    A remote active os fingerprinting tool using icmp,

    O. Arkin, “A remote active os fingerprinting tool using icmp,”login: the Magazine of USENIX and Sage, vol. 27, no. 2, pp. 14–19, 2002

    2002

  13. [21]

    IPv6 Neighbor Discovery Protocol based OS fingerprinting,

    F. Beck, O. Festor, and I. Chrisment, “IPv6 Neighbor Discovery Protocol based OS fingerprinting,” 2007

    2007

  14. [22]

    Remote operating system classification over IPv6,

    D. Fifield, A. Geana, L. MartinGarcia, M. Morbitzer, and J. D. Tygar, “Remote operating system classification over IPv6,” inAISec 2015 - Proceedings of the 8th ACM Workshop on Artificial Intelligence and Security, co-located with CCS 2015. New York, NY , USA: Association for C...

    2015

  15. [23]

    Operating System Fingerprinting for Virtual Machines,

    N. A. Quynh, “Operating System Fingerprinting for Virtual Machines,” DEF CON 18 Hacking Conference, 2010

    2010

  16. [24]

    Fingerprint- ing Mobile Devices Using Personalized Configurations,

    A. Kurtz, H. Gascon, T. Becker, K. Rieck, and F. Freiling, “Fingerprint- ing Mobile Devices Using Personalized Configurations,”Proceedings on Privacy Enhancing Technologies, 2015

    2015

  17. [25]

    SensorID: Sensor calibration fingerprinting for smartphones,

    J. Zhang, A. R. Beresford, and I. Sheret, “SensorID: Sensor calibration fingerprinting for smartphones,” inProceedings - IEEE Symposium on Security and Privacy, vol. 2019-May. Institute of Electrical and Electronics Engineers Inc., 5 2019, pp. 638–655

    2019

  18. [26]

    The leaking battery: A privacy analysis of the HTML5 battery status API,

    Ł. Olejnik, G. Acar, C. Castelluccia, and C. Diaz, “The leaking battery: A privacy analysis of the HTML5 battery status API,” inLecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 2016

    2016

  19. [27]

    Operating system fingerprinting via automated network traffic analysis,

    A. Aksoy, S. Louis, and M. H. Gunes, “Operating system fingerprinting via automated network traffic analysis,” in2017 IEEE Congress on Evolutionary Computation, CEC 2017 - Proceedings, 2017

    2017

  20. [28]

    Passive OS fingerprinting by DNS traffic analysis,

    T. Matsunaka, A. Yamada, and A. Kubota, “Passive OS fingerprinting by DNS traffic analysis,” inProceedings - International Conference on Advanced Information Networking and Applications, AINA, 2013

    2013

  21. [29]

    Passive os fingerprinting methods in the jungle of wireless networks,

    M. Lastovicka, T. Jirsik, P. Celeda, S. Spacek, and D. Filakovsky, “Passive os fingerprinting methods in the jungle of wireless networks,” in IEEE/IFIP Network Operations and Management Symposium: Cognitive Management in a Cyber World, NOMS 2018, 2018

    2018

  22. [30]

    Using TLS Fin- gerprints for OS Identification in Encrypted Traffic,

    M. Lastovicka, S. Spacek, P. Velan, and P. Celeda, “Using TLS Fin- gerprints for OS Identification in Encrypted Traffic,” inProceedings of IEEE/IFIP Network Operations and Management Symposium 2020: Management in the Age of Softwarization and Artificial Intelligence, NOMS 2020...

    2020

  23. [31]

    OS fingerprinting and tethering detection in mobile networks,

    Y . C. Chen, Y . Liao, M. Baldi, S. J. Lee, and L. Qiu, “OS fingerprinting and tethering detection in mobile networks,” inProceedings of the ACM SIGCOMM Internet Measurement Conference, IMC, 2014

    2014

  24. [32]

    Pixel Perfect : Fingerprinting Canvas in HTML5,

    K. Mowery and H. Shacham, “Pixel Perfect : Fingerprinting Canvas in HTML5,”Web 2.0 Security & Privacy 20 (W2SP), 2012

    2012

  25. [33]

    Fingerprinting In- formation in JavaScript Implementations,

    K. Mowery, D. Bogenreif, S. Yilek, and H. Shacham, “Fingerprinting In- formation in JavaScript Implementations,”Web 2.0 Security & Privacy, 2011

    2011

  26. [34]

    JavaScript Template Attacks: Automatically Inferring Host Information for Targeted Exploits,

    M. Schwarz, F. Lackner, and D. Gruss, “JavaScript Template Attacks: Automatically Inferring Host Information for Targeted Exploits,” no. February, 2019

    2019

  27. [35]

    A Web Browser Fingerprinting Method Based on the Web Audio API,

    J. S. Queiroz and E. L. Feitosa, “A Web Browser Fingerprinting Method Based on the Web Audio API,”The Computer Journal, vol. 62, no. 8, pp. 1106–1120, 8 2019. [Online]. Available: https://academic.oup.com/comjnl/article/62/8/1106/5298776

    2019

  28. [36]

    Remote detection of virtual machine monitors with fuzzy benchmarking,

    J. Franklin, M. Luk, J. M. McCune, A. Seshadri, A. Perrig, and L. Van Doorn, “Remote detection of virtual machine monitors with fuzzy benchmarking,” inOperating Systems Review (ACM), vol. 42, no. 3, 4 2008, pp. 83–92

    2008

  29. [37]

    Tick tock: Building browser red pills from timing side channels,

    G. Ho, D. Boneh, L. Ballard, and N. Provos, “Tick tock: Building browser red pills from timing side channels,”8th USENIX Workshop on Offensive Technologies, WOOT 2014, 2014

    2014

  30. [38]

    OS-SOMMELIER: Memory-only operating system fingerprinting in the cloud,

    Y . Gu, Y . Fu, A. Prakash, Z. Lin, and H. Yin, “OS-SOMMELIER: Memory-only operating system fingerprinting in the cloud,” in Proceedings of the 3rd ACM Symposium on Cloud Computing, SoCC 2012. New York, New York, USA: ACM Press, 2012, pp. 1–13. [Online]. Available: http://dl.a...

    2012

  31. [39]

    Non-interactive OS fingerprinting through memory de-duplication technique in virtual machines,

    R. Owens and W. Wang, “Non-interactive OS fingerprinting through memory de-duplication technique in virtual machines,” inConference Proceedings of the IEEE International Performance, Computing, and Communications Conference, 2011

    2011

  32. [40]

    HTTPS traffic analysis and client identification using passive SSL/TLS fingerprinting,

    M. Hus ´ak, M. ˇCerm´ak, T. Jirs´ık, and P. ˇCeleda, “HTTPS traffic analysis and client identification using passive SSL/TLS fingerprinting,”Eurasip Journal on Information Security, 2016

    2016

  33. [41]

    Acoustic fingerprinting revisited: Generate stable device ID stealthily with inaudible sound,

    Z. Zhou, W. Diao, X. Liu, and K. Zhang, “Acoustic fingerprinting revisited: Generate stable device ID stealthily with inaudible sound,” in Proceedings of the ACM Conference on Computer and Communications Security, 2014

    2014

  34. [42]

    Do you hear what i hear? Fin- gerprinting smart devices through embedded acoustic components,

    A. Das, N. Borisov, and M. Caesar, “Do you hear what i hear? Fin- gerprinting smart devices through embedded acoustic components,” in Proceedings of the ACM Conference on Computer and Communications Security, 2014

    2014

  35. [43]

    PowerPrint: Identifying Smartphones through Power Consumption of the Battery,

    J. Chen, K. He, J. Chen, Y . Fang, and R. Du, “PowerPrint: Identifying Smartphones through Power Consumption of the Battery,” 2020. [Online]. Available: https://doi.org/10.1155/2020/3893106

    2020 doi

  36. [44]

    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,” inProceedings - 2015 10th International Conference on Broadband and Wireless Computing, Communication and Applications, BWCCA 2015, 2015

    2015

  37. [45]

    Robust website fingerprinting through the cache occupancy channel,

    A. Shusterman, L. Kang, Y . Haskal, Y . Meltser, P. Mittal, Y . Oren, and Y . Yarom, “Robust website fingerprinting through the cache occupancy channel,” 2018

    2018

  38. [46]

    Emscripten is a complete compiler toolchain to webassembly

    Emscripten. Emscripten is a complete compiler toolchain to webassembly. [Online]. Available: https://emscripten.org

  39. [47]

    LLVM: A compilation framework for lifelong program analysis and transformation,

    C. Lattner and V . Adve, “LLVM: A compilation framework for lifelong program analysis and transformation,” inCGO, San Jose, CA, USA, 3 2004, pp. 75–88

    2004

  40. [48]

    SDL. Sdl. [Online]. Available: https://www.libsdl.org/

  41. [49]

    pthreads(7)

    man7. pthreads(7). [Online]. Available: https://man7.org/linux/ man-pages/man7/pthreads.7.html

  42. [50]

    asm.js - frequently asked questions

    asmjs. asm.js - frequently asked questions. [Online]. Available: http://asmjs.org/faq.html

  43. [51]

    A. Zakai. Why webassembly is faster than asm.js. [Online]. Available: https://hacks.mozilla.org/2017/03/ why-webassembly-is-faster-than-asm-js/

    2017

  44. [52]

    McConnell

    J. McConnell. Webassembly support now shipping in all major browsers. [Online]. Available: https://blog.mozilla.org/blog/2017/11/13/ webassembly-in-browsers

    2017

  45. [53]

    New kid on the web: A study on the prevalence of webassembly in the wild,

    M. Musch, C. Wressnegger, M. Johns, and K. Rieck, “New kid on the web: A study on the prevalence of webassembly in the wild,” in Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 2019

    2019

  46. [54]

    An empirical study of real-world webassembly binaries security, languages, use cases ccs concepts • security and privacy→software and application security. acm reference format,

    A. Hilbig, D. Lehmann, and M. Pradel, “An empirical study of real-world webassembly binaries security, languages, use cases ccs concepts • security and privacy→software and application security. acm reference format,” p. 13, 2020, authors have collected a dataset of 8461 uniqu...

    2020

  47. [55]

    Everything old is new again: Binary security of webassembly,

    D. Lehmann, J. Kinder, and M. Pradel, “Everything old is new again: Binary security of webassembly,” 2020, they performed in-depth analysis of Wasm’s linear memory and its use by programs compiled from languages such a C/C++ and Rust. They show that memory protections are miss...

    2020

  48. [56]

    Fuzzm: Finding memory bugs through binary-only instrumentation and fuzzing of webassembly,

    D. Lehmann, M. T. Torp, and M. Pradel, “Fuzzm: Finding memory bugs through binary-only instrumentation and fuzzing of webassembly,” 2021, they introduce Fuzzm, the first wasm binarry fuzzer, which uses the popular AFL fuzzer. In addition, they also itroduce stack and heap cana...

    2021

  49. [57]

    Crow: Code diversification for webassembly,

    J. C. Arteaga, O. Floros, O. V . Perez, B. Baudry, and M. Monperrus, “Crow: Code diversification for webassembly,” 2020, in this paper they presented CROW, the first code diversification approach for WebAssembly. They evaluated CROW’s capabilities on 303 C programs. CROW was a...

    2020 doi

  50. [58]

    Efficient implementation of a crypto library using web assembly,

    B. Park, J. Song, and S. C. Seo, “Efficient implementation of a crypto library using web assembly,”Electronics 2020, Vol. 9, Page 1839, vol. 9, p. 1839, 11 2020, they implemented a cryptographic library in WebAssembly. The proposed library showed more than 2 times performance ...

    2020

  51. [2018]

    Available: http://dx.doi.org/10.14257/ijfgcn.2018.11.3

    [Online]. Available: http://dx.doi.org/10.14257/ijfgcn.2018.11.3. 04

    2018 doi

Pith tools

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