fingerprint-scan.com draws its bot score badge before it has measured anything. On a page whose hash field still reads collecting… and whose signal line reads 0 visible signals across 0 categories, the badge already says Bot score 0/100. Read the score only once the page says the fingerprint was collected and shows a hash. Until then the 0 is a number about nothing.
We found this in a screenshot, not in a failure, which is the part worth writing down.
The screenshot that looked like a pass
Our detection suite runs a profile through every page in Mosaic's catalogue of public detectors and keeps one screenshot per test from each run. Reading old screenshots is the cheapest evidence we have, because it needs no browser launch, and it is how four rows moved from "no extractor yet" to a real verdict.
The fingerprint-scan.com shot looked fine at a glance: a large badge with a zero on it. Then the rest of the page: the fingerprint hash was still collecting…, and the scanner had found nothing in no categories. The scan had not finished. The badge is rendered from the first paint with its starting value, and its starting value is the best possible score.
An extractor that read the badge alone would have recorded a perfect pass from a page that had measured nothing.
Every profile is drawn from one real computer, not from separate listsIn Mosaic: Machines that exist. GPU, screen, CPU and fonts from one real device. Free holds 3 profiles. Pro is $49 a month for any number.
Mosaic is a desktop app
Email yourself the link and open it on your computer.
How it works: Machines that exist
Why the flattering failure is the dangerous one
The catalogue has one rule above the others: a test that did not run is never a pass. When a site serves nothing, the run records unreachable. When the page loads but the verdict we expect is not on it, the run records unread. Silence is not evidence.
Most broken extractors break loudly. Ours once counted the word "trustworthy" and the word "suspicious" anywhere in IPHey's page text, and IPHey's own captions contain both, so a profile the site scored 100/100 with five green checks went into our report as a failure. That cost two rounds of work hunting a regression that did not exist (what IPHey's number and its cards do mean is in IPHey's score moves on unmodified Chrome). But it was found, because a failure makes people look.
A false pass makes nobody look. The run is green, the report says the profile holds up on another detector, and the next person to read the row has no reason to doubt it. A badge that shows 0 before the scan is a trap set in exactly that direction.
What the extractor reads now
Our extractor for this page reads four things off the rendered text, and the score is only one of them:
- the badge,
Bot score N/100 - the signal line,
N visible signals across N categories - the completion message, "Fingerprint collected successfully"
- the
FINGERPRINT HASH, as at least eight hex characters
No score is read without the last two. If the badge is there and the hash is not, the row is unread, and the report says how many signals the page had found and what the badge claimed, so nobody mistakes it for a result.
The completion check had a bug of its own on the way. Its first version looked for the word "collecting" anywhere on the page and treated its absence as done. The page's prose uses that word too, so the row came back "still collecting" at 90 seconds against a scan that had finished. The fix was the same rule again: match the state the page renders, its own completion message and a hash that looks like a hash, never a word that might appear in a sentence.
The fingerprint-scan.com bot score a real Chrome gets
With the scan actually finished, a second assumption fell over. The first extractor called anything but a 0 a failure. We ran a stock Google Chrome and our own engine, Tesseract Chrome, on the same machine and let both finish:
Google Chrome bot risk 15/100 hash 7169526edc5907c3
our engine bot risk 15/100 hash 1169af435ae9acfe
Both 15. No browser we ran scored 0, so a threshold of zero would have filed a real Chrome as a bot and hidden the result that matters, which is that our engine scores what the browser it imitates scores. The bar is now what stock Chrome gets: 20 or under is a pass, 21 to 40 is worth a look, and above 40 is a fail.
Why it was slow enough to catch
The scan's speed is part of the story. We first gave the page 20 seconds, then 45, and it was still collecting. Through a residential proxy we measured zero signals after 105 seconds. The page has the slowest collector in the catalogue, and our runner had been reading every detector through a background tab, where Chrome skips animation frames and holds timers to about one call a second. Bringing the tab to the front before each navigation took this row from never ready in 140 seconds to ready in 8.2 (a detector that never answered because its tab was in the background has the whole hunt).
The wait is now a deadline rather than a fixed pause. The run leaves as soon as the completion message and the hash are both on the page, and waits the full 140 seconds only when the scan really has not finished. A slow scan costs time; it never turns into a score.
The same discipline applies to any detector you read by eye. A number on a results page is a claim about a measurement, and the page usually tells you somewhere whether the measurement happened. The whole catalogue, and the groups its 49 detectors fall into, is in how we read 49 detectors.
