Trust
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 launch archetype — iPhone 15 Pro, iPhone 16 Pro, and the current iPhone 17 lineup, on iOS 18.7 / Safari 26.4 and Safari 26.5. 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 canvas hash, the WebGL renderer, the AudioContext fingerprint, the Core Text font-metric output, the JavaScript engine timing — those leak the underlying Chromium engine in the next layer of measurement.
Detection systems combine many signals into one score. A single mismatch — UA says iPhone, 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 load-bearing leak: a real iPhone returns the same
value as millions of other iPhones, 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 + DPR | configurable | 393x852 @ 3x (iPhone 16 Pro) |
| CSS @media (hover) value | "hover" | "none" (touch device) |
| requestIdleCallback presence | present (Chromium) | absent (Safari) |
| 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 load-bearing ones that flip categorical-detection decisions.
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 shims — that's the approach every stealth-plugin tool takes, and it's exactly what the rig catches.
When iOS releases a new Safari version, the reference moves and the engine has to catch up. Until it does, the prior reference stays the customer-facing archetype; the engine targets the prior iOS, not a half-built blend.
Related
- /trust/security-overview — the live security posture across the four shipped pillars.
- /comparison — how Driftstack's fingerprint posture compares to other browser-API vendors.
- /security — TLS posture, scrypt-hashed keys, HMAC webhooks, no-customer-data-access enforcement.