Hoe het volgen van een digitale voetafdruk onder de motorkap werkt

Elk apparaat dat verbinding maakt met het internet laat een spoor van technische artefacten achter — een digitale voetafdruk. Bij tracio.ai reconstrueren we deze voetafdruk uit meer dan 300 passieve signalen die tijdens één enkele pagina-lading worden verzameld, zonder dat de identificatie afhankelijk is van cookies of enige andere vorm van persistente opslag aan de clientzijde. Dit artikel legt precies uit hoe dat proces werkt.

De laag voor signaalverzameling

Wanneer onze JavaScript-agent in de browser van een bezoeker laadt, begint hij tegelijkertijd signalen te verzamelen in meerdere categorieën. Canvas-rendering, WebGL-parameterquery's, AudioContext-verwerking, lettertype-enumeratie en het uitlezen van navigator-eigenschappen draaien allemaal parallel, elk begrensd door een eigen timeout zodat één trage meting de rest niet ophoudt. Hoe lang de volledige ronde duurt, hangt af van het apparaat van de bezoeker; de cijfers hieronder zijn wat wij op het onze meten.

Het cruciale inzicht is dat elk signaal een ander aspect van de hardware- en softwarestack van het apparaat vastlegt. Canvas-rendering weerspiegelt de GPU, de driver en de lettertyperenderingsengine. WebGL-parameters onthullen het model en de mogelijkheden van de grafische kaart. AudioContext legt verschillen bloot in hoe de audio-DSP floating-pointbewerkingen verwerkt. Navigator-eigenschappen rapporteren CPU-cores, geheugen, platform en taalinstellingen.

Ons team heeft dit afgelopen maand gemeten over 2 miljard events: de mediane verzameltijd was 38 ms en het 99e percentiel was 52 ms. We hebben eerst de naïeve aanpak geprobeerd — signalen sequentieel verzamelen. Dat was 40x langzamer. Parallelle verzameling met een timeout-grens was een van de eerste architectuurbeslissingen die we goed hadden.

TLS-fingerprinting: de eerste laag

Nog voordat onze JavaScript wordt uitgevoerd, heeft de browser al aanzienlijke informatie prijsgegeven via de TLS-handshake. Het Client Hello-bericht bevat de cipher suites die de browser ondersteunt, de TLS-extensies die hij gebruikt, de elliptische curves die hij verkiest en de handtekeningalgoritmen die hij accepteert. Deze informatie wordt bepaald door de TLS-bibliotheek van de browser en varieert aanzienlijk tussen browserfamilies, versies en besturingssystemen.

We leggen deze TLS-fingerprint vast met JA4-hashing — een moderne vervanger van JA3 die betere granulariteit en cross-versiestabiliteit biedt. De JA4-hash alleen kan Chrome onderscheiden van Firefox en van Safari, en verkleint de identificatie vaak tot een specifieke browserversierange. In combinatie met onze signalen aan de clientzijde levert dit een kruisvalidatielaag op die extreem moeilijk te vervalsen is.

Canvas- en GPU-fingerprinting

Canvas-fingerprinting maakt gebruik van het feit dat verschillende GPU's dezelfde tekeninstructies met subtiele verschillen op pixelniveau renderen. Met de Canvas API kunnen we een zorgvuldig ontworpen scène tekenen — specifieke tekststrings in meerdere lettertypen, geometrische vormen met bepaalde coördinaten en gradiënten met precieze kleurstops — en vervolgens een hash berekenen van de resulterende pixeldata.

De renderingsverschillen komen voort uit variaties in anti-aliasingalgoritmen, subpixelrendering, kleurvermenging en font hinting tussen GPU-modellen en driverversies. Zelfs twee apparaten met hetzelfde GPU-model kunnen verschillende canvas-uitvoer produceren als ze verschillende driverversies of besturingssystemen draaien. Dit maakt de canvas-hash tot een van onze meest onderscheidende signalen.

WebGL-hardwareprofilering

De WebGL API onthult gedetailleerde informatie over het grafische subsysteem die veel verder gaat dan de renderer- en vendorstrings. We bevragen maximale texturegroottes, shaderprecisieformaten, ondersteunde extensies, viewportafmetingen en tientallen andere parameters die variëren tussen GPU-modellen en driverconfiguraties.

De combinatie van deze parameters vormt een gedetailleerd hardwareprofiel. Een apparaat met een NVIDIA RTX 4070 zal bijvoorbeeld andere maximale texturegroottes, andere shaderprecisie en andere extensie-ondersteuning rapporteren dan een apparaat met een AMD RX 7800 XT. Dit hardwareprofiel is inherent stabiel — het verandert niet met browserupdates, alleen met hardware- of driverwijzigingen.

Audioverwerkingsfingerprinting

De Web Audio API biedt nog een hardware-afhankelijke signaalbron. We maken een oscillatornode aan, verbinden die met een dynamics compressor en meten de uitvoerbuffer. Verschillen in floating-pointprecisie, DSP-implementatie en resamplingalgoritmen tussen audiohardware en besturingssystemen produceren meetbare variaties in de uitvoer.

Audiofingerprints hebben een matige uniciteit, maar een uitzonderlijke stabiliteit. De audioverwerkingspijplijn verandert zelden, tenzij de gebruiker van audiohardware wisselt of het besturingssysteem opnieuw installeert. Dit maakt audiosignalen tot waardevolle ankers in ons meerlaagse identificatiesysteem.

Signaalfusie en identiteitsresolutie

Ruwe signalen worden versleuteld en verzonden naar onze server, waar de apparaatidentificatie-engine ze verwerkt via een driedelig hashingsysteem. Hardwaresignalen (canvas, WebGL, audio) vormen Tier 1 — de stabiele kernidentiteit. Browsersignalen (feature detection, CSS-eigenschappen, mediamogelijkheden) vormen Tier 2, verwerkt via cross-sessionmatching om verwachte drift door browserupdates op te vangen. Vluchtige signalen (user agent, tijdzone, taal) vormen Tier 3 en dragen bij aan de betrouwbaarheidsscore zonder de identiteitsbeslissingen te sturen.

Het fusiealgoritme weegt elk signaal op basis van uniciteit en stabiliteit. Een match op een zeldzame canvas-hash weegt veel zwaarder dan een match op een veelvoorkomende schermresolutie. Deze gewogen aanpak zorgt ervoor dat de identificatie accuraat blijft, zelfs wanneer een deel van de signalen verandert.

Wat we opslaan, en waarom identificatie daar niet van afhangt

Een cruciaal ontwerpprincipe van ons systeem is dat identificatie niet afhankelijk is van opslag aan de clientzijde. De bezoekers-ID wordt afgeleid uit de inherente kenmerken van het apparaat — de hardware, de softwarestack, de netwerkconfiguratie — en juist daarom overleeft identificatie het wissen van cookies, de incognitomodus en zelfs het opnieuw installeren van de browser.

Dat is een uitspraak over afhankelijkheid, niet over onthouding, en dat verschil verdient het om ronduit gezegd te worden. We plaatsen wel degelijk één first-party cookie, _vid_t, met een ondoorzichtige identifier en een geldigheid van 365 dagen, en we spiegelen diezelfde waarde naar localStorage. Wat we niet doen: third-party cookies plaatsen, iets schrijven dat over sites heen werkt, of browsegeschiedenis, formuliergegevens of IndexedDB uitlezen. De cookie bestaat omdat het het goedkoopst denkbare antwoord is op "hebben we deze browser eerder gezien" — als hij het overleeft, is de match onmiddellijk en zeker. Als hij het niet overleeft, gaat er niets stuk: de apparaatsignalen reconstrueren de identifier op eigen kracht, met iets minder vertrouwen. Een bezoeker die alles wist, wordt nog steeds herkend; een systeem dat alleen op opslag is gebouwd, was hem kwijtgeraakt.

Privacy door architectuur

Omdat we alleen technische browserattributen verzamelen — geen browsegeschiedenis, geen formuliergegevens, geen persoonlijke inhoud — is de impact op de privacy minimaal. De W3C Fingerprinting Guidance schetst best practices voor verantwoord gebruik van browsersignalen, en onze architectuur sluit aan bij deze principes. De verwerking vindt plaats in onze managed cloud, met dataresidentie in de EU (Frankfurt). Deze architectuur maakt naleving van AVG, CCPA en andere privacyregelgeving eenvoudig.