फिंगरप्रिंट ब्राउज़र पहचानने की प्रायोगिक विधियाँ: संस्करण दावे से व्यवहार सत्यापन तक

ब्राउज़र फिंगरप्रिंट का पता लगाया जा सकता है या नहीं, इस बारे में बाज़ार में कई दावे हैं और उनमें से अधिकांश केवल निष्कर्ष तक सीमित रहते हैं। कौन जीतता है या हारता है, इस पर बहस करने के बजाय यह देखना अधिक उपयोगी है कि शोधकर्ताओं ने इस प्रश्न को दोहराए जा सकने वाले प्रयोग में कैसे बदला और निर्णय के लिए किन मापदंडों का उपयोग किया।

ACM Internet Measurement Conference (IMC) 2024 में प्रकाशित Browser Polygraph नामक अध्ययन Arizona State University, Boston University और Amazon के शोधकर्ताओं ने मिलकर किया; इसका DOI 10.1145/3646547.3688455 है। प्रयोगशाला में simulated data चलाने के बजाय इसे एक बड़ी वित्तीय कंपनी के वास्तविक production environment में 4.5 महीने तक तैनात किया गया और 205,000 वास्तविक user sessions को शामिल किया गया। दस सामान्य environment-masquerading solutions का परीक्षण हुआ और सामान्य user traffic को control के रूप में लिया गया।

प्रयोग कैसे तैयार किया गया

तीन design choices ने detection को पूरे traffic पर बिना business को प्रभावित किए लागू करना संभव बनाया।

Features को कम लागत वाला होना था। Detection केवल properties के एक निश्चित समूह को पढ़ता है और हर run का overhead milliseconds और KB के स्तर पर रहता है। इसलिए इसे sampling के बिना पूरे traffic पर चलाया जा सकता है और user को लगभग कोई प्रभाव महसूस नहीं होता।

Features को स्थिर होना था। ऐसे parameters नहीं चुने गए जिन्हें user बदल सके, बल्कि वे underlying structures चुने गए जिन्हें browser स्वयं तय करता है। हर browser version अलग JavaScript engine के साथ आता है, और versions के बीच API की संख्या तथा हर object से जुड़ी properties की संख्या में छोटे अंतर होते हैं। अध्ययन में Chrome 110 से Chrome 114 तक के range को तुलना के लिए इस्तेमाल किया गया: detection system ने 28 महत्वपूर्ण objects की properties गिनीं और परिणाम को browser द्वारा घोषित version से मिलाया। मेल न होने का अर्थ है कि declaration और वास्तविक behavior एक ही technical stack से नहीं आते।

Labels को विश्वसनीय होना था। हर tested environment को उसी production traffic से जोड़ा गया और उन्हीं rules से आंका गया, जबकि control group वास्तविक users के सामान्य behavior से बना था। इसलिए परिणाम यह नहीं बताता कि कोई चीज़ व्यक्तिपरक रूप से “असली जैसी दिखती” है या नहीं, बल्कि यह कि उसी rule set के तहत उस traffic को अलग पहचाना जा सकता है या नहीं।

यह तय करने के मापदंड कि simulation कितना वास्तविक है

अध्ययन में इस्तेमाल किए गए measurements को चार श्रेणियों में रखा जा सकता है।

• Consistency: क्या browser का घोषित version उसके underlying object structure से मेल खाता है? यह सबसे मुख्य और नकली बनाना सबसे कठिन metric है, क्योंकि केवल एक string बदलने से engine में objects और properties की संख्या अपने-आप नहीं बदलती।
• Detection rate: अध्ययन ने चार solutions पर विस्तृत प्रयोग किए और detection rate 67% से 84% के बीच रहा।
• वास्तविक devices से deviation: समान decision rules के तहत सामान्य browsers का risk score 0 था, जबकि tested solutions का औसत 8.85 से 11.66 के बीच रहा। यह score वास्तविक distribution से दूरी दिखाता है, न कि समानता की कोई व्यक्तिपरक धारणा।
• Distinguishability: क्या tested traffic को normal traffic से अलग किया जा सकता है? जिस श्रेणी को अलग नहीं किया जा सकता, वह इस method के तहत वास्तविक browsers से कोई स्पष्ट behavioral gap नहीं दिखाती।

चार metrics में पहला कारण है और बाकी तीन उसके परिणाम हैं।

चार प्रकार के परिणाम कहाँ अलग होते हैं

अध्ययन ने tested solutions को उनकी underlying implementation के आधार पर चार श्रेणियों में बाँटा।

पहली श्रेणी में low-level features किसी भी ज्ञात वास्तविक browser version से मेल नहीं खाते, यानी उनके अनुरूप कोई वास्तविक engine नहीं है। एक साधारण scan ही mismatch दिखा देता है।

दूसरी श्रेणी में environment में वास्तविक fingerprint features होते हैं, लेकिन identity बदलते समय केवल surface-level declaration बदलती है और underlying engine वही रहता है। अध्ययन में यही सबसे सामान्य pattern था। उदाहरण के लिए, business card पर नया version लिखा है लेकिन बोलने का लहजा अभी भी पुराना है। समस्या यह नहीं कि हर parameter कितना अच्छी तरह tune किया गया है, बल्कि declaration और behavior के बीच का gap है; detection का बड़ा हिस्सा इसी से आता है।

तीसरी श्रेणी में underlying engine identity के साथ बदलता है। Environment जिस version का दावा करता है, वही corresponding engine चलाता है, इसलिए consistency बनी रहती है और इस detector से traffic अलग नहीं किया जा सका। Paper यह भी बताता है कि इस श्रेणी को पहचानने के लिए अधिक जटिल detection methods चाहिए।

चौथी श्रेणी browser को बदलती ही नहीं। Virtual machine में वास्तविक browser चलाया जाता है और फिर target configuration load की जाती है। Browser सचमुच वास्तविक होने के कारण detector उसे अलग नहीं कर पाता, लेकिन operational cost बहुत अधिक होती है और इसे scale करना कठिन है।

चारों श्रेणियों का अंतर parameters की संख्या में नहीं, बल्कि इसमें है कि declaration और behavior एक ही technical base से आते हैं या नहीं।

Environment solution चुनने के व्यावहारिक संकेत

Detection का ध्यान declarations पढ़ने से behavior को validate करने की ओर जा चुका है, इसलिए बदले जा सकने वाले surface-level parameters का लाभ लगातार घट रहा है। व्यावहारिक मूल्यांकन में:

• Parameter list नहीं, underlying layer के बारे में पूछें। जब declared version बदले, तो क्या नीचे की layer भी बदलती है? Fingerprints वास्तविक combinations के रूप में automatically बनते हैं या values को manually जोड़कर तैयार किया जाता है?
• Environments की आपस में तुलना करें। यदि कई environments बहुत समान low-level features लौटाते हैं, तो isolation पूरी नहीं है।
• पहले consistency, फिर differentiation। जितने अधिक internally contradictory features tune किए जाएंगे, detection के लिए exposure surface उतना बड़ा होगा।
• किसी generic detection page को pass करना इस बात की गारंटी नहीं है कि platform environment को स्वीकार करेगा। अंतिम validation के लिए थोड़ी मात्रा में वास्तविक traffic से स्वयं परीक्षण करना चाहिए।

Environment isolation का मुख्य उद्देश्य हर environment को अपने-आप में अलग और internally consistent बनाना है। PurpleMark इसी समस्या पर काम करता है। Detection और anti-detection दोनों का उपयोग लागू compliance सीमाओं के भीतर होना चाहिए; इस अध्ययन का वास्तविक मूल्य अच्छी या बुरी products की ranking देना नहीं, बल्कि evaluation के लिए evidence-based आधार उपलब्ध कराना है।