Instance-Level Fingerprinting Techniques
- Instance-level fingerprinting is the identification of unique characteristics from specific artifacts, enabling fine-grained tracking and authentication.
- Techniques range from hardware-based signals and behavioral analysis to software-exposed attributes, each offering distinct metrics for reliability.
- Empirical studies validate these methods by demonstrating high precision and repeatability across diverse environments like browsers, IoT, and ML models.
Searching arXiv for recent and foundational papers on instance-level fingerprinting across hardware, web, IoT, mobile SDKs, and model fingerprinting. Instance-level fingerprinting denotes the construction, extraction, or detection of identifiers that distinguish a specific instance of an artifact rather than only its broad class. Across the literature, the instance may be a physical machine, a browser or browser installation, an IoT device unit, a protocol implementation, a deployed LLM configuration, or a model family variant observed through black-box behavior. The common requirement is not merely separability, but separability together with some notion of persistence under repeated observation. The mechanisms used to obtain such fingerprints differ sharply by domain: some exploit physical variation in hardware, some aggregate software-visible surfaces, some model input-output behavior, and some study the deployment of fingerprinting scripts and SDKs in the wild rather than generating fingerprints themselves (Li et al., 2022, Venugopalan et al., 2023, Bacis et al., 2024, Richardeau et al., 2 Jun 2026).
1. Scope, granularity, and adjacent meanings
A recurring distinction in the literature is between category, type, and instance. In IoTSense, for example, a device category is a broad functional class, a device type is a specific model within that category, and a device instance is a physical unit of that type (Bezawada et al., 2018). Browser fingerprinting papers define the problem differently but analogously: browser fingerprinting is a stateless identification technique based on browser properties, where a website infers that a visit came from a specific browser or device instance without writing client-side state (Durey et al., 2021, Bahrami et al., 2021).
This granularity matters because several papers target instance identification directly, whereas others target detection, measurement, or risk estimation of fingerprinting systems. FP-Radar studies which web APIs are being combined in the wild to create browser-instance identifiers, rather than proposing a new identifier itself (Bahrami et al., 2021). “An iterative technique to identify browser fingerprinting scripts” classifies individual scripts as fingerprinter, non-fingerprinter, or unknown, which is instance-level classification of scripts rather than instance identification of end-user devices (Durey et al., 2021). “Assessing Web Fingerprinting Risk” quantifies how much identifying information websites extract through Web APIs using entropy, thereby treating fingerprinting as an information-theoretic instance-identification problem (Bacis et al., 2024).
The term is also overloaded outside device and browser identification. “Privacy-Preserving Database Fingerprinting” uses entry-level fingerprinting to embed recipient-specific marks into relational databases while satisfying -entry-level differential privacy; this is a liability and privacy problem, not host or browser instance identification (Ji et al., 2021). By contrast, “Fingerprinting of Machines in Critical Systems for Integrity Monitoring and Verification” does not substantively define an instance-level fingerprinting workflow in the usual sense. The excerpt identifies critical Windows directories, registry keys, and logs for monitoring, which is more consistent with file/directory integrity monitoring than with a per-host fingerprint schema (Paliwal et al., 2024).
2. Fingerprint carriers: physical, behavioral, and software-exposed signals
One major family of instance-level fingerprints is hardware-bound. FPHammer induces Rowhammer bit flips and treats the set of flipped DRAM locations, formatted as (bank, row, column), as a device’s physical fingerprint (Li et al., 2022). FP-Rowhammer similarly exploits DRAM manufacturing-process variation, but models repeated hammering outcomes as probability distributions over capacitor indices in contiguous 2 MB chunks (Venugopalan et al., 2023). “Hardware Fingerprinting Using HTML5” proposes hardware-oriented browser-side signals from the GPU, camera, microphone, motion sensors, GPS, and battery, and presents an initial GPU experiment based on WebGL rendering behavior (Nakibly et al., 2015). “Browser Fingerprinting Using WebAssembly” moves the hardware/software boundary upward: its fingerprint is a timing vector built from CPU-bound operations, memory tasks, and JavaScript↔Wasm boundary behavior, with the most discriminative signals arising from wasm-scripted-setter tests (Guri et al., 31 May 2025).
A second family is behavioral. IoTSense constructs fingerprints from short packet sequences using packet-header and payload-derived features extracted from passive network traces (Bezawada et al., 2018). “Incremental Fingerprinting in an Open World” uses input-output behavior of black-box protocol implementations modeled as deterministic, data-less FSMs, so the fingerprint is a set of separating sequences over protocol inputs (Kruger et al., 29 Jan 2026). FBI fingerprints deep neural networks using ordinary benign inputs and the model’s top- outputs, emphasizing robustness to retraining, quantization, pruning, JPEG preprocessing, randomized smoothing, and finetuning (Maho et al., 2022). FLIPS fingerprints deployed LLM instances through their biases when generating pseudo-random binary sequences, with the instance defined by weights together with prompt, temperature, top-, quantization, and related deployment choices (Richardeau et al., 2 Jun 2026).
A third family is software-exposed surfaces. Browser fingerprinting studies focus on values exposed through navigator, screen properties, canvas, WebGL, audio, performance, sensors, Gamepad, Clipboard, Network Information, and related APIs (Bahrami et al., 2021, Bacis et al., 2024, Annamalai et al., 3 Feb 2025). In mobile apps, “Fingerprinting SDKs for Mobile Apps and Where to Find Them” defines a signal as an individual data point collected from a device and studies third-party SDKs that exfiltrate sufficiently many such signals via ordinary Android APIs (Specter et al., 27 Jun 2025).
The persistence properties differ by carrier. Hardware-derived fingerprints are explicitly motivated as being harder to spoof than software-visible attributes (Nakibly et al., 2015). Behavioral fingerprints may remain effective under encryption or software reinstallation because the discriminative information lies in traffic regularities, memory disturbance, or output behavior rather than in explicit identifiers such as MAC address, IP address, or User-Agent (Bezawada et al., 2018, Li et al., 2022, Guri et al., 31 May 2025).
3. Extraction, similarity, and identification procedures
The literature uses several distinct formalizations of fingerprint extraction and matching. FPHammer models fingerprints as sets: for a device id_i, repeated measurements are represented as , and a new fingerprint is matched against a stored database using a modified Jaccard measure,
where is typically the union of several initial measurements and is a new query result (Li et al., 2022). FP-Rowhammer departs from one-shot sets because Rowhammer is non-deterministic; it builds per-chunk probability distributions over observed bit flips and compares fingerprints using Jensen-Shannon divergence, declaring a match when the minimum divergence falls below an empirically determined threshold (Venugopalan et al., 2023).
Browser-fingerprinting risk work instead frames the problem information-theoretically. “Assessing Web Fingerprinting Risk” uses entropy
for individual surfaces and a Chow–Liu style upper bound on joint entropy,
to avoid overestimating risk when Web APIs are correlated (Bacis et al., 2024). This is a risk-estimation framework rather than a direct classifier, but it formalizes what makes a browser instance distinctive.
Detection of fingerprinting code often relies on similarity over accessed attributes. “An iterative technique to identify browser fingerprinting scripts” represents a fingerprinting attribute signature as the 3-tuple 0, builds a matrix of known fingerprinting behavior from Disconnect, and compares unknown scripts to known fingerprinters with the Jaccard index
1
A score of 1 yields automatic labeling as a fingerprinter; otherwise the algorithm compares overlaps with already-labeled clean scripts and falls back to manual analysis when needed (Durey et al., 2021).
Constrained fingerprint design has also been formalized as an optimization problem. “Near-Optimal Fingerprinting with Constraints” defines targeted fingerprinting and general fingerprinting under a hard budget 2 on the number of attributes, proves both are NP-hard by reduction to Maximum Coverage, and uses greedy approximation algorithms that iteratively maximize separation among remaining candidates (Gulyas et al., 2016). This perspective is important where the fingerprinting budget is restricted by policy or interface limits.
For black-box ML systems, behavioral similarity becomes the core primitive. FBI defines a normalized distance based on empirical mutual information between a queried black-box and a reference model or family,
3
and pairs it with a greedy benign-input selection algorithm for detection (Maho et al., 2022). FLIPS, by contrast, maps generated binary sequences to feature vectors using the NIST statistical test suite and performs closed-set or open-set identification with XGBoost and soft voting across token pairs (Richardeau et al., 2 Jun 2026). In protocol fingerprinting, open-world identification is handled incrementally: the system first fingerprints against known models, then performs conformance checking, and only learns a new model when no reliable match exists (Kruger et al., 29 Jan 2026).
4. Stability, uniqueness, and empirical results
The strongest instance-level claims are those that jointly demonstrate uniqueness and repeatability. FPHammer reports a uniqueness value of 0 between two DIMMs with the same design, specifications, and production batch, and an average reliability of 0.88 for each DIMM (Li et al., 2022). One measurement takes about 128 seconds, ten measurements about 1270 seconds, and two measurements already yield average reliability of about 0.85. The paper also shows that changing MAC address and IP address, and even reinstalling the operating system on one device, does not prevent correct re-identification in a local-network experiment (Li et al., 2022).
FP-Rowhammer reports a larger-scale DRAM study: on 98 DIMMs, it achieves 99.91% accuracy, 100% precision, and 97.06% recall (Venugopalan et al., 2023). Over 10 days on 10 DIMMs, it observes no degradation trend. Under a faster configuration using 1,000,000 accesses + 2 sweeps, extraction takes 9.92 seconds with 99.27% accuracy, 95.96% precision, and 84.61% recall; an optimized half-row configuration reaches 4.54 seconds with 99.09% accuracy, 95.33% precision, and 83.84% recall (Venugopalan et al., 2023).
IoTSense is more cautious in framing: its main contribution is device-type fingerprinting, but its cross-instance experiment provides direct evidence for instance-level recognition. It reports 99.7–100% mean recognition rate for different physical instances of the same device type, while device-type identification yields about 93–99% mean identification rate and about 99% mean accuracy (Bezawada et al., 2018).
WebAssembly-based fingerprinting reports a false-positive rate of less than 1%, and for Chromium-versus-non-Chromium classification a 99.29% success rate with only one misclassified Firefox instance out of 55 (Guri et al., 31 May 2025). The most discriminative ratios are based on wasm-scripted-setter-1, wasm-scripted-setter-2, and wasm-scripted-getter-0, with thresholds 4 and 5.
For model and LLM instances, FBI validates its benign-input approach on 1081 models and variants, typically achieving detection in 1–3 queries in the known-model case and outperforming prior robust fingerprinting baselines on ImageNet variants (Maho et al., 2022). FLIPS evaluates 237 instances derived from 25 open-weight LLMs and reports 96% closed-set accuracy and 90% open-set accuracy with 6, versus 35% for the adapted LLMmap baseline (Richardeau et al., 2 Jun 2026). These results are notable because the goal is deliberately sensitive to prompt, sampling, and quantization changes rather than robust to them.
5. Measurement in the wild: prevalence, deployment, and trigger conditions
A separate body of work studies where fingerprinting appears and how measurement methodology changes conclusions. “Assessing Web Fingerprinting Risk” uses telemetry from tens of millions of real Chrome browsers in-the-wild, over hundreds of thousands of websites, while collecting no more than 20 bits of device-specific information from any client (Bacis et al., 2024). It finds that session entropy is often either well below or well above 20 bits, with strong vertical differences: news and shopping sites consume more entropy than law/government sites, and news websites have the highest third-party entropy (Bacis et al., 2024).
FP-Radar reconstructs historical API co-occurrence graphs from the Wayback Machine for the Alexa top-100K sites, reporting 1,658 fingerprinting scripts and 92,193 non-fingerprinting scripts across the decade-scale dataset (Bahrami et al., 2021). It detects abuse of newly introduced properties of known APIs such as deviceMemory, hardwareConcurrency, WebGL2RenderingContext, and AmbientLightSensor, and also previously unknown fingerprinting use of Gamepad, Clipboard, Network Information, and the Visibility API for ephemeral fingerprinting (Bahrami et al., 2021).
Real-user measurement further changes the picture. “Beyond the Crawl: Unmasking Browser Fingerprinting in Real User Interactions” follows 30 participants over 10 weeks and finds 471 fingerprinting websites in real-user sessions, of which an automated crawl misses 211, or 45% (Annamalai et al., 3 Feb 2025). It reports 695 fingerprinting scripts in real-user sessions versus 498 in the crawl, and attributes the gap to authentication barriers, content reached only after user activity, post-load bot detection, cookie-consent gating, and other interaction-triggered conditions (Annamalai et al., 3 Feb 2025). This implies that fingerprinting is often a property of a specific browsing instance, not merely of a site’s public landing page.
Mobile-app measurement shows comparable heterogeneity. “Fingerprinting SDKs for Mobile Apps and Where to Find Them” starts from a Seed Set of 14 SDKs that openly describe fingerprinting-like behavior, identifying 504 unique signals and 1,043 total raw signals across them (Specter et al., 27 Jun 2025). It then expands to 723 distinct SDKs and 14,178 SDK versions with likely fingerprinting behavior. Only 30.56% of these belong to Ads, while 23.92% are Unclear / Not Found, 23.1% are Tools / Other, 11.7% are Security and Authentication, and 10.6% are Analytics (Specter et al., 27 Jun 2025). The paper also shows that the signal space is sparse: 80% of APIs are exfiltrated by fewer than 50% of the seed SDKs, and only 2% of APIs are used by more than 75% of them (Specter et al., 27 Jun 2025).
6. Limitations, defenses, and conceptual boundaries
Instance-level fingerprints are rarely unconditional. FPHammer assumes the target is susceptible to Rowhammer bit flips, does not have ECC memory, and can execute the fingerprinting code in one of the permitted settings; its evaluation uses DDR4 on PCs (Li et al., 2022). FP-Rowhammer requires native code, contiguous memory, and effective hammering patterns, and its stability weakens when DIMMs are re-seated: the reported controlled experiment shows 100% / 100% / 100% accuracy/precision/recall with no rebooting or with rebooting only, but 91.67% accuracy, 95.83% precision, and 50% recall after re-seating (Venugopalan et al., 2023). These results indicate that some supposedly hardware-bound fingerprints are actually bound to a larger physical configuration.
Web-based methods face different constraints. Entropy estimates can be grossly inflated if APIs are treated as independent when they are correlated, which is why correlation-aware estimation is central in (Bacis et al., 2024). Wasm timing fingerprints can be weakened by browser-side noise injection: “Browser Fingerprinting Using WebAssembly” proposes wrapping setter functions with delayed versions and reports that the mitigation materially shifts timing ratios, thereby reducing classifier reliability (Guri et al., 31 May 2025). Detection systems also face epistemic limits: script-classification methods observe only client-side behavior and cannot prove how backend systems use collected data (Durey et al., 2021).
Open-world identification is a further boundary. Closed-world fingerprinting silently misclassifies unknown implementations when the reference set is incomplete. “Incremental Fingerprinting in an Open World” reports that, on TLS data, closed-world fingerprinting with 21 of 22 models known still misclassifies 4.5% of implementations, and with only 11 of 22 models known misclassification rises to 45.9% (Kruger et al., 29 Jan 2026). Its incremental framework addresses this by combining fingerprinting, conformance checking, and adaptive learning rather than forcing every observation into a known class.
A final boundary is terminological. Not every integrity or monitoring system is an instance-level fingerprinting system. The Windows paths and registry locations enumerated in (Paliwal et al., 2024) are high-value integrity monitoring targets, but the excerpt provides no fingerprint vector, no baseline comparison procedure, no storage or anti-tamper mechanism for fingerprints, and no identification algorithm. A plausible implication is that such monitored state could contribute to a host integrity profile, but the excerpt does not define that profile as a fingerprint (Paliwal et al., 2024).
Taken together, the literature shows that instance-level fingerprinting is not a single technique but a family of identification problems unified by granularity. Some methods identify a physical device through analog variation, some identify a browser or browsing session through high-entropy software surfaces, some identify a model or deployed LLM configuration through output behavior, and some measure the deployment of fingerprinting infrastructure itself. The central research challenge is consistent across these settings: to isolate signals that are distinctive enough to separate instances, stable enough to persist over time, and interpretable enough to support either tracking, authentication, auditing, or defense.