Detection run, October 2026: seven public fingerprint checkers

This is the third run in the series. It covers seven public checkers a user asked us to run, side by side, and one of them flagged us as a bot. It no longer does, and stock Google Chrome still does. Below is why.

Conditions

A new temporary profile for every single check, thrown away after it. Default settings, nothing tuned. Engine runtime Chrome 155, the build released on 2026-10-28. Two hosts, each running the whole set: a macOS machine with a macOS persona, and a Windows 11 machine with a Windows persona on its own hardware. Headful on both.

Every check went out through its own US consumer residential exit, used once. Playwright was attached over the DevTools protocol for the whole page load, as in September.

One thing differs from the earlier runs. August and September presented Windows on a macOS host. This run presents macOS on macOS and Windows on Windows. That is the setup we recommend: some signals belong to the machine underneath, and a persona that matches the host has nothing to contradict.

Results

Checker	What it reports	macOS	Windows
deviceandbrowserinfo.com/are_you_a_bot	"You are human!"	3 of 3	3 of 3
demo.fingerprint.com/playground	bot not detected; developer tools, tampering, anti-detect browser, virtual machine all false	3 of 3	3 of 3
fingerprint.com/demo	a distinct visitor ID per profile, read as Chrome 155 on the persona's OS	3 of 3	3 of 3
browserscan.net	authenticity 100%, proxy No, bot No	5 of 6, one at 95%	3 of 3
pixelscan.net	consistent, no proxy, no masking, no automation	3 of 3	3 of 3
antcpt.com (reCAPTCHA v3)	score 0.9	3 of 3	3 of 3
browserleaks.com/quic	QUIC: False	inconclusive	inconclusive
networktest.twilio.com	"Authentication failed"	inconclusive	inconclusive

BrowserScan has six mac visits and three Windows ones: the three extra mac samples were taken after one mac visit was docked.

The bot flag that stock Chrome also gets

deviceandbrowserinfo.com scored the previous build as a bot on every visit made with Playwright attached. Only one signal was set: hasInconsistentTimingResolution. Before changing anything, we ran stock Google Chrome 156 through the same harness:

Browser	Nothing attached while the page loads	Playwright attached
Google Chrome 156	human, 3 of 3	bot, 3 of 3
AntiBrow, previous build	human, 3 of 3	bot, 3 of 3
AntiBrow, 2026-10-28 build, macOS	not re-run	human, 3 of 3
AntiBrow, 2026-10-28 build, Windows	not re-run	human, 3 of 3

So the flag was never about the fingerprint. It is about the debugger. Any tool that drives Chrome over the DevTools protocol (Playwright, Puppeteer, Selenium 4 and most agent frameworks) turns on the protocol's runtime domain for every page it controls. With that on, Chrome records far more detail every time a page constructs an error, and the extra work grows with how deep the call stack is.

The page measures exactly that. It throws and catches errors ten frames deep and two hundred frames deep and compares the two timings. In our own measurements the deep throw costs about 1.2 times the shallow one in an ordinary browser, and about 8 times with a driver attached. The page flags anything above 1.8.

The fix lives in the engine, not in a script, and it does not touch what the developer tools themselves show. Updating the engine is all it takes: existing profiles pick up the new build without any code change.

Worth knowing if you build on stock Chrome: switching off navigator.webdriver and the other usual tells does nothing about this one. The cost is real and the page measures it directly.

The one BrowserScan visit that lost five points

One BrowserScan visit in six scored 95%. It was docked for "anti-detect browser" on its canvas check. The other five scored 100% with the same settings on different exits. A one-in-six rate is not zero, so the row is in the table as a fail. All three Windows visits scored 100%, which is too few to say the rate differs by host.

Two checks that measure the network, not the browser

browserleaks QUIC reports whether the page reached it over HTTP/3. HTTP/3 runs over UDP, and no HTTP or SOCKS proxy carries UDP, so behind a proxy every Chrome falls back to HTTP/2 over TCP. Stock Chrome through the same kind of proxy reads False as well. A user who connects without a proxy will see True.

Twilio's network test stopped at "Authentication failed. Please try again later." before any connectivity test ran. It did the same on both hosts, and stock Chrome on the mac got the same error, so the failure is on Twilio's side. Recorded as inconclusive, not as a pass.

The proxy and VPN flags on Fingerprint

Fingerprint's Smart Signals set proxy: true on two of the three mac exits and all three Windows exits. That signal is about the address: it comes from IP intelligence, not from the browser. The same visits read developer tools, tampering, anti-detect browser and virtual machine as false. A residential exit that a reputation list already knows is a property of the proxy you buy, and no browser setting changes it.

On Windows it also set vpn: true on all three visits, and on none of the mac ones. The stated reasons varied: its ML model once, a time zone mismatch once, a time zone and OS mismatch once. In every case the browser reported the same time zone as the exit, and a separate probe on that machine had the page, an iframe and a worker agreeing on zone, offset and zone name. We have not found what that mismatch is measured against, so we are not calling it either way. It is in the dataset as reported.

What we did not measure

The commercial walls from September (Cloudflare, DataDome, PerimeterX). Not re-run this month.
Whoer and CreepJS. Not re-run this month.

Every row is in the dataset, the docked BrowserScan visit and the two inconclusive checks included, and the free tier is enough to repeat any of it.

Detection run, October 2026 - seven public checkers, and the bot flag stock Chrome gets too