तीसरा पक्ष क्या है?
ऐसा बहुत कम होता है कि कोई वेबसाइट पूरी तरह अपने-आप में पूरी तरह से छिपी हो. एचटीटीपी वेब कैलेंडर से पता चलता है कि करीब 95% वेबसाइटों पर तीसरे पक्ष का कुछ कॉन्टेंट मौजूद होता है.
Almanac में तीसरे-पक्ष के कॉन्टेंट को एक ऐसी चीज़ के तौर पर परिभाषित किया गया है जिसे सार्वजनिक और शेयर किए जा रहे प्लैटफ़ॉर्म पर होस्ट किया जाता है. अलग-अलग तरह के लोग इस कॉन्टेंट का इस्तेमाल करते हैं जिस पर किसी साइट के मालिक ने कोई असर नहीं डाला है. ये इमेज या अन्य मीडिया हो सकते हैं, जैसे कि वीडियो, फ़ॉन्ट या स्क्रिप्ट. जोड़ी गई बाकी सभी चीज़ों के लिए, इमेज और स्क्रिप्ट का इस्तेमाल किया जाता है. साइट बनाने के लिए तीसरे-पक्ष का कॉन्टेंट ज़रूरी नहीं है. लेकिन यह भी हो सकता है; आप सार्वजनिक रूप से शेयर किए गए सर्वर से लोड की गई किसी चीज़ का इस्तेमाल ज़रूर करेंगे. भले ही, वह वेब फ़ॉन्ट हो, वीडियो, विज्ञापनों या JavaScript लाइब्रेरी के एम्बेड किए गए iframe. उदाहरण के लिए, हो सकता है कि Google Fonts से दिखाए जाने वाले वेब फ़ॉन्ट इस्तेमाल किए जा रहे हों, या Google Analytics की मदद से आंकड़ों को मेज़र करना; आपने सोशल नेटवर्क पर, 'पसंद करें' बटन या 'इससे साइन इन करें' बटन जोड़ा होगा; ऐसा हो सकता है कि आपने मैप या वीडियो एम्बेड किए हों या तीसरे पक्ष की सेवाओं के ज़रिए खरीदारी की खरीदारी मैनेज की हो; कि गड़बड़ियों को ट्रैक किया जा रहा हो और अपनी डेवलपमेंट टीम के लिए, तीसरे पक्ष के मॉनिटरिंग टूल की मदद से लॉग इन करना.
निजता की सुरक्षा के लिहाज़ से, थोड़ा अलग और कम विकल्प देखना सही होता है: तीसरे पक्ष के संसाधन का इस्तेमाल करने पर और खास तौर पर, तीसरे पक्ष की स्क्रिप्ट, जो सार्वजनिक और शेयर किए गए सोर्स से आती है. साथ ही, इसे बड़े पैमाने पर इलस्ट्रेशन के तौर पर इस्तेमाल किया जाता है, लेकिन इसे साइट के मालिक के अलावा, किसी और व्यक्ति ने पब्लिश किया हो. अपनी साइट को सुरक्षित रखने के लिए, तीसरे पक्ष के लेखकत्व का पहलू अहम होता है उपयोगकर्ताओं का निजता बनाए रखते हैं. इससे आपको यह समझने में मदद मिलेगी कि वीडियो में कौन-कौनसे जोखिमों का इस्तेमाल किया जा सकता है. इसके बाद, यह तय करें कि संसाधन उपलब्ध कराने के लिए डिज़ाइन किया गया है. जैसा कि हमने पहले बताया है, इन चीज़ों से आपको वीडियो का संदर्भ समझने और इसलिए, यह समझने की कोशिश की जा सकती है कि आपको क्या-क्या करने की ज़रूरत है और उनका क्या मतलब है.
"तीसरे पक्ष के संसाधनों" पर चर्चा करने का मतलब यह नहीं है सामान्य तौर पर: पहले पक्ष और तीसरा-पक्ष असल में उस कॉन्टेक्स्ट के बारे में होता है जिसमें किसी चीज़ का इस्तेमाल किया जाता है. किसी दूसरी वेबसाइट से लोड की गई स्क्रिप्ट, तीसरे पक्ष की है रिसॉर्स हो सकता है और स्क्रिप्ट लोड करने वाले एचटीटीपी अनुरोध में कुकी शामिल हो सकती हैं, लेकिन वे कुकी "तीसरे पक्ष की कुकी" नहीं होतीं; वे सिर्फ़ कुकी हैं और चाहे वे "तीसरे पक्ष" की हों या "पहले पक्ष का" यह इस बात पर निर्भर करता है कि स्क्रिप्ट आपकी साइट के किसी पेज या स्क्रिप्ट के मालिक की साइट के किसी पेज पर.
हम तीसरे पक्ष के संसाधनों का इस्तेमाल क्यों करते हैं?
तीसरे पक्ष आपकी साइट में कुछ सुविधाएं जोड़ने का एक बेहतरीन तरीका है. ये ऐसी सुविधाएं हो सकती हैं जो लोगों को दिख रही हों या दिख न रही हों डेवलपर फ़ंक्शन, जैसे कि गड़बड़ी ट्रैक करना, लेकिन वे आपके डेवलपमेंट लोड को कम करते हैं और स्क्रिप्ट बनाए रखे जाते हैं किसी अन्य व्यक्ति द्वारा: उस सेवा की डेवलपमेंट टीम को शामिल करना जिसे आप शामिल कर रहे हैं. ये सभी सुविधाएं, वेब के कंपोज़ेबिलिटी की वजह से काम करती हैं: कई हिस्सों को एक साथ जोड़कर बनाया जा सकता है, जो उनके योग से ज़्यादा होता है.
एचटीटीपी संग्रह का वेब कैलेंडर अच्छा ब्यौरा देता है:
तीसरे पक्ष, कई तरह की इमेज, वीडियो, फ़ॉन्ट, टूल, लाइब्रेरी, विजेट, ट्रैकर, विज्ञापन, और इनके अलावा भी कुछ चीज़ें हैं जिन्हें हमारे वेब पेजों में एम्बेड किया जा सकता है. यह चालू करता है जो वेब पर कॉन्टेंट बनाने और पब्लिश करने में सक्षम नहीं हैं. तृतीय पक्षों के बिना, वेब पर यह एक बहुत उबाऊ, टेक्स्ट पर आधारित, शिक्षा का माध्यम हो, न कि शानदार, इमर्सिव, और जटिल प्लैटफ़ॉर्म जो लोगों की ज़िंदगी का अहम हिस्सा है जिसमें हम में से कई लोग आज के दौर में हैं.
तीसरे पक्ष के संसाधन क्या कर सकते हैं?
कुछ जानकारी ऐक्सेस की जा रही है
जब वेबसाइट पर तीसरे पक्ष के किसी संसाधन का इस्तेमाल किया जाता है, तो उसकी कुछ जानकारी तीसरे पक्ष को भेज दी जाती है. भले ही, वह संसाधन किसी भी तरह का हो. उदाहरण के लिए, किसी दूसरी साइट से इमेज शामिल करने पर, उपयोगकर्ता के ब्राउज़र से किया गया एचटीटीपी अनुरोध, रेफ़रर के साथ पास होगा हेडर, जिसमें आपके पेज का यूआरएल और उपयोगकर्ता का आईपी पता भी शामिल होता है.
क्रॉस-साइट ट्रैकिंग
इसी उदाहरण में आगे बढ़ें—जब तीसरे पक्ष की साइट से इमेज लोड होती है, तो उसमें एक कुकी शामिल हो सकती है और वह कुकी उपयोगकर्ता जब अगली बार इमेज के लिए अनुरोध करेगा, तो उसे तीसरे पक्ष को वापस भेज दिया जाएगा. इसका मतलब है कि तीसरा पक्ष यह जान सकता है कि सेवा का उपयोग आपकी साइट पर किया जा रहा है और वह किसी कुकी को वापस भेज सकती है, जो संभावित रूप से उस उपयोगकर्ता के लिए एक अनन्य ID के साथ हो सकती है. इसका मतलब है कि जब अगली बार उपयोगकर्ता आपकी साइट या कोई ऐसी अन्य साइट, जिसमें उस तीसरे पक्ष का कोई संसाधन शामिल है, तो वह यूनीक आईडी कुकी फिर से भेजी जाएगी. इससे तीसरे पक्ष को एक लॉग बनाने की अनुमति मिलती है, जिसमें बताया जाता है कि उपयोगकर्ता कहां-कहां विज़िट करता है: आपकी साइट, ऐसी अन्य साइटें जहां पूरे वेब पर तीसरे पक्ष के एक ही संसाधन का इस्तेमाल करते हैं.
यह क्रॉस-साइट ट्रैकिंग है: इसकी मदद से कोई तीसरा पक्ष, कई वेबसाइटों पर उपयोगकर्ता की गतिविधि का लॉग इकट्ठा कर सकता है, बशर्ते ऐसी सभी वेबसाइटें, एक ही तीसरे पक्ष के संसाधन का इस्तेमाल करती हैं. यह कोई फ़ॉन्ट, इमेज या स्टाइलशीट हो सकता है—ये सभी स्टैटिक रिसॉर्स हैं. यह एक डाइनैमिक रिसॉर्स भी हो सकता है: जैसे, स्क्रिप्ट का कोई हिस्सा, सोशल मीडिया बटन, कोई विज्ञापन. शामिल की गई स्क्रिप्ट, ज़्यादा डेटा इकट्ठा कर सकती है जानकारी देता है, क्योंकि यह डाइनैमिक है: यह उपयोगकर्ता के ब्राउज़र और एनवायरमेंट की जांच कर सकता है और उस डेटा को उसके ऑरिजिनेटर को वापस भेज सकता है. कोई भी स्क्रिप्ट कुछ हद तक ऐसा कर सकती है. जैसे, ऐसे डाइनैमिक रिसॉर्स जो स्क्रिप्ट के तौर पर मौजूद नहीं होते. जैसे, सोशल मीडिया से जोड़ा गया या कोई विज्ञापन या शेयर बटन. अगर लोकप्रिय वेबसाइटों पर मौजूद कुकी बैनर की जानकारी देखें, तो आपको उन संगठनों की सूची दिखेगी जो आपके उपयोगकर्ताओं के लिए ट्रैकिंग कुकी जोड़ सकती है, ताकि उस उपयोगकर्ता की प्रोफ़ाइल बनाने के लिए उनकी गतिविधियों की फ़ोटो बनाई जा सके. यह लीजिए उनकी संख्या सैकड़ों में मौजूद हो सकती है. अगर कोई तीसरा पक्ष किसी सेवा को मुफ़्त में उपलब्ध कराता है, तो इससे उन्हें फ़ायदा होगा. वे इस डेटा को इकट्ठा करके उससे कमाई करते हैं.
निजता से जुड़े खतरों को टारगेट करने वाला मॉडल, एक काम की गाइड है. इससे, निजता से जुड़ी उन समस्याओं के बारे में जानने में मदद मिलती है जिनसे ब्राउज़र को अपने उपयोगकर्ताओं की सुरक्षा करनी चाहिए. इस दस्तावेज़ पर लिखते समय भी चर्चा की जा रही है. हालांकि, यह एक तरह के हाई-लेवल क्लासिफ़िकेशन के बारे में बताता है. निजता को खतरा है. तीसरे पक्ष के संसाधनों से आने वाले जोखिम मुख्य तौर पर "अलग-अलग साइट पर पहचान करना" के काम का नहीं होना चाहिए, जहां किसी ऐसी वेबसाइटें जो एक ही उपयोगकर्ता को कई साइटों पर भेजती हैं. साथ ही, "संवेदनशील जानकारी ज़ाहिर करने" की मदद से भी ऐसा किया जा सकता है. ऐसी जानकारी जिसे उपयोगकर्ता संवेदनशील मानता है.
यह एक मुख्य अंतर है: भले ही तीसरा पक्ष ज़्यादा संवेदनशील जानकारी इकट्ठा न कर रहा हो, लेकिन क्रॉस-साइट की पहचान करना गलत है. जानकारी हटा दी जाती है, क्योंकि यह उपयोगकर्ता का अपनी पहचान पर नियंत्रण छीन लेती है. किसी उपयोगकर्ता के रेफ़रर और आईपी पते का ऐक्सेस पाना और कुकी खुद को अनचाहे तरीके से ज़ाहिर करती हैं. तीसरे पक्ष के संसाधनों का इस्तेमाल करने के साथ-साथ यह तय करने की ज़रूरत होती है कि उनका इस्तेमाल किस तरह किया जाएगा और उनकी निजता बनाए रखने के लिए डिज़ाइन किया गया है. इनमें से कुछ काम, साइट डेवलपर के तौर पर आपके भेजे गए दस्तावेज़ में होते हैं और कुछ काम ब्राउज़र करता है उपयोगकर्ता एजेंट के तौर पर अपनी भूमिका में हो; इसका मतलब है कि संवेदनशील जानकारी ज़ाहिर करने से रोकने के लिए, उपयोगकर्ता की ओर से काम करने वाला एजेंट और जहां संभव हो. नीचे हम ब्राउज़र पर लागू होने वाली पाबंदियों और तरीकों के बारे में ज़्यादा जानकारी देंगे और साइट डेवलपमेंट लेवल पर भी तय किया जा सकता है.
सर्वर साइड तीसरे पक्ष का कोड
तीसरे पक्ष की हमारी पिछली परिभाषा ने जान-बूझकर एचटीटीपी कैलेंडर के क्लाइंट-साइड अप्रोच को बदल दिया है (जैसा कि सही है तीसरे पक्ष के लेखकत्व को शामिल करते हैं, क्योंकि निजता के नज़रिए से, तीसरा पक्ष वह होता है जिसे कुछ भी पता हो. जो आप नहीं हैं.
इसमें क्लाइंट और सर्वर पर इस्तेमाल की जाने वाली सेवाएं देने वाले तीसरे पक्षों के साथ-साथ, क्लाइंट भी शामिल हैं. निजता से मिली जानकारी स्टैंडपॉइंट, किसी तीसरे पक्ष की लाइब्रेरी (जैसे कि 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, कंपोज़र वगैरह) से शामिल किया जाता है वह सारे डेटा पढ़ सकता है जो आपका अन्य कोड पढ़ सकता है.
तीसरे पक्षों के बारे में जानकारी
इसके लिए, तीसरे पक्ष के सप्लायर की आपकी सूची के साथ-साथ उनकी निजता, डेटा इकट्ठा करने, और उपयोगकर्ता के बारे में भी जानना ज़रूरी है अनुभव के नज़रिए और नीतियों को ध्यान में रखते हुए कार्रवाई की जाती है. इसके बाद, यह समझ आपके लिए समझौते की सीरीज़ का हिस्सा बन जाती है: यह आपके लिए कितनी काम की और अहम है एक सेवा है, जो आपके उपयोगकर्ताओं को उनकी तीसरा पक्ष कॉन्टेंट बनाने से, साइट के मालिक के तौर पर आपको काफ़ी मेहनत करनी पड़ती है. साथ ही, आपको अपनी मुख्य योग्यताओं पर ध्यान देने में मदद मिलती है; इस तरह, एक बेहतर उपयोगकर्ता अनुभव देने के लिए इस तरह के भरोसे को कायम रखना और अपनी निजता की सुरक्षा करना काफ़ी फ़ायदेमंद होता है. उपयोगकर्ता अनुभव और डेवलपर अनुभव को भ्रम में नहीं डालना ज़रूरी है. हालांकि: "हमारी डेवलपर टीम के लिए इसे बनाना आसान है सेवा" उपयोगकर्ताओं के लिए आकर्षक नहीं है.
यह आकलन कैसे किया जाता है, यह ऑडिट की प्रोसेस है.
तीसरे पक्ष की सेवाओं का ऑडिट करें
यह समझना कि तीसरा पक्ष क्या करता है, ऑडिट. इसे तकनीकी और गैर-तकनीकी, दोनों तरीकों से किया जा सकता है. एक तीसरे पक्ष के लिए और आपके पूरे कलेक्शन के लिए.
गैर-तकनीकी ऑडिट चलाना
पहला चरण गैर-तकनीकी है: अपने सप्लायर की निजता नीतियां पढ़ें. अगर आपने तीसरे पक्ष के किसी संसाधन को शामिल किया, तो निजता नीतियां पढ़ें. ये लंबे और कानूनी टेक्स्ट से भरे होंगे. कुछ दस्तावेज़ों में, कुछ तरीकों का इस्तेमाल किया जा सकता है खास तौर पर, पहले के मॉड्यूल में चेतावनी दी गई हो. जैसे, बहुत सामान्य स्टेटमेंट और बिना किसी संकेत के इकट्ठा किए गए डेटा को कैसे और कब हटाया जाएगा. यह समझना ज़रूरी है कि उपयोगकर्ता के नज़रिए से देखा जाए, तो आपकी साइट पर जो कॉन्टेंट इकट्ठा किया जाता है उसे इन निजता नीतियों के हिसाब से कंट्रोल किया जाएगा. इसमें तीसरे पक्ष भी शामिल हैं. भले ही आप जब आप अपने लक्ष्यों के बारे में पारदर्शी हों और अपने उपयोगकर्ताओं डेटा की निजता को लेकर हमारी उम्मीदों के बारे में बताना होता है. इसलिए, उपयोगकर्ता आपको चुने गए तीसरे पक्षों की किसी भी कार्रवाई के लिए ज़िम्मेदार ठहरा सकते हैं. अगर इसमें कुछ भी है, तो अपनी निजता नीतियों के बारे में नहीं कहना चाहेंगे, क्योंकि इससे उपयोगकर्ताओं की भरोसा है, तो देखें कि क्या कोई दूसरा सप्लायर है.
यह ऐसा तरीका है जिससे तकनीकी ऑडिट के बारे में आगे बातचीत की जा सकती है. साथ ही, इससे हमें यह जानने में मदद मिलेगी कि कोई दूसरा. आपको तीसरे पक्ष के उन संसाधनों की जानकारी होनी चाहिए जिन्हें कारोबारी वजहों (जैसे कि विज्ञापन नेटवर्क कंपनी) से शामिल किया जा रहा है या एम्बेड किया गया कॉन्टेंट) शामिल करने होंगे. गैर-तकनीकी काम शुरू करने के लिए यह जगह बेहतर है ऑडिट. तकनीकी ऑडिट से तीसरे पक्षों की पहचान की जा सकती है, खास तौर पर वे पक्ष जो तकनीकी वजहों से (बाहरी कॉम्पोनेंट, आंकड़े, यूटिलिटी लाइब्रेरी) के बारे में नहीं बताती हैं और वह सूची, कारोबार को ध्यान में रखकर तीसरे पक्ष की कंपनियां. यहां लक्ष्य है कि आप साइट के मालिक के तौर पर यह महसूस करें कि आपने तीसरे पक्ष की जिन्हें आप अपनी साइट में जोड़ रहे हैं, और एक व्यवसाय के रूप में आपको अपना कानूनी सलाहकार प्रस्तुत करने में सहायता करने के लिए तीसरे पक्षों की इस सूची की मदद से यह पक्का करें कि आप सभी ज़रूरी जवाबदेही को पूरा कर रहे हैं.
टेक्निकल ऑडिट चलाएं
तकनीकी ऑडिट के लिए, वेबसाइट के हिस्से के तौर पर, साइट के संसाधनों का इस्तेमाल करना ज़रूरी है; इसका मतलब है कि डिपेंडेंसी लोड न करें और टेस्ट की मदद से उसकी जांच करते हैं. पक्का करें कि आपको यह दिख रहा हो कि आपकी डिपेंडेंसी आपकी असल वेबसाइट के हिस्से के तौर पर कैसे काम करती हैं, का इस्तेमाल सिर्फ़ टेस्ट या डेवलपमेंट मोड के बजाय, सार्वजनिक इंटरनेट पर करते हैं. अपनी वेबसाइट को इस तरह से देखना कि वह कोई नया उपयोगकर्ता. एक नई प्रोफ़ाइल में ब्राउज़र खोलें, ताकि आपने साइन इन न किया हो और आपका कोई कानूनी समझौता सेव न किया गया हो. इसके बाद, अपनी साइट पर जाकर देखें.
अगर आपने उपयोगकर्ता खाते उपलब्ध कराए हैं, तो नए खाते के लिए अपनी साइट पर साइन अप करें. आपकी डिज़ाइन टीम इस नए उपयोगकर्ता को व्यवस्थित करेगी
उपयोगकर्ता अनुभव के हिसाब से ग्राहक हासिल करने की प्रोसेस है, लेकिन निजता के नज़रिए से भी इसका इस्तेमाल किया जा सकता है. बस क्लिक न करें
"स्वीकार करें" या कुकी चेतावनी या निजता नीति पर लागू होती है; खुद को अपनी सेवा इस्तेमाल करने का काम तय करना
बिना किसी निजी जानकारी या किसी ट्रैकिंग कुकी के जानकारी दिए बिना देखें कि क्या आप यह कर सकते हैं और ऐसा करना कितना कठिन है.
यह देखने से भी मदद मिल सकती है कि कौन-कौनसी साइटों को ऐक्सेस किया जा रहा है और कौनसा डेटा
नहीं डालना है. डेवलपर टूल अलग-अलग एचटीटीपी अनुरोधों (आम तौर पर, "नेटवर्क" सेक्शन में) की सूची देते हैं. साथ ही, यहां
यहां से टाइप के हिसाब से ग्रुप किए गए अनुरोध (एचटीएमएल, सीएसएस, इमेज, फ़ॉन्ट, JavaScript, JavaScript से शुरू किए गए अनुरोध). यह भी संभव है
हर अनुरोध का डोमेन दिखाने के लिए एक नया कॉलम जोड़ें, जो दिखाएगा कि कितनी अलग-अलग जगहों से संपर्क किया जा रहा है,
और उन्हें "तीसरे-पक्ष के अनुरोध" चेकबॉक्स का इस्तेमाल करें. (Content-Security-Policy का इस्तेमाल करना भी काम आ सकता है
लगातार ऑडिट करने के लिए रिपोर्टिंग कर रहे हैं, जिसके बारे में आगे पढ़ें.)
Simon Hearne का "Request Map Generator" टूल, इन सभी कामों में मदद कर सकता है सार्वजनिक रूप से उपलब्ध पेज के ज़रिए किए गए सब-अनुरोधों को.
यहां पर, कारोबार पर फ़ोकस करने वाले तीसरे पक्षों को भी शामिल किया जा सकता है. इन पक्षों की पहचान गैर-तकनीकी ऑडिट में भी की जा सकती है (यानी: उन कंपनियों की सूची जिनके साथ आपके वित्तीय संबंध हैं, ताकि वे अपने संसाधनों का इस्तेमाल कर सकें). यहां हमारा लक्ष्य है का मिलान उन तृतीय पक्षों की सूची से किया जा रहा है, जिनका आप उपयोग कर रहे हैं (वित्तीय और कानूनी रिकॉर्ड से) का इस्तेमाल करके (यह देखकर कि आपकी वेबसाइट तीसरे पक्ष के कौनसे एचटीटीपी अनुरोध करती है). आपको हर कारोबार के तीसरे पक्ष की वह पक्ष जिसके लिए तकनीकी रूप से आउटबाउंड अनुरोध किए गए हैं. अगर किसी तीसरे पक्ष के तकनीकी ऑडिट में आपको अनुरोधों की पहचान नहीं हो पा रही है, तो कारोबारी संबंध से होने वाली पहचान के लिए, यह पता लगाना ज़रूरी है कि ऐसा क्यों किया जाना चाहिए. साथ ही, आपको टेस्टिंग से जुड़े निर्देश देने होंगे: शायद यह तीसरा पक्ष संसाधन सिर्फ़ किसी खास देश में, किसी खास तरह के डिवाइस पर या लॉग-इन किए हुए उपयोगकर्ताओं के लिए लोड किया जाता हो. इससे आपका साइज़ ऑडिट के लिए साइट क्षेत्रों की सूची सबमिट करें और सुनिश्चित करें कि आपको सभी आउटबाउंड ऐक्सेस दिखाई दे रहे हैं. (या यह हो सकता है कि यह किसी तीसरे पक्ष की जिस संसाधन के लिए आप भुगतान कर रहे हैं और जिसका उपयोग नहीं कर रहे हैं, वह हमेशा वित्त विभाग को खुश करता है.)
जब आप ऑडिट का हिस्सा बनने के लिए तीसरे पक्षों के अनुरोधों की सूची बना देंगे, तो इस अनुरोध में, उस अनुरोध की पूरी जानकारी और खास तौर पर यह दिखाया जाएगा कि उस अनुरोध में कौनसा डेटा भेजा गया है. यह भी एक बहुत एक सामान्य बात यह है कि आपके कोड से शुरू किया गया तीसरे पक्ष का अनुरोध बाद में तीसरे पक्ष के कई अन्य अनुरोध करता है. इन अतिरिक्त तीसरे पक्षों को भी "इंपोर्ट" किया जाता है निजता नीति में शामिल किया जा सकता है. यह काम मेहनत भरा है, लेकिन कीमती है और इसे अक्सर मौजूदा विश्लेषण में डाला जा सकता है; आपकी फ़्रंटएंड डेवलपमेंट टीम पहले से ही इसके लिए ऑडिट अनुरोध कर रही होगी परफ़ॉर्मेंस की वजहें (शायद WebPageTest या लाइटहाउस जैसे मौजूदा टूल की मदद से) और डेटा शामिल करके और निजता ऑडिट से प्रक्रिया को और आसान बनाया जा सकता है.
यह करें
नई उपयोगकर्ता प्रोफ़ाइल वाला ब्राउज़र खोलें, ताकि आपने साइन इन न किया हो और आपका कोई स्टोर किया गया कानूनी समझौता न हो; फिर ब्राउज़र खोलें डेवलपमेंट टूल नेटवर्क पैनल पर क्लिक करें. हर अनुरोध का डोमेन दिखाने के लिए एक नया कॉलम जोड़ें. इसके बाद, "तीसरे पक्ष के अनुरोध" अगर मौजूद हो, तो सिर्फ़ तीसरे पक्ष को दिखाने के लिए चेकबॉक्स. इसके बाद:
- अपनी साइट पर जाएं.
- उपयोगकर्ता खाते उपलब्ध कराने पर, नए खाते के लिए साइन अप करें.
- अपना बनाया गया खाता मिटाने की कोशिश करें.
- साइट पर एक या दो सामान्य कार्रवाइयां करें (यह इस बात पर निर्भर करता है कि आपकी साइट क्या करती है, लेकिन आम तौर पर वे कार्रवाइयां चुनें जो ज़्यादातर उपयोगकर्ता करते हैं).
- एक या दो ऐसी कार्रवाइयां करें जिनमें खास तौर पर तीसरे पक्ष की डिपेंडेंसी शामिल है. उदाहरण के लिए, इन लोगों के साथ कॉन्टेंट शेयर करना सोशल मीडिया, चेकआउट फ़्लो शुरू करना या किसी दूसरी साइट से कॉन्टेंट एम्बेड करना.
इनमें से हर काम करते समय, नेटवर्क पैनल को देखकर उन डोमेन से अनुरोध किए गए संसाधनों का रिकॉर्ड बनाएं जो आपके नहीं हैं जैसा बताया गया है. ये आपके कुछ तीसरे पक्ष हैं. ऐसा करने का एक अच्छा तरीका यह है कि नेटवर्क कैप्चर करने के लिए ब्राउज़र नेटवर्क टूल का इस्तेमाल किया जाए HAR फ़ाइल में लॉग के लिए अनुरोध करें.
HAR फ़ाइलें और कैप्चर करना
HAR फ़ाइल, किसी पेज के सभी नेटवर्क अनुरोधों का एक स्टैंडर्ड JSON फ़ॉर्मैट है. किसी खास पेज की HAR फ़ाइल पाने के लिए, इसमें:
Chrome
ब्राउज़र DevTools खोलें (मेन्यू > ज़्यादा टूल > डेवलपर टूल), नेटवर्क पैनल पर जाएं. इसके बाद, पेज लोड करें (या रीफ़्रेश करें) और सबसे ऊपर दाईं ओर मौजूद 'कोई थ्रॉटलिंग नहीं' ड्रॉपडाउन मेन्यू के पास, डाउन ऐरो सेव का निशान चुनें.
Firefox
ब्राउज़र डेवलपर टूल खोलें (मेन्यू > ज़्यादा टूल > वेब डेवलपर टूल), नेटवर्क पैनल पर जाएं, पेज लोड करें (या रीफ़्रेश करें) करें और सबसे ऊपर दाईं ओर थ्रॉटलिंग ड्रॉपडाउन मेन्यू के बगल में कॉग सिंबल दिखेगा. इसके मेन्यू से, Save All as HAR** को चुनें.
Safari
ब्राउज़र डेवलपर टूल खोलें (मेन्यू > डेवलप करें > वेब इंस्पेक्टर दिखाएं; अगर आपके पास 'डेवलप करें' मेन्यू नहीं है, तो इसे यहां से चालू करें मेन्यू > 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!&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 को आपके उपयोगकर्ताओं के बारे में जानकारी इकट्ठा करने के लिए डिज़ाइन किया गया है, ताकि उसका विश्लेषण किया जा सके: यह इस काम के लिए है. ऐनलिटिक्स सिस्टम ज़रूरी हैं ऐक्सेस और उपयोगकर्ताओं के बारे में डेटा इकट्ठा करने और दिखाने के लिए सेवाएं. यह डेटा, तीसरे पक्ष के सर्वर पर आसानी से उपलब्ध कराया जाता है, जैसे कि Google Analytics लागू करने के बाद. https://matomo.org/ जैसे खुद से होस्ट किए जाने वाले ऐनलिटिक्स सिस्टम भी मौजूद हैं. हालांकि, यह तरीका के लिए तीसरे पक्ष का समाधान. अपने इन्फ़्रास्ट्रक्चर पर ऐसा सिस्टम चलाने से, डेटा कलेक्शन को कम करने में मदद मिलती है. हालांकि, क्योंकि यह आपका अपना नेटवर्क नहीं छोड़ता. दूसरी ओर, उस डेटा को मैनेज करना, हटाना, और उसके लिए नीतियां सेट करना आपकी ज़िम्मेदारी बन जाती है. क्रॉस-साइट ट्रैकिंग के साथ सबसे बड़ी चिंता तब आती है, जब उसे गुप्त रूप से किया जाता है और गुप्त रूप से, या किसी ऐसी सेवा के इस्तेमाल के खराब असर के रूप में जिसमें डेटा इकट्ठा करने की ज़रूरत न हो. Analytics का सॉफ़्टवेयर सीधे तौर पर डेटा इकट्ठा करने के लिए डिज़ाइन किया गया है. इसका मकसद साइट के मालिकों को उनके उपयोगकर्ताओं के बारे में जानकारी देना है.
पहले भी, हर चीज़ के बारे में जितना हो सके उतना डेटा इकट्ठा करने का एक तरीका रहा है. जैसे, मछली पकड़ने का बड़ा जाल और फिर बाद में दिलचस्प पैटर्न देखने के लिए उसका विश्लेषण किया. इस मानसिकता ने काफ़ी हद तक बेचैनी और बेचैनी की भावना पैदा की है डेटा कलेक्शन के बारे में है जिसके बारे में इस कोर्स के पहले हिस्से में चर्चा की गई थी. अब कई साइटें सबसे पहले यह तय करती हैं कि कौनसे सवाल पूछने हैं और इसके बाद, उन सवालों के जवाब देने के लिए, खास और सीमित डेटा इकट्ठा करें.
अगर आपकी साइट और दूसरी साइटें तीसरे पक्ष की किसी सेवा का इस्तेमाल करती हैं और वह काम करती हैं, तो अपनी साइट में उनकी JavaScript शामिल करें, और यह हर उपयोगकर्ता के लिए कुकी सेट करता है, तो इस बात पर ध्यान देना ज़रूरी हो जाता है कि कहीं वे दूसरी साइट के डेटा को अनचाहे तरीके से पहचान रहे हैं या नहीं; यानी, अलग-अलग साइटों पर अपने उपयोगकर्ताओं को ट्रैक करना. ऐसा हो सकता है और कुछ न भी हों, लेकिन निजता की सुरक्षा के नज़रिए से यह माना जाता है कि ऐसी तीसरे पक्ष की सेवा का मतलब है क्रॉस-साइट ट्रैकिंग करना. ऐसा तब तक किया जा सकता है, जब तक कि आपके पास इस बारे में सोचने या जानने का कोई सही वजह न हो. अपने-आप में ऐसी सेवाओं से बचने की यह वजह नहीं है, लेकिन आपको ट्रेड-ऑफ़ का आकलन करते समय इस बात का ध्यान रखना चाहिए इस्तेमाल न किया जा सके.
Analytics को इस्तेमाल करने का विकल्प, सिर्फ़ यह तय करने में इस्तेमाल किया जाता था कि इसका इस्तेमाल करना है या नहीं: पूरा डेटा इकट्ठा करना और इसके बदले में निजता को खतरे में डालना या पूरी जानकारी शामिल न करें. हालांकि, अब ऐसा नहीं होता है और ऐसे मामलों में अक्सर इन दो चरम सीमाओं के बीच पाया जा सकता है. सीमित करने के लिए कॉन्फ़िगरेशन विकल्पों के लिए अपनी एनालिटिक्स कंपनी देखें इकट्ठा किए गए डेटा को कम कर सकता है. साथ ही, इसके स्टोरेज और स्टोरेज की अवधि को कम कर सकता है. आपके पास टेक्निकल ऑडिट के रिकॉर्ड हैं ऊपर बताए गए कॉन्फ़िगरेशन के मुताबिक, उस ऑडिट के सेक्शन को फिर से चलाया जा सकता है. इससे यह पुष्टि हो पाएगी कि इन कॉन्फ़िगरेशन में बदलाव करने से कम करने के लिए किया जा सकता है. अगर किसी मौजूदा साइट पर यह बदलाव किया जा रहा है, तो मापे जा सकने वाले कुछ मापे जा सकते हैं. इन्हें अपने उपयोगकर्ताओं के बारे में लिखा जा सकता है. उदाहरण के लिए, 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">; और यदि आप विशिष्ट तृतीय पक्षों के बारे में चिंतित हैं, तो आप referrerpolicy
<script>, <a> या <iframe> जैसे अलग-अलग एलिमेंट पर एट्रिब्यूट: <script src="https://thirdparty.example.com/data.js" referrerpolicy="no-referrer">
Content-Security-Policy
Content-Security-Policy हेडर को अक्सर "सीएसपी" कहा जाता है. इससे पता चलता है कि बाहरी रिसॉर्स कहां से लोड किए जा सकते हैं.
इसका इस्तेमाल मुख्य रूप से सुरक्षा के मकसद से किया जाता है. ऐसा क्रॉस-साइट स्क्रिप्टिंग हमलों और स्क्रिप्ट इंजेक्शन को रोकने के लिए किया जाता है. हालांकि, जब इसका इस्तेमाल किया जाता है, तब भी इसे इस्तेमाल किया जाता है
नियमित ऑडिट के साथ-साथ, यह भी तय कर सकता है कि आपके चुने हुए तीसरे पक्ष, डेटा कहां भेज सकते हैं.
इससे उपयोगकर्ताओं को बेहतरीन अनुभव मिल सकता है; अगर तीसरे पक्ष की कोई स्क्रिप्ट ऑरिजिन आपकी सूची में नहीं है, तो वह अनुरोध ब्लॉक कर दिया जाएगा और स्क्रिप्ट काम नहीं करेगी. साथ ही, हो सकता है कि इसके साथ आपका ऐप्लिकेशन काम न करे (या कम से कम उसके JavaScript-काम न करने वाले फ़ॉलबैक वर्शन तक सीमित कर दिया जाए). यह तब फ़ायदेमंद होता है, जब सुरक्षा के लिए सीएसपी को लागू किया जाता है, जो इसका सामान्य मकसद है: क्रॉस-साइट स्क्रिप्टिंग से जुड़ी समस्याओं से बचाना (और ऐसा करने के लिए, स्ट्रिक्ट सीएसपी का इस्तेमाल करें). आपके पेज पर इस्तेमाल होने वाली सभी इनलाइन स्क्रिप्ट के बारे में जानने के बाद, उनकी सूची बनाई जा सकती है. साथ ही, हैश वैल्यू कैलकुलेट की जा सकती है या कोई रैंडम वैल्यू जोड़ी जा सकती है हर एक के लिए (जिसे "nonce" कहा जाता है) और फिर कॉन्टेंट की सुरक्षा के बारे में अपनी नीति में हैश की सूची जोड़ें. यह ऐसी किसी भी स्क्रिप्ट को रोक देगा, जो लोड होने से सूची में नहीं है. इसे साइट की प्रोडक्शन प्रोसेस में शामिल करना ज़रूरी है: आपके पेज में मौजूद स्क्रिप्ट नॉन्स शामिल करने या बिल्ड के हिस्से के तौर पर हैश की गिनती करने के लिए. पूरी जानकारी के लिए, 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 के ज़रिए लोड किए गए सबफ़्रेम वाले पेजों के लिए. एपीआई के इस्तेमाल की यह पाबंदी, ब्राउज़र फ़िंगरप्रिंट के बारे में नहीं है; इसका मकसद तीसरे पक्षों को रुकावट डालने वाली गतिविधियां करने से रोकना है. जैसे, असरदार एपीआई का इस्तेमाल करना, पॉप-अप विंडो में
अनुमतियों वाली विंडो वगैरह). इसे टारगेट प्राइवसी थ्रेट मॉडल से, "intrusion" के तौर पर परिभाषित किया जाता है.
Permissions-Policy हेडर को (सुविधा, अनुमति वाले ऑरिजिन) पेयर की सूची के तौर पर इस तरह तय किया जाता है:
Permissions-Policy: geolocation=(self "https://example.com"), camera=(), fullscreen=*
इस उदाहरण में, इस पेज ("self") और ऑरिजिन example.com से <iframe> को navigator.geolocation एपीआई इस्तेमाल करने की अनुमति दी गई है
पहले से इस्तेमाल हो रहा हो; यह इस पेज और सभी सबफ़्रेम को फ़ुल स्क्रीन एपीआई का इस्तेमाल करने की मंज़ूरी देता है. साथ ही, ऐसे किसी भी पेज को अनुमति नहीं देता है, जिसमें यह पेज शामिल है,
वीडियो की जानकारी पढ़ने के लिए कैमरे का इस्तेमाल करने से रोका जा सकता है. ज़्यादा जानकारी और संभावित उदाहरणों की सूची यहां दी गई है.
अनुमतियों से जुड़ी नीति के हेडर से मैनेज की जाने वाली सुविधाओं की सूची बड़ी है और हो सकता है कि इन सुविधाओं का फ़्लो सही हो. फ़िलहाल, यह सूची 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 इंजन), और बेहतर ट्रैकिंग सुरक्षा (और इसका इंजन, 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 कुछ और जानकारी देता है).
- तीसरे पक्ष की कुकी पूरी तरह से सीमित होती हैं. इसलिए, हर साइट का एक अलग कुकी जार होता है और उन्हें आपस में जोड़ा नहीं जा सकता साइटें (Mozilla इसे "कुल कुकी सुरक्षा" कहता है.
ब्लॉक की गई चीज़ों के बारे में अहम जानकारी पाने और समस्याओं को डीबग करने के लिए, पता बार में शील्ड आइकॉन पर क्लिक करें या Firefox में about:protections पर जाएं (डेस्कटॉप पर).
Safari
- तीसरे पक्ष की कुकी डिफ़ॉल्ट रूप से ब्लॉक होती हैं.
- अपनी इंटेलिजेंट ट्रैकिंग प्रिवेंशन सुविधा के तहत,
Safari किसी खास पेज के बजाय, दूसरे पेजों को दिए गए रेफ़रर को कम करके टॉप-लेवल की साइट बना देता है: (
https://something.example.com, बजायhttps://something.example.com/this/specific/page). - ब्राउज़र
localStorageका डेटा सात दिनों के बाद मिटा दिया जाता है.
(https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ तक इन सुविधाओं के बारे में खास जानकारी देता है.)
ब्लॉक की जा सकने वाली चीज़ों के बारे में अहम जानकारी पाने और समस्याओं को डीबग करने के लिए, "इंटेलिजेंट ट्रैकिंग प्रिवेंशन डीबग मोड" को चालू करें डेवलपर मेन्यू खोलें (डेस्कटॉप पर). ज़्यादा जानकारी के लिए, https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/ देखें.
एपीआई के प्रस्ताव
हमें नए एपीआई की ज़रूरत क्यों है?
ब्राउज़र प्रॉडक्ट में, निजता बनाए रखने से जुड़ी नई सुविधाएं और नीतियां, उपयोगकर्ता की निजता को बनाए रखने में मदद करती हैं. हालांकि, उनके साथ चुनौतियां भी आती हैं. कई वेब टेक्नोलॉजी, दूसरे कामों के लिए डिज़ाइन और इस्तेमाल किए जाने के बाद भी क्रॉस-साइट ट्रैकिंग के लिए इस्तेमाल की जा सकती हैं. उदाहरण के लिए, रोज़ाना इस्तेमाल किए जाने वाले कई आइडेंटिटी फ़ेडरेशन सिस्टम, तीसरे पक्ष की कुकी पर निर्भर रहते हैं. पब्लिशरों को दिखने वाले विज्ञापन दिखाने के लिए उपलब्ध कई तरह के समाधान और आज के समय में हम तीसरे पक्ष की कुकी का इस्तेमाल करते हैं. धोखाधड़ी का पता लगाने के कई तरीके, फ़िंगरप्रिंट की सुविधा का इस्तेमाल करते हैं. क्या फ़ायदे दें तीसरे पक्ष की कुकी और फ़िंगरप्रिंट की सुविधा बंद होने के बाद, इस्तेमाल के इन मामलों में क्या होता है?
ब्राउज़र के लिए, इस्तेमाल के उदाहरणों को अलग करना और निजता का उल्लंघन करने वाले इस्तेमाल के बीच सही तरीके से अंतर करना मुश्किल और गड़बड़ी-संभावित हो सकता है अन्य से. यही वजह है कि ज़्यादातर बड़े ब्राउज़र तीसरे पक्ष की कुकी और फ़िंगरप्रिंटिंग को ब्लॉक कर देते हैं. ऐसा करना उपयोगकर्ता की सुरक्षा के लिए निजता.
अब आपको नया तरीका अपनाने की ज़रूरत है: तीसरे पक्ष की कुकी के इस्तेमाल को धीरे-धीरे बंद किया जा रहा है और फ़िंगरप्रिंट की सुविधा का इस्तेमाल कम किया जा रहा है. इसलिए, डेवलपर को खास मकसद के लिए बनाए गए एपीआई की ज़रूरत होगी जो अब भी इस्तेमाल के उदाहरण की ज़रूरतों को पूरा करते हैं. हालांकि, इन्हें निजता की सुरक्षा को ध्यान में रखकर डिज़ाइन किया गया है. इसका मकसद है, प्रॉडक्ट को डिज़ाइन करना और ऐसे एपीआई जिनका इस्तेमाल क्रॉस-साइट ट्रैकिंग के लिए नहीं किया जा सकता. पिछले सेक्शन में ब्राउज़र की जिन सुविधाओं के बारे में बताया गया है उनसे अलग ये टेक्नोलॉजी, क्रॉस-ब्राउज़र एपीआई बनाने की कोशिश करें.
एपीआई प्रपोज़ल के उदाहरण
नीचे दी गई सूची में पूरी जानकारी नहीं दी गई है—यह उन विषयों का ब्यौरा है जिनके बारे में चर्चा की जा रही है.
तीसरे पक्ष की कुकी पर बनी टेक्नोलॉजी को बदलने के लिए, एपीआई प्रपोज़ल के उदाहरण:
- पहचान से जुड़े इस्तेमाल के उदाहरण: FedCM
- विज्ञापनों के इस्तेमाल के उदाहरण: निजी क्लिक का मेज़रमेंट, इंटरऑपरेबल प्राइवेट एट्रिब्यूशन, एट्रिब्यूशन रिपोर्टिंग, विषय, FLEDGE, PARAKEET.
पैसिव ट्रैकिंग पर आधारित टेक्नोलॉजी को बदलने के लिए, एपीआई प्रपोज़ल के उदाहरण:
- धोखाधड़ी का पता लगाने के इस्तेमाल के उदाहरण: ट्रस्ट टोकन.
ऐसे अन्य प्रस्तावों के उदाहरण जिन्हें अन्य एपीआई आने वाले समय में, तीसरे पक्ष की कुकी के बिना बना सकते हैं:
इसके अलावा, ब्राउज़र पर आधारित गुप्त ट्रैकिंग के जोखिमों को कम करने के लिए, एक अन्य तरह का एपीआई प्रपोज़ल भी उपलब्ध कराया जा रहा है. इसका एक उदाहरण Privacy बजट है. इन अलग-अलग इस्तेमाल के उदाहरण, जिन एपीआई का सुझाव Chrome ने शुरुआत में दिया था वे Privacy Sandbox के तहत आते हैं.
Global-Privacy-Control एक हेडर है. इसका मकसद किसी साइट को उपयोगकर्ता इकट्ठा किए गए किसी भी निजी डेटा को अन्य साइटों के साथ शेयर न करना चाहे. इसका मकसद Do Not Track के जैसा ही है, जिसे बंद कर दिया गया था.
एपीआई प्रपोज़ल की स्थिति
इनमें से ज़्यादातर एपीआई प्रपोज़ल अभी तक डिप्लॉय नहीं किए गए हैं या उन्हें सिर्फ़ फ़्लैग की मदद से या एक्सपेरिमेंट के लिए सीमित एनवायरमेंट में डिप्लॉय किया गया है.
सार्वजनिक तौर पर, सेवाएं चालू करने का यह चरण अहम है: ब्राउज़र वेंडर और डेवलपर, इस बारे में चर्चा और अनुभव इकट्ठा करते हैं कि ये एपीआई उपयोगी होती है और क्या वे वाकई उस काम को करती हैं जिसके लिए उन्हें बनाया गया है. इस चरण को डेवलपर, ब्राउज़र वेंडर, और नेटवर्क से जुड़े अन्य ऐक्टर इस्तेमाल करते हैं एपीआई के डिज़ाइन को फिर से बनाने के लिए किया जा सकता है.
नए एपीआई के बारे में अप-टू-डेट रहने के लिए सबसे सही जगह, GitHub पर निजता ग्रुप के प्रस्तावों की सूची है.
क्या आपको इन एपीआई का इस्तेमाल करना होगा?
अगर आपका प्रॉडक्ट सीधे तौर पर तीसरे पक्ष की कुकी या तकनीक के आधार पर बनाया गया है, जैसे कि फ़िंगरप्रिंट की सुविधा, तो आपको इन नए एपीआई का इस्तेमाल करना चाहिए. साथ ही, इनके साथ एक्सपेरिमेंट करना चाहिए. साथ ही, बातचीत और एपीआई डिज़ाइन को बेहतर बनाने के अपने अनुभव शेयर करने चाहिए. अन्य सभी मामलों में, जवाब लिखते समय, यह ज़रूरी नहीं है कि आपको इन नए एपीआई से जुड़ी पूरी जानकारी पता हो. हालांकि, आने वाली नई सुविधाओं के बारे में जानकारी होना बेहतर रहता है.