ऑनलाइन ट्रैकिंग

फ़िंगरप्रिंट का मतलब है, आपकी वेबसाइट पर वापस आने वाले उपयोगकर्ता को पहचानने या अलग-अलग वेबसाइटों पर एक ही उपयोगकर्ता को पहचानने की कोशिश करना. आपके सेटअप और किसी अन्य व्यक्ति के सेटअप में कई विशेषताएं अलग हो सकती हैं. उदाहरण के लिए, हो सकता है कि आपके पास अलग तरह के डिवाइस हों जिनमें अलग-अलग फ़ॉन्ट और उनकी स्क्रीन का साइज़ अलग-अलग हो. अगर मेरे पास "Dejavu Sans" फ़ॉन्ट इंस्टॉल है और आपके पास नहीं है, तो कोई भी वेबसाइट उस फ़ॉन्ट की जांच करके, आपके और मेरे बीच का अंतर बता सकती है. इस तरह फ़िंगरप्रिंट की सुविधा काम करती है; की मदद से इन डेटा पॉइंट का कलेक्शन बनाया जाता है. साथ ही, हर डेटा पॉइंट की मदद से, उपयोगकर्ताओं के बीच अंतर किया जा सकता है.

फ़िंगरप्रिंट की ज़्यादा औपचारिक परिभाषा कुछ इस तरह की हो सकती है: फ़िंगरप्रिंट, किसी उपयोगकर्ता के सेटअप की ऐसी विशेषताओं का इस्तेमाल करना है जो लंबे समय तक मौजूद रहती हैं. इनका इस्तेमाल करके, उपयोगकर्ता को ज़्यादा से ज़्यादा अन्य उपयोगकर्ताओं से अलग करने की कोशिश की जाती है.

फ़िंगरप्रिंट की सुविधा से उपयोगकर्ता की निजता को कैसे खतरा पहुंचता है

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

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

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

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

यह करें

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

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

फ़िंगरप्रिंट की सुविधा कैसे काम करती है

आम तौर पर, इन सभी एट्रिब्यूट का आपका निजी कॉम्बिनेशन, आपके लिए या कम से कम आप जैसे लोगों के छोटे ग्रुप के लिए यूनीक होता है. इसका इस्तेमाल, आपको गुप्त रूप से ट्रैक करने के लिए किया जा सकता है.

अलग से: पैसिव और ऐक्टिव फ़िंगरप्रिंट

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

इसके अलावा: फ़िंगरप्रिंट की क्षमता को मापना

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

ब्राउज़र, फ़िंगरप्रिंटिंग के ख़िलाफ़ क्या करते हैं?

अहम बात यह है कि ब्राउज़र वेंडर को किसी वेबसाइट (या वेबसाइट में शामिल किसी तीसरे पक्ष) के लिए कई अलग-अलग तरीकों की जानकारी होती है. इसका इस्तेमाल, उपयोगकर्ता के फ़िंगरप्रिंट की पहचान करने के लिए किया जा सकता है. इसके अलावा, फ़िंगरप्रिंट की पहचान करने के लिए, अलग-अलग जानकारी का इस्तेमाल किया जा सकता है फ़िंगरप्रिंट का एक छोटा सा हिस्सा है. इनमें से कुछ तरीके साफ़ तौर पर और जान-बूझकर किए जाते हैं, जैसे कि ब्राउज़र की उपयोगकर्ता-एजेंट स्ट्रिंग जो अक्सर इस्तेमाल किए जा रहे ब्राउज़र, ऑपरेटिंग सिस्टम, और संस्करण की पहचान करता है (और इस तरह यह आपको मुझसे अलग करता है, यदि आप और मैं भिन्न ब्राउज़र का उपयोग कर रहा/रही हूं). कुछ तरीके जान-बूझकर फ़िंगरप्रिंट के लिए नहीं बनाए गए हैं, लेकिन आखिरकार ऐसा हो जाता है जैसे कि फ़ॉन्ट की सूची या ब्राउज़र में उपलब्ध वीडियो और ऑडियो डिवाइस. (ब्राउज़र को इन डिवाइसों का इस्तेमाल करने की ज़रूरत नहीं है. उसे सिर्फ़ नाम के हिसाब से उनकी सूची चाहिए.) इनमें से कुछ डिवाइसों को फ़िंगरप्रिंट का इस्तेमाल करने में मदद करने के लिए जाना जाता है रिलीज़ के बाद, जैसे कि कैनवस एलिमेंट पर फ़ॉन्ट का हूबहू पिक्सल रेंडरिंग. और भी बहुत से ब्राउज़र हैं और आपका ब्राउज़र जिस तरह से मेरे ब्राउज़र से अलग है वह एंट्रॉपी जोड़ता है और इस तरह से आपके और मेरे बीच का अंतर बताने का एक तरीका है. साथ ही, सभी वेबसाइटों पर किसी व्यक्ति की खास तरह से पहचान करना. https://amiunique.org के पास फ़िंगरप्रिंट का इस्तेमाल करने वाले संभावित टूल की एक लंबी (हालांकि, पूरी जानकारी नहीं है) सूची है सुविधाएं होती हैं, और सूची हर समय बढ़ती जाती है (क्योंकि उपयोगकर्ताओं को फ़िंगरप्रिंट कर पाने में बहुत ज़्यादा रुचि होती है, भले ही उपयोगकर्ता नहीं चाहिए या शायद उसकी उम्मीद नहीं है).

कुछ बेहतरीन एपीआई काम नहीं करते

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

उपयोगकर्ता की अनुमतियों का गेटवे

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

अनचाहे कॉन्टेंट को जोड़ना

कुछ मामलों में, ब्राउज़र वेंडर तीसरा तरीका अपनाते हैं. इसमें वे एपीआई के जवाबों को "फ़ज़" करते हैं, ताकि उन्हें ज़्यादा जानकारी देने वाला और पहचान ज़ाहिर करने वाला न बनाया जा सके. डेटा मॉड्यूल में, इसे रैंडमाइज़ किए गए जवाब के तरीके के हिस्से के तौर पर बताया गया था. इसमें बताया गया था कि उपयोगकर्ताओं से डेटा इकट्ठा करते समय, ऐसा किया जा सकता है. इससे, अनजाने में ऐसा डेटा इकट्ठा होने से बचा जा सकता है जिससे उपयोगकर्ता की पहचान की जा सकती है. ब्राउज़र वेंडर, वेब ऐप्लिकेशन और तीसरे पक्षों के लिए उपलब्ध एपीआई डेटा के लिए भी यह तरीका अपना सकते हैं. इसका एक उदाहरण, window.performance.now() से मिले पेज की परफ़ॉर्मेंस को मेज़र करने के लिए इस्तेमाल किए जाने वाले, समय का सटीक पता लगाने वाले एपीआई हैं. ब्राउज़र इन वैल्यू को जानता है लेकिन लौटाए गए मानों को निकटतम 20 माइक्रोसेकंड में पूर्णांकित करके जान-बूझकर शुद्धता में कम किया जाता है सीमा तय कर दी है. यहां हमारा लक्ष्य है इससे यह पक्का किया जा सकेगा कि एपीआई आपके काम आ सकें. हालांकि, इससे जवाबों की पहचान कम हो सके: इसका मतलब है कि "हर्ड इम्यूनिटी" बनाने में आपका डिवाइस आपके लिए अनूठा होने के बजाय, हर किसी के डिवाइस जैसा ही दिखाई देता है. Safari, सिस्टम कॉन्फ़िगरेशन का आसान वर्शन दिखाता है इसी वजह से.

निजता से जुड़ा बजट लागू करना

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

बड़े पैमाने पर टेस्टिंग एनवायरमेंट का इस्तेमाल करना

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

यह करें

  • टेस्टिंग के दौरान किन ब्राउज़र को प्राथमिकता देनी है, यह तय करने के लिए अपने आंकड़े और ऑडियंस की जांच करें.
  • इन ब्राउज़र की जांच की जा सकती है: डेस्कटॉप पर Firefox, Chrome, Edge, Safari, Android पर Chrome, और Samsung Internet के साथ-साथ iOS पर Safari ब्राउज़र का इस्तेमाल भी कर सकते हैं. इससे यह पक्का होता है कि आपने तीन मुख्य रेंडरिंग इंजन (Firefox में Gecko, Chrome, Edge, और Samsung Internet में Blink के अलग-अलग फ़ॉर्क, और Safari में Webkit) और मोबाइल और डेस्कटॉप, दोनों प्लैटफ़ॉर्म पर जांच की है.
  • अगर आपकी साइट का इस्तेमाल टैबलेट, स्मार्टवॉच या गेम कंसोल जैसे कम इस्तेमाल होने वाले डिवाइसों पर भी किया जा सकता है, तो वहां भी टेस्ट करें. कुछ हार्डवेयर प्लैटफ़ॉर्म, ब्राउज़र को अपडेट करने में मोबाइल और डेस्कटॉप के मुकाबले देरी कर सकते हैं. इस वजह से, हो सकता है कि कुछ एपीआई लागू न किए गए हों या उन प्लैटफ़ॉर्म के ब्राउज़र में उपलब्ध नहीं है.
  • एक या उससे ज़्यादा ऐसे ब्राउज़र से जांच करें जो उपयोगकर्ता की निजता को बढ़ावा देने का दावा करते हैं. अगर आपके पास उपलब्ध हो, तो अपने सबसे ज़्यादा इस्तेमाल किए जाने वाले ब्राउज़र के रिलीज़ होने से पहले के वर्शन और टेस्ट वर्शन शामिल करें: Safari का टेक्नोलॉजी की झलक, Chrome का Canary, और Firefox का बीटा चैनल. इनसे आपको एपीआई के काम न करने और उन बदलावों की पहचान करने का सबसे अच्छा मौका मिलता है जिनसे आपकी साइटों पर असर पड़ता है. ऐसा, इन बदलावों से आपके उपयोगकर्ताओं पर असर पड़ने से पहले किया जा सकता है. इसी तरह, अपने पास मौजूद किसी भी आंकड़े के संदर्भ में, उपयोगकर्ताओं के एनवायरमेंट को ध्यान में रखें. अगर आपके उपयोगकर्ताओं में पुराने Android फ़ोन का इस्तेमाल करने वाले लोगों की संख्या ज़्यादा है, तो अपने टेस्ट में उन्हें ज़रूर शामिल करें. ज़्यादातर लोगों के पास, डेवलपमेंट टीम के पास मौजूद तेज़ हार्डवेयर और नई रिलीज़ नहीं होती हैं.
  • नई प्रोफ़ाइल और गुप्त/निजी ब्राउज़िंग मोड, दोनों का इस्तेमाल करके देखें. हो सकता है कि आपने अपनी निजी प्रोफ़ाइल में ज़रूरी अनुमतियां पहले ही दे दी हों. जांच करें कि किसी सवाल के लिए साइट को अनुमति देने से क्या होता है.
  • Firefox के फ़िंगरप्रिंटिंग से सुरक्षा मोड में, अपने पेजों की साफ़ तौर पर जांच करें. अगर आपके पेज पर फ़िंगरप्रिंट की सुविधा का इस्तेमाल किया जा रहा है, तो ऐसा करने पर आपको अनुमति वाले डायलॉग दिखेंगे. इसके अलावा, कुछ एपीआई के लिए, फ़ज़ज़ किया गया डेटा भी दिखेगा. इससे आपको यह पुष्टि करने में मदद मिलती है कि आपकी सेवा में शामिल तीसरे पक्ष, फ़िंगरप्रिंट वाले डेटा का इस्तेमाल कर रहे हैं या नहीं. इसके अलावा, यह भी पता चलता है कि आपकी सेवा उस डेटा पर निर्भर है या नहीं. इसके बाद, यह देखा जा सकता है कि जान-बूझकर फ़ज़ किए गए डेटा की वजह से, आपको ज़रूरी काम करने में ज़्यादा मुश्किल हो रही है या नहीं. अपने वीडियो के लिए उसमें बदलाव करके उसे किसी दूसरे सोर्स से डाउनलोड करें, उसके बिना करें या कम जानकारी वाले डेटा का इस्तेमाल करें.
  • जैसा कि तीसरे पक्ष के मॉड्यूल में पहले बताया गया था, तीसरे पक्ष का ऑडिट करना भी ज़रूरी है पर निर्भर होता है कि वे फ़िंगरप्रिंटिंग तकनीकों का इस्तेमाल कर रहे हैं या नहीं. पैसिव फ़िंगरप्रिंटिंग का पता लगाना मुश्किल है. अगर तीसरा पक्ष अपने सर्वर पर ऐसा करता है, तो इसका पता लगाना असंभव है. हालांकि, फ़िंगरप्रिंटिंग मोड से फ़िंगरप्रिंटिंग की कुछ तकनीकों का पता चल सकता है. साथ ही, navigator.userAgent के इस्तेमाल या <canvas> ऑब्जेक्ट के अनचाहे तौर पर बनने से, कुछ ऐसे तरीके भी पता चल सकते हैं जिनकी ज़्यादा जांच की ज़रूरत है. तीसरे पक्ष के बारे में बताने वाले मार्केटिंग या तकनीकी कॉन्टेंट में, "संभावित मैचिंग" शब्द के इस्तेमाल को भी ध्यान में रखना चाहिए. इससे कभी-कभी फ़िंगरप्रिंट करने की तकनीकों के इस्तेमाल का पता चल सकता है.

अलग-अलग ब्राउज़र पर काम करने वाले टेस्टिंग टूल

निजता के मकसद से अपने कोड की जांच को ऑटोमेट करना मुश्किल है. साथ ही, मैन्युअल तरीके से जांच करते समय किन बातों का ध्यान रखना है, इस बारे में पहले बताया गया है. उदाहरण के लिए, अगर साइट को किसी एपीआई को ऐक्सेस करने की अनुमति नहीं दी जाती है, तो क्या होता है और उपयोगकर्ता को यह जानकारी कैसे दी जाती है? अपने-आप होने वाले टेस्ट से यह पता नहीं लगाया जा सकता कि साइट ऐसा काम करती है या नहीं, ताकि उपयोगकर्ता को उस पर भरोसा करने में मदद मिल सके या वह उपयोगकर्ता को उस पर भरोसा न करने के लिए बढ़ावा दे सके. या आपको लगता है कि कुछ छिपा हुआ है.

हालांकि, साइट की ऑडिट होने के बाद, एपीआई की जांच अपने-आप की जा सकती है. इससे यह पक्का किया जा सकता है कि ब्राउज़र के नए वर्शन या आने वाले समय में रिलीज़ होने वाले "बीटा" और "झलक" वर्शन में कोई समस्या नहीं है. यह जांच, आपके मौजूदा टेस्ट सुइट का हिस्सा होनी चाहिए. कुछ एपीआई सरफ़ेस कवरेज के साथ काम करते समय, अपने ऑटोमेटेड टेस्ट टूल की मदद से यह तय कर सकते हैं कि ज़्यादातर ब्राउज़र, यह कंट्रोल किया जा सकता है कि कौनसे एपीआई और सुविधाएं उपलब्ध हैं. Chrome ऐसा कमांड लाइन स्विच के ज़रिए करता है, जैसे Firefox करता है और टेस्टिंग टूल में इनकी ऐक्सेस होती है सेटअप से, आपको एपीआई को बंद या चालू करके कुछ टेस्ट करने की सुविधा मिलेगी. (उदाहरण के लिए, देखें कि साइप्रस की ब्राउज़र-लॉन्च प्लगिन दूसरे तरीकों के लिए, कठपुतली का launch.orgs पैरामीटर का नाम का इस्तेमाल करें.)

सिर्फ़ अनुमानित जानकारी के लिए उपयोगकर्ता एजेंट स्ट्रिंग पर भरोसा करें

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

Mozilla/5.0 (Linux; Android 6.0.1; SGP771 Build/32.2.A.0.253; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/52.0.2743.98 Safari/537.36.

अन्य बातों के अलावा, यह दावा करता है कि यह Mozilla/5.0, एक ऐसा ब्राउज़र है जिसे पहले अंतरिक्ष यात्रियों के ठीक उसी समय रिलीज़ किया गया था दो दशक से भी ज़्यादा समय पहले अंतरराष्ट्रीय अंतरिक्ष स्टेशन गए. उपयोगकर्ता-एजेंट स्ट्रिंग, फ़िंगरप्रिंट के लिए एन्ट्रॉपी का एक बेहतरीन सोर्स है. फ़िंगरप्रिंट की सुविधा को कम करने के लिए, ब्राउज़र बनाने वाली कंपनियों ने उपयोगकर्ता-एजेंट हेडर को पहले ही फ़्रीज़ कर दिया है या ऐसा करने की कोशिश कर रही हैं. यह एपीआई से मिलने वाले डेटा को बदलने का एक और उदाहरण है. इसके लिए, एपीआई को पूरी तरह से हटाना ज़रूरी नहीं है. खाली user-agent हेडर भेजने से, ऐसी अनगिनत वेबसाइटें काम नहीं करेंगी जो यह मानती हैं कि यह हेडर मौजूद है. इसलिए, आम तौर पर ब्राउज़र उसमें से कुछ जानकारी हटा देते हैं और फिर उसमें कोई बदलाव नहीं करते. (Safari, Chrome, और Firefox में ऐसा होता हुआ देखा जा सकता है.) यह सुरक्षा, पूरी तरह से फ़िंगरप्रिंटिंग का मतलब है कि उपयोगकर्ता एजेंट हेडर के सटीक होने पर भरोसा नहीं किया जा सकता. इसके अलावा, ऐसा करने से पहले, वैकल्पिक डेटा सोर्स खोजना ज़रूरी होता है.

हम साफ़ तौर पर बता रहे हैं कि उपयोगकर्ता-एजेंट का डेटा पूरी तरह से हटाया नहीं जा रहा है. हालांकि, डेटा का स्तर कम है या कभी-कभी गलत होता है क्योंकि एक पुरानी, लेकिन न बदलने वाली संख्या की रिपोर्ट की जा सकती है. उदाहरण के लिए, Firefox, Safari, और Chrome, macOS के वर्शन की जानकारी में ज़्यादा से ज़्यादा 10 वर्शन शामिल करते हैं. इस बारे में ज़्यादा जानने के लिए, उपयोगकर्ता एजेंट स्ट्रिंग को कम करने के बारे में अपडेट देखें. Chrome, उपयोगकर्ता-एजेंट स्ट्रिंग में डेटा को कैसे कम करेगा, इसकी सटीक जानकारी उपयोगकर्ता-एजेंट को कम करने की सुविधा पर उपलब्ध है लेकिन संक्षेप में, आप रिपोर्ट किए गए ब्राउज़र वर्शन नंबर में सिर्फ़ मेजर वर्शन शामिल होने की उम्मीद कर सकते हैं (इसलिए वर्शन नंबर ब्राउज़र के वर्शन 123.0.0.0 की तरह दिखेगा, भले ही ब्राउज़र का वर्शन 123.10.45.108 ही क्यों न हो) और ओएस वर्शन में कोई जानकारी नहीं होगी और न बदलने वाले विकल्पों में से किसी एक पर फ़्रीज़ करें. इसलिए, "Windows 20" पर चल रहे Chrome के 123.45.67.89 वर्शन का वर्शन नंबर इस तरह दिखेगा:

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

हालांकि, आपको जो मुख्य जानकारी चाहिए वह अब भी उपलब्ध है. जैसे, ब्राउज़र का वर्शन: Windows पर Chrome 123. हालांकि, नियंत्रण वाली कंपनी को जानकारी (चिप आर्किटेक्चर, Windows वर्शन, Safari के किस वर्शन की नकल की जा रही है, ब्राउज़र का माइनर वर्शन) फ़्रीज़ होने के बाद उपलब्ध नहीं होगा.

इसकी तुलना "मौजूदा" से करें किसी दूसरे प्लैटफ़ॉर्म पर Chrome उपयोगकर्ता एजेंट:

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36,

इससे पता चलता है कि Chrome के वर्शन नंबर (104) और प्लैटफ़ॉर्म आइडेंटिफ़ायर में ही अंतर है.

इसी तरह, Safari की उपयोगकर्ता-एजेंट स्ट्रिंग प्लैटफ़ॉर्म और Safari का वर्शन नंबर दिखाती है. साथ ही, iOS पर OS वर्शन भी दिखाती है, लेकिन बाकी सब फ़्रीज़ किया गया है. इसलिए, एक काल्पनिक macOS 20 पर चलने वाला Safari वर्शन 1234.5.67 अपने उपयोगकर्ता एजेंट को इस तरह दे सकता है:

Mozilla/5.0 (Macintosh; **Intel Mac OS X 10_20_0**) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.1 Safari/605.1.15,

और iOS 20 पर यह हो सकता है:

Mozilla/5.0 (iPhone; CPU **iPhone OS 20_0** like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/**20.0 Mobile/15E148 Safari/605.1.15**.

हालांकि, मुख्य जानकारी (यह Safari है, यह iOS या macOS पर है) उपलब्ध है और iOS Safari अब भी iOS वर्शन नंबर दिखाता है. हालांकि, पहले जो अन्य जानकारी उपलब्ध थी वह अब नहीं दिखती. अहम बात यह है कि इसमें Safari के वर्शन का नंबर शामिल होता है, जो ज़रूरी नहीं है कि उपलब्ध हो.

रिपोर्ट किए गए उपयोगकर्ता-एजेंट के बदलावों पर काफ़ी बहस हुई थी. https://github.com/WICG/ua-client-hints#use-cases summarises सारांश बदलाव के कुछ तर्क और वजहें बताई गई हैं. साथ ही, रोवन मेरवुड में एक स्लाइड डेक है के साथ-साथ, UA क्लाइंट हिंट प्रस्ताव के हिसाब से उपयोगकर्ता-एजेंट का इस्तेमाल बंद करने की कुछ रणनीतियों के बारे में बताया गया है.

फ़ज़िंग

फ़ज़िंग, सुरक्षा के तरीकों का एक शब्द है. इसमें एपीआई को अनचाही वैल्यू के साथ इस उम्मीद में कॉल किया जाता है कि वे उन वैल्यू को हैंडल कर पाएं के बारे में जानकारी देनी चाहिए. वेब डेवलपर को क्रॉस-साइट स्क्रिप्टिंग (XSS) के बारे में पता होना चाहिए. इसमें, किसी पेज पर नुकसान पहुंचाने वाली स्क्रिप्ट जोड़ना शामिल है. ऐसा अक्सर इसलिए होता है, क्योंकि पेज में इंजेक्ट किए गए एचटीएमएल को सही तरीके से एस्केप नहीं किया जाता. इसलिए, आपने <script> टेक्स्ट वाली खोज क्वेरी की है. बैक-एंड डेवलपर को SQL इंजेक्शन के बारे में जानकारी होगी, जहां ऐसी डेटाबेस क्वेरी जो उपयोगकर्ता इनपुट की सही तरीके से पुष्टि नहीं करती हैं, उनसे सुरक्षा समस्याएं सामने आती हैं (जैसा कि xkcd के साथ दिखाया गया है Little Bobby Tables). फ़ज़िंग या फ़ज़ टेस्टिंग का इस्तेमाल, एपीआई को कई तरह के अमान्य या अनचाहे इनपुट देने के लिए, अपने-आप किए जाने वाले प्रयासों के लिए किया जाता है. साथ ही, सुरक्षा से जुड़ी जानकारी के लीक होने, क्रैश होने या अन्य गड़बड़ियों की जांच करने के लिए भी इसका इस्तेमाल किया जाता है. जान-बूझकर गलत जानकारी देने के ये सभी उदाहरण हैं. हालांकि, यहां यह किया जा रहा है पहले से ही ब्राउज़र के ज़रिए (उपयोगकर्ता एजेंट को जान-बूझकर गलत बनाकर) ताकि डेवलपर को उस डेटा पर भरोसा करना बंद करने के लिए बढ़ावा मिले.

यह करें

  • उपयोगकर्ता-एजेंट स्ट्रिंग पर कितनी बार भरोसा है, यह जानने के लिए अपना कोड बेस देखें (navigator.userAgent के लिए खोज करने पर, सबसे ज़्यादा बार ये नतीजे मिल सकते हैं कोड डाला गया है और आपका बैकएंड कोड हेडर के तौर पर User-Agent की तलाश कर सकता है, तो इसमें आपका भी शामिल है निर्भरता.
  • अगर आपको अपने कोड में इस्तेमाल का पता चलता है, तो पता करें कि कोड किस चीज़ की जांच कर रहा है. साथ ही, ऐसा करने का कोई और तरीका ढूंढें (या रिप्लेसमेंट डिपेंडेंसी का पता लगाएं या डिपेंडेंसी के तौर पर अपस्ट्रीम का इस्तेमाल करें. इसके लिए, समस्याएं दर्ज करें या अपडेट के लिए उनसे संपर्क करें). कभी-कभी गड़बड़ियों पर काम करने के लिए ब्राउज़र को अलग रखना ज़रूरी है, लेकिन उपयोगकर्ता-एजेंट के फ़्रीज़ होने के बाद, ऐसा करने का तरीका नहीं बदलेगा.
  • आप सुरक्षित हो सकते हैं. अगर ब्रैंड, मेजर वर्शन, और प्लैटफ़ॉर्म की मुख्य वैल्यू का ही इस्तेमाल किया जा रहा है, तो ये वैल्यू काफ़ी हद तक उपलब्ध होना चाहिए और उपयोगकर्ता-एजेंट स्ट्रिंग में सही हो.
  • एमडीएन, उपयोगकर्ता-एजेंट स्ट्रिंग ("ब्राउज़र स्निफ़िंग") पर निर्भर रहने से बचने के अच्छे तरीके बताता है, जिनमें से मुख्य सुविधा है, सुविधा की पहचान.
  • अगर आप किसी भी तरह से उपयोगकर्ता-एजेंट स्ट्रिंग पर निर्भर हैं (यहां तक कि कुछ मुख्य वैल्यू का इस्तेमाल करने पर भी), तो आने वाले समय में ब्राउज़र की नई रिलीज़ में शामिल होने वाले उपयोगकर्ता-एजेंट के साथ जांच करना एक अच्छा आइडिया है. आने वाले समय में रिलीज़ होने वाले ब्राउज़र के वर्शन के साथ, बीटा या टेक्नोलॉजी की झलक वाले बिल्ड की मदद से जांच की जा सकती है. हालांकि, जांच के लिए कस्टम यूज़र-एजेंट स्ट्रिंग भी सेट की जा सकती है. लोकल डेवलपमेंट के दौरान, Chrome, Edge, Firefox, और Safari में उपयोगकर्ता एजेंट स्ट्रिंग को बदला जा सकता है. इससे यह पता चलता है कि आपका कोड, उपयोगकर्ताओं से मिलने वाली अलग-अलग उपयोगकर्ता एजेंट वैल्यू के साथ कैसे काम करता है.

क्लाइंट हिंट

इस तरह की जानकारी देने का एक मुख्य सुझाव है यूज़र-एजेंट क्लाइंट हिंट, हालांकि, यह सभी ब्राउज़र पर काम नहीं करता है. इस्तेमाल किए जा सकने वाले ब्राउज़र, तीन हेडर पास करेंगे: Sec-CH-UA, जो ब्राउज़र के ब्रैंड और वर्शन नंबर की जानकारी देता है; Sec-CH-UA-Mobile, जो यह बताता है कि अनुरोध किसी मोबाइल डिवाइस से आया है या नहीं; और Sec-CH-UA-Platform, जो ऑपरेटिंग सिस्टम का नाम बताता है. (इन हेडर को पार्स करना जितना आसान लगता है उतना आसान नहीं है, क्योंकि ये आसान स्ट्रिंग के बजाय, स्ट्रक्चर्ड हेडर और यह "ट्रिकी" मैसेज भेजने वाले ब्राउज़र से लागू होता है हैं, जिन्हें सही ढंग से पार्स न किए जाने पर गलत ढंग से हैंडल किया जाएगा. यह, पहले की तरह ही ब्राउज़र की ओर से पहले से की जा रही “फ़ज़ टेस्टिंग” का एक उदाहरण है. इस डेटा का इस्तेमाल करने वाले डेवलपर को इसे सही तरीके से मैनेज करना होगा. ऐसा इसलिए, क्योंकि डेटा को इस तरह से डिज़ाइन किया गया है कि गलत या धीमी पार्सिंग से खराब नतीजे मिल सकते हैं. जैसे, ऐसे ब्रैंड दिखाना जो मौजूद नहीं हैं या ऐसी स्ट्रिंग जो सही तरीके से बंद नहीं होती हैं. अच्छी बात यह है कि यह डेटा ब्राउज़र से भी सीधे JavaScript के लिए इस रूप में उपलब्ध कराया जाता है navigator.userAgentData है, जो इसके साथ काम करने वाले ब्राउज़र में कुछ इस तरह का ऑब्जेक्ट दिख सकता है:

{
  "brands": [
    {
    "brand": " Not A;Brand",
    "version": "99"
    },
    {
    "brand": "Chromium",
    "version": "96"
    },
    {
    "brand": "Google Chrome",
    "version": "96"
    }
  ],
  "mobile": false
}