How we measure, and where we fail
No accuracy percentage until we have labelled pilot data. Run Observe mode next to your current tool and compare.
Below: what we ran, the links / does not link table, and the FAIL list.
How we measured
We run a browser zoo against the public demo site on production: real browsers and automation tools submit the signup form, and we record the score, verdict and reason ids each one gets. Scores run 0 to 100; higher is more likely automated.
| Browser or tool | Verdict | Score | Reasons |
|---|---|---|---|
| Regular Chrome, typed by a person | human | 0 | None |
| Regular Chrome, instant autofill | human | 15 | instant_submit |
| Puppeteer with stealth plugin | suspicious | 65 | worker_mismatch 50, instant_submit 15 |
| nodriver | human | 35 | instant_submit 15, pow_too_fast 20 |
| Patchright, undetected-chromedriver | human | 15 | instant_submit |
Production run of 21 October 2026. The last two rows are misses: these tools pass as human on score alone. Repeat signups from them can still get limit through account links.
For repeat accounts we run a second zoo: one person signs up on the demo, changes one thing, and signs up again. A scenario passes only if the second signup links to the first signup of the same run. The first red team (real Chrome driven over CDP, 16 signups) set the baseline below; later rounds added the rows after it.
Links / does not link
| What the person changes before signing up again | Result |
|---|---|
| Clears cookies and site storage | Links |
| Opens an incognito window | Links |
| Creates a new browser profile | Links |
| Spoofs the user agent | Links |
| Uses a Gmail alias (dots, plus tag) or a plus tag at Outlook, iCloud, Fastmail or Proton | Links |
| Changes time zone and language | Links |
| Two fresh Brave sessions, or two fresh Firefox profiles, same network | Links, on a network with fewer than 50 accounts a week |
| Antidetect Chrome profiles, same network | Links, on a network with fewer than 50 accounts a week |
| Same home switching between IPv4 and IPv6 | Links, on a network with fewer than 50 accounts a week |
| Switches from Chrome to Brave or another browser | Does not link by device |
| New browser, new network and new email together | Does not link |
Uses data-storage="none" on your site | Weaker: no stored visitor id, links rely on device and email |
The "fewer than 50 accounts a week" rows: a network where 50 or more different visitors with accounts sign up in 7 days is treated as shared (office, mobile carrier), and the low-detail device keys are switched off there to avoid linking strangers. Our own test network crossed that line after many zoo runs, so those three rows failed in our latest production run and pass in unit tests.
FAIL list
- FAIL: residential-proxy farms. A farm that gives each signup a fresh residential IP and a fresh browser has no shared network or device to link. We have no proxy data yet.
- FAIL: a fresh device, browser and email. A fresh device, browser and email can evade these links.
- FAIL: antidetect browsers with per-session randomisation, across networks. They change canvas, core count and memory every session. We link them through a low-detail key that only holds within one network and one UTC day. On another network or the next day, they do not link.
- FAIL: some stealth automation scores as human. nodriver, Patchright and undetected-chromedriver, see the zoo table.
- FAIL: farms of 50 or more accounts a week from one network switch off the low-detail keys on that network, as above.
- False links: offices with identical laptops. Same model, same /24 network: the fifth colleague can get
limit. Use alegitlabel or an appeal. - Not covered: mobile apps. Browsers only.
What still works against these: a ceiling on credits per linked cluster, held credits released only after a later check, and email checks. None of them is proof.
Measure it on your traffic
No accuracy percentage until we have labelled pilot data. Run Observe mode next to your current tool and compare. Observe records wouldDecide for every signup and enforces nothing. Label the accounts you know with POST /v1/feedback, then compare wouldDecide with your labels and with what your current tool said.