Navigation
View as Markdown

Fingerprints

A fingerprint is a browser-level identity in Rupt's data model. It's a stable hash derived from the signals Rupt collects: the user agent, hardware probes, cryptographic measurements, storage state, and behavioral indicators. The same browser on the same machine, fingerprinted twice, produces the same fingerprint. A different browser on the same machine produces a different fingerprint.

Fingerprints sit between sessions (which are ephemeral) and devices (which are physical). Multiple fingerprints can map to one device, Chrome and Safari on the same Mac, for example. One fingerprint maps to exactly one browser instance.

What fingerprints are good for

  • Linked accounts: multiple user accounts sharing a single fingerprint usually means one person operating multiple accounts.
  • Multi-accounting and ban evasion: clearing cookies doesn't clear a fingerprint. Someone trying to re-create an account after being blocked will trip on fingerprint reuse.
  • Account takeover detection: a login from a brand-new fingerprint, when the user has been on the same one for months, is a meaningful shift.

These are surfaced through checks:

  • is_new_fingerprint: first time this fingerprint is seen for this user.
  • fingerprint_user_count: how many users share this fingerprint.

Differentiating within a browser, not across

Fingerprinting is intra-browser by design. The goal isn't to recognize the same person whether they switch from Chrome to Safari, which is privacy-violating and unreliable. The goal is within a single browser, to differentiate this instance from every other instance, even if they look superficially similar.

What matters for accuracy: that the same browser produces the same fingerprint on every visit, and that two genuinely different browsers don't collide. Cross-browser uniformity isn't the goal.

Anti-fingerprinting tooling

Some browsers and extensions actively try to defeat fingerprinting: Tor Browser, Brave's farbling, Firefox's RFP, Safari's ITP lockdown. Rupt detects this directly: the anti_fingerprinting risk surfaces when these tools are in play, regardless of whether they successfully obscured the underlying signals. That gives you policy options ranging from "ignore" (privacy-friendly product) to "challenge" (high-trust flow).