User-Agent समझाया: UA स्ट्रिंग्स और ब्राउज़र फिंगरप्रिंट से लेकर Client Hints तक

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

यह हेडर को डिवाइस आईडी के रूप में मानने के लिए आकर्षक बनाता है - या यह मानने के लिए कि एक पंक्ति को बदलने से ब्राउज़र एक अलग डिवाइस में बदल सकता है। दोनों विचार केवल आंशिक रूप से सही हैं।

एक User-Agent स्ट्रिंग, या UA, क्लाइंट द्वारा घोषित संगतता जानकारी है। यह एक विश्वसनीय पहचान क्रेडेंशियल नहीं है, और एक ग्राहक इसे संशोधित कर सकता है। फिर भी यह अलगाव में मौजूद नहीं है। एक साइट UA की तुलना Client Hints, JavaScript एपीआई, स्क्रीन गुणों, फ़ॉन्ट, Canvas, WebGL, नेटवर्क संदर्भ और व्यवहार से कर सकती है। इसलिए उपयोगी प्रश्न केवल यह नहीं है कि क्या UA को बदला जा सकता है, बल्कि ब्राउज़र की पूर्ण अवलोकन योग्य सतह में इसकी क्या भूमिका है।

यह आलेख चार प्रश्नों के उत्तर देने के लिए HTTP मानकों और ब्राउज़र-फ़िंगरप्रिंटिंग अनुसंधान का उपयोग करता है:

1. एक UA स्ट्रिंग ब्राउज़र पुरातत्व के एक टुकड़े की तरह क्यों दिखती है?
2. पहचान करने वाली जानकारी UA कितना योगदान दे सकती है, और हमें शोध की व्याख्या कैसे करनी चाहिए?
3. केवल UA को बदलने से अधिक स्पष्ट असंगति क्यों पैदा हो सकती है?
4. UA Reduction और User-Agent Client Hints वास्तव में क्या बदल गए?

इस लेख में, UA मुख्य रूप से HTTP User-Agent अनुरोध शीर्षलेख का अर्थ है। हम JavaScript में navigator.userAgent और navigator.userAgentData पर भी चर्चा करते हैं। ये इंटरफेस संबंधित हैं लेकिन हर ब्राउज़र और संदर्भ में स्थायी रूप से समान नहीं हैं।

1. User-Agent क्या है?

RFC 9110 की धारा 10.1.5 User-Agent को एक ऐसे फ़ील्ड के रूप में परिभाषित करता है जिसमें अनुरोध उत्पन्न करने वाले उपयोगकर्ता एजेंट के बारे में जानकारी होती है. इसका सरलीकृत व्याकरण है:

User-Agent = product *( RWS ( product / comment ) )
product    = token [ "/" product-version ]

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

एक आधुनिक Chromium डेस्कटॉप UA इस तरह दिख सकता है:

Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/145.0.0.0 Safari/537.36

स्ट्रिंग को रिक्त स्थान से विभाजित करने से कई नाम प्रकट होते हैं जो Chrome से असंबंधित दिखाई देते हैं:

टोकन	आज इसका आम तौर पर क्या मतलब है	एक आम गलत रीडिंग
Mozilla/5.0	एक ऐतिहासिक संगतता टोकन	ब्राउज़र Firefox या Mozilla उत्पाद होना चाहिए
Windows NT 10.0	एक Windows प्लेटफ़ॉर्म श्रेणी; एक कम UA मज़बूती से 10 Windows 11 में अंतर नहीं कर सकता है	कंप्यूटर को 10 Windows चलना चाहिए
Win64; x64	एक सुराग है कि यह x86-64 आर्किटेक्चर पर 64-बिट Windows है	यह सटीक भौतिक सीपीयू मॉडल साबित करता है
AppleWebKit/537.36	एक इंजन-वंश और संगतता टोकन	Chrome अभी भी Safari के पूर्ण कार्यान्वयन का उपयोग करता है
KHTML, like Gecko	ऐतिहासिक संगतता भाषा	KHTML और Gecko दोनों चल रहे हैं
Chrome/145.0.0.0	Chrome/Chromium परिवार और प्रमुख संस्करण; निचले संस्करण घटकों को कम किया जा सकता है	यह सटीक पैच संस्करण का खुलासा करता है
Safari/537.36	पुरानी साइटों के साथ संगतता के लिए बनाए रखा गया टोकन	ब्राउज़र Safari होना चाहिए

UA वर्बोज़ बन गया क्योंकि शुरुआती वेबसाइटें अक्सर ब्राउज़र नामों पर शाखाएं होती थीं। नए ब्राउज़रों को सही पृष्ठ प्राप्त करने के लिए पुराने उत्पादों के साथ संगतता का दावा करना पड़ता था। ये घोषणाएँ समय के साथ जमा हुईं, जिससे एक ऐतिहासिक रिकॉर्ड बन गया जिसे शाब्दिक रूप से नहीं पढ़ा जा सकता है।

इसलिए पार्सिंग UA पहला नियम सरल है: **यह एक संगतता प्रोटोकॉल है, सख्त डिवाइस विवरण नहीं।

2. वेबसाइटें अभी भी UA का उपयोग क्यों करती हैं?

UA का उपयोग केवल ट्रैकिंग के लिए नहीं किया जाता है। वैध उपयोगों में शामिल हैं:

• एक ज्ञात संगतता समस्या के साथ एक पुराने ब्राउज़र के लिए एक फ़ॉलबैक की सेवा करना;
• एक उपयुक्त इंस्टॉलर या डाउनलोड प्रारूप का चयन करना;
• डायग्नोस्टिक लॉग में संस्करण-विशिष्ट विफलताओं को ढूँढना;
• व्यापक ब्राउज़र-परिवार, प्लेटफ़ॉर्म और प्रमुख-संस्करण वितरण को मापना;
• स्वचालित या दुर्भावनापूर्ण ट्रैफ़िक में असंभव संयोजनों की पहचान करना।

समस्या तब शुरू होती है जब UA सूँघना एक संकीर्ण संगतता फ़ॉलबैक से उत्पाद के नाम से अनुमान लगाने की क्षमताओं तक चला जाता है। कोड Chrome देख सकता है और मान सकता है कि एक विशेष एपीआई मौजूद है। यह धारणा एक एम्बेडेड वेबव्यू, एक Chromium-व्युत्पन्न ब्राउज़र, एक एंटरप्राइज़ नीति के साथ एक ब्राउज़र, एक जमे हुए UA, या एक क्लाइंट जिसने अपना हेडर बदल दिया है, में विफल हो सकती है।

संचालन का एक अधिक मजबूत क्रम है:

1. जब भी क्षमता का पता लगाना संभव हो तो आवश्यक एपीआई या व्यवहार का सीधे परीक्षण करें।
2. जब ब्राउज़र की पहचान अपरिहार्य हो, तो तदर्थ नियमित अभिव्यक्ति के बजाय एक बनाए रखा पार्सर का उपयोग करें।
3. केवल उन मोटे श्रेणियों को स्टोर करें जिनकी उत्पाद को वास्तव में आवश्यकता है।
4. अज्ञात ब्रांडों, अज्ञात संस्करणों और लापता क्षेत्रों के लिए फ़ॉलबैक प्रदान करें।

3. क्या UA ब्राउज़र फिंगरप्रिंट है?

अधिक सटीक रूप से, UA ब्राउज़र फिंगरप्रिंट के लिए एक इनपुट है, आमतौर पर पूर्ण फिंगरप्रिंट नहीं।

ब्राउज़र फ़िंगरप्रिंटिंग के लिए गुप्त सीरियल नंबर की आवश्यकता नहीं होती है। यह ब्राउज़र द्वारा उजागर अपेक्षाकृत स्थिर, विशिष्ट विशेषताओं के संग्रह को मापता है। UA ब्राउज़र परिवार, संस्करण और प्लेटफ़ॉर्म के बारे में सुराग देता है। स्क्रीन आयाम, फ़ॉन्ट, टाइमज़ोन, Canvas, WebGL, AudioContext और अन्य इंटरफ़ेस अधिक जानकारी जोड़ते हैं।

लैपरड्रिक्स और उनके सहयोगियों द्वारा किए गए सर्वेक्षण, Browser Fingerprinting: A Survey, इन तकनीकों पर राज्यविहीन मान्यता के रूप में चर्चा करते हैं। जरूरी नहीं कि किसी साइट को पहले Cookie लिखना पड़े; यह ब्राउज़र द्वारा उजागर की जाने वाली विशेषताओं से विज़िट को संबद्ध करने का प्रयास कर सकता है। "स्टेटलेस" का मतलब यह नहीं है कि सर्वर कुछ भी संग्रहीत नहीं करता है। इसका मतलब है कि पहचान सामग्री लगातार क्लाइंट-साइड पहचानकर्ता पर निर्भर नहीं करती है।

1. पेपर के 10-बिट परिणाम का क्या अर्थ है?

2010 के Panopticlick अध्ययन How Unique Is Your Web Browser? में, पीटर एकर्सली ने लगभग 470,000 ब्राउज़र उंगलियों के निशान का विश्लेषण किया। अखबार ने बताया कि:

• पूरे फिंगरप्रिंट में उस नमूने में पहचान की जानकारी के औसतन 18.1 बिट्स थे;
• सहज रूप से कहें तो, 286,777 ब्राउज़रों में औसत फिंगरप्रिंट लगभग एक बार हुआ;
• तालिका ने अकेले UA स्ट्रिंग के लिए औसत जानकारी के 10.0 बिट्स की सूचना दी;
• Flash या जावा सक्षम वाले ब्राउज़रों में, 94.2% पूर्ण उंगलियों के निशान अद्वितीय थे।

आत्म-सूचना को आमतौर पर इस प्रकार लिखा जाता है:

I(x) = -log₂ P(x)

यदि कोई विशेष UA किसी आबादी में 1/1024 की संभावना के साथ होता है, तो इसे देखने से 10 बिट्स की जानकारी मिलती है। इसका मतलब यह है कि UA पास बिल्कुल 1,024 संभावित मान हैं या यह विशिष्ट रूप से किसी व्यक्ति की पहचान करता है। यह वर्णन करता है कि अवलोकन औसतन कितनी अनिश्चितता को दूर करता है।

2. 2010 का परिणाम आज के वेब के लिए स्थिर क्यों नहीं है?

परिणाम महत्वपूर्ण बना हुआ है, लेकिन इसके लिए कम से कम तीन योग्यताओं की आवश्यकता है:

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

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

4. केवल UA बदलना उल्टा क्यों हो सकता है?

UA क्रिप्टोग्राफ़िक प्रमाण के बिना एक ग्राहक घोषणा है। कोई सर्वर इस शीर्ष लेख से किसी डिवाइस की फ़ैक्टरी सच्चाई नहीं पढ़ सकता. हालांकि, यह जांच सकता है कि अलग-अलग अवलोकन उचित रूप से संगत हैं या नहीं।

मान लीजिए कि कोई UA मोबाइल ब्राउज़र होने का दावा करता है, लेकिन पृष्ठ पर कोई स्पर्श बिंदु नहीं है, एक विंडो जो लगातार डेस्कटॉप डिस्प्ले जैसा दिखता है, और Client Hints जो डेस्कटॉप प्लेटफ़ॉर्म की रिपोर्ट करता है। किसी भी एक अवलोकन का एक वैध अपवाद हो सकता है। कई स्थिर विरोधाभास एक साथ अभी भी एक वर्गीकृत पैटर्न बना सकते हैं।

Panopticlick पेपर में पहले से ही तुलनीय मामलों का दस्तावेजीकरण किया गया है: कुछ ब्राउज़रों ने Flash का समर्थन करते हुए एक iPhone होने का दावा किया, और कुछ Firefox UA केवल इंटरनेट एक्सप्लोरर में उपलब्ध स्टोरेज सुविधाओं के साथ दिखाई दिए। 2018 FP-Scanner अध्ययन ने इस समस्या की व्यवस्थित रूप से जांच की। कुछ एंटी-फिंगरप्रिंटिंग एक्सटेंशन और स्पूफिंग टूल ने इंटरफेस में विसंगतियों को पेश किया, जिससे एक डिटेक्टर को संशोधित विशेषताओं की पहचान करने की अनुमति मिलती है और कुछ मामलों में, मूल ब्राउज़र या ऑपरेटिंग-सिस्टम परिवार का अनुमान लगाया जाता है।

हर असंगति दुर्भावनापूर्ण नहीं होती है। दूरस्थ डेस्कटॉप, एक्सेसिबिलिटी टूल, एंटरप्राइज़ नीतियां, संगतता परतें और असामान्य हार्डवेयर सभी असामान्य संयोजन बना सकते हैं। एक सावधान जोखिम प्रणाली को एक असंगति को संभाव्य साक्ष्य के रूप में मानना चाहिए, न कि उपयोगकर्ता को ब्लॉक करने का एक स्वचालित कारण।

ब्राउज़र-प्रोफ़ाइल प्रबंधन के लिए, तीन गुण मायने रखते हैं:

• आंतरिक स्थिरता: UA, Client Hints, प्लेटफ़ॉर्म, आर्किटेक्चर, टच और स्क्रीन सिग्नल सीधे एक-दूसरे का खंडन नहीं करना चाहिए।
• समय के साथ स्थिरता: एक लंबे समय तक चलने वाली प्रोफ़ाइल को बिना किसी कारण के हर लॉन्च पर नाटकीय रूप से नहीं बदलना चाहिए।
• प्रशंसनीय विविधता: प्रोफाइल भिन्न हो सकते हैं, लेकिन दुर्लभ यांत्रिक रूप से उत्पन्न संयोजन आवश्यक रूप से सुरक्षित नहीं हैं।

FP-STALKER अध्ययन से यह भी पता चला है कि बदलती विशेषताएँ स्वचालित रूप से लिंकेज को नहीं रोकती हैं। एक मॉडल पहले और बाद में उंगलियों के निशान को कनेक्ट करने के लिए स्थिर विशेषताओं और प्रशंसनीय संस्करण परिवर्तनों का उपयोग कर सकता है।

5. UA Reduction किस समस्या का समाधान करता है?

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

Chromium की User-Agent Reduction योजना इस डिफ़ॉल्ट ग्रैन्युलैरिटी को कम करती है:

• Chrome 101 से शुरू होकर, डेस्कटॉप माइनर, बिल्ड और पैच संस्करणों को घटाकर 0.0.0 कर दिया गया था;
• बाद के चरण एकीकृत डेस्कटॉप ऑपरेटिंग-सिस्टम संस्करण, सीपीयू विवरण और Android डिवाइस की जानकारी;
• एक कम Android UA निश्चित प्लेटफ़ॉर्म और मॉडल मानों जैसे Android 10; K का उपयोग करता है;
• जिन साइटों को वास्तव में अधिक विवरण की आवश्यकता होती है, वे User-Agent Client Hints अनुरोध कर सकती हैं।

कम प्रारूप को संक्षेप में प्रस्तुत किया जा सकता है:

Mozilla/5.0 (<unified platform information>)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/<major version>.0.0.0 Safari/537.36

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

6. User-Agent Client Hints कैसे काम करते हैं?

सामान्य तंत्र को RFC 8942 में परिभाषित किया गया है, जबकि WICG User-Agent Client Hints ड्राफ्ट UA-विशिष्ट क्षेत्रों का वर्णन करता है। दृष्टिकोण उन सूचनाओं को विभाजित करता है जो एक बार एक असंरचित स्ट्रिंग में संरचित क्षेत्रों में रहते थे, कम-एन्ट्रापी संकेतों को अलग करते हैं जो उच्च-एन्ट्रापी संकेतों से डिफ़ॉल्ट रूप से भेजे जा सकते हैं जो एक साइट सामान्य रूप से स्पष्ट रूप से अनुरोध करती है।

एक सरलीकृत प्रारंभिक अनुरोध इस तरह दिख सकता है:

GET /download HTTP/1.1
User-Agent: Mozilla/5.0 (...) Chrome/145.0.0.0 Safari/537.36
Sec-CH-UA: "Chromium";v="145", "Not_A Brand";v="99"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "Windows"

यदि सर्वर को वास्तव में इंस्टॉलर का चयन करने के लिए आर्किटेक्चर और बिटनेस की आवश्यकता है, तो यह इसके साथ जवाब दे सकता है:

HTTP/1.1 200 OK
Accept-CH: Sec-CH-UA-Arch, Sec-CH-UA-Bitness
Vary: Sec-CH-UA-Arch, Sec-CH-UA-Bitness

जब ब्राउज़र तंत्र का समर्थन करता है और सुरक्षा और नीति आवश्यकताओं को पूरा करता है, तो बाद के अनुरोध में शामिल हो सकते हैं:

Sec-CH-UA-Arch: "x86"
Sec-CH-UA-Bitness: "64"

सामान्य UA Client Hints में शामिल हैं:

फ़ील्ड	विशिष्ट उद्देश्य	सूचना स्तर
Sec-CH-UA	ब्रांड और प्रमुख-संस्करण सूची	आमतौर पर कम एन्ट्रापी
Sec-CH-UA-Mobile	क्या ग्राहक मोबाइल अनुभव पसंद करता है	आमतौर पर कम एन्ट्रापी
Sec-CH-UA-Platform	ब्रॉड प्लेटफॉर्म श्रेणी	आमतौर पर कम एन्ट्रापी
Sec-CH-UA-Arch	सीपीयू आर्किटेक्चर	उच्च एन्ट्रापी; जरूरत पड़ने पर अनुरोध
Sec-CH-UA-Bitness	आर्किटेक्चर बिटनेस	उच्च एन्ट्रापी; जरूरत पड़ने पर अनुरोध
Sec-CH-UA-Platform-Version	प्लेटफ़ॉर्म संस्करण	उच्च एन्ट्रापी; जरूरत पड़ने पर अनुरोध
Sec-CH-UA-Full-Version-List	रिपोर्ट किए गए ब्रांडों के लिए पूर्ण संस्करण	उच्च एन्ट्रापी; जरूरत पड़ने पर अनुरोध
Sec-CH-UA-Model	डिवाइस मॉडल	उच्च एन्ट्रापी; जरूरत पड़ने पर अनुरोध

तीन इंजीनियरिंग विवरणों को याद करना आसान है।

1. Client Hints सभी स्वचालित रूप से नहीं भेजे जाते हैं

कम-एन्ट्रापी संकेत डिफ़ॉल्ट रूप से प्रकट हो सकते हैं। उच्च-एन्ट्रापी संकेतों के लिए आमतौर पर Accept-CH प्रतिक्रिया की आवश्यकता होती है। प्रारंभिक नेविगेशन, उप-संसाधन, अनुमति नीति, सुरक्षित परिवहन और ब्राउज़र समर्थन सभी आने वाली चीज़ों को प्रभावित कर सकते हैं। सर्वर को प्रत्येक वैकल्पिक फ़ील्ड को अनुपस्थित होने की अनुमति देनी चाहिए.

2. ब्रांड सूची जानबूझकर पार्सर की मजबूती का परीक्षण करती है

Sec-CH-UA में कई ब्रांड और एक सिंथेटिक ब्रांड हो सकता है जिसका उपयोग अनुकूलता का परीक्षण करने के लिए किया जाता है। कोड को यह नहीं मानना चाहिए कि पहली प्रविष्टि हमेशा उत्पाद का नाम होती है, और जब कोई अज्ञात ब्रांड दिखाई देता है तो यह विफल नहीं होना चाहिए। संरचित फ़ील्ड को पार्स करें, उन प्रविष्टियों को अनदेखा करें जिन्हें आप नहीं पहचानते हैं, और भविष्य के ब्रांडों के लिए जगह छोड़ दें।

3. संकेतों पर भिन्न प्रतिक्रियाओं को सही कैश हैंडलिंग की आवश्यकता होती है

यदि आर्किटेक्चर, प्लेटफ़ॉर्म या कोई अन्य संकेत प्रतिसाद बदलता है, तो Vary या समकक्ष कैश-कुंजी रणनीति को सही ढंग से कॉन्फ़िगर करें। अन्यथा, एक साझा कैश एक डिवाइस वर्ग के लिए दूसरे डिवाइस वर्ग के लिए जेनरेट की गई सामग्री की सेवा कर सकता है।

7. क्या Client Hints पारंपरिक UA की तुलना में अधिक निजी हैं?

वे सुधार करते हैं कि जानकारी कैसे उजागर होती है, लेकिन वे फिंगरप्रिंटिंग से प्रतिरक्षा प्रदान नहीं करते हैं।

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

हालाँकि, आर्किटेक्चर, पूर्ण संस्करण, प्लेटफ़ॉर्म संस्करण और डिवाइस मॉडल अभी भी विशिष्टता बढ़ा सकते हैं। RFC 8942 स्पष्ट रूप से गोपनीयता और प्रदर्शन को डिज़ाइन बाधाओं के रूप में मानता है। डेवलपर्स को पूछना चाहिए:

• क्या इस सुविधा को वास्तव में क्षेत्र की आवश्यकता है?
• क्या क्षमता का पता लगाना या उपयोगकर्ता की पसंद इसे बदल सकती है?
• क्या एप्लिकेशन केवल एक मोटे श्रेणी को स्टोर कर सकता है?
• कच्चे मूल्य कितने समय तक बनाए रखे जाते हैं, और उन तक कौन पहुंच सकता है?
• क्या तृतीय-पक्ष संसाधनों को समान संकेत प्राप्त होंगे?

8. सर्वर-साइड UA हैंडलिंग के लिए इंजीनियरिंग मार्गदर्शन

1. कभी भी पहचान या अधिकार के प्रमाण के रूप में UA का उपयोग न करें

UA प्रस्तुति विकल्पों और संगतता फ़ॉलबैक का समर्थन कर सकते हैं। इसे पहचान, प्राधिकरण, भुगतान ट्रस्ट या सुरक्षा सीमा निर्धारित नहीं करनी चाहिए। क्लाइंट-नियंत्रित मान एक एक्सेस-कंट्रोल क्रेडेंशियल के रूप में काम नहीं कर सकता।

2. ब्राउज़र सूचियों के लिए क्षमता का पता लगाने को प्राथमिकता दें

जब किसी फ्रंट एंड को एपीआई की आवश्यकता होती है, तो सीधे उस क्षमता के लिए परीक्षण करें:

if ('share' in navigator) {
  // Offer the system share feature.
} else {
  // Fall back to copying a link.
}

क्षमता का पता लगाने व्युत्पन्न ब्राउज़र, प्रयोगात्मक सुविधाओं, एंटरप्राइज़ नीतियों और भविष्य के रिलीज़ को "Chrome 145 के लिए इसे सक्षम करें" जैसे नियम से बेहतर तरीके से संभालता है।

3. विरासत UA, Client Hints और अज्ञात राज्यों को स्वीकार करें

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

4. लॉग ग्रैन्युलैरिटी कम करें

अगर Analytics को केवल डेस्कटॉप बनाम मोबाइल, ब्राउज़र परिवार और प्रमुख वर्शन की ज़रूरत है, तो कच्चे UA स्ट्रिंग्स और हर उच्च-एन्ट्रापी संकेत को अनिश्चित काल तक बनाए न रखें. डेटा न्यूनीकरण गोपनीयता जोखिम को कम करता है और एक एनालिटिक्स पाइपलाइन को मामूली भिन्नता को एक सार्थक आयाम के रूप में मानने से रोकता है।

5. विसंगतियों को सबूत के रूप में लें, फैसले के रूप में नहीं

एक UA जो दावा करता है कि Windows जबकि एक एपीआई अलग तरह से व्यवहार करता है, वह अधिक से अधिक एक जोखिम संकेत है। एंटरप्राइज़ वातावरण, वर्चुअलाइजेशन, दूरस्थ सत्र, संगतता परतें और सहायक प्रौद्योगिकियां वैध विसंगतियाँ उत्पन्न कर सकती हैं। एक बेमेल को स्वचालित धोखाधड़ी के निर्णय में बदलना गलत सकारात्मकता पैदा करता है।

9. मल्टी-प्रोफाइल वातावरण में UA कैसे कॉन्फ़िगर किया जाना चाहिए?

क्रॉस-रीजन परीक्षण, विज्ञापन पूर्वावलोकन, खाता संचालन और गोपनीयता अलगाव के लिए, लक्ष्य सबसे असामान्य UA बनाना नहीं होना चाहिए। एक प्रोफ़ाइल समझाने योग्य, स्थिर और उसके आसपास के वातावरण के अनुकूल होनी चाहिए।

क्रम में निम्नलिखित की समीक्षा करें:

1. ब्राउज़र संस्करण: UA प्रमुख संस्करण वास्तविक इंजन और इसकी क्षमताओं के लिए प्रशंसनीय होना चाहिए।
2. ऑपरेटिंग सिस्टम: UA प्लेटफ़ॉर्म, Client Hints प्लेटफ़ॉर्म और JavaScript-दृश्यमान प्लेटफ़ॉर्म श्रेणी संगत होनी चाहिए।
3. वास्तुकला और बिटनेस: UA, Client Hints और निष्पादन योग्य वातावरण को सीधे परस्पर विरोधी दावे नहीं करने चाहिए।
4. डिवाइस फॉर्म फैक्टर: एक मोबाइल घोषणा को टच सपोर्ट, व्यूपोर्ट, पिक्सेल अनुपात और इंटरैक्शन पैटर्न के साथ समझ में आना चाहिए।
5. क्षेत्रीय संदर्भ: भाषा, समय क्षेत्र, जियोलोकेशन और प्रॉक्सी निकास को यंत्रवत् मिलान करने की आवश्यकता नहीं है, लेकिन उन्हें वास्तविक वर्कफ़्लो के लिए समझ में आना चाहिए।
6. प्रोफ़ाइल स्थिरता: जब एक खाता या परीक्षण पहचान लंबे समय तक चलने वाली प्रोफ़ाइल का पुन: उपयोग करती है, तो बिना किसी कारण के प्लेटफ़ॉर्म और प्रमुख संस्करण को बदलने से बचें।

PurpleMark का वर्तमान प्रोफ़ाइल रूपांतरण चयनित ऑपरेटिंग सिस्टम को एक UA प्लेटफ़ॉर्म पर मैप करता है और पहले कॉन्फ़िगर किए गए Chrome/ या CriOS/ टोकन से ब्राउज़र संस्करण निकालने का प्रयास करता है। जब कोई प्रयोग करने योग्य संस्करण मौजूद नहीं होता है, तो यह वर्तमान इंजन के प्रमुख संस्करण से उचित गिरावट प्राप्त करता है। इसका उद्देश्य एक अलग स्ट्रिंग को स्पूफ करना नहीं है, बल्कि UA कॉन्फ़िगरेशन को एक सुसंगत ब्राउज़र-प्रोफाइल मॉडल के अंदर रखना है।

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

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

Q1: क्या UA बदलने से ब्राउज़र दूसरे ब्राउज़र में बदल जाता है?

नहीं। यह क्लाइंट द्वारा घोषित किए गए हिस्से को बदल देता है। यह JavaScript इंजन, रेंडरिंग पाइपलाइन, नेटवर्क स्टैक, या समर्थित वेब एपीआई को प्रतिस्थापित नहीं करता है।

Q2: क्या कोई वेबसाइट "वास्तविक UA" पढ़ सकती है?

कोई सार्वभौमिक हार्डवेयर-स्तरीय "वास्तविक UA" नहीं है जिसे हर वेबसाइट पढ़ने के लिए ब्राउज़र को बायपास कर सकती है। एक साइट फिर भी Client Hints, क्षमता परीक्षण और अन्य फिंगरप्रिंट संकेतों की तुलना कर सकती है, असंगत दावे ढूंढ सकती है और एक संभाव्य अनुमान लगा सकती है।

Q3: क्या कम UA Windows 10 को 11 Windows से अलग कर सकता है?

कम विरासत UA सामान्य रूप से मज़बूती से ऐसा नहीं कर सकती क्योंकि दोनों Windows NT 10.0 रिपोर्ट कर सकते हैं। एक ब्राउज़र जो UA Client Hints का समर्थन करता है, वह साइट के अनुरोध के बाद अधिक विस्तृत प्लेटफ़ॉर्म-संस्करण जानकारी प्रदान कर सकता है। सर्वर अभी भी अनुपलब्ध फ़ील्ड और मैपिंग अंतर को संभालना चाहिए।

Q4: क्या JavaScript अक्षम करने से UA जोखिम रुक जाता है?

पूरी तरह से नहीं। HTTP User-Agent एक अनुरोध हेडर है और इसे पेज JavaScript चलने से पहले पेज अनुरोध के साथ भेजा जा सकता है। JavaScript को अक्षम करने से कुछ संग्रह सतहों को हटा दिया जाता है लेकिन आधुनिक वेब के महत्वपूर्ण हिस्से भी टूट जाते हैं।

Q5: क्या Client Hints User-Agent को पूरी तरह से बदल देंगे?

निकट अवधि में ऐसा न मानें। कई क्लाइंट और सर्वर अभी भी विरासत UA पर निर्भर करते हैं, जबकि UA Client Hints समर्थन भिन्न होता है। Client Hints को प्रगतिशील वृद्धि के रूप में मानें: उपलब्ध होने पर संरचित जानकारी को प्राथमिकता दें, लेकिन विरासत UA और अज्ञात राज्यों के लिए गिरावट बनाए रखें।

Q6: क्या बेतरतीब ढंग से उत्पन्न UA गुमनामी में सुधार करती है?

आवश्यक रूप से नहीं। एक फ़ील्ड को रैंडमाइज़ करने से संस्करण, प्लेटफ़ॉर्म, स्पर्श और रेंडरिंग सिग्नल के साथ विरोधाभास पैदा हो सकता है। लंबे समय तक रहने वाली प्रोफ़ाइल के लिए, एक सामान्य, स्थिर, आंतरिक रूप से संगत कॉन्फ़िगरेशन आमतौर पर लगातार यादृच्छिक परिवर्तनों की तुलना में अधिक रक्षात्मक होता है।

11. निष्कर्ष

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

प्रमुख विचार तीन कथनों में फिट होते हैं:

• UA को शाब्दिक रूप से न पढ़ें; इसमें कई ऐतिहासिक संगतता टोकन शामिल हैं।
• अलगाव में UA मूल्यांकन न करें; व्यावहारिक मान्यता संकेतों के संयोजन और समय के साथ उनके विकास से आती है।
• Client Hints को केवल "अधिक UA क्षेत्रों" के रूप में मत सोचो; उनका मूल्य संरचित, अनुरोध-संचालित, शासन योग्य प्रकटीकरण में निहित है।

जब कोई सिस्टम ब्राउज़र के नाम की पहचान करने से लेकर उस क्षमता का परीक्षण करने तक जाता है जिसकी उसे आवश्यकता होती है - और हर उपलब्ध विवरण एकत्र करने से लेकर केवल वही अनुरोध करने तक जो आवश्यक है - UA अपनी उचित भूमिका में लौट आता है: एक संगतता सुराग, पहचान की सच्चाई नहीं।

संदर्भ और मानक

1. Peter Eckersley. How Unique Is Your Web Browser?. Privacy Enhancing Technologies Symposium, 2010.
2. Pierre Laperdrix, Nataliia Bielova, Benoit Baudry, Gildas Avoine. Browser Fingerprinting: A Survey. ACM Transactions on the Web, 2020.
3. Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy. FP-Scanner: The Privacy Implications of Browser Fingerprint Inconsistencies. USENIX Security Symposium, 2018.
4. Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy. FP-STALKER: Tracking Browser Fingerprint Evolutions. IEEE Symposium on Security and Privacy, 2018.
5. IETF. RFC 9110: HTTP Semantics, 2022.
6. IETF. RFC 8942: HTTP Client Hints, 2021.
7. WICG. User-Agent Client Hints, Draft Community Group Report.
8. Chromium. User-Agent Reduction.
9. Chrome for Developers. Improve user privacy and developer experience with User-Agent Client Hints.