कई संगठनों के पास अलग-अलग डोमेन नाम वाली मिलती-जुलती साइटें हैं, जैसे कि
brandx.site और fly-brandx.site—या अलग-अलग देशों के लिए डोमेन, जैसे कि
example.com, example.rs, example.co.uk वगैरह.
ब्राउज़र, तीसरे पक्ष की कुकी बनाने जा रहे हैं पुराना लेकिन इस तरह की साइटें अक्सर कुकी पर निर्भर रहती हैं. ऐसी सुविधाएं जिनके लिए डोमेन के बीच स्थिति को बनाए रखना और ऐक्सेस करना ज़रूरी होता है (जैसे, सिंगल साइन-ऑन और सहमति मैनेजमेंट की सुविधा).
पहले पक्ष के सेट, मिलते-जुलते ऐसे डोमेन नेम को अनुमति दे सकते हैं जिनका मालिकाना हक और उन्हें चलाने का अधिकार एक ही इकाई को पहले पक्ष के तौर पर माना जाएगा. ऐसा तब होगा, जब पहला पक्ष और हालांकि, तीसरे पक्ष के साथ थोड़ा अलग व्यवहार किया जाता है. इसमें डोमेन नेम पहले-पक्ष के सेट को एक ही पक्ष माना जाता है. वे लेबल कर सकते हैं कि कौनसी कुकी जो समान-पक्ष के संदर्भ में सेट करने या भेजने के लिए हो. इसका मकसद है कि वह इसमें तीसरे पक्षों को क्रॉस-साइट ट्रैकिंग से बचाने के बीच संतुलन बना रहता है. ऐसा पाथ बनाए रखना जो इस्तेमाल के मान्य उदाहरणों का उल्लंघन न करता हो.
पहले पक्ष के सेट के प्रस्ताव की जांच टेस्ट में है चरण, आगे पढ़ें और जानें कि यह कैसे काम करता है इसे आज़माने का तरीक़ा भी बताया गया है.
पहले और तीसरे पक्ष की कुकी में क्या अंतर है?
कुकी मूल रूप से प्रथम-पक्ष या तृतीय-पक्ष नहीं हैं, यह वर्तमान
जहां कुकी को शामिल किया जाता है. यह या तो
JavaScript में cookie हेडर या document.cookie के ज़रिए.
उदाहरण के लिए, ब्राउज़ करते समय video.site में theme=dark कुकी होती है
video.site और video.site को एक अनुरोध किया गया है. यह एक ही साइट है
कॉन्टेक्स्ट और
शामिल की गई कुकी पहले पक्ष की है.
हालांकि, अगर आप my-blog.site पर हैं और
video.site, जब 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 अमान्य है, क्योंकि यह अब भी इसकी अनुमति देता है
एक सेट में मज़बूत साइट आधारित सीएसआरएफ़ सुरक्षा.
पहले पक्ष के सेट के लिए, इस्तेमाल के कौनसे उदाहरण सही हैं?
पहले पक्ष के सेट उन मामलों में बेहतर होते हैं जहां किसी संगठन को अलग-अलग टॉप लेवल साइटों पर एक जैसी पहचान को शेयर किया जा सकता है. इस मामले में एक जैसी पहचान इसका मतलब है, सिंगल साइन-ऑन सलूशन से लेकर, प्राथमिकताएँ चुनी जा सकती हैं.
आपके संगठन के पास इनके लिए अलग-अलग टॉप लेवल डोमेन हो सकते हैं:
- ऐप्लिकेशन डोमेन:
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 कमांड लाइन फ़्लैग और कॉमा लगाकर अलग की गई सूची दे रहा है
रहा है.
इसे डेमो साइट पर आज़माएँ शुरू होने के बाद https://fps-member1.glitch.me/ निम्न फ़्लैग के साथ Chrome:
--use-first-party-set=https://fps-member1.glitch.me,https://fps-member2.glitch.me,https://fps-member3.glitch.me
यह तब काम आता है, जब आपको अपने डेवलपमेंट एनवायरमेंट में टेस्ट करना हो या
लाइव एनवायरमेंट में SameParty एट्रिब्यूट जोड़कर देखें कि
पहले-पक्ष का सेट, कुकी पर असर डालेगा.
अगर आपके पास एक्सपेरिमेंट करने और सुझाव/राय देने या शिकायत करने के लिए बैंडविथ है, तो साइन अप भी किया जा सकता है पहले पक्ष के सेट के लिए ऑरिजिन ट्रायल के लिए और 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 जैसे शुरुआती सुझाव उन तरीकों को एक्सप्लोर किया जा रहा है जिनका इस्तेमाल इन मामलों में किया जा सकता है.