ऐसी कुकी जो स्वतंत्र रूप से बंटी हुई हैं (सीएचआईपीएस)

डेवलपर को किसी कुकी को "सेगमेंट में बांट दिया गया" में ऑप्ट इन करने की अनुमति दें स्टोरेज, हर टॉप लेवल साइट के लिए एक अलग कुकी जार के साथ.

लागू करने की स्थिति

• Chrome 114 और इसके बाद के वर्शन में डिफ़ॉल्ट रूप से काम करता है.
• Chrome 100 से लेकर वर्शन 116 तक का ऑरिजिन ट्रायल अब पूरा हो गया है.
• प्रयोग करने की इच्छा और शिप करने का इरादा लेख पढ़ें.

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

सीएचआईपीएस क्या है?

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

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

ब्राउज़र, तीसरे पक्ष की उन कुकी को बंद कर रहे हैं जिन्हें हिस्सों में नहीं बांटा गया है. इसलिए, तीसरे पक्ष की कुकी ब्लॉक होने पर, सीएचआईपीएस, स्टोरेज ऐक्सेस एपीआई, और मिलती-जुलती वेबसाइट के सेट के ज़रिए ही क्रॉस-साइट कॉन्टेक्स्ट से कुकी पढ़ने और उनमें बदलाव किए जा सकते हैं.

सीएचआईपीएस ने कुकी के लिए नया एट्रिब्यूट Partitioned लॉन्च किया है. यह उन क्रॉस-साइट कुकी के साथ काम करता है जिन्हें टॉप लेवल कॉन्टेक्स्ट के आधार पर बांटा गया है.

सेट-कुकी हेडर:

Set-Cookie: __Host-name=value; Secure; Path=/; SameSite=None; Partitioned;

JavaScript:

document.cookie="__Host-name=value; Secure; Path=/; SameSite=None; Partitioned;"

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

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

जब कोई उपयोगकर्ता किसी नई साइट, जैसे कि B पर जाता है, तो एम्बेड किए गए सी फ़्रेम को वह कुकी नहीं मिलेगी जो साइट A में C को एम्बेड करते समय सेट की गई थी.

अगर कोई उपयोगकर्ता साइट C पर टॉप लेवल की वेबसाइट के तौर पर जाता है, तो A में एम्बेड होने के दौरान, C से सेट की गई पार्टिशन्ड कुकी भी उस अनुरोध में नहीं भेजी जाएगी.

उपयोग के उदाहरण

उदाहरण के लिए, हो सकता है कि साइट retail.example किसी तीसरे पक्ष की सेवा support.chat.example के साथ काम करके, उसकी साइट पर सहायता चैट बॉक्स एम्बेड करना चाहे. एम्बेड की जा सकने वाली कई चैट सेवाएं, स्थिति बचाने के लिए कुकी का इस्तेमाल करती हैं.

क्रॉस-साइट कुकी सेट न किए जाने पर, support.chat.example को स्थिति सेव करने के लिए, वैकल्पिक तरीके ढूंढने होंगे. ये तरीके अक्सर ज़्यादा जटिल होते हैं. इसके अलावा, इसे टॉप लेवल पेज में एम्बेड करना होगा जिससे जोखिम हो सकता है. ऐसा इसलिए, क्योंकि इससे support.chat.example स्क्रिप्ट को Retail.example पर खास अधिकारों को ऐक्सेस करने की अनुमति मिलती है. जैसे, पुष्टि करने वाली कुकी ऐक्सेस करने की सुविधा.

सीएचआईपीएस, क्रॉस-साइट कुकी का इस्तेमाल जारी रखने का आसान विकल्प देता है. इसमें अलग-अलग कुकी के इस्तेमाल से जुड़े जोखिम नहीं होते.

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

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

सीएचआईपीएस, ऑप्ट-इन पार्टीशन मॉडल का इस्तेमाल क्यों करता है

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

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

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

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

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

कुकी विभाजन तकनीकी डिज़ाइन

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

उदाहरण के लिए, https://support.chat.example की कुकी के लिए, होस्ट कुंजी ("support.chat.example") है.

सीएचआईपीएस में, पार्टिशनिंग के लिए ऑप्ट इन करने वाली कुकी को होस्ट कुंजी और पार्टिशन कुंजी पर दो बार दबाकर रखा जाएगा.

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

पहले के उदाहरण में, जहां https://support.chat.example को https://retail.example पर एम्बेड किया गया है, वहीं टॉप लेवल यूआरएल https://retail.example है.

इस मामले में, पार्टिशन कुंजी ("https", "retail.example") है.

इसी तरह, अनुरोध की विभाजन कुंजी उस शीर्ष-स्तरीय URL की साइट होती है, जिसे ब्राउज़र अनुरोध के प्रारंभ में विज़िट करता है. ब्राउज़र को सिर्फ़ उन अनुरोधों में Partitioned एट्रिब्यूट वाली कुकी भेजनी चाहिए जो उस कुकी के साथ काम करने वाली पार्टिशन कुंजी के साथ काम करती हैं.

यहां बताया गया है कि उदाहरण में दी गई कुकी कुंजी, सीएचआईपीएस से पहले और बाद में कैसी दिखती है.

सीएचआईपीएस से पहले

key=("support.chat.example")

सीएचआईपीएस के बाद

key={("support.chat.example"),("https", "retail.example")}

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

सिक्योरिटी डिज़ाइन

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

• सेगमेंट में बांटी गई कुकी, Secure के साथ सेट होनी चाहिए.
• यह सुझाव दिया जाता है कि अलग-अलग हिस्सों में बांटे गई कुकी को सेट करते समय, __Host- प्रीफ़िक्स का इस्तेमाल करें, ताकि वे होस्टनेम तक सीमित रहें, न कि रजिस्टर किए जा सकने वाले डोमेन से.

उदाहरण:

Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

सीएचआईपीएस के विकल्प

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

ये सीएचआईपीएस पार्टिशन के विकल्प हैं, जहां क्रॉस-साइट और बिना पार्टिशन वाले कुक का ऐक्सेस होना ज़रूरी है.

अगर आपको मिलती-जुलती कई साइटों में एम्बेड की गई किसी सेवा के लिए एक जैसी कुकी की ज़रूरत है, तो Storage Access API और मिलती-जुलती वेबसाइट के सेट का इस्तेमाल करें.

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

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

डेमो

इस डेमो में बताया जाएगा कि अलग-अलग हिस्सों में बंटी हुई कुकी कैसे काम करती हैं. साथ ही, DevTools में उनकी जांच करने का तरीका भी बताया गया है.

साइट A, साइट B से एक iframe एम्बेड करती है, जो दो कुकी सेट करने के लिए JavaScript का इस्तेमाल करती है: पहली, सेगमेंट में बांटी गई और बिना सेगमेंट वाली कुकी. साइट B, document.cookie का इस्तेमाल करके उस जगह से ऐक्सेस की जा सकने वाली सभी कुकी दिखाती है.

तीसरे पक्ष की कुकी ब्लॉक होने पर, साइट B सिर्फ़ क्रॉस-साइट कॉन्टेक्स्ट में Partitioned एट्रिब्यूट वाली कुकी को सेट और ऐक्सेस कर पाएगी.

तीसरे पक्ष की कुकी को अनुमति देने पर, साइट B भी उन कुकी को सेट कर सकती है और उन्हें ऐक्सेस कर सकती है जो सेगमेंट में नहीं बांटी गई हैं.

ज़रूरी शर्तें

1. Chrome 118 या इसके बाद का वर्शन हो.
2. chrome://flags/#test-third-party-cookie-phaseout पर जाएं और यह सेटिंग चालू करें

बंटी हुई कुकी की जांच करने के लिए DevTools का इस्तेमाल करना

1. https://chips-site-a.glitch.me पर जाएं.
2. DevTools खोलने के लिए, Control+Shift+J या Mac पर Command+Option+J दबाएं.
3. ऐप्लिकेशन टैब पर क्लिक करें.
4. ऐप्लिकेशन > स्टोरेज > कुकी.
5. https://chips-site-b.glitch.me पर क्लिक करें.

DevTools चुने गए ऑरिजिन की सभी कुकी दिखाएगा.

साइट B, सिर्फ़ अलग-अलग साइट के कॉन्टेक्स्ट में सेगमेंट में बांटी गई कुकी सेट कर सकता है. ऐसी कुकी ब्लॉक कर दी जाएंगी:

• आपको टॉप लेवल साइट https://chips-site-a.glitch.me की पार्टिशन कुंजी के साथ __Host-partitioned-cookie दिखना चाहिए.

1. साइट B पर जाएं पर क्लिक करें.
2. DevTools में, ऐप्लिकेशन > स्टोरेज > कुकी.
3. https://chips-site-b.glitch.me पर क्लिक करें.

इस स्थिति में, क्योंकि आप टॉप-लेवल कॉन्टेक्स्ट में साइट B पर हैं, इसलिए यह दोनों कुकी को सेट कर सकता है और उन्हें ऐक्सेस कर सकता है:

• unpartitioned-cookie में एक खाली विभाजन कुंजी है.
• __Host-partitioned-cookie कुकी में, पार्टिशन कुंजी https://chips-site-b.glitch.me होती है.

साइट A पर वापस जाने पर, unpartitioned-cookie अब ब्राउज़र में सेव हो जाएगा. हालांकि, इसे साइट A से ऐक्सेस नहीं किया जा सकेगा.

1. साइट A पर जाएं पर क्लिक करें.
2. नेटवर्क टैब पर क्लिक करें.
3. https://chips-site-b.glitch.me पर क्लिक करें.
4. कुकी टैब पर क्लिक करें.

साइट A पर, आपको टॉप लेवल साइट https://chips-site-a.glitch.me की पार्टिशन कुंजी के साथ __Host-partitioned-cookie दिखना चाहिए.

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

ऐप्लिकेशन में > स्टोरेज > कुकी, https://chips-site-b.glitch.me पर क्लिक कर रही हैं यह दिखाएगा:

• खाली विभाजन कुंजी के साथ unpartitioned-cookie.
• पार्टिशन कुंजी https://chips-site-a.glitch.me वाली __Host-partitioned-cookie कुकी.

कुकी साफ़ करें

डेमो रीसेट करने के लिए, साइट की सभी कुकी साफ़ करें:

• DevTools खोलने के लिए, Control+Shift+J या Mac पर Command+Option+J दबाएं.
• ऐप्लिकेशन टैब पर क्लिक करें.
• ऐप्लिकेशन > स्टोरेज > कुकी.
• https://chips-site-b.glitch.me पर राइट क्लिक करें.
• मिटाएं पर क्लिक करें.

संसाधन

• GitHub: पूरी जानकारी देने वाला पढ़ें, सवाल पूछें, और चर्चा का पालन करें.
• डेवलपर सहायता: Privacy Sandbox के डेवलपर सहायता रेपो पर सवाल पूछें और चर्चाओं में शामिल हों.