navigator.deviceMemory differs between the main thread and a Worker
br.devicememory_worker_divergence · convicts
What it catches
Realm coherence for the Device Memory API — the gap the general br.worker_divergence missed. navigator.deviceMemory is exposed in WorkerNavigator too (Blink), yet the worker probe only reported ua/hardwareConcurrency/platform, so a main-thread-ONLY patch of navigator.deviceMemory (a spoofer inflating RAM to look like a higher-end device, or hiding a low-memory VM/container) survived every realm check. This adds deviceMemory to the worker postMessage and fires when the worker's value disagrees with the main thread's. A page-added init script (Playwright/Puppeteer addInitScript, CDP addScriptToEvaluateOnNewDocument) does NOT run in Worker scope, so a main-only Object.defineProperty patch diverges here — the same context-isolation gap br.languages_worker_divergence / br.webgl_worker_divergence exploit, extended to deviceMemory. FP-SAFE via the 'u' sentinel: both realms undefined (real Firefox/Safari — no Device Memory API) compare EQUAL and never fire; a real Chromium reports ONE value in both realms and is silent; only a main-only spoof diverges. Convicting (w0.8 — a realm divergence is a hard tamper signal). GROUNDED LIVE: stealth with a main-only navigator.deviceMemory override (KS_SPOOF_DM) fires devicememory_worker_divergence; the same browser without the patch is SILENT.
Signals it reads
browser.devicememory_worker_divergence
How it fires
present
Bypassed by 10
Frontier evaders that reach the detector uncaught (scored only suspicious, defeating every convicting tell) — this check is not one that stops them. The red-team frontier this detection still has to convict.