What is browser fingerprinting and how does it work?

What is a browser fingerprint?

A browser fingerprint is an identity assembled from the properties your browser and device openly expose to websites. Each piece looks ordinary on its own (screen size, language, time zone, graphics card model), but combined they can form a picture distinctive enough to pick you out among a very large number of visitors.

The difference from cookies is simple: a cookie is a marker written to your computer, and it can be deleted. A fingerprint is computed again on every visit; there is nothing to delete. That is why clearing cookies or using a private window does not stop a site from recognising the same device.

Which signals make up a fingerprint?

User-Agent and Client Hints

The browser introduces itself on every request: which browser, which version, which operating system. Modern Chrome exposes this in more detail through User-Agent Client Hints (brand list, full version, platform version, architecture). These values have to agree between the HTTP headers and the JavaScript side.

Screen and window

Screen resolution, available area, colour depth and the scaling factor (devicePixelRatio) say a lot about your device. A 1920×1080 screen at 125% scaling, for example, is very common on everyday Windows laptops.

Canvas, WebGL and audio

The same drawing commands produce tiny pixel-level differences on different graphics cards, drivers and font rasterisers. A site draws text and shapes on an invisible canvas and takes a hash of the result. WebGL additionally reveals the graphics vendor and model (the renderer) and supported features. Audio processing (AudioContext) also produces small hardware- and software-dependent differences.

Fonts

The installed fonts hint at the operating system and installed software. A font that does not ship with Windows appearing in a “Windows” profile is an inconsistency.

Hardware

CPU thread count (hardwareConcurrency), approximate memory (deviceMemory), touch support and battery state can be collected as well.

Language and time zone

The browser's language list and the system time zone are compared with the country of your IP address. A visitor from an Istanbul IP whose clock runs on New York time is memorable.

The network layer

A fingerprint is not only JavaScript. The structure of the TLS handshake, HTTP/2 settings and TCP/IP packet traits help identify the client too. A modified browser that looks like Chrome in JavaScript but behaves differently on the wire creates a contradiction that can be noticed. We cover the IP and proxy side in our guide to leaks.

How do sites use fingerprints?

There are two main uses. The first is re-identification: noticing that the same device comes back with different accounts or after its cookies were cleared. The second is anomaly detection: asking “could the properties this visitor reports belong to a real device?” Security and fraud-prevention systems usually combine both.

If you are curious how distinctive your own fingerprint is, try tools such as the EFF's Cover Your Tracks or the open-source CreepJS test.

Why consistency, not randomness?

The first idea most people have is to randomise every value. Random values, however, tend to trigger the second problem: anomaly detection. A few typical contradictions:

• The user agent says Mac while WebGL reports a Windows-only Direct3D renderer string.
• An entry-level laptop GPU paired with a 4K screen and a very high core count.
• The page reports one device while an iframe or Web Worker inside it reports another.
• Canvas output changing on every load; on a real device the same drawing gives the same result every time.

That is why a good profile should be derived from a device model that actually exists. Graphics card, CPU, memory, screen, fonts and platform have to match; the same profile should give the same fingerprint every time it opens, and two profiles should never resemble each other.

How are fingerprint changes applied?

How a value is changed matters as much as what it is changed to. An extension or script that runs after the page has loaded can leave traces such as modified functions, unexpected properties or timing differences. Sturdier approaches either change the browser's own code (engine level) or apply changes before the page's first statement runs, in a way the page code cannot see. The same identity also has to hold in the page, its iframes and its workers.

How Kalkan manages fingerprints

In Kalkan every profile is built from real OEM device archetypes, not random values: GPU generation, CPU, screen and laptop/desktop traits match, and devices are chosen to fit the generation of your own graphics card. Canvas, WebGL and audio noise is per-profile and persistent; the same profile gives the same result every time.

Because the default Kalkan engine uses the real Google Chrome, its TLS and network behaviour is the same as stock Chrome, and its patches are in place before the page's first statement. For engine-level changes there is also the optional Kalkan Native engine. See how profiles are created in the first profile guide, or download Kalkan and run your own tests.

Summary

• Fingerprinting recognises you without cookies; a private window does not defeat it.
• Dozens of small signals combine into a distinctive identity.
• Random values separate profiles but create contradictions; real device models separate and convince.
• How and when changes are applied matters as much as the values themselves.

The other half of keeping profiles apart is the network identity; continue with our article on proxy, WebRTC, DNS and QUIC leaks.