Take a stock Go program, set the user agent to Chrome 140, request an HTTPS page. Before any header is written, the TLS library has already sent a ClientHello whose cipher suite order, extension list, elliptic curves, ALPN and GREASE placement are the ones `crypto/tls` emits, and the server hashes exactly those features into a JA3/JA4 value [5][6]. The user agent string arrives after that. The post's word for the result is contradiction rather than heuristic, and that is the correct word: nothing needs to be scored, because two assertions about the same client cannot both be true [6].
This is why the most common remediation is aimed at the wrong place. The author numbers `navigator.webdriver` patching as a layer-4 fix applied to a stack that already rejected the client at layer 1 [11]. Patch scripts run in the page. The page only runs after the handshake, the HTTP/2 SETTINGS exchange and the header inspection have all been passed [10].
The Bamberg figure is the strongest evidence in the piece and the one to hold loosely. Their crawl reported that 75% of the blocks observed against headless Chromium could be triggered on HTTP header signals alone, with no JavaScript executed [9]. Invert it and at most a quarter of those blocks needed anything past the headers [20]. For the 75% to describe your workload, your targets have to look like the crawl's: Tranco Top 1M properties, unauthenticated navigation, headless Chromium as the client, and whatever mix of detection vendors those sites happened to run in that sample [9]. A single authenticated vendor portal is a sample size of one, and it is not in that population.
The consistency argument is the more portable part. The post enumerates eight agreements that hold on a real desktop Chrome, running from TLS-to-UA at one end to timezone-versus-exit-IP and language-list-versus-`Intl` at the other, and requires all of them to survive being asked from a Web Worker or an iframe instead of the main thread [13][14]. That is a conjunction, not a checklist you can partially satisfy. The `navigator.connection` case shows the cost of getting it wrong at one node: real Chrome derives `rtt`, `downlink` and `effectiveType` from one measurement, so `effectiveType: '4g'` next to `rtt: 0` is a pair Chrome never emits [18]. The author says his browser measures the actual round trip through the proxy and runs it through Chromium's own effective-connection-type thresholds so the three fields agree by construction [19]. A defender who needs to find two mutually exclusive claims has a cheaper job than a builder who needs eight simultaneous ones, which is an unusual arrangement in this business.
In my context the conclusion is not to build a better disguise. If the job is one portal and one invoice, the coherent fingerprint you already own is a real desktop browser profile on a real desktop, and the cheaper engineering is a credentialed feed. Fleet-scale automation is where you accept the maintenance: someone owns the whole bundle, derives it from measurements rather than field by field, and re-checks it every time the container image changes [13][19].
