botcheckme

What we assume, and which assumptions we doubt

Every rank on this site is surprisal against one of the assumptions below. Real counts from other browsers appear beside a row, never inside its rank. This is the whole comparison object, and it is open to being wrong.

Every competing page of this kind computes a score against something it will not show you. Usually the implication is a population, “rarer than 99% of users”, and usually nobody running a page like this has a representative sample of the web's browsers.

This site does not have one either. It has a real but small population, the devices these eight sites have read, and those visitors are people who came to a page about fingerprints, not the web. So the rank uses a written table of assumptions about how common each value is. Every one is below, with its number, the reasoning, and a mark where the author believes it is probably wrong. 4 of the 15 are marked.

When the assumption is wrong, the ranking on your reading is wrong in a way you can point at and argue with. That is the entire difference between this page and a score.

How an assumption becomes a place in your ranking

Each entry below is a probability: how often this site guesses a condition is present in an ordinary browser. Surprisal is −log₂ of that number, so a condition assumed at one in a hundred carries about 6.6 bits and one assumed at one in four carries 2. Bits are then multiplied by the published challenge weight for that signal, and the product is the only arithmetic on this site. It orders your rows and does nothing else.

Two consequences are worth holding on to while you read the table. A rarer assumption produces more bits, so lowering a number here pushes its row up everyone's ranking — which is why a number chosen too low is not a small error. And a heavily weighted signal with an ordinary value still ranks below a lightly weighted one with a strange value, because the two factors multiply rather than add.

Where these numbers came from

Published vendor documentation, the observable behaviour of the challenges themselves, browser release notes, and the author's judgment where none of those three said anything. That is the complete list of sources, and the third item is doing more work than anybody would like.

What did not contribute: any count of visitors to these sites, or any sample bought or scraped from anywhere. The counts these sites now keep are shown on the rows, labelled as counts, and kept out of the rank: the people who visit a page like this are not the web, and mixing their share into the rank would present one group of sites' traffic as a fact about everyone.

So the honest framing is that this is a set of stated beliefs with reasons attached, dated, and open to being corrected by anybody who can show a better number. If you have one, the changelog is where the correction lands, with a date on it.

Ordered from the least likely to the most. p is the assumed probability of the condition being present in an ordinary browser; bits is −log₂ of it, which is what the ranking multiplies. A rarer assumption produces more bits, and a wrong assumption produces a wrong row.

  • Input events on the page were made by script

    p 0.0050 7.64 bits

    People do not usually run auto-clickers or macro tools on a page like this one. Assumed very low, which makes the row rank high when it does fire.

  • Request headers name a different browser, platform or language than the page reads

    p 0.0100 6.64 bits

    An untouched browser builds its headers and its page values from the same settings, so they agree. Assumed rare because only a rewriting extension, a proxy or a script separates them.

  • The browser is drawing with a software renderer

    p 0.0200 5.64 bits

    Taken unchanged from the shared rubric's GPU prior, which assumes SwiftShader and llvmpipe at p=0.02 against any other specific renderer string at p=0.0025.

  • A resist-fingerprinting tell is present

    p 0.0300 5.06 bits

    A time zone forced to UTC, a rounded screen, a pixel ratio pinned to 1 and a core count clamped to 2 are individually plausible and jointly rare. The prior is for any one of them appearing.

  • A current browser arrives over HTTP/1.1 or below TLS 1.3

    p 0.0300 5.06 bits

    Antivirus HTTPS scanning and company gateways are the common ordinary causes. Assumed from how widely those are deployed, not counted.

  • The exit address belongs to a university, school or government network

    p 0.0400 4.64 bits

    Campus and public-sector networks put thousands of people behind a few addresses. Assumed from how such networks are built, not counted.

  • The exit address belongs to a hosting or VPN network

    p 0.0500 4.32 bits

    A minority of ordinary traffic exits through a data centre. Assumed from the share of consumer VPN use, not counted.

  • Exit country differs from the browser's time-zone country

    p 0.0600 4.06 bits

    Most people browse from the country their clock is set to. This covers VPN users, corporate egress through another region, travellers who have not changed their system time zone, and satellite or carrier routing.

  • The exit address is carrier-grade NAT

    p 0.0900 3.47 bits

    Mobile networks and a growing share of fixed-line ISPs place many subscribers behind one public address. Assumed from published address-exhaustion practice, not counted.

    We think this one is probably wrong
    Almost certainly wrong outside North America and Western Europe, where CGNAT is far more common than this number.

  • Global Privacy Control or Do Not Track is on

    p 0.1200 3.06 bits

    Both are opt-in and both are switched on by some browsers' strict modes by default. Assumed from the share of browsers shipping a strict mode, not from a count.

  • The browser build is more than four releases behind

    p 0.1400 2.84 bits

    Managed machines, delayed enterprise channels and Linux distribution packaging all hold browsers back. Assumed from update-channel practice.

    We think this one is probably wrong
    The four-release threshold is arbitrary. It was picked because it is roughly a quarter of a year on Chromium's cadence, which is a reason but not evidence.

  • A full read of the browser took longer than 20 seconds

    p 0.1500 2.74 bits

    Wall-clock time for this page's own collector, which is a heavier job than any challenge runs. Assumed from the spread of ordinary consumer hardware.

    We think this one is probably wrong
    This one is measurable and should stop being an assumption. The readings these sites now store will make it countable once there are enough of them.

  • An extension injected nodes into the document root

    p 0.2200 2.18 bits

    Password managers, coupon injectors, translation overlays and dark-mode restylers all mutate the document root before the page's own script runs. Assumed lower than blocker installation because many blockers do not inject at the root at all.

  • A content blocker is installed

    p 0.3400 1.56 bits

    Blocker installation is widely reported at roughly a third of desktop browsers in Western markets. Rounded hard, because the reported figures disagree with each other by more than the precision anyone quotes them to.

    We think this one is probably wrong
    This is the assumption most likely to be wrong for this site's actual visitors. Somebody arriving here has already been challenged repeatedly, which correlates with having a blocker — the population reading this page is not the population the prior describes.

  • Third-party storage is refused

    p 0.4500 1.15 bits

    Safari and Firefox block third-party cookies by default and Chrome's own controls are widely used, so a refusal is closer to normal than not. The weight, not the prior, is what makes this row matter.

The browser-build row needs a second kind of assumption: what “current” means on the day you read this. These are the numbers it uses, assumed as of 2026-10-13. They go stale by design, and a stale one makes that row fire on a browser that is perfectly up to date.

Chromium — Chrome, Edge, Opera, Brave
156
Firefox
157
Safari
26
Releases behind before the row fires Roughly a quarter of a year on Chromium's cadence. That is a reason, not evidence.
4

Some rows — the graphics renderer, the installed font set — take their prior unchanged from the uniqueness rubric shared across this portfolio, rather than declaring their own. That rubric carries its own provenance statement, and it is reproduced here verbatim rather than summarised:

Bits are surprisal against this rubric's published prior assumptions, not against a measured population. No sample backs these numbers yet.

Rubric edition 1.0.0, basis “prior-assumption”, measured: false. Correlation model: grouped: strongest member at full weight, others at 35%.

When a real corpus is large enough to publish frequencies, that rubric's edition increments, the priors are replaced with measured values, each gains a sample count, and the changelog says so. Until then, no page built on it may use the word “measured”, and none of them do.

The other half of the arithmetic — how much a challenge is judged to act on each signal — is published separately. The weight table, and what this site deliberately does not measure →

What people ask about a rank built on assumptions

How can this site rank my settings without measuring anyone?
By comparing each value you have against a written assumption about how common it is, and multiplying the result by a written judgment about how hard a challenge acts on it. Both numbers are on this site, both are dated, and both can be argued with. That is a weaker foundation than a measured sample and it is stated as such; what it is not is a hidden one. These sites do count real browsers now, and a row shows that count beside its rank.
Does this site tell me how rare my browser is?
For some values, as a plain count: how many of the devices these eight sites have read share yours. It does not turn that into “rarer than 99% of users”, because the browsers that visit sites like these are not the web, and a percentage would claim they are.
What happens if one of these assumptions is wrong?
Your reading is wrong on the rows that depend on it, in a direction you can point at. A prior that is too low makes an ordinary value look surprising and pushes its row up the ranking; one that is too high buries a row that should have been near the top. That is the practical difference between this and a score: a wrong number here is locatable, and several are already marked as suspected wrong.
Why are some of these assumptions marked as probably wrong?
Because they were doubted at the moment they shipped rather than discovered later, and recording that is more useful than quietly hoping. Each doubt says what is suspected and why. A methodology that only publishes the numbers its author is confident about is publishing a subset chosen for how good it looks.
When will these become real measurements?
When the counted population is large and broad enough to publish frequencies from honestly. At that point an edition replaces a judgment with a count, the changelog records it with a date, and the word assumed comes off that row. Until then the counts are shown beside the rank, labelled as counts.

The rows you cannot fix from a settings page

A VPN you need for work, an address your ISP shares with a thousand other subscribers, a laptop with no graphics chip, a hardened profile that breaks the sites it was meant to protect — none of these have a checkbox. What is left is to present a reading that is internally consistent and ordinary on purpose, instead of one that is accidentally strange.

Donut Browser does that at the engine level: its Wayfern Chromium fork applies the fingerprint through CDP injection rather than patching JavaScript in the page, and it refuses to launch a profile whose proxy exit country, time zone and language contradict the profile's own fingerprint — which is the top row of most readings on this site. It is AGPL-3.0, it has no telemetry of any kind, and it runs on macOS, Windows and Linux.

Stated plainly: this site has no test results showing what any particular anti-bot service does with any particular browser, and neither does Donut Browser's own repository. What can be checked is the source, which is public.

Download Donut Browser

Free · AGPL-3.0 · github.com/zhom/donutbrowser