How Digital Footprint Tracking Works Under the Hood

Every device that connects to the internet leaves a trail of technical artifacts — a digital footprint. At tracio.ai, we reconstruct this footprint from over 300 passive signals collected during a single page load, without the identification depending on cookies or any other persistent client-side storage. This article explains exactly how that process works.

The Signal Collection Layer

When our JavaScript agent loads in a visitor's browser, it begins collecting signals across multiple categories simultaneously. Canvas rendering, WebGL parameter queries, AudioContext processing, font enumeration, and navigator property reads all run in parallel, each one bounded by its own timeout so a slow probe cannot hold up the rest. How long the whole pass takes depends on the visitor's device, and the numbers below are what we measure on ours.

The key insight is that each signal captures a different aspect of the device's hardware and software stack. Canvas rendering reflects the GPU, driver, and font rendering engine. WebGL parameters expose the graphics card model and capabilities. AudioContext reveals differences in how the audio DSP processes floating-point operations. Navigator properties report CPU cores, memory, platform, and language settings.

Our team measured this across 2 billion events last month: the median collection time was 38ms, and 99th percentile was 52ms. We actually tried the naive approach first — collecting signals sequentially. It was 40x slower. Parallel collection with a timeout fence was one of the first architectural decisions we got right.

TLS Fingerprinting: The First Layer

Before our JavaScript even executes, the browser has already revealed significant information through the TLS handshake. The Client Hello message contains the cipher suites the browser supports, the TLS extensions it uses, the elliptic curves it prefers, and the signature algorithms it accepts. This information is determined by the browser's TLS library and varies significantly across browser families, versions, and operating systems.

We capture this TLS fingerprint using JA4 hashing — a modern replacement for JA3 that provides better granularity and cross-version stability. The JA4 hash alone can distinguish Chrome from Firefox from Safari, and often narrows identification to a specific browser version range. Combined with our client-side signals, it provides a cross-validation layer that is extremely difficult to spoof.

Canvas and GPU Fingerprinting

Canvas fingerprinting exploits the fact that different GPUs render the same drawing instructions with subtle pixel-level differences. The Canvas API lets us draw a carefully designed scene — specific text strings in multiple fonts, geometric shapes with particular coordinates, and gradients with precise color stops — then compute a hash of the resulting pixel data.

The rendering differences come from variations in anti-aliasing algorithms, sub-pixel rendering, color blending, and font hinting across GPU models and driver versions. Even two devices with the same GPU model may produce different canvas outputs if they run different driver versions or operating systems. This makes the canvas hash one of our most distinctive signals.

WebGL Hardware Profiling

The WebGL API exposes detailed information about the graphics subsystem that goes far beyond the renderer and vendor strings. We query maximum texture sizes, shader precision formats, supported extensions, viewport dimensions, and dozens of other parameters that vary across GPU models and driver configurations.

The combination of these parameters creates a detailed hardware profile. A device with an NVIDIA RTX 4070, for example, will report different maximum texture sizes, different shader precision, and different extension support than a device with an AMD RX 7800 XT. This hardware profile is inherently stable — it does not change with browser updates, only with hardware or driver changes.

Audio Processing Fingerprinting

The Web Audio API provides another hardware-dependent signal source. We create an oscillator node, connect it to a dynamics compressor, and measure the output buffer. Differences in floating-point precision, DSP implementation, and resampling algorithms across audio hardware and operating systems produce measurable variations in the output.

Audio fingerprints have moderate uniqueness but exceptional stability. The audio processing pipeline rarely changes unless the user switches audio hardware or reinstalls the operating system. This makes audio signals valuable anchors in our multi-tier identification system.

Signal Fusion and Identity Resolution

Raw signals are encrypted and transmitted to our server, where the device identification engine processes them through a three-tier hashing system. Hardware-level signals (canvas, WebGL, audio) form Tier 1 — the stable core identity. Browser-level signals (feature detection, CSS properties, media capabilities) form Tier 2, processed through cross-session matching to handle expected drift from browser updates. Volatile signals (user agent, timezone, language) form Tier 3, contributing to confidence scoring without driving identity decisions.

The fusion algorithm weighs each signal by its uniqueness and stability. A match on a rare canvas hash carries far more weight than a match on a common screen resolution. This weighted approach ensures that identification remains accurate even when a subset of signals changes.

What We Store, and Why Identification Does Not Depend On It

A critical design principle of our system is that identification does not depend on client-side storage. The visitor ID is derived from the device's inherent characteristics — the hardware, the software stack, the network configuration — which is why identification survives cookie clears, incognito mode, and even browser reinstallation.

That is a claim about dependence, not about abstinence, and the difference is worth stating plainly. We do set one first-party cookie, _vid_t, holding an opaque identifier with a 365-day expiry, and we mirror the same value into localStorage. What we do not do is set third-party cookies, write anything that works across sites, or read browsing history, form data, or IndexedDB. The cookie exists because it is the cheapest possible answer to "have we seen this browser before" — when it survives, the match is immediate and certain. When it does not survive, nothing breaks: the device signals reconstruct the identifier on their own, at slightly lower confidence. A visitor who clears everything is still recognized; a system built on storage alone would have lost them.

Privacy by Architecture

Because we collect only technical browser attributes — no browsing history, no form data, no personal content — the privacy impact is minimal. The W3C Fingerprinting Guidance outlines best practices for responsible use of browser signals, and our architecture aligns with these principles. Processing happens in our managed cloud, with data residency in the EU or the US depending on the region you choose. This architecture makes compliance with GDPR, CCPA, and other privacy regulations straightforward.