डिजिटल फुटप्रिंट ट्रैकिंग अंदरूनी तौर पर कैसे काम करती है

इंटरनेट से जुड़ने वाला हर डिवाइस तकनीकी निशानों की एक लकीर छोड़ता है — एक डिजिटल फुटप्रिंट। tracio.ai पर, हम इस फुटप्रिंट को एक ही page load के दौरान एकत्र किए गए 300 से ज़्यादा passive संकेतों से पुनर्निर्मित करते हैं, और पहचान cookies या किसी अन्य स्थायी client-side storage पर निर्भर नहीं होती। यह लेख ठीक-ठीक समझाता है कि यह प्रक्रिया कैसे काम करती है।

संकेत संग्रह परत (The Signal Collection Layer)

जब हमारा JavaScript एजेंट किसी विज़िटर के ब्राउज़र में लोड होता है, तो यह एक साथ कई श्रेणियों में संकेत एकत्र करना शुरू कर देता है। Canvas रेंडरिंग, WebGL पैरामीटर queries, AudioContext प्रोसेसिंग, font enumeration और navigator property reads सभी समानांतर रूप से चलते हैं, और हर एक की अपनी timeout सीमा होती है ताकि कोई धीमी probe बाकी को न रोके। पूरे चक्र में कितना समय लगता है यह विज़िटर के डिवाइस पर निर्भर करता है, और नीचे दिए गए आँकड़े वही हैं जो हम अपने डिवाइस पर मापते हैं।

मुख्य बात यह है कि प्रत्येक संकेत डिवाइस के हार्डवेयर और सॉफ़्टवेयर स्टैक के एक अलग पहलू को कैप्चर करता है। Canvas रेंडरिंग GPU, driver और font रेंडरिंग engine को दर्शाती है। WebGL पैरामीटर ग्राफ़िक्स कार्ड मॉडल और क्षमताओं को उजागर करते हैं। AudioContext यह बताता है कि audio DSP floating-point operations को कैसे प्रोसेस करता है, उसमें अंतर होते हैं। Navigator properties CPU cores, memory, platform और language settings की रिपोर्ट देती हैं।

हमारी टीम ने पिछले महीने 2 अरब events पर इसे मापा: median संग्रह समय 38ms था, और 99वाँ percentile 52ms। हमने वास्तव में पहले सरल तरीका आज़माया था — संकेतों को अनुक्रमिक रूप से एकत्र करना। वह 40 गुना धीमा था। timeout fence के साथ समानांतर संग्रह उन पहले वास्तुशिल्प निर्णयों में से एक था जो हमने सही किए।

TLS Fingerprinting: पहली परत

हमारा JavaScript चलने से पहले ही, ब्राउज़र TLS हैंडशेक के ज़रिए महत्वपूर्ण जानकारी उजागर कर चुका होता है। Client Hello संदेश में वे cipher suites होते हैं जिन्हें ब्राउज़र समर्थन करता है, वे TLS extensions जो यह उपयोग करता है, वे elliptic curves जिन्हें यह पसंद करता है, और वे signature algorithms जिन्हें यह स्वीकार करता है। यह जानकारी ब्राउज़र की TLS लाइब्रेरी द्वारा निर्धारित होती है और ब्राउज़र परिवारों, versions और ऑपरेटिंग सिस्टम के बीच काफ़ी भिन्न होती है।

हम इस TLS fingerprint को JA4 hashing का उपयोग करके कैप्चर करते हैं — यह JA3 का एक आधुनिक विकल्प है जो बेहतर ग्रैन्युलैरिटी और cross-version स्थिरता प्रदान करता है। JA4 hash अकेले ही Chrome को Firefox से और Safari से अलग कर सकता है, और अक्सर पहचान को किसी विशिष्ट ब्राउज़र version रेंज तक सीमित कर देता है। हमारे client-side संकेतों के साथ मिलकर, यह एक cross-validation परत प्रदान करता है जिसे spoof करना बेहद कठिन है।

Canvas और GPU Fingerprinting

Canvas fingerprinting इस तथ्य का लाभ उठाती है कि अलग-अलग GPU एक ही drawing instructions को सूक्ष्म pixel-स्तरीय अंतरों के साथ रेंडर करते हैं। Canvas API हमें एक सावधानीपूर्वक डिज़ाइन किया गया दृश्य बनाने देता है — कई fonts में विशिष्ट text strings, विशेष निर्देशांकों वाली ज्यामितीय आकृतियाँ, और सटीक color stops वाले gradients — फिर परिणामी pixel data का hash परिकलित करता है।

रेंडरिंग में अंतर GPU मॉडलों और driver versions के बीच anti-aliasing algorithms, sub-pixel रेंडरिंग, color blending और font hinting में भिन्नताओं से आते हैं। एक ही GPU मॉडल वाले दो डिवाइस भी अलग-अलग canvas output दे सकते हैं यदि वे अलग-अलग driver versions या ऑपरेटिंग सिस्टम चलाते हैं। यही बात canvas hash को हमारे सबसे विशिष्ट संकेतों में से एक बनाती है।

WebGL हार्डवेयर प्रोफ़ाइलिंग

WebGL API ग्राफ़िक्स subsystem के बारे में विस्तृत जानकारी उजागर करता है जो renderer और vendor strings से कहीं आगे जाती है। हम अधिकतम texture sizes, shader precision formats, समर्थित extensions, viewport dimensions और दर्जनों अन्य पैरामीटर query करते हैं जो GPU मॉडलों और driver कॉन्फ़िगरेशन के बीच भिन्न होते हैं।

इन पैरामीटरों का संयोजन एक विस्तृत हार्डवेयर प्रोफ़ाइल बनाता है। उदाहरण के लिए, NVIDIA RTX 4070 वाला एक डिवाइस, AMD RX 7800 XT वाले डिवाइस की तुलना में अलग अधिकतम texture sizes, अलग shader precision और अलग extension समर्थन की रिपोर्ट देगा। यह हार्डवेयर प्रोफ़ाइल स्वाभाविक रूप से स्थिर है — यह ब्राउज़र अपडेट के साथ नहीं बदलती, केवल हार्डवेयर या driver बदलने पर बदलती है।

Audio Processing Fingerprinting

Web Audio API एक और हार्डवेयर-निर्भर संकेत स्रोत प्रदान करता है। हम एक oscillator node बनाते हैं, इसे एक dynamics compressor से जोड़ते हैं, और output buffer मापते हैं। audio हार्डवेयर और ऑपरेटिंग सिस्टम के बीच floating-point precision, DSP कार्यान्वयन और resampling algorithms में अंतर, output में मापने योग्य भिन्नताएँ पैदा करते हैं।

Audio fingerprints में मध्यम विशिष्टता लेकिन असाधारण स्थिरता होती है। जब तक उपयोगकर्ता audio हार्डवेयर नहीं बदलता या ऑपरेटिंग सिस्टम पुनः इंस्टॉल नहीं करता, तब तक audio प्रोसेसिंग pipeline शायद ही कभी बदलती है। यही बात audio संकेतों को हमारी बहु-स्तरीय पहचान प्रणाली में मूल्यवान anchor बनाती है।

संकेत संलयन और पहचान समाधान (Signal Fusion and Identity Resolution)

कच्चे संकेत encrypt किए जाते हैं और हमारे server पर भेजे जाते हैं, जहाँ डिवाइस पहचान engine उन्हें तीन-स्तरीय hashing प्रणाली के माध्यम से प्रोसेस करता है। हार्डवेयर-स्तरीय संकेत (canvas, WebGL, audio) Tier 1 बनाते हैं — स्थिर मूल पहचान। ब्राउज़र-स्तरीय संकेत (feature detection, CSS properties, media capabilities) Tier 2 बनाते हैं, जिन्हें ब्राउज़र अपडेट से अपेक्षित बहाव (drift) को संभालने के लिए cross-session matching के माध्यम से प्रोसेस किया जाता है। अस्थिर संकेत (user agent, timezone, language) Tier 3 बनाते हैं, जो पहचान निर्णयों को संचालित किए बिना confidence scoring में योगदान देते हैं।

संलयन algorithm प्रत्येक संकेत को उसकी विशिष्टता और स्थिरता के अनुसार तौलता है। किसी दुर्लभ canvas hash पर मिलान, किसी सामान्य screen resolution पर मिलान की तुलना में कहीं अधिक भार रखता है। यह भारित दृष्टिकोण सुनिश्चित करता है कि संकेतों के एक उपसमूह के बदलने पर भी पहचान सटीक बनी रहे।

हम क्या संग्रहित करते हैं, और पहचान उस पर निर्भर क्यों नहीं है

हमारी प्रणाली का एक महत्वपूर्ण डिज़ाइन सिद्धांत यह है कि पहचान client-side storage पर निर्भर नहीं करती। विज़िटर ID डिवाइस की अंतर्निहित विशेषताओं से प्राप्त होती है — हार्डवेयर, सॉफ़्टवेयर स्टैक, नेटवर्क कॉन्फ़िगरेशन — और यही कारण है कि पहचान cookie clear, incognito mode और यहाँ तक कि ब्राउज़र पुनः इंस्टॉल के बाद भी बनी रहती है।

यह निर्भरता के बारे में दावा है, परहेज़ के बारे में नहीं, और यह अंतर स्पष्ट रूप से कहने योग्य है। हम वास्तव में एक first-party cookie सेट करते हैं — _vid_t, जिसमें 365 दिन की समय-सीमा वाला एक opaque पहचानकर्ता होता है — और वही मान localStorage में भी रखते हैं। हम जो नहीं करते: third-party cookies सेट करना, ऐसा कुछ लिखना जो साइटों के बीच काम करे, या browsing history, form data या IndexedDB पढ़ना। यह cookie इसलिए है क्योंकि "क्या हमने यह ब्राउज़र पहले देखा है?" का यह सबसे सस्ता संभव उत्तर है — जब यह बची रहती है, मिलान तत्काल और निश्चित होता है। जब यह नहीं बचती, कुछ नहीं टूटता: डिवाइस संकेत स्वयं ही पहचानकर्ता को पुनर्निर्मित कर देते हैं, थोड़ी कम confidence के साथ। सब कुछ मिटा देने वाला विज़िटर भी पहचाना जाता है; केवल storage पर बनी प्रणाली उसे खो चुकी होती।

आर्किटेक्चर द्वारा गोपनीयता (Privacy by Architecture)

चूँकि हम केवल तकनीकी ब्राउज़र विशेषताएँ एकत्र करते हैं — कोई browsing history नहीं, कोई form data नहीं, कोई व्यक्तिगत सामग्री नहीं — गोपनीयता पर प्रभाव न्यूनतम होता है। W3C Fingerprinting Guidance ब्राउज़र संकेतों के ज़िम्मेदार उपयोग के लिए सर्वोत्तम प्रथाओं की रूपरेखा देती है, और हमारा आर्किटेक्चर इन सिद्धांतों के अनुरूप है। प्रोसेसिंग हमारे मैनेज्ड क्लाउड में होती है, और आपके चुने हुए रीजन के अनुसार डेटा रेजिडेंसी EU या US में रहती है। यह आर्किटेक्चर GDPR, CCPA और अन्य गोपनीयता विनियमों का अनुपालन सरल बनाता है।