Skip to content
All fingerprint checksAutomation surface

window.chrome.* helpers are native (not JS stubs)

Check id chrome-native-stubs

What an ordinary browser yields

chrome.csi and chrome.loadTimes are either native functions or absent — never JS-defined stubs.

What a detector infers

Where the previous check asks whether window.chrome exists, this one asks whether its members are genuine. It walks chrome.csi and chrome.loadTimes and, for each that is a function, stringifies it via Function.prototype.toString; a real built-in returns a body containing { [native code] }, whereas a JavaScript replacement returns its own source text. Any that stringify as JS are collected and fail the check. This is the mechanism that catches shimming libraries: they add these members to satisfy naive existence checks, but a function defined in JavaScript cannot stringify as native, so the very act of filling the gap creates a more specific artifact than the gap itself. Absence is treated as fine — the check only flags functions that are present and non-native. It is N/A on a non-Chrome UA or when window.chrome is missing entirely.

How to resolve it

Remove puppeteer-stealth-style polyfills of chrome.csi / chrome.loadTimes. Real Chrome exposes them as native functions or not at all, so the honest options are a real Chromium build or leaving them absent; a JS stub is strictly more revealing than the missing member it replaces.

Why does Function.toString() reveal a hooked function?

Read in the wild by

PerimeterX / HUMAN

Walks window.chrome, chrome.app and chrome.runtime, requiring every function-typed member to stringify as {[native code]}; separately sums the constructor-string lengths of webstore, runtime, app, csi and loadTimes into a single reported field.

main.min.js (PerimeterX collector, ifood): `ky(t){if(t){try{for(var n in t){var e=t[n];if(hR(e)===ie&&!kz(e))return!1}}catch(t){}return!0}}` where `function kz(t){return hR(t)===ie&&new RegExp("\\{\\s*\\[native code\\]\\s*\\}","").test(""+t)}` and ie="function"; applied inside `AQ()` as `ky(Ax)`, `ky(Ax[Ay])`, `ky(Ax[Az])` with `Ax=hS[jb("Y2hyb21l")]` and `hS=window` (=window.chrome), `Ay=jb(hQ(509))`='app', `Az=jb(hQ(510))`='runtime'. Separately `AA=[hQ(511),Az,Ay,"csi","loadTimes"]` (hQ(511)='webstore') drives `AO(){…for(var n=0,e=0;e<AA[hQ(155)];e++)try{n+=(Ax[AA[e]].constructor+"")[hQ(155)]}catch(t){}t+=n+Av;…}` (hQ(155)='length', Av="|"), emitted as `t["PSkIY3hPCVE="] = AO()` → EV2 "PSkIY3hPCVE=" = "109|66|66|70|80", whose leading 109 is the summed total (Object 35 + Function 37 + Function 37 for app/csi/loadTimes; webstore and runtime absent so .constructor throws and is swallowed), not a per-member list.

Every attribution traces to a published artifact. See the sources and their limits.

Nearby checks in Automation surface

See all 27 checks in Automation surface
Who builds this test

Clearcote is a browser built for fingerprint coherence

It is a Chromium fork, maintained by the same people who wrote this reference. It ships as a compiled browser rather than as a stealth script injected into someone else's — which is a description of how it is built, and is not an argument about how it behaves on this check.

This audit takes no position on how Clearcote scores on Automation surface checks, on this one, or anywhere else. It has no baseline corpus of other people's fingerprints to rank you against and no vendor scoreboard — nearly every check is self-referential, asking one browser the same question through two independent APIs and reporting whether both answers can be true at once. It runs identically on any browser, including ours. Run it on yours and read the result yourself.

See the other checks in Automation surface — the family chrome-native-stubs belongs to.