Even if you've struggled to understand the inner workings of anti-bot protections in the past, this tool changes that. I used to get overwhelmed trying to understand what each website does to distinguish human traffic from non-human traffic. Every time, I'd try to understand and deobfuscate the JavaScript, monitor the traffic, and pinpoint the small changes in the responses whenever I tweaked the environment or the browser configuration.
Finally, we built a solution, and it's called Fingerprint Inspector:
I've wanted this for a while: a real way for users to see exactly what a website is doing to fingerprint them. However, I had no idea what would be the right architecture for it. Then I read a post by a researcher named Veritas about forking Chromium into his own reverse-engineering browser, patching hooks directly into Blink instead of monkey-patching JavaScript from an extension. That post showed me exactly what I'd been missing. And this is how Fingerprint Inspector came to life.
See What the Site Sees
In Kameleo 5.1, Fingerprint Inspector is available as a launch option in the profile context menu for Chroma profiles. Once running, it streams a live, DevTools-style panel showing exactly which fingerprinting calls a page makes against your profile: canvas, WebGL, and WebGPU reads, audio context probes, navigator properties, media device enumeration, WebRTC, and so on.
How It's Made
Our engineering team evaluated JShelter, FPMON, OpenWPM, and similar tools while researching how sites fingerprint browsers in the first place. Each one ran into its own limits: research-grade tooling built for one-off analysis, platform gaps (OpenWPM doesn't run natively on Windows), or, in FPMON's case, a repo with no updates in five years, still stuck on a deprecated Manifest V2. Fingerprint Inspector exists because none of those fit a production workflow, and because Kameleo already controls both the masking layer and the profile the inspector runs in, letting you verify your specific configuration in the same session you're about to deploy.
The interesting part is how we capture those calls compared to the other tools. JShelter, FP-Inspector, and FPMON all work by monkey-patching JavaScript prototypes from a browser extension: stash the original function, wrap it, log the call, hand back the original result. That's detectable, and detection has a cost: a site checking Function.prototype.toString() or walking the prototype chain for signs of tampering can spot the pattern, and once it does, it's free to skip the fingerprinting calls you're trying to watch, so what you observe stops matching what a real visitor would trigger. Some of these tools also block calls outright instead of only logging them, which changes site behavior on its own, the observational equivalent of a cop car with its lights on, hardly undercover. Fingerprint Inspector skips that layer entirely. It patches hooks directly into Chromium's Blink layer through a C++ instrumentation agent, so the page-visible API surface never changes: nothing to detect, nothing to react to.
What's Next
Fingerprint Inspector ships for Chroma first, with Junglefox next in line. Beyond browser coverage, we're already working on usability improvements on top of it, the kind that make the tool nicer to live with day to day. Who knows, one day we might add MCP support so you can use your AI to reverse-engineer anti-bot scripts 50 times faster than you can today... Ask me again once it ships.
