How stable are device fingerprints across browser updates?

Why browser updates are a fingerprinting stress test

A browser update looks like a silent event from a user's perspective: the browser restarts, a new version number appears, and nothing visible changes. From a fingerprinting perspective it can look like a different device.

Browser vendors ship updates at an accelerating pace. Chrome and Firefox both run on four-to-six week major-release cycles. Safari follows macOS and iOS cadences. Edge tracks Chrome's Blink releases. That means a device fingerprinted in January may have been through eight or more major version bumps by December, each one a potential source of signal drift.

The academic literature treats this as a well-known failure mode. The FP-Stalker study (Vastel et al., 2018) tracked real browser fingerprints over time and found that a fingerprint was likely to change within days to a few weeks for a significant fraction of users, with browser updates being among the most frequent causes. The 'Hiding in the Crowd' study (Gomez-Boix et al., 2018) reached similar conclusions: temporal stability is a harder problem than uniqueness. A fingerprint can be rare enough to identify a specific browser in a population and still change frequently enough to lose track of the same user across sessions weeks apart.

Understanding why requires unpacking what a browser fingerprint actually measures, and which parts of that measurement a version bump can touch.

The hardware-engine split: the fundamental stability divide

Every browser fingerprint is a bundle of signals collected from the browser environment. Those signals fall into two categories with very different stability profiles across updates.

Hardware-bound signals measure properties of the physical device underneath the browser: GPU identity and capabilities, CPU architecture and core count, the set of fonts installed on the OS, display geometry and pixel density, and similar facts that live at the OS or device level. A browser update does not change any of these. The GPU is the same chip. The font set is the same OS-managed list. The display did not change resolution. A major version bump has essentially no effect on hardware-bound signals, because the browser is not the source of those facts.

Engine-bound signals measure how the browser engine processes content: the exact floating-point output of an audio DSP pipeline, the specific pixel values produced by a canvas drawing operation, how WebGL maps geometry to screen pixels, what numeric results a JavaScript engine returns for certain floating-point operations. These live inside the browser's implementation. When a browser ships a new rendering engine version, an updated audio stack, a patched WebGL driver interface, or a revised JavaScript engine, any of these values can change. The device did not change. The measurements of the device's rendering environment did.

This split is the single most important structural fact about fingerprint stability across browser updates: hardware-bound signals are insulated from engine changes by definition, and engine-bound signals are exposed to every rendering pipeline change the vendor ships.

What the research shows about drift rates

The EFF's Panopticlick project was among the first to systematically measure the uniqueness of browser fingerprints in a large population, finding that the combination of a modest set of signals was sufficient to uniquely identify a substantial majority of browsers. Uniqueness, however, is not the same as stability, and the research community quickly established that temporal persistence is the harder half of the problem.

FP-Stalker followed real fingerprints over time and measured how quickly they changed. The central finding was that browser updates were one of the top causes of fingerprint change, and that a fingerprint changed for a substantial fraction of tracked users within a few weeks. The practical implication: if your system stores an exact fingerprint hash and matches against it strictly, a proportion of your returning users will look like strangers after their browser auto-updated.

The amiunique.org longitudinal dataset reinforced this. Returning visitors who used the same device and browser often presented a changed fingerprint after a browser update, even though their hardware was unchanged. The change was concentrated in exactly the engine-bound signals the hardware-vs-engine taxonomy would predict: canvas, audio, and rendering outputs, rather than hardware and font characteristics.

What the literature is less explicit about is the asymmetry: hardware-bound signals in these datasets tended to be much more persistent than the aggregate fingerprint hash, because a hash that mixes both categories will drift whenever any component shifts. Separating the two categories and measuring each independently tells a different story.

How much does a major version bump typically move the fingerprint?

A precise answer requires knowing which engine-bound signals a specific version changed, and browser vendors do not publish that kind of signal-level changelog. What the public record supports is a qualitative range.

Minor updates within a major version series tend to cause little or no engine-bound drift. Bug fixes and security patches rarely touch the audio DSP or canvas rasteriser in ways that produce measurable numeric differences.

Major version bumps are more variable. A version that ships a new audio backend, a revised WebGL implementation, or a change to canvas anti-aliasing can shift all three corresponding signal categories simultaneously. A version that focuses on performance improvements to the JavaScript engine may not touch any fingerprinting-relevant output at all.

Privacy-motivated changes are a distinct driver. Google's privacy sandbox initiative, Firefox's anti-fingerprinting mode, and Safari's Intelligent Tracking Prevention have each introduced deliberate canvas noise, restricted access to certain sensor APIs, or homogenised screen-related properties across updates. These are intentional fingerprint-breaking changes, not accidental side effects of engine evolution. They tend to affect specific signal categories in a targeted way and can be identified by examining which signals moved together.

The practical upshot: on a rough average across a year of updates, a user with an unchanged device but a regularly auto-updating browser might experience fingerprint drift from engine-bound signals several times per year, concentrated around major version releases and browser-vendor privacy initiatives. Hardware-bound signals can survive all of those events unchanged.

Why this pushes systems toward probabilistic matching

If browser updates cause engine-bound signals to shift predictably but leave hardware-bound signals intact, then strict equality on a bundle of both categories will fail regularly for legitimate returning users. The standard solution is probabilistic matching: instead of requiring an exact hash match, score the similarity between two fingerprint sets, weight signals by their stability and entropy contribution, and produce a match confidence rather than a binary result.

This is the design Vastel et al. used in FP-Stalker to track fingerprints across changes: a learned model that could decide whether two different fingerprint hashes came from the same browser even after a version bump. The model was trained on which signals changed together (engine-bound signals correlate with browser updates), which changed independently (hardware-bound signals change when hardware changes), and what pattern of change constitutes a legitimate update versus a device substitution.

The architecture-level lesson from this is that the matching layer needs to know something about signal binding, not just signal values. A similarity score that weights all signals equally will be confused by a browser update that shifts ten engine-bound signals while leaving thirty hardware-bound signals unchanged. A score that weights hardware-bound signals more heavily for device continuity, and treats correlated engine-bound changes as consistent with a browser update rather than a device change, recovers the correct 'same device, different browser version' verdict.

This is one of the reasons that the hardware-vs-engine split discussed in the post on hardware-bound versus engine-bound fingerprints is not just a cross-browser concern. It is also a temporal stability concern: the same taxonomy that enables deterministic cross-browser matching also enables a comparison layer to distinguish legitimate update drift from genuine device substitution.

Signal-level drift patterns worth knowing

Several drift patterns recur in the public literature and in observed browser behavior across update cycles.

Canvas and audio signals shift together when a browser ships a rendering or audio pipeline change. When both move simultaneously for a given device, the most likely cause is a browser update rather than hardware change. When they move independently, the picture is more complex.

User-agent strings change on every browser update by definition, since they embed the version number. Any system that uses the user-agent as a fingerprint component will see drift on every update. This is widely understood and most serious fingerprinting systems treat the user-agent at a family level (Chrome/Safari/Firefox) rather than as a full string.

Font sets are highly stable because they are OS-managed, not browser-managed. A browser update does not touch the font list. OS upgrades occasionally do. This makes the font signal a reliable hardware-bound anchor across browser version changes.

GPU-related signals occupy an interesting middle ground. The GPU's reported identity is a hardware fact and does not change with browser updates. The WebGL rendering output is engine-bound and can shift when the GPU driver interface or shader compiler changes in a browser update. A system that uses the GPU identity separately from GPU rendering output captures the stable part without coupling it to the volatile part.

Privacy-mode signals, such as canvas noise injected by browsers in privacy modes or Brave's randomisation layer, introduce a different kind of drift: not deterministic version-linked drift, but per-site or per-session randomisation. These produce a signature of their own: the reported values are internally inconsistent across calls, or vary in ways that hardware variation does not explain. Treating them as a separate detection category, rather than as unexpected signal drift, avoids misclassifying a Brave user as a new device on every visit.

What this means for system design

Three practical implications follow from the hardware-engine split and the drift research.

First, storing a single aggregate hash is the highest-risk design for temporal stability. Any engine-bound signal that shifts on a browser update invalidates the hash, and the hardware-bound information in the hash is discarded along with it. Storing the hardware-bound and engine-bound components separately, or as separate hashes, preserves the stable component across browser updates and makes the match comparison aware of which component changed.

Second, match logic needs to handle correlated shift. When multiple engine-bound signals change simultaneously, that is a browser-update signature, not evidence of device substitution. A comparison algorithm that treats each signal as independent evidence will overweight this pattern. One that recognises correlated engine-bound drift as a coherent event correctly interprets it as 'browser updated' rather than 'new device'.

Third, the time horizon matters. For short-horizon matching, such as sessions within a few hours, an exact hash match on both hardware and engine components is likely to work well for most users, since a browser update mid-session is rare. For longer horizons, such as recognising a returning user weeks or months later, probabilistic matching against the hardware-bound component with fuzzy tolerance on the engine-bound component is the design that survives real-world browser update cadences without generating false rejections.

None of these are novel design conclusions: they follow directly from the academic literature on fingerprint stability. The gap between the literature and most deployed systems is that the literature reasons about signal-level binding and temporal patterns, while most systems hash everything into a single opaque value and only later discover that the value is not as stable as the uniqueness numbers suggested.

The stability picture in summary

Browser updates are frequent, and engine-bound signals shift with them. Hardware-bound signals are insulated from browser version changes by definition. The aggregate fingerprint hash sits in between: it drifts on the engine-bound component's schedule while the hardware-bound component remains stable underneath.

The public research on fingerprint stability over time, from Panopticlick's uniqueness baseline to FP-Stalker's drift-rate tracking to the amiunique.org longitudinal datasets, consistently shows that temporal persistence is the harder problem than uniqueness. Most of that hardness is concentrated in engine-bound signals and is predictably linked to browser update events.

Systems that treat the hardware-bound and engine-bound components separately can survive browser update cadences without false rejections. Systems that hash them together, and match on strict equality, discover the drift problem at production scale. The architectural choice of how to partition and match the signal set is made once, and the consequences of that choice accumulate with every major browser release.