ब्राउज़र फ़िंगरप्रिंट एक्सपोज़र जाँच: संगति के छह परीक्षण

किसी भी ब्राउज़र फ़िंगरप्रिंट टेस्ट पेज को खोलें तो आपको फ़ील्ड की लंबी सूची दिखेगी: UA, स्क्रीन, टाइम ज़ोन, फ़ॉन्ट, Canvas रेंडरिंग परिणाम और हार्डवेयर पैरामीटर। अधिकतर लोग पहले “uniqueness” पर ध्यान देते हैं, जबकि वास्तव में वही सबसे कम महत्वपूर्ण है। अधिक महत्वपूर्ण यह है कि ये सभी फ़ील्ड एक-दूसरे से मेल खाते हैं या नहीं।

वेबसाइटें सामान्य रूप से क्या पढ़ सकती हैं

फ़िंगरप्रिंट cookie की तरह संग्रहीत नहीं होता। Cookie को आप मिटा सकते हैं, ब्लॉक कर सकते हैं या private browsing से उससे बच सकते हैं; फ़िंगरप्रिंट ब्राउज़र और डिवाइस की अपनी कॉन्फ़िगरेशन से बनता है। UA में ब्राउज़र का प्रकार और संस्करण, साथ ही ऑपरेटिंग सिस्टम और उसका संस्करण शामिल होता है। इसके अलावा इंस्टॉल किए गए plugins, स्क्रीन resolution और color depth, फ़ॉन्ट सूची, time zone और पसंदीदा भाषा, CPU प्रकार, GPU मॉडल और memory, IP पता, ISP और connection type, तथा Canvas और WebGL जैसे HTML5 interfaces के rendering परिणाम भी शामिल होते हैं। ये फ़ील्ड मिलकर एक identifier बनाते हैं जो IP बदलने, cookies साफ़ करने या private mode इस्तेमाल करने पर भी सामान्यतः नहीं बदलता। प्लेटफ़ॉर्म खातों के बीच संभावित संबंध पहचानने के लिए इसी मूल सिद्धांत का उपयोग करते हैं।

पहले तीन चीज़ों का सिस्टम से मिलान करें

User Agent से शुरुआत करना सबसे उपयोगी है, क्योंकि इसी से ब्राउज़र अपना परिचय देता है। टेस्ट पेज से UA कॉपी करें, browser settings में browser version जाँचें और system settings में operating system version देखें। यदि UA में बताया गया system या kernel version वास्तविक मशीन से मेल नहीं खाता, या सामान्य वर्तमान versions से स्पष्ट रूप से पीछे है, तो यह सबसे आसानी से पकड़े जाने वाले विरोधाभासों में से एक है।

Time zone को network exit की region से मेल खाना चाहिए। Test page आम तौर पर current time zone सीधे दिखाता है, और time zone पढ़ने वाला एक सरल script भी वही value देता है। किसी भी IP lookup page से यह भी देखें कि exit IP किस region से जुड़ा है। यदि दोनों अलग क्षेत्रों की ओर इशारा करते हैं, तो यह mismatch ठीक करने योग्य है।

Language और region अलग-अलग कमजोर संकेत हैं, लेकिन साथ में उपयोगी हो जाते हैं। navigator.language और navigator.languages द्वारा लौटाई गई सूची देखें और उसे exit region में सामान्य भाषाओं से मिलाएँ। यदि time zone अमेरिका का हो, language चीनी हो और exit यूरोप में हो, तो यह संयोजन किसी एक संकेत की तुलना में अधिक स्पष्ट दिखता है।

स्क्रीन, नेटवर्क एग्ज़िट और रेंडरिंग विशेषताएँ

Screen और hardware parameters में दो बातें देखें: ये values कितनी सामान्य हैं, और क्या वे UA द्वारा बताए गए device type से मेल खाती हैं। Resolution, pixel ratio, available area, CPU cores और memory को साथ देखकर जाँचा जा सकता है। फ़ोन-जैसी resolution के साथ desktop UA एक सामान्य विरोधाभास है।

WebRTC को अलग से जाँचना चाहिए, क्योंकि यह वास्तविक network information उजागर कर सकता है। Test pages आम तौर पर इसे अलग item के रूप में दिखाते हैं। देखें कि क्या local network address लौटता है, जैसे 192.168 या 10 से शुरू होने वाला पता, या वास्तविक public exit address ही दिखाई देता है। Proxy चालू होने पर भी वास्तविक address दिखे तो उस traffic का proxy से न गुजरना स्पष्ट है। इसे सबसे अधिक प्राथमिकता देनी चाहिए।

Canvas और WebGL के लिए देखें कि लौटे हुए results स्थिर हैं या नहीं और घोषित GPU model से मेल खाते हैं या नहीं। एक महत्वपूर्ण बात यह है कि एक ही मशीन पर साथ-साथ चल रहे कई environments यदि बिल्कुल समान rendering values लौटाएँ, तो उन्हें आपस में जोड़ना उन values की तुलना में आसान हो सकता है जिनमें कुछ variation या noise हो।

विरोधाभास, कम यथार्थवादी मान से अधिक दिखाई देते हैं

प्लेटफ़ॉर्म यह अपेक्षा नहीं करते कि हर device पूरी तरह unique हो। वे यह देखते हैं कि पूरी जानकारी किसी सामान्य मशीन से आई हुई लगती है या नहीं। कोई एक कम “realistic” value, जैसे दुर्लभ resolution, आम तौर पर केवल कमजोर संकेत है। लेकिन जब कई fields एक-दूसरे से टकराते हैं, तो mismatch पकड़ना बहुत आसान हो जाता है। UA Windows बताता है लेकिन font list macOS जैसी है; time zone अमेरिका का है, language चीनी है और exit यूरोप में है; resolution फ़ोन जैसी है लेकिन UA desktop browser बताता है। इनमें से कोई भी संयोजन बाकी parameters की महीन tuning को कम उपयोगी बना सकता है। इसलिए self-check में पहले स्पष्ट विरोधाभास ढूँढें और उसके बाद parameters की बारीकियों पर जाएँ।

अगर केवल तीन चीज़ें ठीक करनी हों

पहले WebRTC leak को देखें, क्योंकि यह वास्तविक network information उजागर करता है। दूसरे, time zone और language को exit region से संगत रखें, क्योंकि ऐसे mismatches मिलकर आसानी से असामान्य profile बना सकते हैं। तीसरे, Canvas और WebGL को इस तरह संभालें कि वही मशीन सीधे एक स्थिर और unique rendering value उजागर न करे।

एक व्यावहारिक सीमा भी है: JavaScript को बंद या सीमित करने से कुछ collection रुक सकती है, लेकिन इससे कई websites की usability स्पष्ट रूप से घटती है। Privacy browsers में कुछ built-in protections होते हैं और वे रोज़मर्रा की browsing के लिए अक्सर पर्याप्त होते हैं, पर लंबे समय तक कई असंबंधित identities बनाए रखने की स्थिति में वे कम लचीले पड़ सकते हैं।

कई environments कैसे बनाए रखें

लक्ष्य हर बार पूरी तरह random fingerprint बनाना नहीं है। हर environment को अपने भीतर स्थिर और दूसरे environments से अलग रहना चाहिए। PurpleMark में हर account के लिए अलग browser environment बनाएं, Canvas जैसे parameters को अलग से संभालें, और फिर fingerprint test page पर हर environment की internal consistency जाँचें। जो environment यह self-check पास करे, वही लंबे समय तक बनाए रखने के योग्य है।

अंततः fingerprint testing के केवल दो उद्देश्य हैं: यह देखना कि आप क्या उजागर कर रहे हैं और यह पुष्टि करना कि पूरी जानकारी आपस में संगत है। Uniqueness वह चीज़ है जिसके बारे में सबसे कम चिंता करनी चाहिए।