कई संगठनों के पास अलग-अलग डोमेन नेम वाली मिलती-जुलती साइटें हैं, जैसे कि brandx.site और fly-brandx.site या फिर अलग-अलग देशों के डोमेन, जैसे कि example.com, example.rs, example.co.uk वगैरह.
वेब पर निजता को बेहतर बनाने के लिए, ब्राउज़र तीसरे पक्ष की कुकी को पुराना बनाने की दिशा में काम कर रहे हैं. हालांकि, ऐसी साइटें अक्सर उन फ़ंक्शन के लिए कुकी पर निर्भर रहती हैं जिन्हें सभी डोमेन (जैसे कि सिंगल साइन-ऑन और सहमति मैनेजमेंट) को बनाए रखने और ऐक्सेस करने की ज़रूरत होती है.
पहले पक्ष के सेट, एक ही इकाई के मालिकाना हक और उसे चलाने वाले मिलते-जुलते डोमेन नेम को उन स्थितियों में पहले पक्ष के तौर पर माने जा सकते हैं जहां पहले पक्ष और तीसरे पक्ष को अलग-अलग माना जाता है. पहले पक्ष के सेट में मौजूद डोमेन नेम एक ही पक्ष के माने जाते हैं. साथ ही, इनसे यह लेबल किया जा सकता है कि किन कुकी को सेट करना है या कुछ कुकी को एक ही पक्ष के लिए भेजा गया है. इसका मकसद, तीसरे पक्ष की मदद से क्रॉस-साइट ट्रैकिंग को रोकने के बीच संतुलन बनाना है. साथ ही, ऐसे पाथ का इस्तेमाल करना है जो इस्तेमाल के मान्य उदाहरणों को तोड़ता न हो.
पहले पक्ष के सेट का प्रस्ताव अभी टेस्टिंग फ़ेज़ में है. यह कैसे काम करता है और इसे कैसे आज़माया जा सकता है, यह जानने के लिए आगे पढ़ें.
पहले-पक्ष और तीसरे-पक्ष की कुकी में क्या अंतर है?
कुकी, मूल रूप से पहले पक्ष या तीसरे पक्ष की नहीं होती हैं. यह उस मौजूदा कॉन्टेक्स्ट पर निर्भर करती है जिसमें कुकी को शामिल किया गया है. वह या तो cookie हेडर में मौजूद अनुरोध पर या JavaScript में document.cookie के ज़रिए मिला है.
उदाहरण के लिए, अगर video.site को ब्राउज़ किया जा रहा है और video.site को ब्राउज़ करने पर video.site के पास theme=dark कुकी है, तो यह एक ही साइट के कॉन्टेक्स्ट से जुड़ी होगी और इसमें शामिल की गई कुकी पहले पक्ष की होगी.
हालांकि, अगर आपने my-blog.site पर video.site के लिए iframe प्लेयर एम्बेड किया है, तो my-blog.site से video.site पर अनुरोध किए जाने पर, यह अलग-अलग साइट के लिए है और theme कुकी तीसरे पक्ष की है.
कुकी शामिल करने की सेटिंग, कुकी के SameSite एट्रिब्यूट की मदद से तय की जाती है:
- एक ही साइट के कॉन्टेक्स्ट के लिए,
SameSite=Lax,StrictयाNoneका इस्तेमाल किया जाता है. यह कुकी को पहले पक्ष के तौर पर सेट करता है. 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 वगैरह के साथ अपने पहले पक्ष का संबंध तय कर पाएगा.
प्राइवसी सैंडबॉक्स के अलग-अलग प्रपोज़ल को लाने वाला प्राइवसी मॉडल, क्रॉस-साइट ट्रैकिंग को रोकने के लिए, पहचान को बांटने के कॉन्सेप्ट पर आधारित है. इससे, साइटों के बीच एक सीमा बनती है. इससे ऐसी किसी भी जानकारी का ऐक्सेस सीमित हो जाता है जिसका इस्तेमाल उपयोगकर्ताओं की पहचान करने के लिए किया जा सकता है.
डिफ़ॉल्ट विकल्प के तौर पर, साइट के हिसाब से डेटा को बांटा जा सकता है. इससे पहले पक्ष के इस्तेमाल के कई उदाहरण हल किए जा सकते हैं. वहीं, 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 अमान्य है. इसकी वजह यह है कि यह अब भी किसी सेट के अंदर, साइट-आधारित CSRF सुरक्षा की अनुमति देता है.
पहले पक्ष के सेट के लिए, इस्तेमाल के कौनसे उदाहरण सही हैं?
पहले पक्ष के सेट उन मामलों में अच्छे हैं जब किसी संगठन को अलग-अलग टॉप लेवल साइटों पर शेयर की गई पहचान की ज़रूरत होती है. इस मामले में, शेयर की गई पहचान का मतलब है कि सिंगल साइन-ऑन की सुविधा से लेकर अलग-अलग साइटों पर शेयर की गई प्राथमिकता की ज़रूरत हो.
आपके संगठन में इन चीज़ों के लिए अलग-अलग टॉप लेवल डोमेन हो सकते हैं:
- ऐप्लिकेशन डोमेन:
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
आप कैसे शामिल हो सकते हैं?
अगर आपके पास ऊपर बताई गई शर्तों से मेल खाने वाली साइटों का एक सेट है, तो शामिल होने के कई विकल्प मौजूद हैं. सबसे आसान निवेश दोनों प्रस्तावों पर होने वाली चर्चा को पढ़ना और उसमें शामिल होना है:
- निजता से जुड़े कम्यूनिटी ग्रुप में, पहले पक्ष के ग्रुप की चर्चा
- सेम पार्टी कुकी एट्रिब्यूट के बारे में चर्चा
टेस्टिंग के दौरान, --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 कुकी सिर्फ़ तब दिखेगी, जब उसमें शामिल साइटें, सेट में हों और ब्राउज़र ऑरिजिन ट्रायल में हो. पिछले वर्शन को बंद करने से पहले, इस तरीके को अपडेट की गई किसी सुविधा को एक साथ लॉन्च करने के बारे में सोचें.
आपको पहले-पक्ष का सेट क्यों नहीं चाहिए?
ज़्यादातर साइटों के लिए, उनकी साइट की सीमा, सेगमेंट या निजता की सीमा बनाने के लिए सही जगह होती है. इस रूट के बारे में सीएचआईपीएस (कुकीिंग इंडिपेंडेंट पार्टिशन्ड स्टेट) के साथ सुझाव दिया जा रहा है. इससे साइटों को Partitioned एट्रिब्यूट के ज़रिए ऑप्ट-इन करने का विकल्प मिलेगा. इससे साइटों को ज़रूरी क्रॉस-साइट एम्बेड, संसाधन, एपीआई, और सेवाएं मिलती रहेंगी. साथ ही, अलग-अलग साइटों पर पहचान ज़ाहिर करने वाली जानकारी को लीक होने से रोका जा सकेगा.
यहां कुछ और बातें बताई गई हैं, जिनका मतलब है कि आपकी साइट बिना सेट के भी ठीक से काम कर सकती है:
- आप अलग-अलग ऑरिजिन पर होस्ट करते हैं, अलग-अलग साइटों पर. ऊपर दिए गए उदाहरण में, अगर
brandx.siteमेंfly.brandx.siteऔरdrive.brandx.siteथे, तो वे सभी एक ही साइट के अलग-अलग सबडोमेन हैं. कुकीSameSite=Laxका इस्तेमाल कर सकती हैं और इसके लिए किसी सेट की ज़रूरत नहीं है. - आपने तीसरे पक्ष के वीडियो को दूसरी साइटों पर एम्बेड किया है. वीडियो की शुरुआत में,
my-blog.siteपर एम्बेड किए गएvideo.siteके वीडियो का उदाहरण साफ़ तौर पर दिख रहा है. इन साइटों को अलग-अलग संगठन ऑपरेट करते हैं और उपयोगकर्ता उन्हें अलग-अलग इकाइयों के तौर पर देखते हैं. ये दोनों साइटें एक साथ एक सेट में नहीं होनी चाहिए. - आपने तीसरे पक्ष की सोशल साइन-इन सेवाएं दी हैं. OAuth या OpenId Connect जैसी चीज़ों का इस्तेमाल करने वाली आइडेंटिटी प्रोवाइडर की साइट पर, तीसरे पक्ष की कुकी का इस्तेमाल किया जाता है. इससे उपयोगकर्ताओं को साइन-इन करने का बेहतर अनुभव मिलता है. यह इस्तेमाल का मान्य उदाहरण है, लेकिन यह पहले पक्ष के सेट के लिए सही नहीं है, क्योंकि संगठनों में एक-दूसरे से काफ़ी अंतर है. WebID जैसे शुरुआती सुझाव, ऐसे तरीकों की जांच कर रहे हैं जिनसे यह तय किया जा सके कि इनका इस्तेमाल कैसे किया जा सकता है.