Så fungerar spårning av digitala fotavtryck under huven
Från TLS-handskakningar till canvas-rendering — så rekonstruerar vi en enhets digitala fotavtryck från över 300 passiva signaler, utan att vara beroende av lagrat tillstånd.
Varje enhet som ansluter till internet lämnar ett spår av tekniska artefakter — ett digitalt fotavtryck. På tracio.ai rekonstruerar vi detta fotavtryck från över 300 passiva signaler som samlas in under en enda sidladdning, utan att identifieringen är beroende av cookies eller någon annan form av beständig lagring på klientsidan. Den här artikeln förklarar exakt hur den processen fungerar.
Lagret för signalinsamling
När vår JavaScript-agent laddas i en besökares webbläsare börjar den samla in signaler över flera kategorier samtidigt. Canvas-rendering, WebGL-parameterförfrågningar, AudioContext-bearbetning, teckensnittsuppräkning och avläsningar av navigator-egenskaper körs alla parallellt, var och en begränsad av sin egen timeout så att en långsam mätning inte håller upp de övriga. Hur lång tid hela svepet tar beror på besökarens enhet, och siffrorna nedan är vad vi mäter på vår.
Den avgörande insikten är att varje signal fångar en annan aspekt av enhetens hård- och mjukvarustack. Canvas-rendering återspeglar GPU:n, drivrutinen och renderingsmotorn för teckensnitt. WebGL-parametrar avslöjar grafikkortets modell och kapacitet. AudioContext blottar skillnader i hur ljudets DSP bearbetar flyttalsoperationer. Navigator-egenskaper rapporterar CPU-kärnor, minne, plattform och språkinställningar.
Vårt team mätte detta över 2 miljarder händelser förra månaden: medianinsamlingstiden var 38 ms, och den 99:e percentilen var 52 ms. Vi provade faktiskt den naiva metoden först — att samla in signaler sekventiellt. Den var 40 gånger långsammare. Parallell insamling med en timeout-gräns var ett av de första arkitekturbesluten vi fick rätt.
TLS-fingeravtryck: det första lagret
Innan vår JavaScript ens körs har webbläsaren redan avslöjat betydande information genom TLS-handskakningen. Client Hello-meddelandet innehåller de chiffersviter webbläsaren stöder, de TLS-tillägg den använder, de elliptiska kurvor den föredrar och de signaturalgoritmer den accepterar. Denna information bestäms av webbläsarens TLS-bibliotek och varierar avsevärt mellan webbläsarfamiljer, versioner och operativsystem.
Vi fångar detta TLS-fingeravtryck med JA4-hashning — en modern ersättare för JA3 som ger bättre granularitet och stabilitet mellan versioner. Enbart JA4-hashen kan skilja Chrome från Firefox från Safari, och begränsar ofta identifieringen till ett specifikt webbläsarversionsintervall. Kombinerad med våra signaler på klientsidan ger den ett lager för korsvalidering som är extremt svårt att förfalska.
Canvas- och GPU-fingeravtryck
Canvas-fingeravtryck utnyttjar det faktum att olika GPU:er renderar samma ritinstruktioner med subtila skillnader på pixelnivå. Canvas API låter oss rita en noggrant utformad scen — specifika textsträngar i flera teckensnitt, geometriska former med bestämda koordinater och gradienter med exakta färgstopp — och sedan beräkna en hash av de resulterande pixeldata.
Renderingsskillnaderna kommer från variationer i kantutjämningsalgoritmer, subpixelrendering, färgblandning och teckensnittshinting mellan GPU-modeller och drivrutinsversioner. Även två enheter med samma GPU-modell kan producera olika canvas-utdata om de kör olika drivrutinsversioner eller operativsystem. Detta gör canvas-hashen till en av våra mest särskiljande signaler.
WebGL-hårdvaruprofilering
WebGL API exponerar detaljerad information om grafiksubsystemet som går långt bortom renderar- och leverantörssträngarna. Vi frågar efter maximala texturstorlekar, precisionsformat för shaders, stödda tillägg, viewport-dimensioner och dussintals andra parametrar som varierar mellan GPU-modeller och drivrutinskonfigurationer.
Kombinationen av dessa parametrar skapar en detaljerad hårdvaruprofil. En enhet med en NVIDIA RTX 4070 kommer till exempel att rapportera andra maximala texturstorlekar, annan shader-precision och annat tilläggsstöd än en enhet med en AMD RX 7800 XT. Denna hårdvaruprofil är i sig stabil — den ändras inte med webbläsaruppdateringar, endast med ändringar av hårdvara eller drivrutiner.
Fingeravtryck genom ljudbearbetning
Web Audio API tillhandahåller ytterligare en hårdvaruberoende signalkälla. Vi skapar en oscillatornod, kopplar den till en dynamikkompressor och mäter utdatabufferten. Skillnader i flyttalsprecision, DSP-implementering och omsamplingsalgoritmer mellan ljudhårdvara och operativsystem ger mätbara variationer i utdata.
Ljudfingeravtryck har måttlig unikhet men exceptionell stabilitet. Ljudbearbetningskedjan ändras sällan om inte användaren byter ljudhårdvara eller ominstallerar operativsystemet. Detta gör ljudsignaler till värdefulla ankare i vårt identifieringssystem med flera nivåer.
Signalfusion och identitetsupplösning
Råsignaler krypteras och överförs till vår server, där enhetsidentifieringsmotorn bearbetar dem genom ett hashsystem i tre nivåer. Signaler på hårdvarunivå (canvas, WebGL, ljud) utgör nivå 1 — den stabila kärnidentiteten. Signaler på webbläsarnivå (funktionsdetektering, CSS-egenskaper, mediekapacitet) utgör nivå 2, bearbetade genom matchning mellan sessioner för att hantera förväntad drift från webbläsaruppdateringar. Flyktiga signaler (user agent, tidszon, språk) utgör nivå 3 och bidrar till konfidenspoängsättning utan att styra identitetsbeslut.
Fusionsalgoritmen väger varje signal efter dess unikhet och stabilitet. En matchning på en sällsynt canvas-hash väger långt tyngre än en matchning på en vanlig skärmupplösning. Detta viktade tillvägagångssätt säkerställer att identifieringen förblir korrekt även när en delmängd av signalerna ändras.
Vad vi lagrar, och varför identifieringen inte är beroende av det
En avgörande designprincip i vårt system är att identifieringen inte är beroende av lagring på klientsidan. Besökar-ID:t härleds från enhetens inneboende egenskaper — hårdvaran, mjukvarustacken, nätverkskonfigurationen — och det är därför identifieringen överlever rensade cookies, inkognitoläge och till och med ominstallation av webbläsaren.
Det är ett påstående om beroende, inte om avhållsamhet, och skillnaden är värd att säga rakt ut. Vi sätter mycket riktigt en förstapartscookie, _vid_t, som innehåller en ogenomskinlig identifierare med 365 dagars giltighet, och vi speglar samma värde till localStorage. Vad vi inte gör: sätter tredjepartscookies, skriver något som fungerar över webbplatsgränser eller läser webbhistorik, formulärdata eller IndexedDB. Cookien finns för att den är det billigast tänkbara svaret på "har vi sett den här webbläsaren förut" — när den överlever är matchningen omedelbar och säker. När den inte överlever går inget sönder: enhetens signaler rekonstruerar identifieraren på egen hand, med något lägre konfidens. En besökare som rensar allt känns fortfarande igen; ett system byggt enbart på lagring hade förlorat hen.
Integritet genom arkitektur
Eftersom vi endast samlar in tekniska webbläsarattribut — ingen webbhistorik, inga formulärdata, inget personligt innehåll — är påverkan på integriteten minimal. W3C Fingerprinting Guidance beskriver bästa praxis för ansvarsfull användning av webbläsarsignaler, och vår arkitektur är i linje med dessa principer. Bearbetningen sker i vårt hanterade moln, med datalagringsplats i EU (Frankfurt). Denna arkitektur gör efterlevnad av GDPR, CCPA och andra integritetsregler enkel.