HN user
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?
Plenty of improvements to mouse movement algorithms have already been made and they’re still evolving. While the blog post and the product it introduces offer some interesting ideas, they don’t yet reach the robustness of modern anti-bot solutions and still trail current industry standards. I doubt it would take me - or any average reverse engineer - more than five seconds to bypass something like this. There are already numerous open source mouse movement libraries available; and even if they didn’t exist, writing one wouldn’t be difficult. Yes, mouse movement or keyboard data can be quite powerful in a modern anti-bot stack and an in depth analysis of it is genuinely valuable, but on its own it’s still insufficient. Relying on this data alone isn’t costly for the attacker and offers little real protection.
You can look at my previous answer:
To clarify, If I disclose the exploit publicly, my concern is that the company could take legal action against me, even if I don’t share any technical details or information that would allow someone to reproduce it. – Something I really don't want to deal with.
To clarify, If I disclose the exploit publicly, my concern is that the company could take legal action against me, even if I don’t share any technical details or information that would allow someone to reproduce it. – Something I really don't want to deal with.
In its current state, the protections are pretty weak. I’m sure they’ll update it, and we’ll see what changes they bring. If this header is meant to serve as an anti-bot measure, then there’s a lot more work they need to do both on the JS and WASM sides. On top of that, processing fingerprint data on the backend, like building user/fingerprint profiles, analyzing detailed browser, device and low level connection info, and using AI to spot patterns, makes the system a lot more complex. However, based on the current implementation, I anticipate they’ll likely stick to a relatively simplistic approach.
You’re right. In this case, just knowing the guest_id is enough to break down the header. Twitter’s main goal here is mostly to obfuscate the data and make the reverse engineering process more painful.