Global Privacy Control reads the same in the page, in a worker and on the wire
On Firefox-family engines and Brave, the window property, the worker property and the Sec-GPC header all agree. Shown but not asserted on other Chromium browsers; N/A when the header probe cannot be reached (severity: warn).
What a detector infers
Global Privacy Control has three faces: navigator.globalPrivacyControl in the window, the same property in workers, and the Sec-GPC: 1 request header. Where GPC is native, one setting drives all three. Measured on Firefox 144: default is false, false and no header; with GPC enabled it is true, true and Sec-GPC: 1; a sweep of all eight combinations of Firefox's GPC and Do-Not-Track preferences could not produce a true property without the header.
So on an engine that implements GPC natively — Firefox and its forks, and Brave — any disagreement between the three is a value written into one layer and not the others. On Chrome and other Chromium browsers GPC exists only when an extension adds it, and an extension may add either half, so the row shows what it saw there and asserts nothing.
How to resolve it
Turn GPC on through the browser's own preference (Firefox: privacy.globalprivacycontrol.enabled) so the property in every realm and the header follow it together, or leave it at the default. Injecting only the navigator value creates a state no real configuration reaches.
Read in the wild by
Camoufox (measured)
Measured while establishing ground truth for this row. With globalPrivacyControl set in its fingerprint config, the page reads the property as false, a worker reads it as true, and the request carries no Sec-GPC header — three answers to one setting.
Camoufox (Firefox 152 base) on Windows, config { navigator.globalPrivacyControl: true }: window false, worker true, no Sec-GPC. Stock Firefox 144 with privacy.globalprivacycontrol.enabled: window true, worker true, Sec-GPC: 1.
camoufox.comEvery attribution traces to a published artifact. See the sources and their limits.
Other checks in HTTP request vs the runtime
- Accept-Language leads with the same language as navigator.languages
accept-language-vs-navigatorAccept-Language and navigator.languages are two views of one browser preference: the header is serialised by the network stack, the array is… - the client-hint headers match navigator.userAgentData
sec-ch-ua-vs-uadataUser-Agent Client Hints exist in two places at once, which is what makes them checkable. - Sec-Fetch-* describes the request this page actually made
sec-fetch-metadataSec-Fetch-Site, Sec-Fetch-Mode and Sec-Fetch-Dest are attached by the browser to describe the request's own provenance — where it came from… - the order your browser emits its HTTP headers in
http-header-order-readoutA browser emits its request headers in a fixed sequence compiled into its network stack, and that sequence differs between engines… - no cache-validation headers on requests that should carry none
request-cache-headersA real Chrome sends no cache-validation headers on a request it has not been told to revalidate.
Clearcote is a browser built for fingerprint coherence
It is a Chromium fork, maintained by the same people who wrote this reference. It ships as a compiled browser rather than as a stealth script injected into someone else's — which is a description of how it is built, and is not an argument about how it behaves on this check.
This audit takes no position on how Clearcote scores on HTTP request vs the runtime checks, on this one, or anywhere else. It has no baseline corpus of other people's fingerprints to rank you against and no vendor scoreboard — nearly every check is self-referential, asking one browser the same question through two independent APIs and reporting whether both answers can be true at once. It runs identically on any browser, including ours. Run it on yours and read the result yourself.
See the other checks in HTTP request vs the runtime — the family gpc-header-vs-navigator belongs to.