Canvas Fingerprinting, बुनियादी बातों से आगे: दो एक जैसे Chrome अलग-अलग पिक्सल क्यों रेंडर करते हैं
एक ही Chrome, OS और GPU वाले दो डिवाइस भी अलग canvas पिक्सल रेंडर करते हैं। रेंडरिंग पाइपलाइन non-deterministic क्यों है, प्राइवेसी noise injection उलटा क्यों पड़ता है, और आधुनिक detection stack में canvas कहाँ फिट होता है।
Canvas fingerprinting 2012 से production में इस्तेमाल हो रहा है। विचार सीधा है: ब्राउज़र से 2D content रेंडर करवाएँ, पिक्सल वापस पढ़ें, और उन्हें hash कर लें। एक ही instructions के लिए अलग-अलग डिवाइस थोड़े अलग पिक्सल बनाते हैं, और वे अंतर इतने स्थिर होते हैं कि एक डिवाइस को कई sessions में पहचाना जा सके।
इतना तो सर्वविदित है। जो कम समझा जाता है वह यह है कि यह तकनीक काम क्यों करती है — एक जैसे hardware पर एक जैसी software configuration भी अलग पिक्सल output क्यों देती है। इसका उत्तर GPU drivers, font rendering और floating-point अंकगणित के संगम पर बैठता है।
रेंडरिंग पाइपलाइन deterministic नहीं है
जब JavaScript context.fillText("Cwm fjord bank glyphs vext quiz", 4, 45) को कॉल करता है, तो Chrome खुद पिक्सल रेंडर नहीं करता। यह Skia — 2D graphics लाइब्रेरी — के लिए instructions बनाता है, जो बदले में किसी GPU-accelerated backend (आमतौर पर Windows पर ANGLE, macOS पर Metal, या containers में software fallback) को drawing commands जारी करता है।
हर चरण पर छोटे-छोटे implementation अंतर जमा होते जाते हैं:
-
Skia का font subsystem एक font family चुनता है। अगर Arial इंस्टॉल नहीं है, तो यह fallback करता है — और fallback सिस्टम में इंस्टॉल fonts के अनुसार बदलता है।
-
चुना गया font अनुरोधित आकार पर FreeType (Linux पर), DirectWrite (Windows पर), या Core Text (macOS पर) का उपयोग करके रेंडर किया जाता है। हर लाइब्रेरी के hinting algorithms अलग हैं।
-
Subpixel positioning लागू की जाती है। यहीं से एक जैसे fonts अलग पिक्सल बनाने लगते हैं — algorithm positions को भिन्नात्मक पिक्सल offsets पर round करता है, और rounding के नियम platforms के बीच अलग होते हैं।
-
Rasterized text को canvas पर composite किया जाता है। Hardware-accelerated सिस्टम पर blending GPU shaders से होती है, और fallback mode में CPU code से।
इनमें से हर चरण एक या दो पिक्सल मानों का अंतर ला सकता है। अलग-अलग देखें तो अदृश्य। मिलाकर देखें तो अद्वितीय।
GPU driver versions fingerprint पर हावी रहते हैं
Intel UHD Graphics 620 चिप वाली दो Windows 11 मशीनें अलग canvas output दे सकती हैं अगर उनके GPU drivers अलग हों। Intel साल में कई बार driver updates जारी करता है, और हर update subpixel filtering, gamma correction और text anti-aliasing को बदल सकता है।
इसका मतलब है कि canvas fingerprint की स्थिरता driver update की आवृत्ति से सीमित होती है। जो उपयोगकर्ता अपना graphics driver अपग्रेड करता है — अक्सर चुपचाप, Windows Update के जरिए — उसका canvas fingerprint बदल जाएगा।
Detection सिस्टम इससे इस तरह निपटते हैं कि वे canvas fingerprint को कई संकेतों में से एक मानते हैं, न कि एक स्वतंत्र पहचानकर्ता। जब यह बदलता है पर बाकी संकेत स्थिर रहते हैं (TLS fingerprint, WebGL renderer, timezone, इंस्टॉल किए गए fonts), तब भी visitor पहचान लिया जाता है।
Emoji rendering एक सोने की खान है
Canvas fingerprint का सबसे अधिक पहचान-योग्य तत्व अक्सर text या आकृतियाँ नहीं बल्कि emoji होता है। Emoji rendering OS के साथ आने वाले emoji font पर निर्भर करता है — Windows पर Segoe UI Emoji, macOS पर Apple Color Emoji, Android पर Noto Color Emoji।
एक ही OS के भीतर भी, emoji rendering versions के अनुसार बदलता है। Windows 10 का rainbow emoji रेंडर करने का तरीका Windows 11 से अलग है। iOS 16 के grinning face का anti-aliasing iOS 17 से अलग है।
आधुनिक canvas fingerprinting scripts खासतौर पर emoji के अनुक्रम रेंडर करती हैं, जिनमें Unicode में हाल में जोड़े गए emoji भी शामिल होते हैं। जो visitor iPhone Safari चलाने का दावा करता है पर iOS 17 में जोड़ा गया कोई emoji रेंडर नहीं कर पाता, वह या तो पुराना iOS चला रहा है — या platform के बारे में झूठ बोल रहा है।
Automation frameworks विशिष्ट fingerprints पैदा करते हैं
Headless Chrome, जो बिना GPU के Docker container में चलता है, रेंडरिंग के लिए SwiftShader का उपयोग करता है। SwiftShader ऐसे canvas outputs बनाता है जो आंतरिक रूप से सुसंगत होते हैं पर किसी भी hardware-accelerated Chrome से अलग होते हैं।
यह signature पहचानने योग्य है: असामान्य रूप से साफ anti-aliasing, gradient क्षेत्रों में विशिष्ट color values, और ऐसे text edges जो किसी ज्ञात GPU driver से मेल नहीं खाते। Linux container में Chrome 124 में SwiftShader से मेल खाने वाला canvas fingerprint लगभग निश्चित रूप से automation है — कोई असली उपयोगकर्ता ब्राउज़र इस तरह नहीं चलाता।
Puppeteer-extra-stealth toDataURL() को intercept करके और संशोधित data लौटाकर canvas output को spoof करने की कोशिश करता है। पर यह संशोधन अक्सर अपने ही artifacts ले आता है — noise के ऐसे पैटर्न जो sessions में दोहराते हैं, जो विरोधाभासी रूप से anti-fingerprinting के इस प्रयास को कुछ न करने की तुलना में अधिक पकड़ में आने योग्य बना देते हैं।
Noise injection ठीक से काम क्यों नहीं करता
Brave जैसे प्राइवेसी-केंद्रित ब्राउज़र ट्रैकिंग रोकने के लिए canvas output में noise inject करते हैं। विचार यह है कि पिक्सल मानों में छोटे यादृच्छिक बदलाव जोड़े जाएँ ताकि एक ही डिवाइस हर session में अलग fingerprints पैदा करे।
व्यवहार में, noise injection की तीन समस्याएँ हैं:
1. Noise खुद एक fingerprint है। जिस visitor का canvas output हर load पर बदलता है, पर बाकी संकेत एक जैसे रहते हैं, वह एक noise-inject करने वाले ब्राउज़र के रूप में पहचाना जा सकता है। वह अपने आप में पहचान-योग्य है।
2. Noise algorithm स्थिर है। Brave का implementation विशिष्ट noise पैटर्न पैदा करता है जो GPU rendering की स्वाभाविक भिन्नता से मेल नहीं खाते। Detection सिस्टम पहचान सकते हैं कि कौन-से canvas outputs noise-injected दिखते हैं और कौन-से स्वाभाविक।
3. परिष्कृत सिस्टम samples को जोड़ते हैं। एक ही पेज पर, या कई sessions में लिए गए कई renders का औसत निकाला जा सकता है। अगर noise छोटा है, तो औसत अंतर्निहित deterministic fingerprint पर आ जाता है।
Canvas fingerprinting क्या-क्या पकड़ता है
स्पष्ट दृश्य output के अलावा, canvas fingerprinting side effects के रूप में डिवाइस की कई विशेषताएँ निकाल सकता है:
Rendering time — canvas को रेंडर होने में कितना समय लगता है, यह GPU क्षमता को उजागर करता है। एक discrete GPU वाला 4K डेस्कटॉप एक मध्यम-श्रेणी के लैपटॉप की तुलना में तेज़ी से रेंडर करता है।
Text metrics — measureText() सटीक पिक्सल चौड़ाई लौटाता है जो font rendering के अनुसार बदलती है। Text की चौड़ाई को बिना रेंडर किए भी fingerprint के रूप में इस्तेमाल किया जा सकता है।
Composite operation support — कुछ ब्राउज़र या GPU configurations विस्तारित composite modes का समर्थन करते हैं। समर्थन की जाँच करने से क्षमता की सीमाएँ उजागर होती हैं।
Filter effects — canvas पर लागू CSS-शैली के filters अलग-अलग GPUs में अलग outputs देते हैं, खासकर blur और drop-shadow filters।
Detection stack में canvas fingerprinting कहाँ फिट होता है
अकेले, canvas fingerprinting एक मजबूत पहचानकर्ता नहीं है। Drivers बदलते हैं। उपयोगकर्ता ब्राउज़र बदलते हैं। प्राइवेसी-केंद्रित दर्शकों में noise injection आम है।
इसकी असली ताकत एक cross-check के रूप में है। जब कोई session cookies या account login के आधार पर लौटने वाला उपयोगकर्ता होने का दावा करता है, तो canvas fingerprint एक दूसरे संकेत के रूप में काम करता है — ऐतिहासिक fingerprint से मेल खाना दावे की पुष्टि करता है, मेल न खाना account takeover या session hijacking को चिह्नित करता है।
Bot detection के लिए, canvas fingerprinting containerized automation पकड़ने में उत्कृष्ट है। असली उपयोगकर्ताओं के पास असली GPUs होते हैं। असली GPUs पहचानने योग्य rendering signatures पैदा करते हैं। जो कुछ भी SwiftShader की तरह, या किसी बुरी तरह spoof किए गए canvas की तरह रेंडर होता है, वह लगभग निश्चित रूप से bot वाली श्रेणी में बैठता है।
2012 की तकनीक 2026 में भी उसी कारण से काम करती है: रेंडरिंग हर environment में deterministic होती है पर पूरी तरह spoof करना लगभग असंभव है। छिपाने का हर प्रयास खुद उस प्रयास के निशान छोड़ जाता है।