---
title: Instance-Level Fingerprinting Techniques
url: https://www.emergentmind.com/topics/instance-level-fingerprinting
type: topic
---

# Instance-Level Fingerprinting Techniques

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 [2201.07597] [2307.00143] [2403.15607] [2606.03330].

## 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 [1804.03852]. 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 [2103.00590] [2112.01662].

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 [2112.01662]. “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 [2103.00590]. “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 [2403.15607].

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 $\epsilon$-entry-level differential privacy; this is a liability and privacy problem, not host or browser instance identification [2109.02768]. 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 [2412.16595].

## 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 [2201.07597]. FP-Rowhammer similarly exploits DRAM manufacturing-process variation, but models repeated hammering outcomes as probability distributions over capacitor indices in contiguous 2 MB chunks [2307.00143]. “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 [1503.01408]. “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 [2506.00719].

A second family is **behavioral**. IoTSense constructs fingerprints from short packet sequences using packet-header and payload-derived features extracted from passive network traces [1804.03852]. “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 [2601.21680]. FBI fingerprints deep neural networks using ordinary benign inputs and the model’s top-$k$ outputs, emphasizing robustness to retraining, quantization, pruning, JPEG preprocessing, randomized smoothing, and finetuning [2208.03169]. 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-$k$, quantization, and related deployment choices [2606.03330].

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 [2112.01662] [2403.15607] [2502.01608]. 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 [2506.22639].

The persistence properties differ by carrier. Hardware-derived fingerprints are explicitly motivated as being harder to spoof than software-visible attributes [1503.01408]. 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 [1804.03852] [2201.07597] [2506.00719].

## 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 $f_{ij}$, and a new fingerprint $f_u$ is matched against a stored database using a modified Jaccard measure,
\[
Jaccard^{'}(S_n,S_d)=\frac{|S_n \cap S_d|}{|S_n|},
\]
where $S_d$ is typically the union of several initial measurements and $S_n$ is a new query result [2201.07597]. 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 [2307.00143].

Browser-fingerprinting risk work instead frames the problem information-theoretically. “Assessing Web Fingerprinting Risk” uses entropy
\[
H(X) = -\sum_x \Pr[X = x] \log \Pr[X = x]
\]
for individual surfaces and a Chow–Liu style upper bound on joint entropy,
\[
H(X_S) \le \sum_{s \in S} H(X_s) - \sum_{(s, s') \in T} I(X_s; X_{s'}),
\]
to avoid overestimating risk when Web APIs are correlated [2403.15607]. 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 $\langle name, args, N \rangle$, builds a matrix of known fingerprinting behavior from Disconnect, and compares unknown scripts to known fingerprinters with the Jaccard index
\[
J(A,B)=\frac{|A\cap B|}{|A\cup B|}.
\]
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 [2103.00590].

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 $s$ 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 [1605.08664]. 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,
\[
\dist(\bb,\mod)\defi 1 - \frac{\hat{I}(\tZ,\tY)}{\min(\hat{H}(\tY),\hat{H}(\tZ))}\in[0,1],
\]
and pairs it with a greedy benign-input selection algorithm for detection [2208.03169]. 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 [2606.03330]. 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 [2601.21680].

## 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 [2201.07597]. 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 [2201.07597].

FP-Rowhammer reports a larger-scale DRAM study: on **98 DIMMs**, it achieves **99.91% accuracy**, **100% precision**, and **97.06% recall** [2307.00143]. 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** [2307.00143].

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 [1804.03852].

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** [2506.00719]. The most discriminative ratios are based on `wasm-scripted-setter-1`, `wasm-scripted-setter-2`, and `wasm-scripted-getter-0`, with thresholds $SS1Threshold = 3.05$ and $SS2Threshold = 3.10$.

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 [2208.03169]. FLIPS evaluates **237 instances derived from 25 open-weight LLMs** and reports **96% closed-set accuracy** and **90% open-set accuracy** with $N_t=8$, versus **35%** for the adapted LLMmap baseline [2606.03330]. 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 [2403.15607]. 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 [2403.15607].

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 [2112.01662]. 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 [2112.01662].

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%** [2502.01608]. 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 [2502.01608]. 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 [2506.22639]. 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** [2506.22639]. 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 [2506.22639].

## 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 [2201.07597]. 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 [2307.00143]. 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 [2403.15607]. 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 [2506.00719]. Detection systems also face epistemic limits: script-classification methods observe only client-side behavior and cannot prove how backend systems use collected data [2103.00590].

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%** [2601.21680]. 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 [2412.16595] 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 [2412.16595].

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.

Source: https://www.emergentmind.com/topics/instance-level-fingerprinting