तीसरे पक्ष

तीसरा पक्ष क्या होता है?

ऐसा बहुत कम होता है कि कोई वेबसाइट पूरी तरह से अपने-आप में पूरी तरह से शामिल हो. एचटीटीपी वेब अलमैनक से पता चलता है कि करीब 95% वेबसाइटों में तीसरे पक्ष का कोई कॉन्टेंट होता है.

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

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

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

हम तीसरे पक्ष के संसाधनों का इस्तेमाल क्यों करते हैं?

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

एचटीटीपी संग्रह का वेब कैलेंडर इससे अच्छा ब्यौरा देता है:

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

तीसरे पक्ष के संसाधन क्या काम कर सकते हैं?

कुछ जानकारी ऐक्सेस की जा रही है

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

क्रॉस-साइट ट्रैकिंग

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

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

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

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

सर्वर साइड तीसरे पक्ष का कोड

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

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

आपको तीसरे पक्षों से सावधान क्यों रहना चाहिए?

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

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

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

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

तीसरे पक्षों के कुछ उदाहरण क्या हैं?

आम तौर पर, हम "तीसरे पक्ष" की बात करते हैं, लेकिन असल में ये दोनों तरह के होते हैं. साथ ही, उनके पास उपयोगकर्ता के अलग-अलग तरह के डेटा का ऐक्सेस होता है. उदाहरण के लिए, किसी अलग सर्वर से लोड किए गए अपने एचटीएमएल में <img> एलिमेंट जोड़ने से, उस सर्वर को आपके उपयोगकर्ताओं के बारे में <iframe> मुमकिन या <script> एलिमेंट की तुलना में अलग जानकारी मिलेगी. ये पूरी सूची देने के बजाय उदाहरण के तौर पर दिए गए हैं. हालांकि, इनसे तीसरे पक्ष के अलग-अलग तरह के आइटम के बीच के फ़र्क़ को समझा जा सकता है. इन आइटम का इस्तेमाल, आपकी साइट पर किया जा सकता है.

क्रॉस-साइट संसाधन का अनुरोध करना

क्रॉस-साइट रिसॉर्स आपकी साइट पर मौजूद होता है, जो किसी दूसरी साइट से लोड किया जाता है. यह <iframe> या <script> नहीं होता. उदाहरणों में <img>, <audio>, <video>, CSS से लोड किए गए वेब फ़ॉन्ट, और WebGL टेक्सचर शामिल हैं. ये सभी अनुरोध एचटीटीपी अनुरोध से लोड किए जाते हैं और जैसा कि पहले बताया गया है, इन एचटीटीपी अनुरोधों में, दूसरी साइट से पहले सेट की गई कुकी, अनुरोध करने वाले उपयोगकर्ता का आईपी पता, और मौजूदा पेज के यूआरएल को रेफ़रर के तौर पर शामिल किया जाएगा. पहले सभी तीसरे पक्षों के अनुरोधों में यह डेटा डिफ़ॉल्ट रूप से शामिल होता था. हालांकि, हमारी कोशिश रहती है कि अलग-अलग ब्राउज़र से तीसरे पक्षों को पास किए जाने वाले डेटा को कम या अलग किया जाए. इस बारे में आगे "तीसरे पक्ष के ब्राउज़र की सुरक्षा को समझना" में बताया गया है.

क्रॉस-साइट iframe एम्बेड करना

<iframe> की मदद से, आपके पेजों में एम्बेड किए गए पूरे दस्तावेज़ से, कुकी, आईपी पते, और रेफ़रर की तीन चीज़ों के अलावा, ब्राउज़र के एपीआई के लिए ज़्यादा ऐक्सेस का अनुरोध किया जा सकता है. ब्राउज़र के हिसाब से, <iframe>d पेजों के लिए असल में कौनसे एपीआई उपलब्ध हैं और वे ऐक्सेस का अनुरोध कैसे करते हैं. फ़िलहाल, इनमें बदलाव किए जा रहे हैं: एम्बेड किए गए दस्तावेज़ों में एपीआई ऐक्सेस को कम करने या उसकी निगरानी करने की मौजूदा कोशिशों के बारे में जानने के लिए, नीचे “अनुमतियों से जुड़ी नीति” देखें.

क्रॉस-साइट JavaScript चलाना

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

आपकी डिपेंडेंसी में तीसरे पक्ष की लाइब्रेरी शामिल करना

जैसा कि पहले बताया गया है, आपके सर्वर-साइड कोड में तीसरे पक्ष की डिपेंडेंसी भी शामिल होंगी. इन्हें आपके कोड से अलग नहीं पहचाना जा सकता है. GitHub के डेटा स्टोर करने की जगह या प्रोग्रामिंग लैंग्वेज की लाइब्रेरी (npm, PyPI, कंपोज़र वगैरह) से मिला कोड, आपके दूसरे कोड की तरह ही डेटा पढ़ सकता है.

अपने तीसरे पक्षों के बारे में जानना

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

आपको यह जानकारी कैसे मिलती है, यह ऑडिट की प्रक्रिया है.

अपने तीसरे पक्षों को ऑडिट करें

ऑडिट की प्रोसेस में यह समझना ज़रूरी है कि तीसरा पक्ष क्या करता है. यह काम तकनीकी और गैर-तकनीकी रूप से, किसी तीसरे पक्ष के लिए और अपने पूरे कलेक्शन के लिए किया जा सकता है.

गैर-तकनीकी ऑडिट चलाना

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

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

तकनीकी ऑडिट करना

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

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

Simon Hearne का "मैप जनरेटर अनुरोध करें" टूल, उन सभी सबअनुरोधों की खास जानकारी दे सकता है जो सार्वजनिक तौर पर उपलब्ध किसी पेज से होते हैं.

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

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

ऐसा करें

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

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

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

HAR फ़ाइलें और कैप्चर करना

HAR फ़ाइल किसी पेज से किए जाने वाले सभी नेटवर्क अनुरोधों का एक मानक JSON फ़ॉर्मैट है. किसी खास पेज के लिए HAR फ़ाइल पाने के लिए, इसमें:

Chrome

ब्राउज़र DevTools (मेन्यू > ज़्यादा टूल > डेवलपर टूल) खोलें. इसके बाद, नेटवर्क पैनल पर जाएं और पेज को लोड करें (या रीफ़्रेश करें). इसके बाद, 'कोई थ्रॉटल नहीं' ड्रॉपडाउन मेन्यू के पास सबसे ऊपर दाईं ओर, डाउनवर्ड ऐरो सेव करने का निशान चुनें.

Firefox

ब्राउज़र डेवलपर टूल खोलें (मेन्यू > ज़्यादा टूल > वेब डेवलपर टूल), नेटवर्क पैनल पर जाएं, पेज को लोड करें (या रीफ़्रेश करें) और थ्रॉटलिंग ड्रॉपडाउन मेन्यू के बगल में सबसे ऊपर दाईं ओर कॉग सिंबल चुनें. इसके मेन्यू से, Save All As HAR** चुनें.

Safari

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

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

तीसरे पक्षों के साथ इंटिग्रेशन करने के सबसे सही तरीके

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

सोशल मीडिया पर शेयर करने का बटन जोड़ते समय

एचटीएमएल बटन को सीधे एम्बेड करने पर विचार करें: https://sharingbuttons.io/ साइट पर कुछ अच्छे डिज़ाइन किए गए उदाहरण दिए गए हैं. इसके अलावा, सामान्य एचटीएमएल लिंक भी जोड़े जा सकते हैं. शायद, इसमें आपकी "शेयर की संख्या" के आंकड़े नहीं आ रहे हैं. साथ ही, Facebook Analytics में ग्राहकों को कैटगरी में बांटने की सुविधा भी नहीं मिल पाएगी. यह, तीसरे पक्ष की सेवा देने वाली कंपनी का इस्तेमाल करने और कम आंकड़ों वाला डेटा पाने के बीच संतुलन बनाने का एक उदाहरण है.

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

उदाहरण के लिए, आप mysite.example.com पर अपनी सेवा शेयर करने के लिए Twitter और Facebook के लिंक इस तरह जोड़ सकते हैं:

<a href="https://facebook.com/sharer/sharer.php?u=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Facebook" target="_blank" >Share on Facebook</a>
<a href="https://twitter.com/intent/tweet/?text=My%20cool%20service!&amp;url=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Twitter" target="_blank">Share on Twitter</a>

ध्यान दें कि Facebook, शेयर करने के लिए यूआरएल तय करने की अनुमति देता है और Twitter, यूआरएल और कुछ टेक्स्ट तय करने की अनुमति देता है.

वीडियो एम्बेड करते समय

वीडियो होस्ट करने वाली साइटों से वीडियो एम्बेड करते समय, एम्बेड करने वाले कोड में निजता बनाए रखने के विकल्प देखें. उदाहरण के लिए, YouTube के लिए, एम्बेड किए गए यूआरएल में youtube.com को www.youtube-nocookie.com से बदलें. इससे, एम्बेड किए गए पेज को देखने वाले उपयोगकर्ताओं पर कुकी की जाने वाली कार्रवाई से बचा जा सकेगा. YouTube से ही शेयर/एम्बेड करने का लिंक जनरेट करते समय भी "बेहतर निजता मोड चालू करें" चुना जा सकता है. यह तीसरे पक्ष की ओर से उपलब्ध कराए गए 'उपयोगकर्ता की सुरक्षा के लिए बेहतर' मोड का इस्तेमाल करने का एक अच्छा उदाहरण है. (https://support.google.com/youtube/answer/171780 पर इस बारे में ज़्यादा जानकारी दी गई है. साथ ही, खास तौर पर YouTube पर वीडियो एम्बेड करने के दूसरे विकल्पों के बारे में बताया गया है.)

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

जैसा कि पहले चर्चा किए गए इंटरैक्टिव विजेट की तरह है, अक्सर एम्बेड किए गए वीडियो को उपलब्ध कराने वाली वेबसाइट के लिंक से बदला जा सकता है. यह कम इंटरैक्टिव होता है, क्योंकि वीडियो इनलाइन नहीं चलता है. हालांकि, यह उपयोगकर्ता के साथ देखने का विकल्प चुनता है. इसका इस्तेमाल "फ़ेकेड पैटर्न" के उदाहरण के तौर पर किया जा सकता है. यह इंटरैक्टिव कॉन्टेंट को डाइनैमिक तौर पर किसी ऐसी चीज़ से बदलने के लिए नाम है जिसे ट्रिगर करने के लिए उपयोगकर्ता को कार्रवाई करने की ज़रूरत होती है. एम्बेड किए गए TikTok वीडियो को TikTok वीडियो पेज के सादे लिंक से बदला जा सकता है. हालांकि, थोड़ा और काम करके, वीडियो का थंबनेल लेकर उसे एक लिंक बनाया जा सकता है. भले ही, चुने गए वीडियो प्रोवाइडर में, ट्रैक किए बिना वीडियो एम्बेड करने का विकल्प मौजूद न हो, लेकिन कई वीडियो होस्ट oEmbed की सुविधा देते हैं. यह एपीआई, जब किसी वीडियो या एम्बेड किए गए कॉन्टेंट का लिंक देता है, तो वह उसके लिए प्रोग्राम की मदद से जानकारी देता है. इसमें थंबनेल और टाइटल भी शामिल है. TikTok, oEmbed की सुविधा करता है (ज़्यादा जानकारी के लिए https://developers.tiktok.com/doc/embed-videos देखें), इसका मतलब है कि मैन्युअल या प्रोग्राम के ज़रिए किसी TikTok वीडियो के लिंक को https://www.tiktok.com/@scout2015/video/6718335390845095173 से उस वीडियो के बारे में JSON मेटाडेटा में बदला जा सकता है और उसे दिखाने के लिए थंबनेल का इस्तेमाल किया जा सकता है.https://www.tiktok.com/oembed?url=https://www.tiktok.com/@scout2015/video/6718335390845095173 उदाहरण के लिए, WordPress अक्सर इसका इस्तेमाल एम्बेड किए गए कॉन्टेंट के लिए, oEmbed की जानकारी का अनुरोध करने के लिए करता है. इस प्रोग्राम का इस्तेमाल, प्रोग्राम के हिसाब से ऐसा "फ़ेकेड" दिखाने के लिए किया जा सकता है जो इंटरैक्टिव दिखता है. साथ ही, जब उपयोगकर्ता उस वीडियो पर क्लिक करता है, तो उस वीडियो को एम्बेड या लिंक करने के लिए स्विच कर दिया जाता है.

Analytics स्क्रिप्ट एम्बेड करते समय

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

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

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

आंकड़ों के बीच ट्रेड-ऑफ़ सिर्फ़ यह चुनने का था कि इसे इस्तेमाल करना है या नहीं: अहम जानकारी और प्लान बनाने के बदले में पूरा डेटा इकट्ठा करें और निजता से समझौता करें या पूरी जानकारी को शामिल न करें. हालांकि, अब ऐसा नहीं होता और इन दोनों चरम सीमाओं के बीच अक्सर बीच की वजह का पता चलता है. इकट्ठा किए गए डेटा को सीमित करने और उसके स्टोरेज की सीमा और अवधि को कम करने के लिए, कॉन्फ़िगरेशन के विकल्पों के बारे में जानने के लिए, ऐनलिटिक्स प्रोवाइडर से संपर्क करें. आपके पास पहले बताए गए तकनीकी ऑडिट के रिकॉर्ड हैं, इसलिए आप उस ऑडिट के काम के सेक्शन को फिर से चलाकर यह पुष्टि कर सकते हैं कि इन कॉन्फ़िगरेशन में बदलाव करने से, इकट्ठा किए गए डेटा की मात्रा कम होती है. अगर यह ट्रांज़िशन किसी मौजूदा साइट पर किया जा रहा है, तो इससे आकलन किए जा सकने वाले कुछ ऐसे डेटा मिल सकते हैं जिनके बारे में उपयोगकर्ताओं के लिए लिखा जा सकता है. उदाहरण के लिए, Google Analytics में निजता के लिए ऑप्ट-इन (डिफ़ॉल्ट रूप से बंद) कई सुविधाएं मौजूद होती हैं. इनमें से कई सुविधाएं, डेटा की सुरक्षा से जुड़े स्थानीय कानूनों का पालन करने में मदद कर सकती हैं. Google Analytics सेट अप करते समय, कई बातों का ध्यान रखा जा सकता है. जैसे, इकट्ठा किए गए डेटा के रखरखाव की समयसीमा (एडमिन > ट्रैकिंग की जानकारी > डेटा का रखरखाव), 26 महीने की डिफ़ॉल्ट अवधि से कम सेट करना और आईपी की पहचान छिपाने जैसे कुछ तकनीकी समाधानों को चालू करना. इस बारे में ज़्यादा जानने के लिए, https://support.google.com/analytics/answer/9019185 पर जाएं.

निजता बनाए रखने के लिए तीसरे पक्षों का इस्तेमाल करना

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

रेफ़रलकर्ता-नीति

ऐसा करें

strict-origin-when-cross-origin या noreferrer की नीति सेट करें, ताकि दूसरी साइटों को रेफ़रर हेडर मिलने से रोका जा सके. ऐसा तब करें, जब उन्हें किसी पेज से लिंक किया जाता है या जब उन्हें सबरिसॉर्स के तौर पर लोड किया जाता है:

index.html:
<meta name="referrer" content="strict-origin-when-cross-origin" />

या सर्वर-साइड, उदाहरण के लिए एक्सप्रेस में:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

ज़रूरत पड़ने पर, खास तरह के एलिमेंट या अनुरोधों के लिए, लैक्सर नीति सेट करें.

यह उपयोगकर्ता की निजता की सुरक्षा क्यों करता है

डिफ़ॉल्ट रूप से, ब्राउज़र हर एचटीटीपी अनुरोध को एक Referer हेडर पर पास करता है, जिसमें अनुरोध शुरू करने वाले पेज का यूआरएल होता है. भले ही, कोई लिंक, एम्बेड की गई इमेज या स्क्रिप्ट हो. यह निजता से जुड़ी समस्या हो सकती है, क्योंकि यूआरएल में निजी जानकारी हो सकती है और तीसरे पक्षों को उपलब्ध होने वाले यूआरएल में, वह निजी जानकारी भेजी जाती है. Web.dev की सूची में निजी डेटा वाले यूआरएल के कुछ उदाहरण दिए गए हैं—यह जानते हुए कि कोई उपयोगकर्ता https://social.example.com/user/me@example.com से आपकी साइट पर आया है और इससे आपको पता चलता है कि वह उपयोगकर्ता कौन है. हालांकि, कोई ऐसा यूआरएल जो खुद अपनी निजी जानकारी सार्वजनिक नहीं करता है, उससे यह पता चलता है कि यह उपयोगकर्ता (जिसे आप जानते हैं, अगर उसने लॉग इन किया हुआ है) किसी अन्य साइट से यहां आया है. इससे पता चलता है कि उपयोगकर्ता ने उस दूसरी साइट पर विज़िट किया था. यह अपने-आप में ऐसी जानकारी का एक्सपोज़र है जो शायद आपको अपने उपयोगकर्ता के ब्राउज़िंग इतिहास के बारे में नहीं पता होनी चाहिए.

Referrer-Policy हेडर (सही वर्तनी के साथ!) देने से आप इसमें बदलाव कर सकते हैं, ताकि रेफ़र करने वाला कुछ या कोई भी यूआरएल पास न हो सके. MDN में पूरी जानकारी मौजूद होती है, लेकिन ज़्यादातर ब्राउज़र अब डिफ़ॉल्ट रूप से strict-origin-when-cross-origin वैल्यू मान लेते हैं. इसका मतलब है कि रेफ़रर यूआरएल को अब ऑरिजिन के तौर पर सिर्फ़ तीसरे पक्षों को भेजा जाता है (https://web.dev/learn/privacy के बजाय https://web.dev). यह निजता के लिए काम की है, बिना कुछ किए आपको. हालांकि, इसे और ज़्यादा सख्त बनाया जा सकता है. इसके लिए, आपको Referrer-Policy: same-origin तय करना होगा, ताकि तीसरे पक्षों को रेफ़रल देने वाली किसी भी जानकारी को न भेजा जाए (या Referrer-Policy: no-referrer की मदद से, ताकि ऐसे लोगों को जानकारी न भेजी जाए जिनमें आपका ऑरिजिन शामिल है). (यह निजता बनाम उपयोगिता बैलेंस का एक अच्छा उदाहरण है; नया डिफ़ॉल्ट विकल्प पहले की तुलना में कहीं ज़्यादा निजता बनाए रखता है, लेकिन यह फिर भी आपकी पसंद के तीसरे पक्षों को ऊंचे स्तर की जानकारी देता है, जैसे कि आपका ऐनलिटिक्स प्रोवाइडर.)

इस हेडर को साफ़ तौर पर बताना भी फ़ायदेमंद होता है, क्योंकि तब आपको पता चल जाता है कि नीति क्या है, इसलिए ब्राउज़र की डिफ़ॉल्ट सेटिंग पर निर्भर रहने के बजाय. अगर हेडर सेट नहीं हो पा रहे हैं, तो <head>: <meta name="referrer" content="same-origin"> में मौजूद मेटा एलिमेंट का इस्तेमाल करके पूरे एचटीएमएल पेज के लिए, रेफ़रर नीति सेट की जा सकती है. साथ ही, अगर किसी तीसरे पक्ष को लेकर सवाल हैं, तो <script>, <a> या <iframe> जैसे अलग-अलग एलिमेंट पर referrerpolicy एट्रिब्यूट सेट किया जा सकता है: <script src="https://thirdparty.example.com/data.js" referrerpolicy="no-referrer">

कॉन्टेंट की सुरक्षा से जुड़ी नीति

Content-Security-Policy हेडर को अक्सर "सीएसपी" कहा जाता है. यह बताता है कि बाहरी संसाधनों को कहां से लोड किया जा सकता है. मुख्य रूप से इसका इस्तेमाल सुरक्षा के मकसद से किया जाता है. क्रॉस-साइट स्क्रिप्टिंग हमलों और स्क्रिप्ट इंजेक्शन को रोकने के लिए इसका इस्तेमाल किया जाता है. हालांकि, जब नियमित ऑडिट के साथ इसका इस्तेमाल किया जाता है, तो इससे यह भी सीमित हो सकता है कि आपके चुने गए तीसरे पक्ष, डेटा कहां भेज सकते हैं.

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

अच्छी बात यह है कि ब्राउज़र पर इससे मिलते-जुलते हेडर, Content-Security-Policy-Report-Only का भी इस्तेमाल किया जा सकता है. अगर यह हेडर दिया गया है, तो दी गई नीति का उल्लंघन करने वाले अनुरोधों को ब्लॉक नहीं किया जाएगा. हालांकि, दिए गए यूआरएल पर एक JSON रिपोर्ट भेजी जाएगी. ऐसा हेडर ऐसा दिख सकता है: Content-Security-Policy-Report-Only: script-src 3p.example.com; report-uri https://example.com/report/ और अगर ब्राउज़र 3p.example.com के अलावा किसी दूसरी जगह से कोई स्क्रिप्ट लोड करता है, तो वह अनुरोध स्वीकार कर लिया जाएगा. हालांकि, दिए गए report-uri पर एक रिपोर्ट भेजी जाएगी. आम तौर पर, किसी नीति को लागू करने से पहले, इसे प्रयोग के तौर पर इस्तेमाल किया जाता है. हालांकि, इसका इस्तेमाल "जारी ऑडिट" के लिए किया जा सकता है. जैसा कि पहले बताया गया है, अपने नियमित ऑडिट की तरह ही, सीएसपी रिपोर्टिंग की सुविधा चालू करके पता लगाया जा सकता है कि कोई अनचाहे डोमेन तो नहीं दिख रहा. इसका मतलब यह हो सकता है कि तीसरे पक्ष के संसाधन, तीसरे पक्ष के उन संसाधनों को लोड कर रहे हैं जिन्हें वे खुद लोड कर रहे हैं. साथ ही, आपको उन संसाधनों पर विचार करके आकलन करना होगा. (यह आपकी सुरक्षा सीमा से बाहर निकल चुके कुछ क्रॉस-साइट स्क्रिप्टिंग शोषण का संकेत भी हो सकता है, जिसके बारे में जानना भी ज़रूरी है!)

Content-Security-Policy, इस्तेमाल करने में आसान और भरोसेमंद एपीआई है. इस बात की जानकारी है और सीएसपी की "अगली-पीढ़ी की टेक्नोलॉजी" बनाने के लिए काम चल रहा है. यह ऐसे ही लक्ष्यों को पूरा करेगा, लेकिन इस्तेमाल करने में इतना मुश्किल भी नहीं होगा. यह अभी तैयार नहीं है, लेकिन अगर आपको यह देखना है कि यह कहां है (या इसके डिज़ाइन में शामिल होने के लिए!), तो ज़्यादा जानकारी के लिए https://github.com/WICG/csp-next पर जाएं.

ऐसा करें

इस एचटीटीपी हेडर को उन पेजों पर जोड़ें जो दिखाए गए हैं: Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://a-url-you-control. जब उस यूआरएल पर JSON पोस्ट हो, तो उसे सेव करें. तीसरे पक्ष के जिन डोमेन का अनुरोध आपकी वेबसाइट पर दूसरों के भेजे जाने पर किया जाता है उनका कलेक्शन पाने के लिए, सेव किए गए डेटा की समीक्षा करें. Content-Security-Policy-Report-Only हेडर को अपडेट करें, ताकि आप अपने हिसाब से डोमेन की सूची देख सकें. इससे आपको पता चलेगा कि सूची में कब बदलाव होगा:

Content-Security-Policy-Report-Only: default-src 'self' https://expected1.example.com https://expected2.example.com ; report-uri https://a-url-you-control

क्यों शुरू करें?

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

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

अनुमतियों की नीति

Permissions-Policy हेडर (जिसे Feature-Policy नाम से दिखाया गया था) का कॉन्सेप्ट, Content-Security-Policy जैसा है, लेकिन यह ब्राउज़र की बेहतर सुविधाओं के ऐक्सेस को प्रतिबंधित करता है. उदाहरण के लिए, एक्सलरोमीटर, कैमरा या यूएसबी डिवाइस जैसे डिवाइस हार्डवेयर के इस्तेमाल पर पाबंदी लगाई जा सकती है. इसके अलावा, हार्डवेयर के अलावा दूसरी सुविधाओं को भी पाबंदी लगाई जा सकती है, जैसे कि फ़ुलस्क्रीन मोड पर जाने या सिंक्रोनस XMLHTTPRequest का इस्तेमाल करने की अनुमति देना. ये पाबंदियां किसी टॉप लेवल पेज (लोड की गई स्क्रिप्ट को इन सुविधाओं का इस्तेमाल करने से रोकने के लिए) या iframe के ज़रिए लोड किए गए सबफ़्रेम वाले पेजों पर लागू की जा सकती हैं. एपीआई के इस्तेमाल पर यह पाबंदी, ब्राउज़र की फ़िंगरप्रिंटिंग से जुड़ी नहीं है. इसका मतलब है कि तीसरे पक्षों को घुसपैठ करने वाले काम करने से रोकना है. जैसे, असरदार एपीआई का इस्तेमाल करना, अनुमति वाली विंडो पॉप-अप करना वगैरह. टारगेट निजता से जुड़े खतरे के मॉडल में इसे "घुसपैठ" के तौर पर बताया गया है.

Permissions-Policy हेडर को (सुविधा, अनुमति वाले ऑरिजिन) पेयर की सूची के तौर पर बनाया जाता है. इस तरह:

Permissions-Policy: geolocation=(self "https://example.com"), camera=(), fullscreen=*

इस उदाहरण में, example.com ऑरिजिन से इस पेज ("self") और <iframe>s को JavaScript से navigator.geolocation API का इस्तेमाल करने की अनुमति दी गई है. यह इस पेज और सभी सबफ़्रेम को फ़ुल स्क्रीन एपीआई का इस्तेमाल करने की अनुमति देता है. साथ ही, यह इस पेज के शामिल किए गए किसी भी पेज पर पाबंदी लगाता है. जैसे कि कैमरे का इस्तेमाल करके वीडियो की जानकारी पढ़ना. इसके बारे में ज़्यादा जानकारी और संभावित उदाहरणों की सूची यहां दी गई है.

अनुमतियां-नीति हेडर से मैनेज की जाने वाली सुविधाओं की सूची बड़ी है और उसमें बार-बार बदलाव हो सकता है. फ़िलहाल, इस सूची का रखरखाव https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md पर किया जाता है.

ऐसा करें

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

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

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

Permissions-Policy: accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), cross-origin-isolated=(),
display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(),
fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), navigation-override=(),
payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=()

वेब ब्राउज़र में पहले से मौजूद, निजता से जुड़ी सुविधाओं को समझना

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

इनमें Safari में इंटेलिजेंट ट्रैकिंग प्रिवेंशन (और इसमें मौजूद WebKit इंजन) और Firefox (और इसका इंजन, Gecko) में बेहतर ट्रैकिंग सुरक्षा शामिल है. इन सभी की वजह से, तीसरे पक्ष के लिए आपके उपयोगकर्ताओं की पूरी जानकारी वाली प्रोफ़ाइल बनाना मुश्किल हो जाता है.

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

Chrome

• तीसरे पक्ष की कुकी को आने वाले समय में ब्लॉक किया जा सकता है. फ़िलहाल, इन्हें डिफ़ॉल्ट रूप से ब्लॉक नहीं किया गया है (लेकिन इसे कोई भी उपयोगकर्ता चालू कर सकता है): https://support.google.com/chrome/answer/95647 पर इससे जुड़ी पूरी जानकारी दी गई है.
• Chrome की निजता सुविधाओं और खास तौर पर, Chrome की वे सुविधाएं जो Google और तीसरे पक्ष की सेवाओं से संपर्क करती हैं, उनके बारे में privacysandbox.com/ पर जानकारी दी गई है.

Edge

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

Firefox

• तीसरे पक्ष की कुकी डिफ़ॉल्ट रूप से ब्लॉक नहीं होती हैं, लेकिन कोई उपयोगकर्ता इन्हें चालू कर सकता है.
• Firefox का बेहतर ट्रैकिंग सुरक्षा, डिफ़ॉल्ट रूप से कुकी, फ़िंगरप्रिंटिंग स्क्रिप्ट, क्रिप्टोमाइनर स्क्रिप्ट, और जाने-पहचाने ट्रैकर को ट्रैक करने से रोकती है. (https://support.mozilla.org/kb/trackers-and-scripts-firefox-blocks-enhanced-track में कुछ और जानकारी मिलती है.
• तीसरे पक्ष की कुकी साइट के लिए सीमित होती हैं. इसलिए, हर साइट में एक अलग कुकी जार होता है और उसे अलग-अलग साइटों पर नहीं जोड़ा जा सकता (मोज़िला इसे "कुल कुकी सुरक्षा" कहता है.

ब्लॉक की गई चीज़ों के बारे में अहम जानकारी पाने और समस्याओं को डीबग करने में मदद करने के लिए, पता बार में शील्ड आइकॉन पर क्लिक करें या डेस्कटॉप पर Firefox में about:protections पर जाएं.

Safari

• तीसरे पक्ष की कुकी डिफ़ॉल्ट रूप से ब्लॉक होती हैं.
• Safari, इंटेलिजेंट ट्रैकिंग प्रिवेंशन सुविधा के हिस्से के तौर पर, अन्य पेजों को पास किए गए रेफ़रर को कम कर देता है. इससे कोई खास पेज नहीं, बल्कि टॉप-लेवल साइट बन जाती है: (https://something.example.com/this/specific/page के बजाय https://something.example.com).
• ब्राउज़र localStorage का डेटा सात दिनों के बाद मिटा दिया जाता है.

(https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/, इन सुविधाओं के बारे में खास जानकारी देगा.)

ब्लॉक किए जा सकने वाले कॉन्टेंट के बारे में कुछ अहम जानकारी पाने और समस्याओं को डीबग करने में मदद पाने के लिए, डेस्कटॉप पर Safari के डेवलपर मेन्यू में, "इंटेलिजेंट ट्रैकिंग प्रिवेंशन डीबग मोड" चालू करें. (ज़्यादा जानकारी के लिए, https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/ पर जाएं.)

एपीआई के प्रपोज़ल

हमें नए एपीआई की ज़रूरत क्यों है?

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

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

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

एपीआई प्रस्तावों के उदाहरण

इस सूची में पूरी जानकारी नहीं दी गई है. इसमें कुछ ऐसे विषयों के बारे में बताया गया है जिन पर चर्चा की जा रही है.

तीसरे पक्ष की कुकी का इस्तेमाल करके बनाई गई टेक्नोलॉजी को बदलने के लिए, एपीआई के प्रस्तावों के उदाहरण:

• पहचान से जुड़े इस्तेमाल के उदाहरण: FedCM
• विज्ञापनों के इस्तेमाल के उदाहरण: प्राइवेट क्लिक मेज़रमेंट, इंटरऑपरेबल प्राइवेट एट्रिब्यूशन, एट्रिब्यूशन रिपोर्टिंग, विषय, FLEDGE, पैरामीटर.

पैसिव ट्रैकिंग पर बनाई गई टेक्नोलॉजी को बदलने के लिए, एपीआई के प्रस्तावों के उदाहरण:

• धोखाधड़ी का पता लगाने के इस्तेमाल के उदाहरण: ट्रस्ट टोकन.

ऐसे अन्य प्रस्तावों के उदाहरण जिन्हें अन्य एपीआई आने वाले समय में, तीसरे पक्ष की कुकी के बिना बना सकते हैं:

• स्टोरेज ऐक्सेस एपीआई

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

Global-Privacy-Control एक ऐसा हेडर है, जिसका मकसद किसी साइट पर यह बताना होता है कि उपयोगकर्ता, इकट्ठा किए गए किसी भी निजी डेटा को दूसरी साइटों के साथ शेयर नहीं करना चाहता. इस गेम का इरादा 'ट्रैक न करें' सुविधा से मिलता-जुलता है, जिसे बंद कर दिया गया था.

एपीआई प्रस्तावों की स्थिति

इनमें से ज़्यादातर एपीआई प्रपोज़ल अभी तक डिप्लॉय नहीं किए गए हैं या इन्हें सिर्फ़ फ़्लैग के पीछे या सीमित जगहों पर प्रयोग के लिए डिप्लॉय किया गया है.

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

नए एपीआई के बारे में अप-टू-डेट रहने के लिए, फ़िलहाल Privacy Group की GitHub पर प्रपोज़ल की सूची है. यह सबसे बेहतर विकल्प है.

क्या आपको इन एपीआई का इस्तेमाल करने की ज़रूरत है?

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