Non-Chromium UA (Safari/Firefox) sends Sec-CH-UA (a Blink-only header) — Chromium faking it
net.ch_ua_on_non_chromium_ua · convicts
What it catches
Network-layer engine coherence via the User-Agent Client Hints header set. Sec-CH-UA is Blink-EXCLUSIVE: Chromium sends it; Safari (macOS + iOS) has NEVER shipped Client Hints (WebKit declined the spec) and Firefox declined them too (Mozilla, privacy). So a request whose UA claims Safari or Firefox while ANY Sec-CH-UA header is present is a Chromium engine wearing that UA. This is the HEADER-layer twin of br.apple_ua_nonwebkit / br.firefox_ua_nongecko (which read JS window.chrome/buildID): because it lives on the HTTP request, it fires even for a NO-JS scraper — a curl/Go/Python client that copied a Safari/Firefox UA but sits behind a Chromium-Client-Hints-emitting stack, or a headless Chromium with JS disabled — that the JS-based checks never see (no JS runs). Complements net.ch_ua_vs_ua_browser, which needs the JS ua_browser to COMPARE against; this needs only the header's PRESENCE under a non-Chromium UA. FP-SAFE: no real Safari (or iOS in-app WKWebView) or Firefox emits any Sec-CH-UA header; scoped to a Safari/Firefox UA (uaHeaderBrowser) so a real Chrome UA is out of scope. Convicting (w0.7). GROUNDED LIVE: a Chromium (stealth) given an iPhone-Safari UA OR a Firefox UA sends Sec-CH-UA under it and fires ch_ua_on_non_chromium_ua; under its native Chrome UA it does not.
Signals it reads
network.ch_ua_on_non_chromium_ua
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.