Why sticky browser fingerprints matter more than unique ones

A fraudster you blocked last week comes back after updating the browser. The fingerprint is new, so your block list lets the request through. The same thing happens after they set up a new phone.

A unique fingerprint can still be short-lived. What matters is whether an identifier stays connected through browser changes and whether it can be assessed alongside the email, phone, IP and bank account around an application.

Unique is easy, sticky is hard

Uniqueness answers a narrow question: does this fingerprint look different from the others you have seen? Stickiness answers the operational question: does the same browser or device continue to receive a usable identifier after its software or settings change?

You can think of a fingerprint as many small signals from one browser on one device: how it renders a canvas image, what its graphics card reports through WebGL, how its sound card processes audio, which fonts are installed, the screen size, how many processor cores it reports, touch support, the browser and its version, and the time zone. Commercial services combine over 100 such signals. Each browser on each device gives its own combination, so Chrome and Firefox on the same laptop, and a new phone, are separate fingerprints. What makes them one customer is the links between them: the same login, email or bank account.

A hash computed in the browser is sensitive to its inputs. Change one attribute and the result can become a new id. Fingerprint's open-source library says its browser-generated ids have significantly lower accuracy than its commercial product, are vulnerable to spoofing and reverse engineering, and last several weeks rather than months or years.

In practice, a sticky id is one that can remain the same through a browser update and after cookies are deleted or unavailable. Fingerprint describes its commercial visitor ids in those terms. Its service combines server data with browser data, using a deterministic match when it can and a probabilistic match when it cannot.

That distinction changes how you judge a provider. Ask how its id behaves after the visitor changes, not only whether the first fingerprint is unique.

What browsers and phones took away

Browser and platform changes have reduced the information available to fingerprinting. The changes are specific, and they affect browsers and apps differently.

Apps can recover a different kind of signal through attestation. Play Integrity can tell an app's server whether the app is unmodified, the device is genuine and certified, and the install came from Google Play. Its device recall feature can store three bits per device that survive a reinstall and factory reset. Apple's DeviceCheck stores two binary digits per device, and App Attest proves that a request comes from a valid instance of the app.

These capabilities are available to app developers. They provide signals about a genuine device or an unmodified app, rather than recreating the old browser fingerprint. Fingerprinting through the relevant device-detail APIs is not allowed under Apple's rules for iPhone apps, and an app using the relevant device-detail APIs needs an approved reason to be uploaded to the App Store.

What a good service does

A useful service treats identification as a continuing resolution problem.

• It resolves the id on its own servers from browser data and server data instead of sending you only a hash computed in the browser.
• It matches deterministically when it can and probabilistically when it cannot, and gives the probabilistic match a confidence score.
• It reports signals for tampering, VPN use and bots, so a stable id is not mistaken for a trustworthy visit.
• It shows how many IPs and countries one visitor used across five minutes, one hour and 24 hours.

Fingerprint is an example of this model. Its documentation says the visitor id remains stable across visits and can stay the same when device settings or software change, or when cookies are deleted or unavailable. The confidence score matters because a probabilistic match is an inference, not a certainty.

Put these checks into a decision flow

Create rules for credit, fraud or collections, then run them on live decisions.

Start free See pricing

Recognise your good customers

Stickiness has a positive use as well as a fraud-control use. A returning good customer can be recognised on the device they normally use, so the request can go through without a step-up. The customer gets a stable experience because a browser update or deleted cookies does not automatically make them look new.

A known good device can also sit on an allow list. When the device matches, the decision flow can skip a check. The list still reflects a rule you choose, rather than turning the device id into a permanent judgement about every future request.

A changed device needs a different response. Email and bank account details can link a known customer’s new device back to earlier applications. The rule can then ask for a step-up, rather than treating the arrival as a stranger or letting the old device history decide on its own.

That is why stability for current customers belongs beside fraud detection when you assess a fingerprinting service. The useful question is not only whether the service catches a device you want to block. It is whether the identifier helps you recognise a legitimate return, apply the right check when circumstances change, and keep the customer’s normal path intact. Sticky identity, stickier CX.

Connect the fingerprint to everything else

A new device does not automatically mean a new person. The fingerprint is one node in a larger set of connections. Email, phone, IP and bank account details can join applications that share them, so a device change becomes a change to investigate rather than a clean break.

Fraud link analysis lets you examine those connections on your own data. It accepts applications with emails, phones, device ids, bank accounts and IPs, then links applications that share an exact value after cleaning. Values shared too widely, such as an office IP or test email, can be set aside above a limit you choose. The result shows which applications sit within one, two or three steps of a known bad application.

A link is a reason to look at an application, not proof of fraud. That distinction matters when a shared value has an ordinary explanation.

Device ids can also be used directly in block, allow and watch lists. A decision flow can see a list change without a release, and it can add a device id after a confirmed fraud decision. That gives the id a role in an ongoing control rather than treating the first observation as final.

How fingerprinting got here

Each step found a new way to recognise a returning browser as the earlier one became less available:

• Evercookies stored themselves in several places on a device, so they survived a user deleting them.
• ETags, often on a single-pixel image, let a site recognise a returning browser through the cache.
• Canvas fingerprinting draws an image and reads the small differences in how each device renders it.
• WebGL fingerprinting applies the same idea through 3D graphics rendering.
• Media device fingerprinting reads the cameras, microphones and speakers a browser reports, and audio fingerprinting measures how a device processes sound.
• Fingerprinting without JavaScript takes its signals from the HTTP requests themselves.
• Server-side identification combines what the server receives with browser data to keep the id stable as the signals change.

Frequently asked questions

Do Safari's and Firefox's protections make fingerprinting useless?

No. They make particular signals less stable or less detailed. Safari adds noise to canvas and Web Audio, fixes reported screen size and limits access to other signals. Firefox has extended protection to GPU information, fonts, hardware concurrency and touch capabilities. A service that combines server data with browser data can still attempt to resolve an id, and it can report a confidence score when the match is probabilistic.

Can I use the open-source library?

You can use it as a browser-generated fingerprint, but its own documentation says that accuracy is significantly lower than the commercial version. It also says the ids are vulnerable to spoofing and reverse engineering and last several weeks rather than months or years. Treat that id as a limited signal, not as a sticky identity.

Can an iPhone app fingerprint the device?

Apple's rules say fingerprinting is not allowed for apps using the relevant device-detail APIs. The advertising identifier is all zeros unless tracking is allowed, and the vendor identifier changes after all of one vendor's apps are deleted and reinstalled. DeviceCheck and App Attest provide different signals for app developers.

What do I do when the fingerprint changes for a known customer?

Look at the surrounding connections. Compare the email, phone, IP and bank account with other applications, then treat a shared value as a reason to investigate rather than proof of fraud. A decision flow can then put that device id on a watch list, and the next request sees it.

Put these checks into a decision flow

Create rules for credit, fraud or collections, then run them on live decisions.

Start free See pricing