What is device fingerprinting?

Device fingerprinting is a technique that identifies a device by combining dozens of observable attributes, such as screen dimensions, installed fonts, GPU characteristics, and timezone, into a single identifier. The fingerprint is computed from what the device is rather than stored on it, so it survives cookie clearing, private browsing, and logouts. Fraud teams use it to recognize a returning device even when the person behind it is trying to look new.

How it works

A script on the page (or an SDK inside a native app) reads attributes the platform exposes and hashes them into an identifier. No single attribute identifies anyone. Your timezone is shared with millions of people. The power is in the combination: enough weakly identifying signals, taken together, separate one browser from almost every other browser that visits the site. The EFF's Cover Your Tracks project demonstrates this by showing visitors how identifiable their own browser is.

The signals that carry the most entropy:

• Canvas rendering. The script draws text and shapes to an invisible canvas and reads the pixels back. Anti-aliasing, font rasterization, and GPU quirks make the output differ across hardware and driver combinations. Mowery and Shacham described the technique in 2012 and it is still one of the strongest signals available.
• WebGL. The reported renderer, the supported extensions, and the exact output of a rendered test scene reveal the GPU and driver stack.
• Fonts. The set of installed fonts, measured by rendering text and comparing element dimensions, reflects the operating system and whatever software the user has installed over the years.
• Hardware and environment. CPU core count, device memory, screen resolution, pixel density, touch support, timezone, and language each contribute a few bits.

Browser fingerprinting versus device fingerprinting

On the web the two terms get used interchangeably, but what a script collects is really a browser fingerprint. Chrome and Firefox on the same laptop produce different fingerprints because every signal passes through the browser's rendering engine and API surface. That is not a flaw. Fingerprinting is per-browser by design, and the practical job is differentiating users within a browser population: telling apart the thousands of Chrome-on-Windows visitors who would otherwise look identical. Producing one identifier that follows a person across different browsers is a separate identification problem, solved above the fingerprint layer by linking fingerprints through accounts, sessions, and network history rather than by stretching the fingerprint itself. Browser fingerprinting covers the web-specific mechanics in more depth. Native mobile apps get closer to a true device fingerprint because they can read hardware-level identifiers, though platforms restrict those too: Apple scopes its identifier for vendors to a single developer's apps.

Stability versus uniqueness

Every fingerprinting system balances two goals that pull against each other. A fingerprint should be stable, so the same device produces the same value next week and after a browser update. It should also be unique, so no two devices share one. Adding more signals increases uniqueness but makes the fingerprint brittle: a browser upgrade or a newly installed font changes a signal and breaks continuity. Using fewer, coarser signals keeps the fingerprint stable but produces collisions.

Collisions are worst on uniform hardware. Two iPhones of the same model on the same iOS version are nearly identical: same screen, same GPU, same font set, and an operating system that deliberately limits the APIs that could tell them apart. A fingerprint alone cannot separate them, and treating a raw match as proof of "same device" merges strangers. The false positive cost is real. An innocent user can inherit a ban meant for someone else's ban evasion, or two unrelated customers can get flagged as one multi-accounting operator. The practitioner's answer is corroboration: a fingerprint match on commodity hardware should only be trusted when supporting evidence agrees, such as overlapping IP history, shared account linkage, or consistent behavioral patterns. Fingerprints work best as a weighted input to a scoring system, not a binary verdict.

Fraud prevention versus ad tracking

Fingerprinting earned its poor reputation from advertising, where it was used to follow people across unrelated websites and rebuild profiles they had tried to delete. Fraud prevention uses the same techniques with a narrower scope: first party, on a single service, to answer whether this device has been here before and what it did. That covers recognizing the device behind repeated fake signups, catching one device that operates a farm of accounts, and spotting the rendering anomalies that give away headless browsers in bot detection. The distinction matters legally as well. Under GDPR, fraud prevention is explicitly named as a legitimate interest (Recital 47), while cross-site ad tracking generally requires consent.

How Rupt handles it

Rupt collects a browser fingerprint as one input to its identification layer, not as the identity itself. Fingerprint matches are corroborated with network and account signals before devices are merged, which keeps same-model phones from collapsing into a single device, and the resulting device IDs stay stable even when individual fingerprint signals change.