Chrome's hidden X-Browser-Validation header reverse engineered
35 comments
·July 11, 2025userbinator
ulrikrasmussen
I am also alarmed. Google has to split off its development of both Chrome and Android now, this crazy vertical integration is akin to a private company building and owning both the roads AND the cars. Sure, you can build other cars, but we just need to verify that your tires are safe before you can drive on OUR roads. It's fine as long as you build your car on our complete frame, you can still choose whatever color you like! Also, the car has ads.
nurettin
Ok but The Road is the internet, how much of that does google/alphabet actually own?
Retr0id
SHA-1 is a head-scratcher for sure.
I can only assume it's the flawed logic that it's "reasonably secure, but shorter than sha256". Flawed because SHA1 is broken, and SHA256 is faster on most hardware, and you can just truncate your SHA256 output if you really want it to be shorter.
adrian_b
SHA-1 is broken for being used in digital signature algorithms or for any other application that requires collision resistance.
There are a lot of applications for which collision resistance is irrelevant and for which the use of SHA-1 is fine, for instance in some random number generators.
On the CPUs where I have tested this (with hardware instructions for both hashes, e.g. some Ryzen and some Aarch64), SHA-1 is faster than SHA-256, though the difference is not great.
In this case, collision resistance appears irrelevant. There is no point in finding other strings that will produce the same validation hash. The correct input strings can be obtained by reverse engineering anyway, which has been done by the author. Here the hash was used just for slight obfuscation.
pinoy420
[dead]
mindslight
> have they not heard of Sega v. Accolade ?
My mind went here immediately as well, but some details are subtly different. For example being a remote service instead of a locally-executed copy of software, Google could argue that they are materially relying on such representation to provide any service at all. Or that without access to the service's code, someone cannot prove this string is required in order to interoperate. It also wouldn't be the first time the current Supreme Court took advantage of slightly differing details as an excuse to reject longstanding precedent in favor of fascism.
wongarsu
And even if it falls under fair use in the US, they could still have a case in some other relevant market. The world is a big place
dsekz
Dug into chrome.dll and figured out how the x-browser-validation header is generated. Full write up and PoC code here: https://github.com/dsekz/chrome-x-browser-validation-header
Why do you think Chrome bothers with this extra headers. Anti-spoofing, bot detection, integrity or something else?
userbinator
Making it easier to reject "unapproved" or "unsupported" browsers and take away user freedom. Trying to make it harder for other browsers to compete.
wernerb
Is it not likely that it protects against AI bot Llama?
twapi
Seems like they are using these headers only for google.com requests.
xnx
Yes I think it is part of their multi level testing of for new version rollouts. In addition to all the internal unit and performance tests, they want an extra level of verification that weird things aren't happening in the wild
null
exiguus
I have two questions:
1. Do I understand it correctly and the validation header is individual for each installation?
2. Is this header only in Google Chrome or also in Chromium?
gruez
>1. Do I understand it correctly and the validation header is individual for each installation?
I'm not sure how you got that impression. It's generated from fixed constants.
https://github.com/dsekz/chrome-x-browser-validation-header?...
cebert
I have to imagine Google added these headers to make it easier for them to identify agentic requests vs human requests. What angers me is that this is yet another signal that can be used to uniquely fingerprint users.
gruez
It doesn't really meaningfully increase the fingerprinting surface. As the OP mentioned the hash is generated from constants that are the same for all chrome builds. The only thing it really does is help distinguish chrome from other chromium forks (eg. edge or brave), but there's already enough proprietary bits inside chrome that you can easily tell it apart.
thayne
> The only thing it really does is help distinguish chrome from other chromium forks (eg. edge or brave)
You could already do that with the user agent string. What this does is distinguishes between chrome and something else pretending to be chrome. Like say a firefox user who is spoofing a chrome user agent on a site that blocks, or reduces functionality for the firefox user agent.
bobbiechen
Plenty of bots pretend to be Chrome via user agent, but if you look closely are actually running Headless Chromium. This is a very useful signal for fraud and abuse prevention.
thayne
I'm more concerned that whether intentional or not this will probably cause problems for users who use non-chrome browsers. Like say slowing down requests that don't have this header, responding with different content, etc.
userbinator
User-agent discrimination has been happening for literally decades at this point, but you're right that this could make things worse.
snackbroken
User-agent discrimination is tolerable when it's Joe Webmaster doing it out of ignorance. It is not acceptable if it is being used by a company leveraging their dominant position in one market to gain an advantage over its competitors in another market. It's not acceptable even if it's not said company's expressed intent to do so but merely a "happy accident" that is getting "overlooked".
Indeed, even for those who require a round of mental gymnastics before they concede that monopolies are, like, "bad" or whatever, GP points out precisely how this would constitute "consumer harm".
thayne
Why would they think this was a good idea after losing the chrome anti-trust trial? I don't know the intended purpose is for this, but I can see several ways this could be used anti-competitive way, although now it has been reverse engineered, an extension could spoof it. On the other hand, I wonder if they intend to claim the header is a form of DRM and such spoofing is a DMCA violation...
Retr0id
x-browser-copyright seems like an attempt at something similar to the Gameboy's nintendo-logo DRM (wherein cartridges are required to have the nintendo logo bitmap before they can boot, so any unlicensed carts would be trademark infringement)
userbinator
http://en.wikipedia.org/wiki/Sega_Enterprises_Ltd._v._Accola... is the legal precedent that says trying to do that won't work, but then again maybe Google thinks it's invincible and can do whatever it wants after it ironically defeated Oracle in a case about interoperability and copyright.
Retr0id
Even if they can't defend it legally, it costs them ~nothing to add the header and it could still act as a deterrent.
krackers
>an extension could spoof it
not if they make it dynamic somehow (e.g. include current day in hash). Then with MV3 changes that prevent dynamic header manipulation there is no way for an extension to spoof it.
aussieguy1234
So this is basically hidden client attestation?
Everdred2dx
If you were using a user agent spoofing extension couldn't this be used to guess your "real" UA?
_imnothere
And why should anyone with a sane mind (except for Googlers) allow this kind of validation bs to exist?
This should be somewhat alarming to anyone who already knows about WEI.
I wonder if "x-browser-copyright" is an attempt at trying to use the legal system to stifle competition and further their monopoly. If so, have they not heard of Sega v. Accolade ?
I'm a bit amused that they're using SHA-1. Why not MD5, CRC32, or (as the dumb security scanners would recommend) even SHA256?