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

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

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

User-Agent Client Hints (UA-CH)

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

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

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

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

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

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

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

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

कम किए गए UA और UA-CH कैसे काम करते हैं?

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

कोई उपयोगकर्ता ब्राउज़र खोलता है और पता बार में 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 Hint हेडर में भी यही जानकारी शामिल करता है. उदाहरण के लिए:

      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 की मदद से टैबलेट डिवाइसों का पता लगाना

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

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

उदाहरण के लिए, अगर 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 का इस्तेमाल और उसकी जांच कैसे करूं?

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

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

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

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

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

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

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

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

क्लाइंट हिंट और क्रिटिकल हिंट के लिए सहायता

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

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

ज़रूरी सलाह ऑप्टिमाइज़ करना

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

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

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

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

BoringSSL (OpenSSL का फ़ॉर्क), Chromium में Google की प्रयोग के तौर पर उपलब्ध सुविधाओं का इस्तेमाल करने में आपकी मदद करता है. फ़िलहाल, ALPS सिर्फ़ BoringSSL में लागू किया गया है.

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

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

Accept-CH हेडर की मदद से, सुझाव कितने समय तक भेजे जाएंगे?

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

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

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

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

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

यूज़र-एजेंट रिडक्शन का, बॉट का पता लगाने पर क्या असर पड़ता है?

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

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

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

दर्शकों से जुड़ना और सुझाव/राय देना या शिकायत करना

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