timer handles are a real per-realm counter

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.