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

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

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

फ़िंगरप्रिंटिंग से उपयोगकर्ता की निजता क्यों बनी रहती है

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

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

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

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

ऐसा करें

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अनुमान लगाना मुश्किल है

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

निजता बजट लागू करना

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

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

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

ऐसा करें

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

क्रॉस-ब्राउज़र टेस्टिंग टूल

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

हालांकि, साइट का ऑडिट हो जाने के बाद, एपीआई की जांच से इस बात की पुष्टि होगी कि ब्राउज़र के नए वर्शन या आने वाले "बीटा" और "झलक" वर्शन में कुछ भी काम नहीं कर रहा है. यह जांच आपके मौजूदा टेस्ट सुइट के हिस्से के तौर पर होनी चाहिए. अपने-आप काम करने वाले टूल को एपीआई के प्लैटफ़ॉर्म कवरेज के साथ काम करते समय यह ध्यान में रखना चाहिए कि ज़्यादातर ब्राउज़र उपलब्ध एपीआई और सुविधाओं पर कुछ हद तक कंट्रोल देते हैं. Firefox की तरह Chrome कमांड लाइन स्विच की मदद से ऐसा करता है. टेस्टिंग टूल के सेटअप में इनका ऐक्सेस होने से, आपको एपीआई बंद या चालू करके, कुछ टेस्ट चलाने में मदद मिलेगी. उदाहरण के लिए, लॉन्च करते समय ब्राउज़र फ़्लैग जोड़ने के तरीकों के बारे में जानने के लिए, साइप्रस का ब्राउज़र-लॉन्च प्लगिन और puppeteer का 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 पर सेट किया जाता है. ज़्यादा जानकारी के लिए, उपयोगकर्ता-एजेंट स्ट्रिंग को कम करने के बारे में अपडेट देखें. उपयोगकर्ता-एजेंट स्ट्रिंग में डेटा को कम करने की योजना के बारे में सटीक जानकारी, उपयोगकर्ता-एजेंट में कम करने की सुविधा पर उपलब्ध है. हालांकि, कम शब्दों में कहें, तो रिपोर्ट किए गए ब्राउज़र का वर्शन नंबर सिर्फ़ मेजर वर्शन वाला होगा. इसलिए, वर्शन नंबर 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 का कौनसा वर्शन, ब्राउज़र का माइनर वर्शन है) फ़्रीज़ होने के बाद उपलब्ध नहीं होगी.

इसकी तुलना किसी अलग प्लैटफ़ॉर्म पर, "मौजूदा" 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 पर ओएस वर्शन भी देती है, लेकिन बाकी सब फ़्रीज़ हो जाता है. इसलिए, किसी काल्पनिक 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 सारांश, बदलाव की कुछ तर्क और वजहें बताता है. साथ ही, रोवन मेरेवुड के पास एक स्लाइड डेक है, जिसमें अलग करने के लिए उपयोगकर्ता-एजेंट का इस्तेमाल न करने से माइग्रेट करने की कुछ रणनीतियां हैं.

फ़ज़िंग

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

ऐसा करें

• उपयोगकर्ता-एजेंट स्ट्रिंग पर निर्भर करने के लिए अपना कोड बेस देखें (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
}