डेवलपर को "सेगमेंट में बांटी गई" स्टोरेज में कुकी चुनने की अनुमति दें, जिसमें हर टॉप लेवल साइट के लिए एक अलग कुकी जार हो.
लागू किए जाने की स्थिति
- 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
की साइट पर सहायता चैट बॉक्स एम्बेड करने के लिए काम करना चाहे. एम्बेड की जा सकने वाली कई चैट सेवाएं, मौजूदा समय में डेटा सेव करने के लिए कुकी का इस्तेमाल करती हैं.
क्रॉस-साइट कुकी सेट न कर पाने पर, 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 से पहले और बाद में कैसी दिखती है.
सीएचआईपीएस से पहले
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 और इससे जुड़े मिलती-जुलती वेबसाइट के सेट (RWS), वेब प्लैटफ़ॉर्म के वे तरीके हैं जिनसे उपयोगकर्ताओं के लिए उपलब्ध खास मकसद के लिए, क्रॉस-साइट कुकी का सीमित ऐक्सेस चालू किया जा सकता है.
सीएचआईपीएस बंटवारे की जगह, ये ऐसे विकल्प हैं जिनमें अलग-अलग साइटों पर मौजूद, अलग-अलग हिस्सों वाले कुक का ऐक्सेस देना ज़रूरी होता है.
Storage Access API और मिलती-जुलती वेबसाइट के सेट का इस्तेमाल तब करें, जब आपको किसी ऐसी सेवा में एक जैसी कुकी उपलब्ध करानी हो जिसे मिलती-जुलती कई साइटों में एम्बेड किया गया हो.
CHIPS, किसी सेवा को कई साइटों पर एक आइसोलेटेड कॉम्पोनेंट के तौर पर काम करने की सुविधा देता है, जहां एक ही कुकी के कई साइटों पर उपलब्ध होने की ज़रूरत नहीं होती. अगर सेवा पार्टिशन्ड कुकी सेट करती है, तो उसकी पार्टीशन कुंजी, टॉप लेवल की साइट होगी. साथ ही, वह कुकी उन साइटों के लिए भी उपलब्ध नहीं होगी जो इस सेवा का इस्तेमाल कर रही हैं.
'मिलती-जुलती वेबसाइट के सेट' का डिज़ाइन, स्टोरेज ऐक्सेस एपीआई पर निर्भर करता है. यह सीएचआईपीएस पार्टीशन के साथ इंटिग्रेट नहीं होता. अगर आपके पास इस्तेमाल का कोई ऐसा उदाहरण है जो RWS में मौजूद साइटों के बीच शेयर की गई कुकी पार्टीशन पर निर्भर है, तो GitHub की समस्या के बारे में उदाहरण और सुझाव दें.
डेमो
इस डेमो में आपको बताया जाएगा कि बांटी गई कुकी कैसे काम करती हैं और DevTools में उनकी जांच कैसे की जा सकती है.
साइट A, साइट B से एक iframe एम्बेड करती है, जो दो कुकी को सेट करने के लिए JavaScript का इस्तेमाल करता है: पार्टिशन्ड और बिना पार्टीशन वाली कुकी. साइट B उन सभी कुकी को दिखाती है जिन्हें उस जगह से ऐक्सेस किया जा सकता है. इसके लिए, document.cookie
का इस्तेमाल किया जाता है.
तीसरे पक्ष की कुकी ब्लॉक होने पर, साइट B सिर्फ़ क्रॉस-साइट कॉन्टेक्स्ट में Partitioned
एट्रिब्यूट का इस्तेमाल करके, कुकी को सेट और ऐक्सेस कर पाएगी.
तीसरे पक्ष की कुकी को अनुमति मिलने पर, साइट B बिना पार्टीशन वाली कुकी को भी सेट और ऐक्सेस कर सकती है.
ज़रूरी शर्तें
- Chrome 118 या उसके बाद का वर्शन.
chrome://flags/#test-third-party-cookie-phaseout
पर जाएं और इस सेटिंग को चालू करें
अलग-अलग सेगमेंट में बांटी गई कुकी की जांच करने के लिए, DevTools का इस्तेमाल करें
- https://chips-site-a.glitch.me पर जाएं.
- DevTools खोलने के लिए
Control+Shift+J
(या Mac परCommand+Option+J
) दबाएं. - ऐप्लिकेशन टैब पर क्लिक करें.
- ऐप्लिकेशन > स्टोरेज > कुकी पर जाएं.
https://chips-site-b.glitch.me
पर क्लिक करें.
DevTools चुने गए ऑरिजिन की सभी कुकी दिखाएगा.
साइट B, पार्टिशन्ड कुकी को सिर्फ़ क्रॉस-साइट कॉन्टेक्स्ट में सेट कर सकती है. यह कुकी ब्लॉक नहीं होगी:
- आपको टॉप लेवल साइट
https://chips-site-a.glitch.me
की विभाजन कुंजी के साथ__Host-partitioned-cookie
दिखना चाहिए.
- साइट B पर जाएं पर क्लिक करें.
- DevTools में, ऐप्लिकेशन > स्टोरेज > कुकी पर जाएं.
https://chips-site-b.glitch.me
पर क्लिक करें.
इस स्थिति में, टॉप लेवल कॉन्टेक्स्ट में साइट B पर होने की वजह से, यह दोनों कुकी को सेट और ऐक्सेस कर सकता है:
unpartitioned-cookie
में कोई खाली विभाजन कुंजी है.__Host-partitioned-cookie
कुकी में विभाजन कुंजीhttps://chips-site-b.glitch.me
है.
साइट A पर वापस जाने पर, unpartitioned-cookie
को अब ब्राउज़र में सेव किया जाएगा. हालांकि, इसे साइट A से ऐक्सेस नहीं किया जा सकेगा.
- साइट A पर जाएं पर क्लिक करें.
- नेटवर्क टैब पर क्लिक करें.
https://chips-site-b.glitch.me
पर क्लिक करें.- कुकी टैब पर क्लिक करें.
साइट A पर रहने के दौरान, आपको टॉप लेवल साइट https://chips-site-a.glitch.me
की पार्टीशन कुंजी के साथ __Host-partitioned-cookie
दिखेगा.
फ़िल्टर की गई कुकी के अनुरोध दिखाएं को चुनने पर DevTools यह दिखेगा कि अलग-अलग कुकी ब्लॉक की गई हैं. इन्हें टूलटिप के साथ पीले रंग से हाइलाइट किया गया है: "उपयोगकर्ता की सेटिंग की वजह से इस कुकी को ब्लॉक किया गया था".
ऐप्लिकेशन > स्टोरेज > कुकी में, https://chips-site-b.glitch.me
पर क्लिक करने से यह दिखेगा:
unpartitioned-cookie
में, खाली पार्टीशन कुंजी का इस्तेमाल किया जा सकता है.__Host-partitioned-cookie
कुकी, जिसमें विभाजन कुंजीhttps://chips-site-a.glitch.me
है.
कुकी साफ़ करें
डेमो रीसेट करने के लिए, साइट की सभी कुकी मिटाएं:
- DevTools खोलने के लिए
Control+Shift+J
(या Mac परCommand+Option+J
) दबाएं. - ऐप्लिकेशन टैब पर क्लिक करें.
- ऐप्लिकेशन > स्टोरेज > कुकी पर जाएं.
https://chips-site-b.glitch.me
पर राइट क्लिक करें.- मिटाएं पर क्लिक करें.
रिसॉर्स
- GitHub: जानकारी पढ़ें, सवालों को पूछें, और चर्चा को फ़ॉलो करें.
- डेवलपर सहायता: प्राइवसी सैंडबॉक्स डेवलपर सहायता रेपो पर होने वाली चर्चा में हिस्सा लें और सवाल पूछें.