कई संगठनों की साइटों के डोमेन नेम अलग-अलग होते हैं. जैसे, brandx.site और fly-brandx.site या अलग-अलग देशों के लिए डोमेन, जैसे कि example.com, example.rs, example.co.uk वगैरह.
वेब पर निजता को बेहतर बनाने के लिए, ब्राउज़र तीसरे पक्ष की कुकी को अमान्य बनाने की दिशा में बढ़ रहे हैं. हालांकि, ऐसी साइटें अक्सर उन सुविधाओं के लिए कुकी पर निर्भर करती हैं जिनमें सभी डोमेन में स्थिति को बनाए रखने और ऐक्सेस करने की ज़रूरत होती है. जैसे, सिंगल साइन-ऑन और सहमति मैनेजमेंट.
फ़र्स्ट-पार्टी सेट की मदद से, मिलते-जुलते उन डोमेन नेम को फ़र्स्ट-पार्टी के तौर पर माना जा सकता है जिनका मालिकाना हक और जिन्हें एक ही इकाई मैनेज करती है. ऐसा तब किया जा सकता है, जब फ़र्स्ट-पार्टी और तीसरे पक्ष को अलग-अलग माना जाता हो. पहले पक्ष के सेट में मौजूद डोमेन नेम को एक ही पक्ष माना जाता है. साथ ही, वे यह लेबल कर सकते हैं कि किन कुकी को एक ही पक्ष के संदर्भ में सेट या भेजा जाना है. इसका मकसद, तीसरे पक्षों की क्रॉस-साइट ट्रैकिंग को रोकने के साथ-साथ, ऐसे पाथ को बनाए रखना है जिससे मान्य इस्तेमाल के उदाहरणों में कोई रुकावट न आए.
फ़िलहाल, पहले पक्ष के सेट का प्रस्ताव टेस्टिंग के चरण में है. यह कैसे काम करता है और इसे आज़माने का तरीका जानने के लिए, आगे पढ़ें.
पहले पक्ष और तीसरे पक्ष की कुकी में क्या अंतर है?
कुकी, पहले पक्ष या तीसरे पक्ष की नहीं होती हैं. यह इस बात पर निर्भर करता है कि कुकी को किस मौजूदा संदर्भ में शामिल किया गया है. यह cookie हेडर में अनुरोध करने पर या JavaScript में document.cookie के ज़रिए होता है.
उदाहरण के लिए, अगर video.site पर theme=dark कुकी है और video.site को ब्राउज़ करते समय video.site पर अनुरोध किया जाता है, तो इसे एक ही साइट का कॉन्टेक्स्ट कहा जाता है. साथ ही, शामिल की गई कुकी को पहले पक्ष की कुकी कहा जाता है.
हालांकि, अगर आप my-blog.site पर हैं, जो video.site के लिए iframe प्लेयर को एम्बेड करता है, तो my-blog.site से video.site पर अनुरोध करने पर, वह क्रॉस-साइट कॉन्टेक्स्ट होता है और theme कुकी तीसरे पक्ष की होती है.
कुकी को शामिल करने का फ़ैसला, कुकी के SameSite एट्रिब्यूट के हिसाब से लिया जाता है:
SameSite=Lax,StrictयाNoneके साथ Same-site context, कुकी को पहले पक्ष की कुकी बनाता है.SameSite=Noneके साथ क्रॉस-साइट कॉन्टेक्स्ट, कुकी को तीसरे पक्ष की कुकी बनाता है.
हालांकि, ऐसा हमेशा नहीं होता. मान लें कि brandx.site एक ट्रैवल बुकिंग साइट है. साथ ही, फ़्लाइट और किराये पर कार लेने की सेवाओं को अलग-अलग दिखाने के लिए, fly-brandx.site और drive-brandx.site का इस्तेमाल भी किया जाता है. यात्रा बुक करने के दौरान, वेबसाइट पर आने वाले लोग अलग-अलग विकल्प चुनने के लिए, इन साइटों पर जाते हैं. वे उम्मीद करते हैं कि इन साइटों पर, उनके चुने गए विकल्पों का "शॉपिंग कार्ट" बना रहेगा. brandx.site, SameSite=None कुकी की मदद से उपयोगकर्ता के सेशन को मैनेज करता है, ताकि उसे दूसरी साइट के कॉन्टेक्स्ट में इस्तेमाल किया जा सके. हालांकि, इसका एक नुकसान यह है कि अब कुकी में किसी दूसरी साइट से किए गए फ़र्ज़ी अनुरोध (सीएसआरएफ़) से सुरक्षा नहीं मिलती. अगर evil.site में brandx.site का अनुरोध शामिल है, तो उसमें वह कुकी शामिल होगी!
कुकी, क्रॉस-साइट है, लेकिन उन सभी साइटों का मालिकाना हक और उन्हें एक ही संगठन मैनेज करता है. वेबसाइट पर आने वाले लोग भी समझते हैं कि यह एक ही संगठन है और उन्हें एक ही सेशन चाहिए. दूसरे शब्दों में, उन्हें एक ही पहचान चाहिए.
पहले पक्ष के सेट की नीति
पहले पक्ष के सेट, एक ही पक्ष के मालिकाना हक वाली और मैनेज की जा रही कई साइटों के बीच के संबंध को साफ़ तौर पर बताने का तरीका बताते हैं. इससे brandx.site को fly-brandx.site,
drive-brandx.site वगैरह के साथ अपने पहले पक्ष (ग्राहक) के संबंध को तय करने में मदद मिलेगी.
Privacy Sandbox के अलग-अलग प्रस्तावों को चलाने वाला निजता मॉडल, क्रॉस-साइट ट्रैकिंग को रोकने के लिए, पहचान को अलग-अलग हिस्सों में बांटने के कॉन्सेप्ट पर आधारित है. यह साइटों के बीच एक सीमा तय करता है, ताकि उपयोगकर्ताओं की पहचान करने के लिए इस्तेमाल की जा सकने वाली किसी भी जानकारी का ऐक्सेस सीमित किया जा सके.
डिफ़ॉल्ट विकल्प के तौर पर, साइट के हिसाब से पार्टिशन किया जाता है. इससे पहले पक्ष के कई इस्तेमाल के उदाहरणों को हल किया जा सकता है. brandx.site उदाहरण से पता चलता है कि पहले पक्ष की साइट, सिर्फ़ एक साइट से बड़ी हो सकती है.
पहले पक्ष के सेट के प्रस्ताव का एक अहम हिस्सा यह पक्का करना है कि सभी ब्राउज़र में नीति, गलत इस्तेमाल को रोकती है. उदाहरण के लिए, पहले पक्ष के सेट, उपयोगकर्ता की जानकारी को अलग-अलग साइटों के बीच शेयर नहीं कर सकते. इसके अलावा, वे ऐसी साइटों को एक साथ ग्रुप नहीं कर सकते जिनका मालिकाना हक एक ही इकाई के पास नहीं है. इसका मकसद यह पक्का करना है कि फ़र्स्ट-पार्टी सेट, किसी ऐसी चीज़ से मैप हो जिसे कोई व्यक्ति फ़र्स्ट-पार्टी के तौर पर समझता हो और उसका इस्तेमाल, अलग-अलग पक्षों के साथ पहचान शेयर करने के तरीके के तौर पर न किया गया हो.
किसी साइट के लिए, पहले पक्ष का सेट रजिस्टर करने का एक संभावित तरीका यह हो सकता है कि साइट, डोमेन के अपने सुझाए गए ग्रुप को किसी सार्वजनिक ट्रैकर (जैसे, GitHub का खास रिपॉज़िटरी) पर सबमिट करे. साथ ही, ब्राउज़र की नीति को पूरा करने के लिए ज़रूरी जानकारी भी सबमिट करे.
नीति के मुताबिक, पहले पक्ष के सेट के दावे की पुष्टि हो जाने के बाद, ब्राउज़र अपडेट की प्रोसेस के ज़रिए सेट की सूचियां फ़ेच कर सकते हैं.
ऑरिजिन ट्रायल के लिए एक नीति तय की गई है, जो फ़ाइनल नहीं है. हालांकि, सिद्धांतों में कोई बदलाव नहीं होगा:
- पहले पक्ष के सेट में मौजूद डोमेन का मालिकाना हक और उन्हें मैनेज करने का अधिकार, एक ही संगठन के पास होना चाहिए.
- उपयोगकर्ताओं को डोमेन, ग्रुप के तौर पर दिखने चाहिए.
- डोमेन के लिए एक ही निजता नीति होनी चाहिए.
फ़र्स्ट-पार्टी सेट तय करने का तरीका
अपने संगठन के फ़र्स्ट पार्टी सेट के सदस्यों और मालिक की पहचान करने के बाद, अनुमति के लिए अपना सुझाया गया सेट सबमिट करना एक अहम चरण होगा. इसकी सटीक प्रोसेस पर अब भी चर्चा की जा रही है.
किसी फ़र्स्ट-पार्टी सेट का एलान करने के लिए, सदस्यों और मालिकों की सूची दिखाने वाले स्टैटिक JSON संसाधनों को, शामिल किए गए हर डोमेन के टॉप लेवल पर /.well-known/first-party-set पर होस्ट किया जाना चाहिए.
brandx फ़र्स्ट पार्टी सेट के उदाहरण में, मालिक-डोमेन https://brandx.site/.well-known/first-party-set पर ये होस्ट करता है:
{
"owner": "brandx.site",
"version": 1,
"members": ["fly-brandx.site", "drive-brandx.site"]
}
सेट के हर सदस्य के पास एक स्टैटिक JSON रिसॉर्स भी होता है, जो सेट के मालिक पर वापस ले जाता है.
https://fly-brandx.site/.well-known/first-party-set में हमारे पास:
{ "owner": "brandx.site" }
और https://drive-brandx.site/.well-known/first-party-set पर:
{ "owner": "brandx.site" }
फ़र्स्ट-पार्टी सेट के लिए कुछ सीमाएं हैं:
- किसी सेट का मालिकाना हक सिर्फ़ एक खाते के पास हो सकता है.
- कोई सदस्य सिर्फ़ एक सेट से जुड़ा हो सकता है. एक सेट में एक से ज़्यादा सदस्यों को शामिल नहीं किया जा सकता.
- सदस्यों की सूची को इस तरह से बनाया जाना चाहिए कि उसे पढ़ने में आसानी हो और वह बहुत बड़ी न हो.
फ़र्स्ट-पार्टी सेट, कुकी पर कैसे असर डालते हैं?
कुकी के लिए मैच करने वाला कॉम्पोनेंट, सुझाया गया SameParty एट्रिब्यूट है. SameParty की वैल्यू सबमिट करने पर, ब्राउज़र को कुकी को शामिल करने के लिए कहा जाता है. ऐसा तब किया जाता है, जब कुकी का कॉन्टेक्स्ट, टॉप-लेवल कॉन्टेक्स्ट के तौर पर सेट किए गए पहले पक्ष के कॉन्टेक्स्ट का हिस्सा हो.
इसका मतलब है कि अगर brandx.site यह कुकी सेट करता है, तो:
Set-Cookie: session=123; Secure; SameSite=Lax; SameParty
इसके बाद, जब वेबसाइट पर आने वाला व्यक्ति fly-brandx.site पर होगा और कोई अनुरोध brandx.site पर जाएगा, तो उस अनुरोध में session कुकी शामिल हो जाएगी.
अगर कोई ऐसी साइट जो पहले पक्ष के सेट का हिस्सा नहीं है, उदाहरण के लिए hotel.xyz, brandx.site को अनुरोध भेजती है, तो कुकी शामिल नहीं की जाएगी.
जब तक SameParty का इस्तेमाल सभी प्लैटफ़ॉर्म पर नहीं किया जा सकता, तब तक कुकी के लिए फ़ॉलबैक व्यवहार तय करने के लिए, SameSite एट्रिब्यूट का इस्तेमाल करें. SameParty एट्रिब्यूट को SameSite=Lax और SameSite=None के बीच की सेटिंग के तौर पर देखा जा सकता है.
SameSite=Lax; SameParty,Laxकी सुविधाओं को बढ़ाएगा, ताकि एक ही पक्ष के कॉन्टेक्स्ट को शामिल किया जा सके. हालांकि, अगर ऐसा नहीं किया जा सकता, तोLaxकी पाबंदियां लागू होंगी.SameSite=None; SameParty,Noneफ़ंक्शन को सिर्फ़ एक ही पक्ष के कॉन्टेक्स्ट तक सीमित कर देगा. ऐसा तब किया जाएगा, जब यह सुविधा काम करती हो. अगर यह सुविधा काम नहीं करती है, तोNoneकी सामान्य अनुमतियों का इस्तेमाल किया जाएगा.
इसके लिए, कुछ और ज़रूरी शर्तें पूरी करनी होंगी:
SamePartyकुकी मेंSecureशामिल होना चाहिए.SamePartyकुकी मेंSameSite=Strictशामिल नहीं होना चाहिए.
Secure एट्रिब्यूट का इस्तेमाल करना ज़रूरी है, क्योंकि यह अब भी क्रॉस-साइट है. इसलिए, आपको सुरक्षित (एचटीटीपीएस) कनेक्शन की पुष्टि करके, इन जोखिमों को कम करना चाहिए. इसी तरह, यह एक क्रॉस-साइट रिलेशनशिप है, इसलिए SameSite=Strict अमान्य है. ऐसा इसलिए है, क्योंकि यह अब भी किसी सेट में साइट पर आधारित सीएसआरएफ सुरक्षा की अनुमति देता है.
फ़र्स्ट-पार्टी सेट के लिए, इस्तेमाल के कौनसे उदाहरण सही हैं?
पहले पक्ष के सेट, उन मामलों के लिए सही होते हैं जब किसी संगठन को अलग-अलग टॉप लेवल साइटों पर, एक जैसी पहचान की ज़रूरत होती है. इस मामले में, शेयर की गई पहचान का मतलब है कि साइटों पर एक ही साइन-ऑन से जुड़ा पूरा समाधान या सिर्फ़ एक ही साइट पर शेयर की गई प्राथमिकता.
आपके संगठन के पास इनके लिए अलग-अलग टॉप लेवल डोमेन हो सकते हैं:
- ऐप्लिकेशन के डोमेन:
office.com,live.com,microsoft.com - ब्रैंड वाले डोमेन:
amazon.com,audible.com/disney.com,pixar.com - स्थानीय भाषा में अनुवाद करने की सुविधा चालू करने के लिए, देश के हिसाब से डोमेन:
google.co.in,google.co.uk - सेवा देने वाले ऐसे डोमेन जिनसे उपयोगकर्ता सीधे तौर पर इंटरैक्ट नहीं करते, लेकिन जो एक ही संगठन की साइटों पर सेवाएं देते हैं:
gstatic.com,githubassets.com,fbcdn.net - ऐसे सैंडबॉक्स डोमेन जिनसे उपयोगकर्ता सीधे तौर पर कभी इंटरैक्ट नहीं करते, लेकिन ये सुरक्षा से जुड़ी वजहों से मौजूद होते हैं:
googleusercontent.com,githubusercontent.com
इसमें शामिल होने का तरीका क्या है?
अगर आपके पास ऊपर दी गई शर्तों से मेल खाने वाली साइटों का कोई सेट है, तो इसमें शामिल होने के कई विकल्प हैं. सबसे कम समय में, इन दो प्रस्तावों को पढ़कर और उन पर होने वाली चर्चा में हिस्सा लेकर, इनमें से किसी एक को चुना जा सकता है:
- पहले पक्ष के सेट की निजता से जुड़ी कम्यूनिटी ग्रुप की चर्चा
- SameParty कुकी एट्रिब्यूट के बारे में चर्चा
टेस्टिंग के दौरान, --use-first-party-set कमांड लाइन फ़्लैग का इस्तेमाल करके, इस सुविधा को आज़माया जा सकता है. इसके लिए, आपको अल्पविराम से अलग की गई साइटों की सूची देनी होगी.
इस सुविधा को आज़माने के लिए, Chrome को इस फ़्लैग के साथ शुरू करें: इसके बाद, https://fps-member1.glitch.me/ पर जाएं:
--use-first-party-set=https://fps-member1.glitch.me,https://fps-member2.glitch.me,https://fps-member3.glitch.me
अगर आपको डेवलपमेंट एनवायरमेंट में टेस्ट करना है या लाइव एनवायरमेंट में SameParty एट्रिब्यूट जोड़कर यह देखना है कि पहले पक्ष के सेट का कुकी पर क्या असर पड़ेगा, तो यह तरीका अपनाएं.
अगर आपके पास एक्सपेरिमेंट और सुझाव/राय देने के लिए समय है, तो ओरिजिन ट्रायल के लिए फ़र्स्ट पार्टी सेट और एक ही पार्टी के लिए साइन अप करें. यह सुविधा, Chrome के 89 से 93 वर्शन में उपलब्ध है.
ऑरिजिन ट्रायल के लिए कुकी अपडेट करने का तरीका
अगर आपने ऑरिजिन ट्रायल में हिस्सा लिया है और अपनी कुकी पर SameParty एट्रिब्यूट की जांच की है, तो यहां दो पैटर्न पर ध्यान दें.
पहला विकल्प
सबसे पहले, अगर आपने SameSite=None के तौर पर लेबल की गई कुकी को पहले पक्ष के कॉन्टेक्स्ट तक सीमित रखना है, तो उनमें SameParty एट्रिब्यूट जोड़ें. जिन ब्राउज़र में ऑरिजिन ट्रायल चालू है उनमें कुकी, सेट के बाहर क्रॉस-साइट कॉन्टेक्स्ट में नहीं भेजी जाएगी.
हालांकि, ऑरिजिन ट्रायल के बाहर के ज़्यादातर ब्राउज़र के लिए, कुकी को पहले की तरह ही क्रॉस-साइट भेजा जाता रहेगा. इसे बेहतर बनाने के लिए, धीरे-धीरे बदलाव करने का तरीका अपनाएं.
इससे पहले:
set-cookie: cname=cval; SameSite=None; Secure
इसके बाद:
set-cookie: cname=cval; SameSite=None; Secure; SameParty
दूसरा विकल्प
दूसरा विकल्प ज़्यादा काम का है. हालांकि, इससे आपको ऑरिजिन ट्रायल को मौजूदा फ़ंक्शन से पूरी तरह अलग करने में मदद मिलती है. साथ ही, SameSite=Lax; SameParty कॉम्बिनेशन की जांच करने में भी मदद मिलती है.
इससे पहले:
set-cookie: cname=cval; SameSite=None; Secure
इसके बाद:
set-cookie: cname=cval; SameSite=None; Secure
set-cookie: cname-fps=cval; SameSite=Lax; Secure; SameParty
इनकमिंग अनुरोधों पर कुकी की जांच करते समय, आपको अलग-अलग साइटों के अनुरोध पर cname-fps कुकी सिर्फ़ तब दिखनी चाहिए, जब उन साइटों को सेट में शामिल किया गया हो और ब्राउज़र, ऑरिजिन ट्रायल में हो. इस तरीके को, पुराने वर्शन को बंद करने से पहले, अपडेट की गई सुविधा के साथ-साथ लॉन्च करने के तौर पर देखें.
आपको पहले पक्ष के सेट की ज़रूरत क्यों नहीं पड़ सकती?
ज़्यादातर साइटों के लिए, उनकी साइट की सीमा को, सेगमेंट या निजता की सीमा तय करने के लिए स्वीकार किया जाता है. CHIPS (कुकी जिनमें अलग-अलग हिस्सों में बांटी गई स्थिति होती है) के साथ यह तरीका अपनाने का सुझाव दिया जा रहा है. इससे साइटों को Partitioned एट्रिब्यूट के ज़रिए ऑप्ट-इन करने का तरीका मिलेगा. इससे साइटों पर, अब भी क्रॉस-साइट एम्बेड, संसाधन, एपीआई, और सेवाएं उपलब्ध होंगी. साथ ही, साइटों पर पहचान से जुड़ी जानकारी लीक होने से भी रोका जा सकेगा.
यहां कुछ और बातों के बारे में बताया गया है. इनके आधार पर, हो सकता है कि आपकी साइट को सेट करने की ज़रूरत न पड़े:
- आपने अलग-अलग साइटों के बजाय, अलग-अलग ऑरिजिन पर होस्ट किया है. ऊपर दिए गए उदाहरण में, अगर
brandx.siteमेंfly.brandx.siteऔरdrive.brandx.siteहै, तो वे एक ही साइट के अलग-अलग सबडोमेन हैं. कुकी मेंSameSite=Laxका इस्तेमाल किया जा सकता है और इसे सेट करने की ज़रूरत नहीं है. - आपने अन्य साइटों को तीसरे पक्ष के एम्बेड की सुविधा दी हो. शुरुआत में,
my-blog.siteपर एम्बेड किए गएvideo.siteके वीडियो का उदाहरण, तीसरे पक्ष के बंटवारे को साफ़ तौर पर दिखाता है. साइटों को अलग-अलग संगठन चलाते हैं और उपयोगकर्ता उन्हें अलग-अलग इकाइयों के तौर पर देखते हैं. ये दोनों साइटें एक सेट में नहीं होनी चाहिए. - आपने तीसरे पक्ष की सोशल साइन-इन सेवाएं उपलब्ध कराई हैं. OAuth या OpenId connect जैसी सेवाओं का इस्तेमाल करने वाले आइडेंटिटी प्रोवाइडर, अक्सर तीसरे पक्ष की कुकी का इस्तेमाल करते हैं. इससे, उपयोगकर्ताओं को साइन इन करने में आसानी होती है. यह इस्तेमाल का एक मान्य उदाहरण है, लेकिन यह फ़र्स्ट-पार्टी सेट के लिए सही नहीं है, क्योंकि संगठनों में साफ़ तौर पर अंतर है. WebID जैसे शुरुआती प्रस्तावों में, इन इस्तेमाल के उदाहरणों को चालू करने के तरीकों को एक्सप्लोर किया जा रहा है.