उपयोगकर्ता-एजेंट को कम करने की सुविधा क्या है?

उपयोगकर्ता-एजेंट (UA) को छोटा करने से, उपयोगकर्ता-एजेंट स्ट्रिंग में शेयर की गई पहचान ज़ाहिर करने वाली जानकारी कम हो जाती है. इस जानकारी का इस्तेमाल पैसिव फ़िंगरप्रिंटिंग के लिए किया जा सकता है. इन बदलावों को अब सामान्य उपलब्धता के लिए रोल आउट कर दिया गया है. इसलिए, सभी संसाधन अनुरोधों के User-Agent हेडर को कम कर दिया गया है. इस वजह से, कुछ Navigator इंटरफ़ेस से मिलने वाली रिटर्न वैल्यू कम हो जाती हैं. इनमें navigator.userAgent, navigator.appVersion, और navigator.platform शामिल हैं.

वेब डेवलपर को उपयोगकर्ता-एजेंट स्ट्रिंग के इस्तेमाल के लिए, अपने साइट कोड की समीक्षा करनी चाहिए. अगर आपकी साइट, डिवाइस मॉडल, प्लैटफ़ॉर्म वर्शन या ब्राउज़र के पूरे वर्शन को पढ़ने के लिए, उपयोगकर्ता-एजेंट स्ट्रिंग को पार्स करने पर निर्भर है, तो आपको User-Agent Client Hints API को लागू करना होगा.

उपयोगकर्ता-एजेंट क्लाइंट हिंट (UA-CH)

उपयोगकर्ता-एजेंट क्लाइंट हिंट, उपयोगकर्ता-एजेंट के डेटा के पूरे सेट का ऐक्सेस सिर्फ़ तब देते हैं जब सर्वर, डेटा के किसी खास हिस्से की साफ़ तौर पर ज़रूरत का एलान करते हैं.

उपयोगकर्ता के बिना अनुमति के सार्वजनिक किए गए डेटा को हटाकर, हम उस जानकारी को बेहतर तरीके से मापते हैं और कम करते हैं जिसे अनुरोध के हेडर, JavaScript एपीआई, और दूसरे तरीकों से जान-बूझकर दिखाया जाता है.

हमें UA और UA-CH कम करने की ज़रूरत क्यों है?

अब तक, उपयोगकर्ता-एजेंट स्ट्रिंग, उपयोगकर्ता के ब्राउज़र, ऑपरेटिंग सिस्टम, और हर एचटीटीपी अनुरोध के वर्शन के बारे में डेटा की एक बड़ी स्ट्रिंग ब्रॉडकास्ट करती थी. यह दो वजहों से समस्या भरा था:

  • जानकारी का स्तर और ज़्यादा जानकारी होने से, उपयोगकर्ता को आसानी से पहचाना जा सकता है.
  • डिफ़ॉल्ट रूप से यह जानकारी उपलब्ध होने पर, गुप्त मोड की ट्रैकिंग हो सकती है.

UA और UA-CH में कमी होने पर, डिफ़ॉल्ट रूप से सिर्फ़ बुनियादी जानकारी शेयर करके उपयोगकर्ता की निजता को बेहतर बनाया जाता है.

कम उपयोगकर्ता-एजेंट में ब्राउज़र का ब्रैंड और एक अहम वर्शन शामिल है, जहां अनुरोध (डेस्कटॉप या मोबाइल) से अनुरोध किया गया है, और प्लैटफ़ॉर्म. ज़्यादा डेटा ऐक्सेस करने के लिए, उपयोगकर्ता-एजेंट क्लाइंट हिंट की मदद से, उपयोगकर्ता के डिवाइस या शर्तों के बारे में खास जानकारी मांगी जा सकती है.

इसके अलावा, समय के साथ User-Agent स्ट्रिंग लंबी और जटिल होती गई. इसकी वजह से स्ट्रिंग को पार्स करने में गड़बड़ी हुई. UA-CH व्यवस्थित और भरोसेमंद डेटा देता है, जिसे समझना आसान होता है. UA स्ट्रिंग को पार्स करने वाला मौजूदा कोड काम नहीं करना चाहिए, हालांकि, इससे कम डेटा दिखेगा. अगर आपकी साइट को क्लाइंट की खास जानकारी की ज़रूरत है, तो आपको UA-CH पर माइग्रेट करना होगा.

UA और UA-CH के डेटा में कमी कैसे होती है?

यहां एक उदाहरण में बताया गया है कि कम की गई उपयोगकर्ता-एजेंट स्ट्रिंग और UA-CH कैसे काम करते हैं. ज़्यादा जानकारी के लिए, उपयोगकर्ता-एजेंट क्लाइंट हिंट की मदद से, उपयोगकर्ता की निजता और डेवलपर अनुभव को बेहतर बनाना देखें.

कोई उपयोगकर्ता ब्राउज़र खोलता है और पता बार में example.com डालता है:

  1. ब्राउज़र, वेबपेज को लोड करने का अनुरोध भेजता है.

    1. ब्राउज़र में, User-Agent हेडर को कम की गई User-Agent स्ट्रिंग के साथ शामिल किया जाता है. उदाहरण के लिए: User-Agent: Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.0.0 Mobile Safari/537.36

    2. यही जानकारी, ब्राउज़र के डिफ़ॉल्ट User-Agent Client सलाह हेडर में भी शामिल होती है. उदाहरण के लिए:

      Sec-CH-UA: "Chrome"; v="98"
Sec-CH-UA-Mobile: ?1
Sec-CH-UA-Platform: "Android"

  2. सर्वर, ब्राउज़र को Accept-CH रिस्पॉन्स हेडर के साथ क्लाइंट के डिवाइस मॉडल जैसे अन्य संकेत भेजने के लिए कह सकता है. उदाहरण के लिए: Accept-CH: Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA-Model

  3. ब्राउज़र, नीतियों और उपयोगकर्ता कॉन्फ़िगरेशन को लागू करके यह तय करता है कि बाद के अनुरोध के हेडर में, सर्वर पर कौनसा डेटा वापस भेजा जा सकता है. उदाहरण के लिए:

    Sec-CH-UA: "Chrome"; v="93"
Sec-CH-UA-Mobile: ?1
Sec-CH-UA-Platform: "Android"
Sec-CH-UA-Model: "Pixel 2"

क्लाइंट के लिए अहम संकेत

अगर आपको शुरुआती अनुरोध में क्लाइंट हिंट का कोई खास सेट चाहिए, तो Critical-CH रिस्पॉन्स हेडर का इस्तेमाल करें. Critical-CH की वैल्यू, Accept-CH के अनुरोध की गई वैल्यू की एक सबसेट होनी चाहिए.

उदाहरण के लिए, शुरुआती अनुरोध में Device-Memory और Viewport-Width के लिए अनुरोध शामिल हो सकता है, जहां Device-Memory को अहम माना जाता है.

GET / HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/html
Accept-CH: Device-Memory, Viewport-Width
Vary: Device-Memory, Viewport-Width
Critical-CH: Device-Memory

अगर वेबपेज को सही तरीके से रेंडर करने के लिए ब्राउज़र को किसी अहम संकेत (Critical-CH) की ज़रूरत होती है, तो सर्वर Accept-CH हेडर के साथ यह ज़्यादा जानकारी मांग सकता है. इसके बाद, ब्राउज़र अहम संकेत के साथ-साथ पेज के लिए नया अनुरोध भेज सकता है.

खास जानकारी में, Accept-CH उन सभी वैल्यू के लिए अनुरोध करता है जिन्हें आपको पेज के लिए चाहिए. वहीं, Critical-CH सिर्फ़ उन वैल्यू के सबसेट का अनुरोध करता है जो आपके पेज को सही तरीके से लोड करने के लिए, ऑन-लोड होने चाहिए. ज़्यादा जानकारी के लिए, क्लाइंट हिंट के भरोसेमंद होने की जानकारी देखें.

UA-CH API की मदद से, टैबलेट डिवाइसों का पता लगाएं

मोबाइल, टैबलेट, और डेस्कटॉप डिवाइसों के बीच का फ़र्क़ लगातार कम होता जा रहा है. साथ ही, अलग-अलग तरह के डिवाइस लगातार बदलते रहते हैं (डिवाइस फ़ोल्ड करना, लैपटॉप और टैबलेट मोड के बीच स्विच करना), इसलिए सही यूज़र इंटरफ़ेस पेश करने के लिए रिस्पॉन्सिव डिज़ाइन और सुविधा पहचानने की सुविधा इस्तेमाल करने की सलाह दी जाती है.

हालांकि, उपयोगकर्ता-एजेंट स्ट्रिंग और उपयोगकर्ता-एजेंट क्लाइंट हिंट, दोनों के लिए ब्राउज़र से मिली जानकारी एक ही सोर्स से मिलती है. इसलिए, एक ही तरह का लॉजिक काम करेगा.

उदाहरण के लिए, अगर UA स्ट्रिंग पर इस पैटर्न को चुना गया है, तो:

  • फ़ोन का पैटर्न: 'Android' + 'Chrome/[.0-9]* Mobile'
  • टैबलेट का पैटर्न: 'Android' + 'Chrome/[.0-9]* (?!Mobile)'

मैच होने वाले डिफ़ॉल्ट UA-CH हेडर इंटरफ़ेस की जांच की जा सकती है:

  • फ़ोन का पैटर्न: Sec-CH-UA-Platform: "Android", Sec-CH-UA-Mobile: ?1
  • टैबलेट पैटर्न: Sec-CH-UA-Platform: "Android", Sec-CH-UA-Mobile: ?0

या इसके जैसा कोई JavaScript इंटरफ़ेस:

  • फ़ोन का पैटर्न: navigator.userAgentData.platform === 'Android' && navigator.userAgentData.mobile === true
  • टैबलेट का पैटर्न: navigator.userAgentData.platform === 'Android' && navigator.userAgentData.mobile === false

किसी खास हार्डवेयर के इस्तेमाल के लिए, डिवाइस मॉडल के नाम के लिए, हाई-एंट्रॉपी Sec-CH-UA-Model संकेत की मदद से अनुरोध किया जा सकता है.

कम किए गए UA को इस्तेमाल और टेस्ट करने का तरीका क्या है?

शुरू करने के लिए, उपयोगकर्ता-एजेंट स्ट्रिंग के इंस्टेंस और इस्तेमाल के लिए, अपने साइट कोड की समीक्षा करें. अगर आपकी साइट, डिवाइस मॉडल, प्लैटफ़ॉर्म वर्शन या ब्राउज़र के पूरे वर्शन को पढ़ने के लिए, उपयोगकर्ता-एजेंट स्ट्रिंग को पार्स करने पर निर्भर है, तो आपको UA-CH API को लागू करना होगा.

UA-CH API में अपडेट होने के बाद, आपको User-Agent से उम्मीद के मुताबिक डेटा मिल रहा है या नहीं, यह पक्का करने के लिए जांच करनी चाहिए. जांच करने के तीन तरीके हैं, जिनमें से हर एक की जटिलता बढ़ती जा रही है.

उपयोगकर्ता-एजेंट को कम करने की स्केल उपलब्धता का मतलब है कि सभी Chrome डिवाइसों पर शिप की जाने वाली UA स्ट्रिंग की संख्या पूरी तरह कम हो गई है. 2022 की दूसरी तिमाही में, Chrome का छोटा वर्शन रिलीज़ होने के बाद, कमी की शुरुआत हुई.

स्थानीय तौर पर कस्टम स्ट्रिंग की जांच करना

अगर आपको अलग-अलग डिवाइसों को सिम्युलेट करने के लिए, कस्टम उपयोगकर्ता-एजेंट स्ट्रिंग इस्तेमाल करके अपनी साइट की जांच करनी है, तो Chrome को --user-agent="Custom string here" कमांड लाइन फ़्लैग के साथ लॉन्च करें. यहां कमांड-लाइन फ़्लैग के बारे में ज़्यादा जानकारी पाएं.

इसके अलावा, Chrome DevTools में डिवाइस एम्युलेटर का इस्तेमाल किया जा सकता है.

अपनी साइट के कोड में स्ट्रिंग को बदलें

अगर Chrome user-agent स्ट्रिंग को अपने क्लाइंट-साइड या सर्वर साइड कोड में प्रोसेस किया जाता है, तो यह जांच की जा सकती है कि यह स्ट्रिंग नए फ़ॉर्मैट में है या नहीं. स्ट्रिंग को ओवरराइड करके और बदलकर या नया वर्शन जनरेट करके और साथ-साथ टेस्ट करके टेस्ट किया जा सकता है.

क्लाइंट हिंट और ज़रूरी संकेतों के लिए सहायता

सर्वर पर तीन डिफ़ॉल्ट क्लाइंट हिंट दिखाए जाते हैं. इनमें ब्राउज़र का नाम और मेजर वर्शन, एक बूलियन जो यह बताता है कि ब्राउज़र मोबाइल डिवाइस पर है या नहीं, और ऑपरेटिंग सिस्टम का नाम. इन्हें ट्रांसपोर्ट लेयर सिक्योरिटी प्रोटोकॉल (टीएलएस) हैंडशेक के बाद भेजा जाता है. ये पहले से उपलब्ध हैं और आपके ब्राउज़र में काम करते हैं.

हालांकि, कई बार ऐसा भी हो सकता है कि आपको अपनी साइट को रेंडर करने के लिए अहम जानकारी की ज़रूरत पड़े.

ज़रूरी संकेतों को ऑप्टिमाइज़ करें

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

ज़रूरी संकेतों के साथ क्लाइंट हिंट के लिए सिलसिलेवार डायग्राम.
जब सर्वर से किसी अहम संकेत के लिए अनुरोध किया जाता है, तो क्लाइंट अहम संकेत वाले वेबपेज के लिए पहला अनुरोध भेजने की फिर से कोशिश करता है. इस उदाहरण में, Sec-CH-UA-Model के लिए संकेत का अनुरोध दो बार किया गया है: एक बार, क्लाइंट संकेत के तौर पर Accept-CH के साथ और दोबारा Critical-CH के साथ, एक गंभीर संकेत के तौर पर.

क्रिटिकल हिंट (Critical-CH हेडर) को ऑप्टिमाइज़ करने के लिए, आपको इस हैंडशेक को रोकना होगा और क्लाइंट हिंट के लिए एक मॉडल देना होगा. ये चरण जटिल हो सकते हैं और इनके लिए बेहतर जानकारी की ज़रूरत होती है.

TLS ALPS एक्सटेंशन के साथ ACCEPT_CH एचटीटीपी/2 और एचटीटीपी/3 फ़्रेम कनेक्शन-लेवल ऑप्टिमाइज़ेशन है. इससे पहले एचटीटीपी अनुरोध के लिए, सर्वर की क्लाइंट संकेत की सेटिंग को समय पर पूरा किया जा सकता है. इनके लिए जटिल कॉन्फ़िगरेशन की आवश्यकता होती है और हमारा सुझाव है कि आप इसका उपयोग केवल वास्तविक रूप से महत्वपूर्ण जानकारी के लिए ही करें.

BooringSSL (SSL का फ़ॉर्क), आपको Chromium में Google की एक्सपेरिमेंटल सुविधाओं के साथ काम करने में मदद करता है. फ़िलहाल, ALPS को सिर्फ़ BeringSSL में लागू किया जाता है.

अगर आपको अहम संकेतों का इस्तेमाल करना है, तो अहम संकेतों की विश्वसनीयता और ऑप्टिमाइज़ेशन से जुड़ी हमारी गाइड देखें.

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

Accept-CH हेडर के ज़रिए दिए गए संकेत कितने समय तक भेजे जाएंगे?

Accept-CH हेडर से दिए गए संकेत, ब्राउज़र सेशन के दौरान या संकेत के दूसरे सेट के तय होने तक भेजे जाएंगे.

क्या UA-CH, एचटीटीपी/2 और एचटीटीपी/3 के साथ काम करता है?

UA-CH, एचटीटीपी/2 और एचटीटीपी/3 कनेक्शन, दोनों के साथ काम करता है.

क्या सबडोमेन (और CNAME) के लिए UA-CH को ऐक्सेस करने के लिए टॉप लेवल पेज Permissions-Policy की ज़रूरत होती है?

अनुरोध के हेडर पर हाई एंट्रॉपी UA-CH, क्रॉस-ऑरिजिन अनुरोधों के लिए प्रतिबंधित है. इससे कोई फ़र्क़ नहीं पड़ता कि ऑरिजिन को डीएनएस साइड पर कैसे तय किया गया है. किसी भी क्रॉस-ऑरिजिन सबरिसॉर्स के लिए, डेलिगेशन को Permissions-Policy से मैनेज किया जाना चाहिए. इसके अलावा, इसे क्रॉस-ऑरिजिन कॉन्टेक्स्ट में एक्ज़ीक्यूट होने वाले JavaScript से भी मैनेज किया जाना चाहिए.

उपयोगकर्ता-एजेंट को कम करने से, बॉट की पहचान पर कैसे असर पड़ता है?

Chrome की उपयोगकर्ता-एजेंट स्ट्रिंग में किए गए बदलाव का असर, उस उपयोगकर्ता-एजेंट स्ट्रिंग पर सीधे तौर पर नहीं पड़ता जिसे बॉट भेजने के लिए चुना जाता है.

Chrome की भेजी गई कम जानकारी को दिखाने के लिए, बॉट अपनी स्ट्रिंग अपडेट कर सकते हैं. हालांकि, यह पूरी तरह से लागू करने की उनकी पसंद होती है. Chrome अब भी वही उपयोगकर्ता-एजेंट फ़ॉर्मैट भेज रहा है. साथ ही, ऐसे बॉट जो अपने आइडेंटिफ़ायर को Chrome की उपयोगकर्ता एजेंट स्ट्रिंग के आखिर में जोड़ते हैं, वे ऐसा करना जारी रख सकते हैं.

किसी बॉट से जुड़ी किसी भी समस्या के लिए, सीधे उसके मालिकों से संपर्क किया जा सकता है. इससे यह पूछा जा सकता है कि क्या वे अपनी उपयोगकर्ता-एजेंट स्ट्रिंग में बदलाव करने के बारे में कोई सोच रहे हैं.

दिलचस्पी दिखाएं और सुझाव/राय दें या शिकायत करें

ज़्यादा जानें