Multi-accounting and duplicate account detection

Where it shows up

Referral bonus farming. Free trial cycling. Review manipulation. Marketplace seller rings that survive a ban by opening the next account. Airdrop farming. One paid seat serving a team of nine. Promotional abuse where the promotion was the whole marketing budget.

In every case the control you wanted was one per person, and the control you implemented was one per email, or per phone, or per card, or per fingerprint hash.

Why a fingerprint hash does not close it

A browser fingerprint is built from values the browser reports about itself: user agent, platform, screen, timezone, language list, core count, a canvas render, a WebGL render. All of them are JavaScript, and all of them are writable before your page loads.

An anti-detect browser sells exactly that as a product. The operator picks the operating system, the GPU string, the core count and the timezone per profile, and the tool injects noise into the canvas so the hash rotates. Forty profiles produce forty identifiers, and the household laptop shared by three people produces one.

You have built something that separates the accounts you needed linked and merges the people you needed apart.

Identity derived from measurement

Heretic derives two identifiers per session from things the page cannot rewrite: an instance identifier and a machine identifier. Both are scoped per site key, so they are not a cross-customer tracking token, and both are normalised for screen orientation, so a phone turning sideways is not a new device.

The inputs are measurements rather than claims. What the processor delivers under a fixed parallel workload. What the GPU produces, checked against the limits its own driver reports. The transport stack the kernel built. The construction of the TLS and HTTP handshakes.

Both tiers are marked conditional, and we would rather say that here than bury it. Browser measurements of compute and rendering are affected by scheduling, JIT warmup, thermal state and power management, and we control none of them. A matching machine identifier is strong evidence the same hardware came back. It is not proof, and we will not report it as proof. A rule is only as good as its premise.

For most signup decisions, strong evidence is what the decision needs. You are not convicting anyone. You are deciding whether this registration gets the referral bonus.

When you need more than evidence

A probe is a measurement. A challenge is an assertion. You mint one because you have already decided the measurement alone was not enough, and what comes back is us clearing a specific device.

The ceremony asks for a phone. Level, steady under load, turned sideways, then a passkey signing the readings. It ends passed, contradicted or not_completed with the step named.

The part that matters for this problem is the payload. The outcome names the device it ruled on: the request, the address, and the identity hashes. Without that you learn a device passed but never which one, so you cannot ledger it, and deleting the passkey hands the same hardware a second account. Registering the credential with excludeCredentials set to the ones you have already seen means a device that already holds an account cannot quietly produce another.

A masked ceremony is not a cleared one

A probe reports concealment and rules nothing by it. A VPN is not a lie, and millions of people run one for ordinary reasons.

A ceremony is different. A clearance from behind a mask is worth nothing to you: you cannot record an exit-node address, cannot tie the machine identifier to anything, and cannot see the second account. So a ceremony whose legs show a concealment indicator is held rather than cleared. Nothing it produced is kept, the page says to turn the VPN off, and the visitor can run it again inside the same window. Held, not contradicted, because a privacy tool is not fraud and the mask is the one thing the visitor can fix.

The limits, stated

The signature binds browser-supplied bytes to a challenge. It is not hardware attestation, it does not prove the readings came from a real sensor, and a sufficiently coherent synthetic motion stream can satisfy the physics checks. A QR hand-off between a desktop and a phone establishes freshness, not that the two devices are in the same room.

What you get is a cost change. An account goes from free to one physical device plus one passkey, and most multi-accounting economics do not survive that.

The privacy shape

There is a version of this problem that becomes identity verification, and it is usually a bad trade. A document scan makes you the controller of the most sensitive data your users have, in exchange for answering a question you did not ask.

The device check answers the narrow question. Is this the machine that already holds an account. It needs no name, no document and no face. What is collected is the address the connection arrived from, what the browser said about itself, and two identifiers scoped to your site. If you would rather nothing be retained, zero-retention mode holds the result in memory for ten seconds, lets you read it once, and destroys it.