Skip to content
All fingerprint checksAutomation surface

timer handles are a real per-realm counter

Check id timer-id-sequencing

What an ordinary browser yields

A newly created realm hands out consecutive positive integers from a single counter shared by setTimeout and setInterval — 1, 2, then 3.

What a detector infers

The number setTimeout hands back is not a token, it is an index into the realm's own timer table — so it carries structure that a fabricated handle does not. A realm that has just been created has an empty table, hands out its first slot, then its second, and setInterval draws from the SAME counter rather than starting one of its own. Measured on a stock Chrome: a newborn realm returns 1, then 2, then 3 for setInterval, while the page's own window had already reached 47. The check therefore does its measuring inside a PRIVATE iframe it creates and destroys, not in the page and not in the audit's shared realm. That is the whole trick. The main window's counter is racing every timer that React, a chat widget or an extension schedules, so consecutive numbering there proves nothing and would fail honestly at random; a virgin realm is the only place the sequence is deterministic. Consecutive numbering is asserted only on V8, because the specification says merely that the handle is a 'user-agent-defined integer' — demanding consecutiveness of every engine would be inventing a rule rather than reading one, so elsewhere the check falls back to what is universally true: the handles must be positive integers and they must increase. What this catches is a wrapper that issues its own handles — randomised to look unpredictable, or drawn from a separate counter per function — which breaks an invariant that costs nothing to verify.

How to resolve it

Leave setTimeout and setInterval native. If they must be wrapped, the wrapper has to return the real underlying handle rather than one of its own, and setInterval must continue the same sequence setTimeout is drawing from — which is easier to achieve by not wrapping them at all.

How automation gets caught, layer by layer

Read in the wild by

Kasada

Reads the numeric handle setTimeout/setInterval return, in both realms — the handle, not just the function.

window_set_timeout_id, iframe_set_timeout_id, window_set_interval_id, iframe_set_interval_id

Kasada ips.js teardown — the full 427-probe 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 timer-id-sequencing belongs to.