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

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

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

ब्राउज़र सहायता

• 114
• 114
• x
• x

सोर्स

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

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

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

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

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

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

CHIPS ने एक नया कुकी एट्रिब्यूट 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, साइट A पर एम्बेड करते समय सेट करती है. ब्राउज़र उस कुकी को तभी भेजेगा, जब टॉप-लेवल की साइट A होगी.

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

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

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

इस्तेमाल के उदाहरण

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

टॉप लेवल साइट Retail.example को तीसरे पक्ष की सेवा में जोड़ना support.chat.example.

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

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

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

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

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

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

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

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

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

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

कुकी पार्टिशन का टेक्निकल डिज़ाइन

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

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

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

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

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

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

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

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

साइट A और एम्बेड की गई साइट C, पार्टिशन की गई कुकी शेयर करती हैं. एम्बेड नहीं किए जाने पर, साइट C पार्टिशन की गई कुकी को ऐक्सेस नहीं कर सकती.

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

key=("support.chat.example")

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

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

ध्यान दें: Chrome के हर हिस्से के लिए, ज़्यादा से ज़्यादा 180 कुकी हो सकती हैं. किसी साइट को एम्बेड करने के बाद, उसका साइज़ 10 केबी से ज़्यादा नहीं होना चाहिए.

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

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

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

उदाहरण:

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

ध्यान दें: SameSite=None जोड़ने से आपकी कुकी को तीसरे पक्ष के ऐसे कॉन्टेक्स्ट में भेजा जा सकता है जहां Partitioned एट्रिब्यूट का इस्तेमाल नहीं किया जा सकता. ऐसा तब तक होगा, जब तक ब्राउज़र सेटिंग में तीसरे पक्ष की कुकी को अनुमति दी गई हो.

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

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

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

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

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

'मिलती-जुलती वेबसाइट के सेट' का डिज़ाइन, स्टोरेज ऐक्सेस एपीआई पर निर्भर करता है. यह सीएचआईपीएस पार्टीशन के साथ इंटिग्रेट नहीं होता. अगर आपके पास इस्तेमाल का कोई ऐसा उदाहरण है जो RWS में मौजूद साइटों के बीच शेयर की गई कुकी पार्टीशन पर निर्भर है, तो 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 चुने गए ऑरिजिन की सभी कुकी दिखाएगा.

DevTools ऐप्लिकेशन टैब में साइट B की कुकी.

साइट B, पार्टिशन्ड कुकी को सिर्फ़ क्रॉस-साइट कॉन्टेक्स्ट में सेट कर सकती है. यह कुकी ब्लॉक नहीं होगी:

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

__Host-partitioned-cookie के लिए विभाजन कुंजी.

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

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

टॉप लेवल पर, साइट B पर सभी कुकी देखी जा सकती हैं - वे कुकी को अलग-अलग सेगमेंट में नहीं बांटना चाहते हैं

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

• unpartitioned-cookie में कोई खाली विभाजन कुंजी है.
• __Host-partitioned-cookie कुकी में विभाजन कुंजी https://chips-site-b.glitch.me है.

B को टॉप-लेवल वाली साइट के तौर पर विज़िट करने पर, DevTools ऐप्लिकेशन टैब में साइट B की कुकी. __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 दिखेगा.

नेटवर्क टैब, साइट B iframe की कुकी दिखा रहा है, जो साइट A पर एम्बेड होने पर ऐक्सेस की जा सकती हैं.

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

नेटवर्क टैब, जिसमें साइट B iframe की ब्लॉक की गई कुकी दिख रही हैं.

ध्यान दें: आपने B को टॉप लेवल साइट के तौर पर विज़िट किया था. इसलिए, साइट B में पार्टिशन की कुंजी https://chips-site-b.glitch.me के साथ एक पार्टिशन्ड कुकी भी मौजूद है, जो इस कॉन्टेक्स्ट में इसके लिए उपलब्ध नहीं है. इसलिए, आपको यह मैसेज दिखेगा: "इस साइट के एक और हिस्से में ऐसी कुकी हैं जो इस अनुरोध के साथ नहीं भेजी गई थीं".

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

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

DevTools ऐप्लिकेशन टैब में साइट B की कुकी. __Host-partitioned-cookie कुकी में विभाजन कुंजी https://chips-site-a.glitch.me है. unpartitioned-cookie दिखाया गया है, लेकिन साइट A में एम्बेड होने पर इसे साइट B iframe पर ऐक्सेस नहीं किया जा सकता.

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

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

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

रिसॉर्स

• GitHub: जानकारी पढ़ें, सवालों को पूछें, और चर्चा को फ़ॉलो करें.
• डेवलपर सहायता: प्राइवसी सैंडबॉक्स डेवलपर सहायता रेपो पर होने वाली चर्चा में हिस्सा लें और सवाल पूछें.