UserAgent कंसिस्टेंसी कैसे चेक करें? UA मिसमैच से उजागर होने वाली चार गड़बड़ियाँ

डिटेक्शन साइट पर UA वाला कॉलम सामान्य दिखता है, फिर भी अकाउंट लॉगिन होने के कुछ ही दिनों में वेरिफ़िकेशन आ जाता है। कई लोगों का पहला रिएक्शन होता है कि दूसरा UA लगा लें, या UA बदलने वाला एक और एक्सटेंशन इंस्टॉल कर लें। नतीजा उलटा होता है: एब्नॉर्मलिटी पहले से ज़्यादा बार दिखने लगती है।

ऐसा ज़्यादातर कंसिस्टेंसी की वजह से होता है। UA एक फ़ील्ड है, लेकिन प्लेटफ़ॉर्म इसे पढ़ने की जगहें एक से कम नहीं हैं। अगर आप सिर्फ़ एक जगह बदलें और बाकी जगहों पर पुरानी वैल्यू रह जाए, तो तुलना होते ही मतभेद सामने आ जाता है।

UA चेक का पहला कदम यह देखना है कि यह फ़ील्ड हर एक्सपोज़र पॉइंट पर एक ही बात कह रहा है या नहीं, उसके बाद ही यह जाँचने की बारी आती है कि वह डिवाइस, रीजन जैसे पैरामीटर से मैच करता है या नहीं। इस लेख में पहले वे तीन चैनल समझाए गए हैं जिनसे प्लेटफ़ॉर्म UA पढ़ता है, फिर मिसमैच से उजागर होने वाले चार तरह के सिग्नल गिनाए गए हैं। आखिर में पाँच चेकपॉइंट की जाँच सूची और फ़िंगरप्रिंट ब्राउज़र में कॉन्फ़िगरेशन का तरीका दिया गया है।

प्लेटफ़ॉर्म UA पढ़ने के तीन चैनल

एक ही UA वैल्यू को प्लेटफ़ॉर्म असल में तीन जगहों से पढ़ता है: HTTP रिक्वेस्ट हेडर, Client Hints हेडर, पेज स्क्रिप्ट। तीनों चैनल एक-दूसरे से अलग हैं और हर एक की अलग से जाँच हो सकती है।

रिक्वेस्ट भेजते समय हेडर में मौजूद UA स्ट्रिंग सबसे पहला चैनल है; साइट को पेज मिलने से पहले ही वह इसे पढ़ लेती है। Chrome ने वर्शन 89 से डिवाइस की जानकारी को Sec-CH-UA सीरीज़ के हेडर में अलग से भेजना शुरू किया। ब्राउज़र ब्रांड, प्लेटफ़ॉर्म और प्लेटफ़ॉर्म वर्शन, तीनों के अलग हेडर हैं, जिन्हें साइट ज़रूरत के हिसाब से पूछती है। MDN का Client Hints दस्तावेज़ इन हेडर का स्ट्रक्चर बहुत साफ़ तौर पर समझाता है।

तीसरा चैनल पेज स्क्रिप्ट में है। navigator.userAgent और navigator.userAgentData पेज के अंदर से ब्राउज़र और प्लेटफ़ॉर्म की जानकारी एक बार फिर रिपोर्ट करते हैं। सिद्धांत रूप में तीनों रीडिंग अक्षरशः एक समान होती हैं। किसी एक जगह को अकेले बदला जाए, तो बाकी दो जगहें उसके साथ नहीं बदलतीं।

UA बदलने वाले एक्सटेंशन की दिक्कत ठीक यहीं है। ज़्यादातर एक्सटेंशन सिर्फ़ रिक्वेस्ट हेडर की UA स्ट्रिंग बदलते हैं; पेज स्क्रिप्ट से पढ़ने पर पुरानी वैल्यू ही मिलती है, यानी दो चैनल की रीडिंग उसी वक़्त टकराने लगती है। ऐसा मतभेद पकड़ने के लिए कोई ऊँचा तकनीकी स्तर नहीं चाहिए। रिस्क कंट्रोल स्क्रिप्ट दो जगहों की रीडिंग लेकर तुलना कर ले, बस।

एक बैकग्राउंड बात और जान लें। Chrome पुराने UA स्ट्रिंग की जानकारी धीरे-धीरे फ़्रीज़ कर रहा है: वर्शन नंबर का पिछला हिस्सा अब फ़िक्स हो चुका है और ज़्यादा डिटेल Client Hints में शिफ़्ट हो गई है। सिर्फ़ UA स्ट्रिंग पर काम करने की गुंजाइश सिमट रही है। इसके उलट, चैनल आपस में मैच करते हैं या नहीं, यह दिन-ब-दिन ज़्यादा अहम होता जा रहा है।

UA मिसमैच क्या उजागर करता है: चार तरह के सिग्नल

UA अकेले देखने पर सही-ग़लत का फ़र्क़ नहीं पड़ता; सिग्नल कॉम्बिनेशन में रखने पर ही गड़बड़ी सामने आती है। एनवायरनमेंट में दिक्कत होने पर मिसमैच ज़्यादातर नीचे दी गई चार श्रेणियों में आता है।

पहली श्रेणी, चैनल आपस में टकराना। रिक्वेस्ट हेडर Chrome 126 बताता है और पेज स्क्रिप्ट की रीडिंग अब भी Chrome 118 पर अटकी है; या Sec-CH-UA में घोषित ब्रांड navigator.userAgentData की रिपोर्ट से मेल नहीं खाता। ऐसी रीडिंग का लगभग एक ही मतलब बनता है। UA को अकेले बदला गया था, और बदलाव सारे चैनल तक नहीं पहुँचा।

दूसरी श्रेणी, घोषणा और हार्डवेयर पैरामीटर में टकराव। UA में iPhone लिखा है, पर स्क्रीन 1920×1080 का डेस्कटॉप रेज़ोल्यूशन है और टच पॉइंट ज़ीरो हैं; UA Windows घोषित करता है, पर GPU रेंडरर ऐप्पल चिप बताता है। हार्डवेयर पैरामीटर असली एनवायरनमेंट से पढ़ी गई मेज़रमेंट वैल्यू होती हैं, जबकि UA मनचाहे भरे जाने वाले घोषणा-पत्र जैसा है। दोनों की तुलना करने पर गड़बड़ी UA से कहीं ज़्यादा साफ़ दिखती है। इस तरह के टकराव की वजहें फ़िंगरप्रिंट रैंडमाइज़ेशन असुरक्षित क्यों है में पैरामीटर दर पैरामीटर समझाई गई हैं।

तीसरी श्रेणी, एनवायरनमेंट कॉम्बिनेशन से टकराव। आउटगोइंग IP अमेरिका का है, पर UA चीनी वर्शन का ब्राउज़र है और भाषा सूची व टाइमज़ोन भी किसी दूसरे रीजन की ओर झुके हुए हैं। UA, सिस्टम, भाषा, टाइमज़ोन और IP का एक ही रीजनल प्रोफ़ाइल बनाना चाहिए। एक भी चीज़ इधर-उधर हो जाए, तो पूरा प्रोफ़ाइल संदिग्ध लगने लगता है। ऐसा टकराव UA बदलकर ठीक नहीं होता; बदलनी पड़ती है एनवायरनमेंट कॉन्फ़िगरेशन।

चौथी श्रेणी, ट्रांसपोर्ट लेयर विशेषताओं से मेल न खाना। TLS हैंडशेक के निशान स्क्रिप्ट टूल जैसे या बहुत पुराने ब्राउज़र वर्शन जैसे लगते हैं, जबकि रिक्वेस्ट हेडर नया Chrome वर्शन बताता है। ट्रांसपोर्ट लेयर की विशेषताएँ UA से भी मुश्किल से छिपती हैं। प्लेटफ़ॉर्म दोनों को मिलाना चाहे तो उसकी लागत बहुत कम है।

चार सिग्नल में से पहली तीन श्रेणियाँ एनवायरनमेंट कॉन्फ़िगरेशन के दौरान ही टाली जा सकती हैं। चौथी श्रेणी कनेक्शन तरीके पर निर्भर करती है। रोज़ की सेल्फ़-चेक में पहली तीनों पर नज़र रखें और रीडिंग में मतभेद दिखते ही वापस कॉन्फ़िगरेशन ताली करें।

कंसिस्टेंसी चेक कैसे करें: पाँच चेकपॉइंट

जाँच किसी एक साइट पर निर्भर नहीं; पाँच चेकपॉइंट क्रम से पार करें।

1. चैनल तुलना: एनवायरनमेंट से डिटेक्शन पेज खोलें, डेवलपर टूल्स के Network पैनल से रिक्वेस्ट हेडर की UA और Sec-CH-UA देखें, फिर कंसोल की navigator.userAgent रीडिंग से मिलाएँ; तीनों जगह एक समान होनी चाहिए।

2. हार्डवेयर तुलना: UA में घोषित डिवाइस टाइप को स्क्रीन रेज़ोल्यूशन, टच क्षमता, GPU रेंडरर, कोर संख्या और मेमोरी से एक-एक कर मिलाएँ; जो डिवाइस घोषित है, मेज़रमेंट वैल्यू उसी जैसी होनी चाहिए।

3. रीजन तुलना: UA की भाषा, ब्राउज़र की भाषा सूची, टाइमज़ोन और आउटगोइंग IP एक ही रीजनल प्रोफ़ाइल में हों; मोबाइल डिवाइस की घोषणा को मोबाइल नेटवर्क की विशेषताओं से भी मेल खाना चाहिए।

4. वर्शन तुलना: UA का ब्राउज़र वर्शन टारगेट मार्केट के मेनस्ट्रीम रेंज में हो; बहुत नया या सालों पुराना वर्शन दोनों ही एब्नॉर्मल सिग्नल हैं, और वर्शन को इंजन के व्यवहार से भी मेल खाना चाहिए।

5. री-चेक रिकॉर्ड: कॉन्फ़िगरेशन बदलने के बाद डिटेक्शन पेज दोबारा पार करें और हर बार की रीडिंग सहेज लें; अगली बार एनवायरनमेंट में दिक्कत आए, तो यही रिकॉर्ड पड़ताल की शुरुआत बनेंगे।

टूल्स की बात करें, तो CreepJS पेज स्क्रिप्ट की रीडिंग और ब्राउज़र के दावे के बीच के मतभेद इकट्ठा करने में माहिर है; इससे UA बदले हुए एनवायरनमेंट की जाँच करेंगे, तो चैनलों का टकराव सीधे उभर आएगा। Browserscan जैसी कॉम्प्रिहेंसिव डिटेक्शन साइटें पाँचों पैरामीटर की कुल रीडिंग के लिए ठीक हैं। दोनों तरह के टूल साथ में इस्तेमाल करें। UA सिर्फ़ एनवायरनमेंट कंसिस्टेंसी का एक सिग्नल है। पूरे एनवायरनमेंट की जाँच का क्रम, एंटी-असोसिएशन कंसिस्टेंसी चेक वाले लेख में छह आइटम की चेक टेबल दी गई है, जिसे यहाँ के पाँच चेकपॉइंट के साथ मिलाकर इस्तेमाल किया जा सकता है।

फ़िंगरप्रिंट ब्राउज़र में UA को मैच कराना

पाँचों चेकपॉइंट के हिसाब से अलग-अलग बदलने की बजाय सबसे कारगर तरीका यह है कि UA और संबंधित पैरामीटर एक साथ जनरेट हों, न कि हर एक को हाथ से भरना पड़े। MostMate शुरुआती लोगों के लिए फ़्रेंडली एक AI फ़िंगरप्रिंट ब्राउज़र है, जो हर अकाउंट के लिए अलग ब्राउज़र एनवायरनमेंट तैयार करता है; UA की कंसिस्टेंसी ठीक उसके एनवायरनमेंट कॉन्फ़िगरेशन फ़्लो में ही संभलती है। शुरू करने से पहले MostMate प्रोडक्ट पेज पर पूरा क्रिएशन फ़्लो एक बार देख सकते हैं।

एनवायरनमेंट बनाते समय पहले ऑपरेटिंग सिस्टम और ब्राउज़र वर्शन चुनें, User-Agent उसी के साथ जनरेट हो जाता है, और ज़रूरत पड़े तो एडिट भी किया जा सकता है। भाषा सेटिंग, टाइमज़ोन सेटिंग और जियोलोकेशन, तीनों की डिफ़ॉल्ट सेटिंग "IP के आधार पर कॉन्फ़िगर करें" है। आउटगोइंग प्रॉक्सी चुनते ही ये चीज़ें UA के रीजनल कॉम्बिनेशन से अपने-आप मैच हो जाती हैं। फ़िंगरप्रिंट प्रीव्यू पैनल User-Agent और बाकी पैरामीटर की मौजूदा वैल्यू रीयल टाइम में दिखाता है। एनवायरनमेंट बनाने के चरण में ही पता चल जाता है कि पूरा कॉन्फ़िगरेशन आपस में टिकता है या नहीं; एनवायरनमेंट चलने के बाद वापस आकर बदलने की दरकार नहीं पड़ती।

कॉन्फ़िगरेशन का ग्रैन्युलैरिटी भी आप खुद तय कर सकते हैं। मैन्युअल फ़िंगरप्रिंट सेटिंग में UA, स्क्रीन, टाइमज़ोन, भाषा समेत ग्यारह आइटम एक-एक कर चुनने पड़ते हैं, जबकि ऑफ़िशियल होमपेज की रिकमेंडेड कॉन्फ़िगरेशन डिवाइस लॉजिक के हिसाब से सीधे एक सुसंगत एनवायरनमेंट जनरेट कर देती है। दोनों रास्तों के अपने उपयोग के दृश्य हैं।

एक बाउंड्री बात साफ़ कर लें। UA और एनवायरनमेंट कॉन्फ़िगरेशन की कंसिस्टेंसी सिर्फ़ एक तरह के एक्सपोज़र सिग्नल कम करती है। अकाउंट को प्लेटफ़ॉर्म द्वारा जोड़ा जाएगा या नहीं, यह प्लेटफ़ॉर्म के नियमों, अकाउंट्स के रिश्तों और इस्तेमाल के तरीके पर भी निर्भर करता है; एनवायरनमेंट कॉन्फ़िगरेशन सिर्फ़ एनवायरनमेंट वाली परत संभालता है।

अक्सर पूछे जाने वाले सवाल

UA बदलने वाला एक्सटेंशन इंस्टॉल करने के बाद पहचान और आसान क्यों हो जाती है?

एक्सटेंशन आम तौर पर सिर्फ़ रिक्वेस्ट हेडर वाला चैनल बदलता है; पेज स्क्रिप्ट और Client Hints को अब भी पुरानी वैल्यू मिलती है। चैनलों के बीच मतभेद उभरते ही यह रीडिंग में लिखा हुआ दिखने लगता है कि UA बदला गया है। मतभेद खुद ही एब्नॉर्मल सिग्नल है, न बदलने से भी ज़्यादा चुभता हुआ।

UA वर्शन नंबर जितना नया हो, उतना बेहतर है क्या?

टारगेट मार्केट के मेनस्ट्रीम वर्शन रेंज में रहना काफ़ी है। लेटेस्ट वर्शन से भी नया वर्शन या सालों पुराना वर्शन, दोनों ही एब्नॉर्मल सिग्नल हैं। वर्शन को इंजन के व्यवहार से भी मेल खाना चाहिए; अकेले नए वर्शन के पीछे भागने का कोई मतलब नहीं।

क्या डेस्कटॉप एनवायरनमेंट में मोबाइल UA इस्तेमाल कर सकते हैं?

हाँ, लेकिन स्क्रीन रेज़ोल्यूशन, टच क्षमता, डिवाइस मेमोरी जैसे पैरामीटर भी मोबाइल डिवाइस के हिसाब से एक साथ सेट करने होंगे। पैरामीटर कैसे लिंक होते हैं, इसकी ठोस तुलना स्क्रीन रेज़ोल्यूशन और विंडो साइज़ फ़िंगरप्रिंट में दी गई है।

डिटेक्शन साइट पर UA कंसिस्टेंट दिख रहा है, तो क्या कोई दिक्कत नहीं है?

डिटेक्शन साइट की रीडिंग ज़्यादातर पेज स्क्रिप्ट से पढ़े जा सकने वाले पैरामीटर तक सीमित होती है; ट्रांसपोर्ट लेयर की विशेषताएँ और कुछ Client Hints डिटेल रीडिंग में शामिल नहीं भी हो सकती हैं। पाँचों चेकपॉइंट पार करने के बाद नतीजा निकालना ज़्यादा भरोसेमंद है।

निष्कर्ष

UA चेक का असली लक्ष्य यह है कि तीनों चैनल और पूरा एनवायरनमेंट आपस में टिकें। चैनल आपस में न टकराएँ, घोषणा और हार्डवेयर मेज़रमेंट मेल खाएँ, रीजनल कॉम्बिनेशन समझ में आए और वर्शन रेंज सामान्य लगे। पाँचों चेकपॉइंट क्रम से पार कर लें, तो UA लेयल की ज़्यादातर गड़बड़ियाँ एनवायरनमेंट लाइव होने से पहले ही निकल जाती हैं। जाँच लॉन्च से पहले करें, लागत सबसे कम रहती है।

नए एनवायरनमेंट को अकाउंट अंदर भेजने से पहले इस जाँच से एक बार पार करा लेना, वेरिफ़िकेशन आने के बाद वापस जा कर UA बदलने से कहीं आसान है। इसी फ़्लो से एनवायरनमेंट मैनेज करना चाहें, तो MostMate डाउनलोड करें; सिस्टम चुनने से लेकर प्रॉक्सी सेट करने और फ़िंगरप्रिंट प्रीव्यू ताली करने तक, UA और पूरा एनवायरनमेंट एक ही बार में सेट कर लें।