Most fraud checks are amnesiac. They look at one response, decide, and forget. That is a comfortable design for the person filling in forty surveys a day, because every survey is a fresh start and nothing they did yesterday counts against them.
Cipher keeps a memory. Not of people, of devices and the behavior attached to them. This post explains how that memory is built, what it is allowed to do to a score, how long it lasts, and where we deliberately made it weaker than we could have.
If you are here because you were thinking of running a few dozen throwaway responses through a study, read the section on how long an incident lasts. It is the most useful part of the post for you.
Every response arrives with a set of browser characteristics: what the rendering stack produces, what the screen and hardware report, what fonts are installed, what timezone and language are set. None of that is identifying on its own. Together, it is stable enough to tell whether this is the same machine that answered a survey last month.
Resolution is a ladder, tried in order, and the first rung that answers wins. An anchor from a previous visit is strongest, but only if the device still looks like the device that anchor was issued to. That last condition is what makes a client-held identifier safe to trust at all: an anchor that turns up on a machine which looks nothing like the original is treated as evidence of sharing or theft, not as recognition.
What survives the request is deliberately thin. Lookup happens through a blind index, which is a keyed hash: it can answer "have I seen this before" and nothing else. Everything else is sealed with a key that lives outside the database entirely, in a different trust boundary, so a stolen copy of the table is inert. There is no raw fingerprint on disk, no address in the clear, no readable IP, and no name anywhere in the graph. An identity is a pseudonym with a history attached.
There is also a deliberate hole in the net. A device that keeps resolving to different humans is a library machine, a family laptop or a kiosk, and past a small number of distinct people it stops contributing links entirely. Without that rule, one computer lab collapses into a single identity and every student in it inherits the worst behavior in the room.
People who try to defeat fingerprinting usually change the two things that are easy to change: the user agent string and the language. Here is where our matcher's weight actually sits.
Three caveats on that chart, because it would be easy to read more into it than it says.
These are our weights, not a measurement. They are set by hand in our matcher. They are not entropy, and there is no canonical table in the literature that this could be compared against. What the literature measures is bits of entropy per attribute on a specific population, which is a different quantity entirely.
The shares do not add up to identifying power. Entropy does not sum across correlated attributes, and these attributes are heavily correlated: the canvas hash, the WebGL renderer string, the device pixel ratio and font rasterisation all fall out of the same GPU, driver, operating system and font stack. Once you know the WebGL renderer, the canvas hash tells you much less than its share suggests. Any chart of this kind, ours included, is a picture of how a matcher is tuned rather than a partition of how identifiable someone is.
Where our weights disagree with the published work, the published work is worth more than our intuition. Eckersley's 2010 Panopticlick study put installed fonts among the top three attributes at 13.9 bits, behind plugins at 15.4, with the user agent at 10, against a total of at least 18.1 bits. Our matcher gives fonts 8.8% and puts the rendering stack well ahead of it. That gap is our tuning, not a finding, and it is on the list to revisit against our own data.
The user agent is the one place where the old measurements have genuinely aged. Chrome began reducing the entropy in the UA string in 2022 and phased the reduction in over the following releases, so it carries meaningfully less than it did when those studies were run. That is why we weight it low. It is not because the literature says it never mattered.
One more number is worth stating, because it cuts against us. The famous uniqueness figures come from self-selecting samples: people who visit a site that offers to tell them how unique their browser is are not typical, and Panopticlick's 83.6% unique reflects that. When Gómez-Boix and colleagues repeated the exercise in 2018 on more than two million fingerprints from a mainstream French site, only 33.6% were unique overall, and just 18.5% of the mobile ones. Fingerprinting works far less well on a real population than the headline numbers imply, and it works least well on phones. That is a limit on what recognition can do for us, and it is the same limit that shows up as the missed mobile archetype in our engine post.
Every scored response folds into two decaying quantities: a mass of good evidence and a mass of bad. Both decay with a half-life of about three months, which means a reputation is a rolling window rather than a permanent record. Severity is superlinear, so one seriously bad response counts for considerably more than two mildly bad ones. That is intentional. Two slightly rushed responses are a person having a bad afternoon; one straight-lined submission with a filled honeypot is a decision.
A separate quantity tracks the most recent incident and decays much faster, on a three-week half-life. It does not lower the score directly, it puts a ceiling on it. So a respondent with a long clean history who does something bad does not get quietly downgraded, they get capped, and the cap lifts as the incident ages.
A clean streak works in the other direction, raising a floor under the score, so a long run of good responses buys real protection against a single bad day.
Here is the same respondent, twenty responses of history, after exactly one incident.
A severe incident takes trust from the low eighties to 46 immediately. Twenty days later it is back around 72, and by day 40 the ceiling has lifted almost entirely. A minor incident is barely visible after a week.
That is the answer for the person doing arithmetic about throwaway responses: the penalty is real, it is proportional, and it is measured in weeks rather than in permanent bans. We chose that shape because a permanent ban on a fingerprint punishes the next person who buys the laptop.
But note what the chart does not show. Underneath the decaying score sits a set of counters that never decay and are never touched by recovery: how many responses this identity has submitted in its lifetime, how many were flagged, how many were blocked, what the worst incident was and when. Those counters stay out of the trust formula and out of the prior on purpose, so they can never quietly re-punish someone whose score has healed. They exist for a human reviewer looking at a repeat pattern. You can earn your score back. The record of what happened stays on file.
This is the part of the design we are most careful about, because reputation systems fail in a specific and well-documented way: a low score raises the prior, the raised prior produces a higher fraud score, and the higher score lowers the reputation again. Left alone that loop manufactures guilt.
Three things stop it here.
First, the structural one. The score that feeds reputation is computed with a fixed base rate that ignores who submitted it. Cipher scores the response twice for exactly this reason: once identity-blind, which is what reputation is allowed to read, and once with the prior the identity implies, which is what the verdict uses. Reputation can never influence its own input.
Second, the prior shift is bounded.
However bad a history is, the prior lands inside a hard clamp, and a separate cap limits how far any single decision can move regardless. A terrible reputation does not convict anyone. It moves the starting point a little, and the evidence in the response still has to do the work.
Third, history only counts once there is history.
The confidence term scales the entire effect and starts at zero, so a first-time respondent is scored exactly as they are today: on this response alone. It takes about five responses before their history carries half its eventual weight. There is no way for a new respondent to arrive already suspicious.
There is a respondent every fraud system gets wrong, and it is not the fraudster.
They are fast because they read quickly. They type cleanly because they compose the answer in their head before they start, so there are almost no corrections. They keep notes and paste from them. They are on a VPN because their employer requires one. They answer consistently across a study because they are paying attention, which makes their answers less varied than a distracted person's.
Read one response in isolation and that profile trips nearly every heuristic we have: rapid completion, no corrections, heavy pasting, network flag, low answer entropy. A system with no memory has no way to tell that person apart from someone racing through for the money, because within a single response they genuinely look the same. This is the single largest source of false positives in survey fraud detection, and it lands hardest on the most capable respondents in your sample. You end up throwing away your best data.
History is what separates them, and it is the only thing that does. The careful respondent has twenty prior responses, passed every honeypot, was never contradicted across studies, and has a clean streak long enough to raise a floor under their score. The prior chart above is the mechanism: at the top of the trust range with real history behind it, the starting suspicion is roughly half the base rate a stranger gets. The same fast, clean, pasted response that reads as suspicious from a stranger reads as ordinary from them, because it is ordinary for them.
Two honest caveats. This only works once there is history, so the brilliant first-timer is still judged on the response alone, and that is a gap we have not closed. And the effect is bounded on purpose: a good reputation moves the starting point, it does not grant immunity, because a compromised or sold account with a clean history is a real attack. The bound that stops reputation from convicting anyone is the same bound that stops it from exonerating anyone.
Not the score. A creator sees one of four coarse bands, and never the number behind it, never the history, and never anything about what happened in another customer's survey.
That restraint is not decoration. A trust score is reverse-engineerable into a history, and a history in one customer's hands is a fact about a person that they gave to somebody else entirely. A creator seeing a caution band learns "be careful with this response". They do not learn that this respondent was flagged at another company on a particular date, and they never will.
The short version: this is lawful processing on a recognised basis, and what is unfinished is paperwork rather than protection.
The basis is legitimate interests under Article 6(1)(f). Recital 47 names fraud prevention directly as a legitimate interest, and for this particular processing the controller is us rather than our customer, which we state rather than bury. A data protection impact assessment and a legitimate interests assessment are both written, because monitoring behavior at this scale is exactly what those documents exist for. What is left on them is legal sign-off and the contract language that goes with it, which is a real reason to wait but not a gap in how the system behaves.
The protections are in the code rather than in the document. Lookup runs through a keyed hash that can only answer "seen before". Everything else is sealed with keys held outside the database. Nothing is kept indefinitely: fingerprint drift for 12 months, a device for 400 days after it was last seen, events and access logs for 24 months, enforced by a nightly job. Erasure destroys the identifiers including the blind indexes, so re-linking is severed rather than hidden, and because the basis is legitimate interests rather than consent you can object outright.
One question is genuinely open, so we will say it plainly. Cipher recommends and a human decides, which is what keeps this away from the automated decision-making rules in Article 22, but how a customer treats a flag is not entirely in our control, and our assessment records that as under review. That, and the sign-off, is why the subsystem is still in shadow mode.
The graph is built, and every response updates it. The reputation is computed. But the subsystem ships in shadow mode by default, which means it records what it would have done and moves no score. Turning that off is a deliberate act gated on three things: a data protection impact assessment, a legitimate interest assessment, and a public privacy policy that describes cross-survey recognition in plain language. A reasonable-expectations argument that depends on people being able to read what we do is worth nothing if they cannot read it. This post is part of paying that down.
Erasure works the way you would expect. An identity can be dissolved on request, which unlinks the graph and destroys the sealed material, leaving nothing to re-link it later.
If you fill in surveys for money and you do it honestly, none of this touches you. A clean history is worth real points, and the floor a clean streak buys you is the difference between one bad afternoon costing you a submission and costing you nothing.
If you were planning to run the same study twenty times behind a VPN and a fresh browser profile: the VPN is one signal of many and a weak one, the fresh profile keeps the rendering stack you already had, and the memory is per device rather than per session.
There is a sharper version of that, and it is the one worth understanding. Spoofing part of your fingerprint can leave you easier to spot than changing nothing at all. A user agent claiming one machine while the GPU underneath reports another is not a missing signal, it is a contradiction, and a contradiction is high-value evidence. Our matcher has a named check for exactly that case, which fires when a device presents an identifier that its own hardware disagrees with. Half-hearted spoofing is worse than none.
We would rather tell you that now than catch you later. Detection that nobody knows about is a trap. Detection that is published is a deterrent, and a deterrent is cheaper for everyone, including us.
