Trust center · Cumulative rig
Cumulative rig methodology.
The cumulative rig is the full set of measurable signals a detection system can read from a browser session. Driftstack's product claim — indistinguishable from a real iPhone — is only meaningful if every signal in the rig matches what the reference phone sends. This page documents what we measure, how, and against which reference.
The table below shows the rig run against iPhone 16 Pro · iOS 18.7 · Safari 26.4 as a worked example. The same methodology runs against every archetype in the catalog — 81 profiles, iPhone 13 → 17 Pro Max, on iOS 18.6 / 18.7, Safari 18.6–26.5. (An archetype is one specific iPhone model + iOS version + Safari version combination — see the glossary.) If any signal differs from what the real phone sends, we treat it as a launch-blocking bug and fix the engine — not a JavaScript wrapper over it.
Why cumulative
Any single signal is easy. Every signal at once is the hard part.
A stealth Chromium tool can spoof the user-agent string in five minutes. It can fake the screen size in another five. But the deeper measurements — how the browser draws an invisible test image (the canvas hash), which graphics engine it reports (the WebGL renderer), how its audio system rounds numbers (the AudioContext fingerprint), how its fonts measure on screen (the Core Text font-metric output), even the timing rhythm of its JavaScript engine — those leak the underlying Chromium engine in the next layer of measurement.
Detection systems combine many signals into one score. A single mismatch — the browser introduces itself as an iPhone (its user-agent, "UA"), but its drawing output betrays Chrome's engine (the canvas hash says Blink) — flags the session as inauthentic. Driftstack's claim isn't "we got the user-agent right." It's "every signal in the rig, at the same time, returns the iPhone value."
Measured signals
Signal-by-signal table.
Each row is a signal a detection system can read. The
"Driftstack" column is what an iPhone 16 Pro returns; the
"Stealth Chromium" column is what a representative
Chromium-with-stealth-plugin tool returns. Cells marked
unique-per-session
are the giveaway that matters most: a real iPhone returns the same
value as millions of other iPhones — that is what
population-stable means in the Driftstack column — so any
tool that returns
a hash unique to its own session has already given itself
away.
| Signal | Stealth Chromium | Driftstack (iPhone 16 Pro · iOS 18.7) |
|---|---|---|
| navigator.userAgent | spoofed string | iPhone Safari UA (unmodified) |
| navigator.platform | spoofed | "iPhone" |
| Canvas 2D hash | unique-per-session (Skia) | population-stable (Core Graphics) |
| WebGL renderer | "ANGLE / SwiftShader" | "Apple GPU" |
| WebGL hash | unique-per-session | population-stable |
| AudioContext fingerprint | Blink audio backend | iOS audio backend |
| Font metric outputs | Linux / desktop fonts | iOS Core Text metrics |
| JavaScript engine timing | V8 latency profile | JSCore latency profile |
| TLS ClientHello fingerprint | Chrome / Edge profile | iOS Safari profile |
| Touch-event support flag | absent or spoofed | native |
| Screen dimensions + pixel density (DPR) | configurable | 393x852 @ 3x (iPhone 16 Pro) |
| CSS @media (hover) value | "hover" | "none" (touch device) |
| requestIdleCallback presence | present (Chromium) | absent (Safari) |
| Same fingerprint, session after session? Hash uniqueness across sessions | 100% unique | population-stable |
14 signals shown above. The internal rig measures 60+ signals across every session built; the published subset is the ones that most decide whether a detection system classifies a session as real or fake.
Launch-blocker policy
Any drift from the reference is a launch-blocking bug.
Every Driftstack engine build runs the cumulative rig against the reference iPhone. If any signal differs from what the reference returns, the build does not ship. We don't paper over individual signals with JavaScript patches ("shims") layered on top — that's the approach every stealth-plugin tool takes, and it's exactly what the rig catches.
When Apple ships a new iOS or Safari version, our target (the reference) moves and the engine has to catch up. Until it fully matches the new version, we keep offering the previous version's profiles — a phone Apple really shipped — as the customer-facing archetype; the engine targets the prior iOS, not a half-built blend of old and new.