the ClientHello extension order is shuffled per connection, as Chrome does
Check id tls-clienthello-order-varies
What an ordinary browser yields
JA3 differing between the two probe handshakes while JA4 stays identical. N/A for non-Chromium claims, for Chromium below 110, and when only one probe answered (severity: warn).
What a detector infers
JA4 and JA3 disagree about ordering on purpose, and that disagreement is the assertion. JA4 sorts the cipher and extension lists and drops GREASE, so it describes the SET a stack offers. JA3 preserves order, so it describes the set AND its arrangement. Chrome has shuffled its ClientHello extension order on every connection since version 110 - a deliberate anti-ossification measure, so middleboxes cannot come to depend on a fixed layout. The consequence is that a real Chrome produces a stable JA4 and an unstable JA3, and the pair moving in opposite directions is something no reference corpus is needed to verify: the browser is asked twice and compared against itself. MEASURED on this machine, six connections across three ports in two rounds: stock Chrome 150 produced six distinct JA3 values and a single JA4; a Chromium 150 stealth build produced six distinct JA3 values and the same single JA4. Both correct, and neither distinguishable from the other on this axis. WHAT IT CATCHES is the shape the JA4-stability row cannot see, because that row is satisfied by it: a stack that PINS its ClientHello. Impersonation libraries and TLS-rewriting proxies typically replay one captured hello byte-for-byte, which holds JA4 perfectly stable while also holding JA3 constant - a combination no Chrome has produced since 110. Gated on a Chromium brand at 110 or later, because the shuffle is Chrome's behaviour rather than the web's: Gecko does not randomise extension order, and scoring it there would fail Firefox for being Firefox. The honest false positive, stated in the row's own detail rather than hidden, is a TLS-terminating proxy - corporate inspection or some VPN clients - which re-originates the handshake with its own deterministic stack and is entitled to do so. That is why this is warn.
How to resolve it
Do not pin the ClientHello. A stack replaying one captured hello is stable in a way Chrome stopped being at 110, and that stability is the signal - the opposite of what pinning is for. A TLS library presenting a Chrome profile has to shuffle the extension order per connection the way Chrome does, not merely match Chrome's offered set once. Note that matching the set is what JA4 already checks, so a profile that gets JA4 right and JA3 pinned has satisfied the easier half and failed the half that moves.
Other 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 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. - DNS resolver path
dns-path-readoutResolver identity requires an authoritative DNS canary; page JavaScript cannot inspect it.
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-clienthello-order-varies belongs to.