Why instability is a red flag
On a real device, reading the canvas or audio fingerprint twice gives the same answer - the computation is deterministic for that hardware and software. Some privacy tools defend against tracking by injecting random noise so the value differs on every read. Detectors exploit that: a simple check renders a known pattern and verifies the pixels, and per-call noise makes the output deviate from the deterministic baseline, exposing the modification. When consecutive reads disagree, a consistency tool reports the value as unstable. So randomisation that is too aggressive trades one signal (a unique fingerprint) for a louder one (an impossible, ever-changing fingerprint).
How tools measure persistence
Consistency tools such as CreepJS collect raw signals across many APIs and compute more than one identifier from them: a stable, exact identity hash plus a looser, fuzzy hash that groups similar browsers. Comparing those identifiers across reloads and sessions answers the persistence question - does this profile stay the same when it should? A genuine browser holds steady; a profile whose values drift between reads stands out. The same tools pair this with consistency checks that look for values contradicting each other, so an unstable fingerprint and an internally inconsistent one are flagged by the same machinery.
Why stability matters for scraping
The practical lesson is that blending in is about coherence and stability, not noise. A profile drawn from a real browser population and kept consistent across a session looks ordinary; one that scrambles its fingerprint on every request looks like nothing a real user runs. This is also why a profile should return the same fingerprint when it reconnects through the same network and TLS context - a fingerprint that resets unpredictably between reconnects is as anomalous as one that changes mid-session. Stability is the goal; randomisation is the tell.
