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

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

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

यूज़र-एजेंट क्लाइंट हिंट (UA-CH)

User-Agent Client Hints से, User-Agent के पूरे डेटा को ऐक्सेस किया जा सकता है. हालांकि, ऐसा सिर्फ़ तब किया जा सकता है, जब सर्वर, डेटा के कुछ हिस्सों की ज़रूरत के बारे में साफ़ तौर पर बताते हैं.

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

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

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

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

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

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

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

UA और UA-CH को कम करने की सुविधा कैसे काम करती है?

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

कोई उपयोगकर्ता ब्राउज़र खोलता है और पता बार में 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 की मदद से टैबलेट डिवाइसों का पता लगाना

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

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

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

मैं कम किए गए यूज़र ऐजेंट स्ट्रिंग का इस्तेमाल और उसकी जांच कैसे करूं?

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

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

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

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

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

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

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

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

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

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

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

ज़रूरी जानकारी को ऑप्टिमाइज़ करना

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

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

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

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

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

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

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

Accept-CH हेडर के ज़रिए दिए गए सुझाई गई वैल्यू कितने समय तक भेजी जाएंगी?

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

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

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

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

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

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

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

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

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

सुझाव/राय देना या शिकायत करना

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