फ़िंगरप्रिंटिंग

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

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

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

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

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

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

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

यह करें

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

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

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

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

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

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

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

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

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

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

कुछ खास एपीआई के साथ काम नहीं करता है

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

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

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

अनुमान लगाने की सुविधा जोड़ना

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

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

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

टेस्ट एनवायरमेंट का इस्तेमाल करें

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

यह करें

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

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

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 Summarymarises बदलाव के कुछ तर्क और वजहें बताई गई हैं. साथ ही, रोवन मेरवुड में एक स्लाइड डेक है के साथ-साथ, 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
}