उपयोगकर्ता-एजेंट क्लाइंट हिंट पर माइग्रेट करना

आपकी साइट को उपयोगकर्ता-एजेंट स्ट्रिंग पर भरोसा करने के बजाय, नए उपयोगकर्ता-एजेंट क्लाइंट हिंट पर माइग्रेट करने की रणनीतियां.

Rowan Merewood

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

इस लेख में, उपयोगकर्ता-एजेंट डेटा के आपके ऐक्सेस के ऑडिट और उपयोगकर्ता-एजेंट स्ट्रिंग के इस्तेमाल को उपयोगकर्ता-एजेंट क्लाइंट हिंट पर माइग्रेट करने का तरीका बताया गया है.

ऑडिट के लिए, उपयोगकर्ता एजेंट का डेटा इकट्ठा करना और उसका इस्तेमाल करना

डेटा इकट्ठा करने के किसी भी अन्य तरीके की तरह, आपको हमेशा यह समझना चाहिए कि उसे क्यों इकट्ठा किया जा रहा है. पहला कदम, चाहे आप कोई भी कार्रवाई करें या न करें, यह समझना कि उपयोगकर्ता एजेंट डेटा का इस्तेमाल कहां और क्यों किया जा रहा है.

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

फ़ंक्शन के हिसाब से, अपने कोड में उस जगह के बारे में सोचें जहां रिकॉर्ड किया जा रहा है या प्रोसेस किया जा रहा है:

  • ब्राउज़र का नाम या वर्शन
  • ऑपरेटिंग सिस्टम का नाम या वर्शन
  • डिवाइस का ब्रैंड या मॉडल
  • सीपीयू का टाइप, आर्किटेक्चर या बिटनेस (उदाहरण के लिए, 64-बिट)

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

क्या उपयोगकर्ता एजेंट के सिर्फ़ बेसिक डेटा का इस्तेमाल किया जा रहा है?

यूज़र-एजेंट क्लाइंट हिंट के डिफ़ॉल्ट सेट में ये चीज़ें शामिल हैं:

  • Sec-CH-UA: ब्राउज़र का नाम और मेजर/अहम वर्शन
  • Sec-CH-UA-Mobile: मोबाइल डिवाइस की बूलियन वैल्यू से पता चलता है
  • Sec-CH-UA-Platform: ऑपरेटिंग सिस्टम का नाम
    • ध्यान दें कि इसे स्पेसिफ़िकेशन में अपडेट कर दिया गया है. जल्द ही, इसे Chrome और Chromium के अन्य ब्राउज़र में दिखने लगेगा.

प्रस्तावित उपयोगकर्ता-एजेंट स्ट्रिंग के छोटे वर्शन में भी इस बुनियादी जानकारी को पुराने सिस्टम के साथ काम करने वाले तरीके से सेव रखा जाएगा. उदाहरण के लिए, Chrome/90.0.4430.85 के बजाय स्ट्रिंग में Chrome/90.0.0.0 शामिल होगा.

सिर्फ़ ब्राउज़र के नाम, मेजर वर्शन या ऑपरेटिंग सिस्टम के लिए उपयोगकर्ता एजेंट स्ट्रिंग की जांच करते समय, आपका कोड काम करता रहेगा. हालांकि, कोड काम न करने की चेतावनियां दिख सकती हैं.

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

रणनीति: मांग पर क्लाइंट-साइड JavaScript API

अगर फ़िलहाल navigator.userAgent का इस्तेमाल किया जा रहा है, तो उपयोगकर्ता एजेंट स्ट्रिंग को पार्स करने से पहले, आपको navigator.userAgentData को प्राथमिकता देनी चाहिए.

if (navigator.userAgentData) {
  // use new hints
} else {
  // fall back to user-agent string parsing
}

मोबाइल या डेस्कटॉप के लिए, बूलियन mobile वैल्यू का इस्तेमाल करें:

const isMobile = navigator.userAgentData.mobile;

userAgentData.brands, brand और version प्रॉपर्टी वाले ऑब्जेक्ट का कलेक्शन है. इसमें ब्राउज़र उन ब्रैंड के साथ काम करने की सूची बना सकता है. इसे सीधे तौर पर कलेक्शन के तौर पर ऐक्सेस किया जा सकता है. इसके अलावा, some() कॉल का इस्तेमाल करके भी यह देखा जा सकता है कि कोई खास एंट्री मौजूद है या नहीं:

function isCompatible(item) {
  // In real life you most likely have more complex rules here
  return ['Chromium', 'Google Chrome', 'NewBrowser'].includes(item.brand);
}
if (navigator.userAgentData.brands.some(isCompatible)) {
  // browser reports as compatible
}

अगर आपको ज़्यादा जानकारी वाली हाई-एंट्रॉपी वाली उपयोगकर्ता-एजेंट वैल्यू में से किसी एक की ज़रूरत है, तो आपको उस वैल्यू के बारे में बताना होगा और नतीजे के तौर पर दिखाए गए Promise में देखना होगा:

navigator.userAgentData.getHighEntropyValues(['model'])
  .then(ua => {
    // requested hints available as attributes
    const model = ua.model
  });

अगर आपको सर्वर साइड प्रोसेसिंग से क्लाइंट-साइड प्रोसेसिंग पर स्विच करना है, तो यह रणनीति भी इस्तेमाल की जा सकती है. JavaScript API को एचटीटीपी अनुरोध के हेडर के ऐक्सेस की ज़रूरत नहीं होती. इसलिए, उपयोगकर्ता एजेंट वैल्यू के लिए किसी भी समय अनुरोध किया जा सकता है.

रणनीति: स्टैटिक सर्वर साइड हेडर

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

अगर उपयोगकर्ता एजेंट के डेटा के आधार पर दिखाए गए जवाबों को बदलना या पसंद के मुताबिक बनाना है, तो इस रणनीति का इस्तेमाल करें.

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

उदाहरण के लिए, Chrome की मौजूदा डिफ़ॉल्ट सेटिंग इस तरह दिखेंगी:

⬇️ रिस्पॉन्स हेडर

Accept-CH: Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA

अगर आपको रिस्पॉन्स के तौर पर डिवाइस का मॉडल भी चाहिए, तो आपको यह भेजना होगा:

⬇️ रिस्पॉन्स हेडर

Accept-CH: Sec-CH-UA-Mobile, Sec-CH-UA-Model, Sec-CH-UA-Platform, Sec-CH-UA

इसे सर्वर-साइड पर प्रोसेस करते समय, आपको सबसे पहले यह देखना चाहिए कि आपकी पसंद का Sec-CH-UA हेडर भेजा गया है या नहीं. इसके बाद, उपलब्ध न होने पर User-Agent हेडर पर वापस जाएं.

रणनीति: क्रॉस-ऑरिजिन अनुरोधों के लिए संकेत सौंपना

अगर आपने ऐसे क्रॉस-ऑरिजिन या क्रॉस-साइट सब-रिसॉर्स के लिए अनुरोध किया है जिनके लिए, उनके अनुरोधों पर उपयोगकर्ता एजेंट क्लाइंट हिंट भेजना ज़रूरी है, तो आपको अनुमतियों की नीति का इस्तेमाल करके, साफ़ तौर पर सही संकेत देने होंगे.

उदाहरण के लिए, मान लें कि https://blog.site, https://cdn.site पर संसाधनों को होस्ट करता है. ये संसाधन, किसी खास डिवाइस के लिए ऑप्टिमाइज़ किए गए संसाधन दिखा सकते हैं. https://blog.site, Sec-CH-UA-Model संकेत मांग सकता है, लेकिन Permissions-Policy हेडर का इस्तेमाल करके इसे साफ़ तौर पर https://cdn.site को सौंपना होगा. नीति से कंट्रोल होने वाले संकेतों की सूची, क्लाइंट हिंट इन्फ़्रास्ट्रक्चर ड्राफ़्ट में उपलब्ध है

⬇️ संकेत सौंपने के लिए blog.site से जवाब मिला

Accept-CH: Sec-CH-UA-Model
Permissions-Policy: ch-ua-model=(self "https://cdn.site")

⬆️ cdn.site के सबरिसॉर्स के लिए अनुरोध में बताया गया संकेत शामिल है

Sec-CH-UA-Model: "Pixel 5"

आपके पास एक से ज़्यादा ऑरिजिन के लिए, एक से ज़्यादा हिंट देने का विकल्प होता है, न कि सिर्फ़ ch-ua रेंज से:

⬇️ blog.site से मिला जवाब, जिसमें एक से ज़्यादा ऑरिजिन को एक से ज़्यादा ऑरिजिन के लिए शामिल किया गया है

Accept-CH: Sec-CH-UA-Model, DPR
Permissions-Policy: ch-ua-model=(self "https://cdn.site"),
                    ch-dpr=(self "https://cdn.site" "https://img.site")

रणनीति: iframe को संकेत सौंपना

क्रॉस-ऑरिजिन iframe, क्रॉस-ऑरिजिन रिसॉर्स की तरह ही काम करते हैं. हालांकि, आपने allow एट्रिब्यूट में वे संकेत तय किए होते हैं जिन्हें आपको डेलिगेट करना है.

⬇️ blog.site से मिला जवाब

Accept-CH: Sec-CH-UA-Model

blog.site के लिए ↪️ एचटीएमएल

<iframe src="https://widget.site" allow="ch-ua-model"></iframe>

⬆️ widget.site को भेजा गया अनुरोध

Sec-CH-UA-Model: "Pixel 5"

iframe में allow एट्रिब्यूट ऐसे किसी भी Accept-CH हेडर को बदल देगा जो widget.site खुद को भेज सकता है. इसलिए, पक्का करें कि आपने पूरी जानकारी दी है या यह बताया है कि iframe की साइट को इसकी ज़रूरत है या नहीं.

रणनीति: डाइनैमिक सर्वर-साइड संकेत

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

यहां ध्यान देने वाली खास बात यह है कि Accept-CH हेडर का हर इंस्टेंस, मौजूदा सेट को असरदार तरीके से ओवरराइट कर देगा. इसलिए, अगर हेडर को डाइनैमिक तरीके से सेट किया जा रहा है, तो हर पेज को संकेतों के पूरे सेट का अनुरोध करना होगा.

उदाहरण के लिए, हो सकता है कि आपकी साइट पर एक ऐसा सेक्शन हो जहां आपको उपयोगकर्ता के ऑपरेटिंग सिस्टम से मेल खाने वाले आइकॉन और कंट्रोल उपलब्ध कराने हों. इसके लिए, हो सकता है कि आप सही सबरिसॉर्स दिखाने के लिए, Sec-CH-UA-Platform-Version अलग से इस्तेमाल करना चाहें.

⬇️ /blog के लिए रिस्पॉन्स हेडर

Accept-CH: Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA

⬇️ /app के लिए रिस्पॉन्स हेडर

Accept-CH: Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA-Platform-Version, Sec-CH-UA

रणनीति: पहले अनुरोध पर सर्वर-साइड संकेत ज़रूरी हैं

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

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

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

⬆️ शुरुआती अनुरोध

[With default headers]

⬇️ रिस्पॉन्स हेडर

Accept-CH: Sec-CH-UA-Model
Critical-CH: Sec-CH-UA-Model

🔃 ब्राउज़र अतिरिक्त हेडर के साथ शुरुआती अनुरोध को फिर से करने की कोशिश करता है

[With default headers + …]
Sec-CH-UA-Model: Pixel 5

इससे, पहले अनुरोध पर ही दोबारा कोशिश करने पर अतिरिक्त खर्च करना पड़ेगा. हालांकि, इसे लागू करने की लागत कम है. अतिरिक्त हेडर भेजें और बाकी काम ब्राउज़र कर देगा.

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

रणनीति: लेगसी सपोर्ट

आपकी साइट पर ऐसा लेगसी या तीसरे पक्ष का कोड हो सकता है जो navigator.userAgent पर निर्भर करता है. इसमें उपयोगकर्ता एजेंट स्ट्रिंग के वे हिस्से भी शामिल हैं जिन्हें कम किया जाएगा. लंबे समय के लिए, आपको समान navigator.userAgentData कॉल पर स्विच करना चाहिए. हालांकि, इसका एक फ़िलहाल हल नहीं है.

UA-CH रेट्रोफ़िल एक छोटी लाइब्रेरी है. इसमें navigator.userAgent को, अनुरोध की गई navigator.userAgentData वैल्यू से बनाई गई नई स्ट्रिंग से बदला जा सकता है.

उदाहरण के लिए, यह कोड एक उपयोगकर्ता एजेंट स्ट्रिंग जनरेट करेगा, जिसमें "मॉडल" संकेत भी शामिल होता है:

import { overrideUserAgentUsingClientHints } from './uach-retrofill.js';
overrideUserAgentUsingClientHints(['model'])
  .then(() => { console.log(navigator.userAgent); });

इस नतीजे के साथ मिली स्ट्रिंग में Pixel 5 मॉडल दिखेगा. हालांकि, कम की गई 92.0.0.0 वैल्यू अब भी दिखेगी, क्योंकि uaFullVersion संकेत का अनुरोध नहीं किया गया है:

Mozilla/5.0 (Linux; Android 10.0; Pixel 5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.0.0 Mobile Safari/537.36

अतिरिक्त सहायता

अगर ये रणनीतियां आपके इस्तेमाल के उदाहरण को कवर नहीं करती हैं, तो कृपया Privacy-sandbox-dev-support Repo में चर्चा करें. इससे हम आपकी समस्या के बारे में साथ मिलकर बेहतर तरीके से जान पाएंगे.

Unस्प्लैश पर रिकार्डो रोचा की फ़ोटो