How rarity is measured
The Count-Min Sketch — counting without remembering
When you run the audit, the page tells you how common or rare your browser setup is among everyone who has visited. That sounds like it needs a guest list: store each visitor's fingerprint, then count how many match yours. It doesn't — and deliberately so. This page explains the data structure that makes the rarity figure possible without ever keeping your fingerprint.
The problem: counting without remembering
Your "fingerprint" here is the combination of dozens of browser traits — screen size, fonts, a canvas-rendering hash, time zone, and so on — boiled down to a single 64-character SHA-256 number. The obvious way to measure rarity is a table: this fingerprint → seen 12 times. It works, but that table is a problem. A stable per-device number, stored row by row, is a pseudonym: it singles out a device across visits. Under EU data-protection law that is personal data, not anonymous data — exactly what this service is built to avoid.
So the goal is awkward: count how often a fingerprint occurs, while keeping no record of any fingerprint at all. A Count-Min Sketch does precisely that.
A grid of counters
The sketch is nothing but a fixed grid of plain integers — here 5 rows × 2,048 columns, so 10,240 counters in total. That size never changes: the millionth visitor adds no new row, because there are no rows-per-device to add. Each counter starts at zero. There is no list of fingerprints anywhere — just the grid.
Recording a fingerprint
To record a visit, the server takes your fingerprint hash and runs it through five independent hash functions — one per row. Each one points at a single column in its row. The server adds 1 to those five cells. That's the whole write: five +1s scattered across the grid.
Crucially, your fingerprint itself is thrown away the instant those five positions are computed. What remains is five slightly larger counters — counters that thousands of other, completely different fingerprints also land on. There is no cell that "belongs" to you.
Reading it back: take the minimum
To estimate how often a fingerprint has been seen, the server looks at the very same five cells and reports the smallest of them. Why the minimum? A counter can only ever be too high — other fingerprints may have bumped it too — never too low. So the smallest of your five cells is the one least polluted by collisions, and therefore closest to the truth.
For the estimate to be wrong, some other fingerprint would have to collide with yours in all five rows at once. Because every row hashes independently, that is astronomically unlikely — which is the whole trick: spreading the count across several independent rows lets the minimum cancel most of the collision noise, as long as the grid is wide enough that most cells stay lightly loaded (more on that just below).
Try it
Below is a miniature sketch — 5 rows, but only 16 columns so the whole thing is visible (and so collisions show up quickly). Type any text as a "fingerprint" and press Record to add it; the five counters it touches light up, and the filled one is the minimum — the estimate. Press Estimate to look a value up without recording it, and + random visitor to pile in background noise and watch what it does to the estimate.
Push the demo far enough and the estimate climbs well above the true count: with only 16 columns, a few dozen visitors fill every cell, so even the smallest of your five is no longer close. That is not the minimum failing — it is the grid being too small for the data. Accuracy depends on the load factor (records ÷ columns), shown beneath the grid. The real sketch has 2,048 columns, so for realistic traffic each cell stays lightly loaded and the minimum tracks the true count closely: usually exact, occasionally one or two high. You will never see it read lower than the truth — that asymmetry is the point.
Why it can't identify you
- It's lossy and shared. Every counter is the blurred sum of many fingerprints piled together. You cannot subtract them back apart into individual devices.
- It's one-way. The positions come from SHA-256. You cannot run a counter backwards to discover which fingerprint incremented it.
- It can't be fished. To ask "how common is fingerprint X?" you must already hold X's exact 64-character hash. There is no list to browse and no way to enumerate fingerprints you don't already have — and only your own browser ever computes your hash.
- It's bounded. 10,240 integers, forever. Nothing accumulates per person, so there is simply nowhere for a per-visitor record to live.
- It floors the rare tail. The slight overcount means a genuinely unique setup never reports "seen once", and a k-anonymity rule refuses to quote any count below five. The page can't confirm to anyone that they are one of a kind.
The trade-off
A sketch buys this privacy with a little accuracy: the estimate can read slightly high, never low. With 2,048 columns the expected inflation per row is only about e × N / 2048 ≈ 0.13% of all submissions, and taking the minimum over five rows trims even that. "Slightly too common" is the safe direction to be wrong in — it never falsely flags someone as unique. We trade a hair of precision for the guarantee that no fingerprint is ever stored.
A separate 24-hour deduplication filter stops the same browser inflating the totals on repeat visits within a day. It, too, stores only opaque bits — never a fingerprint and never your IP address.