Firefox/Safari UA but navigator.deviceMemory (a Blink-only API) is present
br.devicememory_vs_engine · convicts
What it catches
Engine<->API-surface coherence via the Device Memory API. navigator.deviceMemory is Blink-EXCLUSIVE: Chromium ships it, but Firefox deliberately declined it (privacy — https://github.com/w3c/device-memory has no Gecko implementation) and Safari/WebKit never shipped it. So a UA whose engine token is firefox or safari while navigator.deviceMemory is DEFINED is a Blink engine wearing a non-Blink UA. This is the inverse of br.no_devicememory (Chromium UA MISSING deviceMemory) and complements br.apple_ua_nonwebkit (window.chrome/userAgentData present under a Safari UA) + the Gecko buildID check through a THIRD, independent Blink surface — so it still fires when a spoofer patches out window.chrome + navigator.userAgentData and fakes buildID but forgets deviceMemory. The ratchet: one more Blink surface a Chromium-faking-Firefox/Safari must scrub. FP-SAFE: no real Firefox or Safari exposes deviceMemory. Scoped to the firefox/safari UA engines (not 'other', which may be a legitimately Chromium-based browser with an unusual UA). GROUNDED LIVE: a Chromium (stealth) given a Firefox UA fires devicememory_vs_engine (Blink deviceMemory present under a Firefox UA); under its native Chromium UA it does NOT (that path is the coherent chrome_no_devicememory forward-check instead).
Signals it reads
browser.devicememory_vs_engine
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.