नई और सुरक्षित कुकी सेटिंग SameSite=None के लिए तैयार हो जाएं

गुरुवार, 16 जनवरी, 2020

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

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

Chrome, फ़रवरी 2020 में Chrome 80 वर्शन के साथ नए मॉडल को लागू करने की योजना बना रहा है. Mozilla और Microsoft ने भी संकेत दिए हैं कि वे Firefox और Edge में, अपने हिसाब से नए मॉडल को लागू करेंगे. हालांकि, Chrome में किए गए बदलावों को कुछ महीने बाद लागू किया जाएगा. फिर भी, यह ज़रूरी है कि कुकी मैनेज करने वाले डेवलपर अभी से इसके लिए तैयार रहें. इस ब्लॉग पोस्ट में, बड़े लेवल के सिद्धांतों के बारे में बताया गया है. डेवलपर के लिए दिशा-निर्देशों के बारे में जानने के लिए, कृपया web.dev पर जाकर, SameSite कुकी के बारे में जानकारी वाला लेख पढ़ें.

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

कई वेबसाइटों का मालिकाना हक रखने वाली किसी इकाई का अपनी सभी प्रॉपर्टी पर एक ही कुकी का इस्तेमाल करना, अलग-अलग साइटों वाली कुकी (क्रॉस-साइट कुकी) के इस्तेमाल का एक उदाहरण है. हालांकि, ऐसा कम होता है. हालांकि, अगर एक ही इकाई, कुकी और वेबसाइटों, दोनों का मालिकाना हक रखती है, तो भी उसे क्रॉस-साइट या "तीसरे पक्ष" वाली कुकी के तौर पर गिना जाएगा. ऐसा इसलिए, क्योंकि कुकी का डोमेन, उस साइट या साइटों से मेल नहीं खाता है, जिससे कुकी को ऐक्सेस किया जाता है.

साइट का डोमेन, कुकी के डोमेन से मेल नहीं खाता है

जब किसी वेब पेज पर मौजूद, तीसरे पक्ष का कोई रिसॉर्स ऐसी कुकी को ऐक्सेस करता है जो साइट के डोमेन से मेल नहीं खाती, तो उसे अलग-अलग साइटों या "तीसरे पक्ष" वाली कुकी कहा जाता है.

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

साइट का डोमेन, कुकी के डोमेन से मेल खाता है

जब किसी वेब पेज पर मौजूद कोई रिसॉर्स किसी ऐसी कुकी को ऐक्सेस करता है जो उपयोगकर्ता की देखी जा रही साइट से मेल खाती है, तो उसे एक ही साइट या "पहले पक्ष" वाली कुकी कहा जाता है.

अगर किसी कुकी को सिर्फ़ पहले पक्ष के तौर पर ऐक्सेस किया जाना है, तो किसी तीसरे पक्ष के ऐक्सेस को रोकने के लिए, डेवलपर दो में से कोई एक सेटिंग (SameSite=Lax या SameSite=Strict) लागू कर सकता है. हालांकि, बहुत ही कम डेवलपर, सुझाया गया यह तरीका अपनाते हैं. साथ ही, पहले पक्ष वाली कुकी को बड़ी संख्या में ऐसे ही छोड़ दिया जाता है, जिन पर कई तरह के खतरे हो सकते हैं. जैसे, किसी दूसरी साइट से किए जाने वाले संदिग्ध अनुरोध के ज़रिए हमले करना.

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

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

फ़रवरी 2020 में शुरू होने वाला Chrome एनफ़ोर्समेंट

फ़रवरी में Chrome 80 की शुरुआत के साथ, Chrome ऐसी कुकी को SameSite=Lax कुकी के तौर पर मानेगा जिनमें कोई भी SameSite वैल्यू नहीं बताई गई है. सिर्फ़ SameSite=None; Secure सेटिंग वाली कुकी को ही तीसरे पक्ष के रिसॉर्स ऐक्सेस कर सकेंगे. हालांकि, यह ज़रूरी है कि उन्हें सुरक्षित कनेक्शन से ऐक्सेस किया जा रहा हो. SameSite=None और Secure के लिए, Chrome Platform Status के ट्रैकर को अपडेट किया जाना जारी रहेगा. इनमें लॉन्च से जुड़ी नई जानकारी शामिल की जाएगी.

Mozilla ने कुकी क्लासिफ़िकेशन के नए मॉडल के साथ काम करने की सहमति दी है. इसके लिए, उन्होंने Firefox में, अलग-अलग साइटों वाली कुकी के लिए, ज़रूरी SameSite=None; Secure सेटिंग लागू करने की इच्छा भी जताई है. Microsoft ने हाल ही में, इस मॉडल को लागू करने का एलान किया है. शुरुआत में, इसे Microsoft Edge 80 में एक प्रयोग के तौर पर लागू किया जाएगा.

जटिलताओं से निपटने के लिए तैयारी कैसे करें

अगर उपयोगकर्ता अलग-अलग साइटों वाली कुकी मैनेज करता है, तो उसे उन कुकी के लिए, SameSite=None; Secure सेटिंग लागू करनी होगी. नए मॉडल को लागू करने की प्रक्रिया, ज़्यादातर डेवलपर के लिए आसान होनी चाहिए. हालांकि, हमारी सलाह है कि आप अभी से इसे जांचना शुरू करें, ताकि इसमें मौजूद जटिलताओं और खास मामलों की पहचान की जा सके, जैसा कि यहां बताया गया है:

  • None वैल्यू फ़िलहाल, सभी भाषाओं और लाइब्रेरी में काम नहीं करती है. इसलिए, डेवलपर को कुकी का हेडर सीधे तौर पर सेट करना होगा. GitHub की इस रिपॉज़िटरी (डेटा स्टोर करने की जगह) में, SameSite=None; Secure सेटिंग को लागू करने के लिए निर्देश दिए गए हैं. इनकी मदद से, इस सेटिंग को कई भाषाओं, लाइब्रेरी, और फ़्रेमवर्क में लागू किया जा सकता है.
  • हो सकता है कि कुछ ब्राउज़र में, None वैल्यू को अनचाहे तरीकों से मैनेज किया जाए. इनमें Chrome, Safari, और UC Browser के कुछ वर्शन शामिल हैं. इसकी वजह से, डेवलपर को ऐसे क्लाइंट के लिए अपवाद रखकर, कोड करने की ज़रूरत होगी. इसमें, Chrome के पुराने वर्शन की मदद से काम करने वाला Android वेबव्यू भी शामिल है. यहां कुछ ऐसे क्लाइंट की सूची दी गई है जिनके साथ यह एट्रिब्यूट काम नहीं करता.
  • ऐप्लिकेशन डेवलपर को सलाह दी जाती है कि वे Android WebViews के लिए सही SameSite cookie सेटिंग का एलान करें. यह सेटिंग, Chrome के उन वर्शन के आधार पर होनी चाहिए जिन पर None वैल्यू काम करती है. साथ ही, यह सेटिंग एचटीटीपी(एचटीटीपीएस) हेडर और Android WebView के CookieManager एपीआई, दोनों की मदद से ऐक्सेस किए जाने वाली कुकी के लिए होनी चाहिए. हालांकि, नए मॉडल को फ़िलहाल, Android वेबव्यू पर लागू नहीं किया जाएगा.
  • एंटरप्राइज़ आईटी एडमिन को खास नीतियां लागू करने की ज़रूरत पड़ सकती है, ताकि Chrome ब्राउज़र के काम करने के तरीके को कुछ समय के लिए पहले जैसा किया जा सके. ऐसा करने की ज़रूरत तब होगी, जब सिंगल साइन-ऑन या अंदरूनी ऐप्लिकेशन जैसी कुछ सेवाएं, फ़रवरी में किए जाने वाले लॉन्च के लिए तैयार नहीं होंगी.
  • अगर आपके पास ऐसी कुकी हैं जिन्हें पहले और तीसरे पक्ष, दोनों के लिए ऐक्सेस किया जाता है, तो पहले पक्ष के लिए, SameSite=Lax सुरक्षा फ़ायदे पाने के लिए, अलग-अलग कुकी इस्तेमाल की जा सकती हैं.

SameSite कुकी के बारे में पूरी जानकारी लेख में, ऊपर बताई गई स्थितियों के लिए खास दिशा-निर्देश दिए गए हैं. इसमें, समस्याओं की शिकायत करने और सवाल पूछने के तरीकों के बारे में भी बताया गया है.

Chrome के नए वर्शन के काम करने के तरीके का आपकी साइट या आपकी मैनेज की जाने वाली कुकी पर क्या असर होता है, इसकी जांच करने के लिए, Chrome 76 और इसके बाद वाले वर्शन में, chrome://flags पर जाएं. इसके बाद, "SameSite by default cookies" और "Cookies without SameSite must be secure" जांच चालू करें. साथ ही, ये जांच Chrome 79 के बीटा वर्शन के कुछ उपयोगकर्ताओं के लिए, अपने-आप चालू हो जाएंगी. बीटा वर्शन के कुछ ऐसे उपयोगकर्ता जिनके लिए ये जांच चालू होंगी, उन्हें वे सेवाएं इस्तेमाल करने में समस्याएं आ सकती हैं जो अभी नए मॉडल के साथ काम नहीं करती हैं. उपयोगकर्ता, बीटा वर्शन पर चालू इन जांच से ऑप्ट आउट कर सकते हैं. इसके लिए, उन्हें chrome://flags पर जाकर, जांच को बंद करना होगा.

अगर एक ही साइट के लिए ऐक्सेस की जाने वाली कुकी मैनेज करनी हैं, तो आपको कुछ भी करने की ज़रूरत नहीं है. ऐसे में, Chrome अपने-आप ही तीसरे पक्ष की इकाइयों को, उन कुकी को ऐक्सेस करने से रोक देगा. भले ही, SameSite एट्रिब्यूट मौजूद न हो या कोई वैल्यू सेट न की गई हो. हालांकि, हमारा सुझाव है कि आप सही SameSite वैल्यू (Lax या Strict) लागू करें और डिफ़ॉल्ट ब्राउज़र के भरोसे न रहें. ऐसा इसलिए, क्योंकि यह ज़रूरी नहीं है कि सभी ब्राउज़र डिफ़ॉल्ट रूप से, एक ही साइट के लिए ऐक्सेस की जाने वाली कुकी की सुरक्षा करते हों.

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

(कुकी डोमेन) में, अलग-अलग साइटों के रिसॉर्स से जुड़ी कुकी, 'SameSite' एट्रिब्यूट के बिना सेट की गई थी

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

यह लेख, Chrome और वेब प्लैटफ़ॉर्म पार्टनरशिप के बार्ब पाल्सर ने पोस्ट किया है