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.
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.
This is what I don't get. Anybody scraping at scale is using headful browsers as fallback, this does nothing. I will just find the browser that works, and use it.
Let's ignore for the moment that this has been reverse engineered.
If they only look at this header, then legitimate users using non-chrome browsers will get treated as bots.
If the these headers are only used for chrome user agents, then it would be easy to bypass by using headless chromium with a user agent that spoofs firefox or safari.
> This is a very useful signal for fraud and abuse prevention.
Like people spoofing the Chrome UA in Firefox to avoid artificial performance degradation inflicted by Google on their websites...
I spoof User Agent, TLS/browser fingerprinting all day. These are the basics. None of this bothers me tbh, I'm constantly running tests on lots of versions chrome, firefox and brave and haven't really seen any impact in bot detection. I do a lot of browser emulation of other browsers in Chrome. PermiterX/Human seems to be the only WAF that is really good about catching this.
> 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.