the TLS ClientHello carries what the claimed Chrome major always sends
The ClientHello carries every extension the claimed major enables by default. N/A for other Chromium vendors, non-Chromium engines and majors before 120; enterprise policies that disable the post-quantum share or ECH are named in the detail (severity: warn).
What a detector infers
The cipher-list row asks whether a Chromium network stack made the connection. This one asks whether it is the Chromium the user agent names, without comparing against a database of fingerprints (those go stale as Chrome releases). It checks only for extensions a milestone switched on by default and has sent on every connection since: trust_anchors (0xCA34) from 152, the X25519MLKEM768 post-quantum key share from 131, and encrypted_client_hello from 120.
Measured through the probe: Chrome 153 and a bare Chromium 153 send all three; Chromium 143 sends the post-quantum share and ECH but no trust_anchors, as a 143 should. A browser claiming Chrome 153 whose ClientHello lacks trust_anchors has a network stack older than its user agent — or a TLS library imitating an older Chrome profile. Edge 153 does not send trust_anchors, so the row is limited to the Google Chrome brand and bare Chromium, where the measurement holds.
How to resolve it
Claim the Chrome major the binary actually is — the ClientHello is written below any user-agent override. A TLS library imitating Chrome must use a profile that matches the claimed major, not an older release's.
Nearby checks in TLS & the network layer
- the TLS fingerprint is the same on two separate connections
ja4-stable-across-connectionsEverything else on this page reads the browser through JavaScript. - the ClientHello extension order is shuffled per connection, as Chrome does
tls-clienthello-order-variesJA4 and JA3 disagree about ordering on purpose, and that disagreement is the assertion. - the TLS fingerprint this browser presents to a server
tls-fingerprint-readoutThis row reports rather than judges, and the reason it exists is that it is the only place on this page where the browser is described by… - TLS cipher list matches the claimed engine
tls-cipher-suite-vs-engineYour browser announces which engine it is twice, through channels that cannot reach each other. navigator.userAgent is a string any page can… - TLS identity matches the browser
tls-browser-identityJA4 repeatability proves stability, not that the profile matches the claimed browser. - HTTP/2 settings and order
http2-fingerprint-readoutHTTP/2 SETTINGS and pseudo-header order are emitted below JavaScript. - HTTP/3 / QUIC transport
http3-quic-readoutQUIC versions and transport parameters form an independent fingerprint. - IP network classification
network-reputation-readoutASN, network class, and proxy/VPN/Tor indicators describe the route, not the browser, and are never standalone verdicts.
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 TLS & the network layer 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 TLS & the network layer — the family tls-extensions-vs-claimed-major belongs to.