How the limit is measured
The probe is a few lines: recurse a counter-incrementing function until it throws, and record the counter. The resulting number is surprisingly specific. V8 (Chrome), SpiderMonkey (Firefox), and JavaScriptCore (Safari) each allocate stacks differently and enforce different ceilings, so the depth lands in distinct ranges per engine. The exact value also shifts with CPU architecture (x86-64 vs ARM64), OS (stack size defaults differ), and the size of each frame - so probes fix the frame shape (number of arguments and locals) to keep the measurement comparable.
Because the number comes from the engine running real instructions, you cannot move it from JavaScript without changing how the engine actually executes - there is no property to overwrite.
Why it catches engine spoofing
The decisive use is catching tools whose engine does not match their claimed browser. Camoufox is Firefox under the hood; if it presents a Chrome User-Agent, its recursion depth lands in the SpiderMonkey range, not the V8 range - an immediate contradiction. The same applies to any "Chrome" that is really something else, or a JS runtime impersonating a browser. Measuring the depth separately on the main thread, in a Web Worker, and in WASM adds further resolution, because the ratios between those contexts are also engine-specific.
This is one of a family of engine-level probes (alongside Math precision and WASM tricks) that read the real implementation rather than the advertised one. The only robust defence is to actually run the engine you claim - a Chrome-based tool for a Chrome UA - or to patch the engine's stack limit at the C++ level to match the target, which is exactly the kind of deep change DIY stealth scripts cannot make.
