Skip to content
All fingerprint checksEngine & OS oracles

the number of font families the page can detect is reported for comparison

Check id font-family-count-vs-claimed-os

What an ordinary browser yields

No expected value, by construction. The count is reported so it can be compared against a machine you trust — on the reference Windows host, stock Chrome resolves 71 of the 240 probed families.

What a detector infers

The two font rows beside this one ask whether the font layer CONTRADICTS the operating system being claimed. This one asks a blunter question that neither reaches: whether the detectable font set is the right SIZE. It matters because an anti-detect build that ships a fixed canonical font list makes two mistakes at once, and both are properties of the list rather than of any font in it. The list is short — an ordinary desktop carries several hundred families and a hand-curated list carries tens — and it is identical on every installation of that build, so the same short set arrives from every machine running it. Rare and shared at the same time is the worst position available to something meant to blend in: unusual enough to notice, consistent enough to name. Measured on one Windows host with the 240-family pool this row probes, three browsers on the same machine: stock Chrome 150 resolved 71 families; Clearcote PRO 150 r11, which shipped a fixed 63-entry canonical list, resolved 54; Clearcote PRO 150 r12, whose list was rebuilt from a corpus of three thousand real machines and then intersected with what the host can actually draw, resolved 65. The same measurement moved a second signal with it — the layout of U+2581, which is supplied by MS PGothic on a real Windows machine and fell through to another face while MS PGothic was missing from the shorter list — so the glyph geometry vector went from differing against stock to matching it exactly. That is the shape of the problem: a list short enough to be distinctive also changes what a page measures, without anyone asking about fonts at all. The row is nonetheless INFORMATIONAL and is never scored, and the reason is the whole design. There is no count that separates a truncated persona from a browser that restricts font enumeration on purpose. Brave and the Tor Browser both answer from a bounded standard set as an anti-fingerprinting defence and land in the same range a trimmed persona lands in, so a floor low enough to spare them catches nothing and a floor high enough to catch a persona convicts them for a privacy feature working correctly. Publishing a per-OS threshold would therefore both rot and mislabel. The number and the notable absences are reported instead, with a measured reference alongside them, and the judgement is left to a reader who knows which machine they are comparing against. Two states are declined outright because the number means nothing in them: a browser answering font queries synthetically, caught by probing a family nobody has, and a browser flattening every metric onto a generic, caught when nothing at all resolves.

How to resolve it

A count well below what the same operating system's stock browser reports means the browser is answering from a shorter list than the machine actually has. That is either a deliberate enumeration defence, in which case nothing is wrong, or an anti-detect build shipping a fixed canonical list, in which case the list is probably identical on every installation of that build and is doing the opposite of what it was added for. If you control the build, derive the list from real machines and intersect it with what the host can actually render, so no family is advertised that cannot be drawn; a family that is listed but absent is substituted on the cross-OS path and measures as present, which is the over-claim the mechanism exists to prevent. If you control only the host, install a realistic font set — a minimal container image ships four font packages and no persona can conjure the rest.

What is font fingerprinting?

Read in the wild by

FingerprintJS

Its open-source agent measures a fixed candidate list against the three generic base fonts and keeps the resulting presence vector as an identifier component. The size and membership of that vector is exactly what this row reports: a browser answering from a short fixed list produces a presence vector that is both low-entropy for the machine and identical across every installation of that build, which is a stable identifier for the build rather than a disguise for the machine.

src/sources/fonts.ts: a fixed font list measured span-by-span against monospace, sans-serif and serif base fonts, presence recorded when the rendered size differs from the base.

FingerprintJS (open-source agent)

CloakBrowser (measured)

Recorded because it shows the discipline this row is describing, from a competing product rather than from us. Across runs on two hosts its detectable font set varied where the host allowed it and stopped varying where it did not — on a workstation with 139 families available it offered both a lean and a near-native profile, and on a host with 65 available it produced one profile every time. It never advertised more than the host could draw. Bounding persona diversity by host capability, rather than picking freely, is the correct failure mode.

Workstation (139 families installed): 57 / 57 / 130 families reported across three launches. GPU-less RDP host (65 installed): 58 families on all five launches, no rotation.

CloakHQ/CloakBrowser

Clearcote (measured)

The measurement that motivated the row, taken on our own build and reported against us. A fixed 63-entry canonical Windows list resolved 54 of the 240 probed families where stock Chrome on the same machine resolved 71, and because the list was the same on every installation the shortfall was shared by every machine running that build. Rebuilding the list from three thousand real machines, bounded by what the host can draw, moved it to 65 and brought the glyph geometry vector into exact agreement with stock Chrome on the same host.

One Windows host, same 240-family pool: stock Chrome 150 = 71 resolved, glyph vector hash 7ed1170e. Clearcote PRO 150 r11 = 54 resolved, 9b8e7a8d, U+2581 laid out 64x74. Clearcote PRO 150 r12 = 65 resolved, 7ed1170e, U+2581 laid out 43x74 — identical to stock.

clearcote release r12

Every attribution traces to a published artifact. See the sources and their limits.

Other checks in Engine & OS oracles

Who builds this test

Clearcote is a browser built for fingerprint coherence

It is a Chromium fork, maintained by the same people who wrote this reference. It ships as a compiled browser rather than as a stealth script injected into someone else's — which is a description of how it is built, and is not an argument about how it behaves on this check.

This audit takes no position on how Clearcote scores on Engine & OS oracles checks, on this one, or anywhere else. It has no baseline corpus of other people's fingerprints to rank you against and no vendor scoreboard — nearly every check is self-referential, asking one browser the same question through two independent APIs and reporting whether both answers can be true at once. It runs identically on any browser, including ours. Run it on yours and read the result yourself.

See the other checks in Engine & OS oracles — the family font-family-count-vs-claimed-os belongs to.