Chrome में तीसरे पक्ष की कुकी बंद होने के बाद, पहले पक्ष के सेट (एफ़पीएस) को उपयोगकर्ताओं के वेब ब्राउज़िंग अनुभव को बेहतर बनाने के लिए डिज़ाइन किया गया है. एफ़पीएस इनक्यूबेशन के दौरान, ओपन-वेब फ़ोरम में यह प्रस्ताव काफ़ी बेहतर हो गया है. पहले W3C के प्राइवसी कम्यूनिटी ग्रुप में और अब वेब इनक्यूबेटर कम्यूनिटी ग्रुप में.
इस ब्लॉग पोस्ट में, हम डेवलपमेंट की प्रोसेस के बारे में फिर से जानेंगे. साथ ही, हम अहम बदलावों को हाइलाइट करेंगे. साथ ही, इस बात पर चर्चा करेंगे कि इन बदलावों से, नेटवर्क की मदद करते हुए, वेब पर निजता को बेहतर क्यों बनाया जाता है.
बैकग्राउंड
साइटें, अक्सर तीसरे पक्ष की अपनी कुकी के ऐक्सेस पर निर्भर रहती हैं. इससे उन्हें लोगों को आसान और उनके हिसाब से अनुभव देने में मदद मिलती है. निजता सुरक्षा वाले विज्ञापन एपीआई (Topics, Protected Audience API, और Attribution) के अलावा, Chrome की टीम ने लोगों को दिलचस्पी के मुताबिक विज्ञापन दिखाने या विज्ञापन की परफ़ॉर्मेंस को मेज़र करने के अलावा, उन स्थितियों के दायरे को समझने की कोशिश की है जिनमें तीसरे पक्ष की कुकी का इस्तेमाल किया गया था.
हमने पाया है कि संगठन तीसरे पक्ष की कुकी का इस्तेमाल कर सकते हैं, क्योंकि उनके वेब आर्किटेक्चर को कई डोमेन का इस्तेमाल करने के लिए डिज़ाइन किया गया है. उदाहरण के लिए, हो सकता है कि किसी संगठन का एक डोमेन अपने हाइकिंग ब्लॉग के लिए और दूसरा डोमेन अपने कैंपिंग स्टोर के लिए हो. साथ ही, वह उन साइटों पर उपयोगकर्ता के अनुभव को बेहतर बनाना चाहता हो. कोई संगठन अपनी वेब सेवा के शेयर किए गए इंफ़्रास्ट्रक्चर की मदद से, कई देशों के कोड वाले डोमेन भी मैनेज कर सकता है. इस तरह के मामलों के लिए, हमने एक ऐसा समाधान तैयार किया जो इन संगठनों की ज़रूरतों को पूरा करता हो. साथ ही, वेब पर निजता की सुरक्षा को लेकर, उपयोगकर्ताओं की उम्मीदों को भी बनाए रखा गया हो.
हमने शुरुआत कहां से की थी
फ़िलहाल, ब्राउज़र "पहले पक्ष" बनाम "तीसरे पक्ष" को समझने के लिए, साइट-लेवल की सीमा का इस्तेमाल करता है. इसलिए, संगठन जिन डोमेन को मैनेज कर सकता है उनकी रेंज को ध्यान में रखते हुए, इस तकनीकी सीमा को ज़्यादा सटीक परिभाषा से बदलना सही लग रहा है.
2021 में, Chrome ने शुरुआत में पहले पक्ष के सेट के लिए SameParty कुकी एट्रिब्यूट का सुझाव दिया. ऐसा इसलिए किया गया, ताकि साइटें "एक ही पक्ष" की साइटों से जनरेट होने वाली कुकी के बारे में बता सकें. "एक ही पक्ष" का क्या मतलब है, यह बताने के लिए हमने एक
उपयोगकर्ता-एजेंट नीति
का इस्तेमाल किया है. इस नीति की परिभाषा में, "पक्ष" के मौजूदा फ़्रेमवर्क (उदाहरण के लिए, W3C DNT की जानकारी से) को बनाने की कोशिश की गई. साथ ही, निजता से जुड़े मुद्दों पर आधारित सुझाव शामिल किए गए. जैसे, "तेज़ी से होने वाले बदलाव के दौर में उपभोक्ता की निजता की सुरक्षा करना" टाइटल वाली, 2012 की फ़ेडरल ट्रेड कमीशन की रिपोर्ट.
उस समय, हमें लगा कि इस तरीके ने अलग-अलग तरह के संगठनों को इंडस्ट्री में काम करने की सहूलियत दी है. साथ ही, यह तीसरे पक्ष की कुकी के ज़रिए बड़े पैमाने पर ट्रैकिंग को कम करने के हमारे बुनियादी लक्ष्य का भी पालन कर रहा था.
शुरुआती प्रस्ताव पर फ़ीडबैक
वेब नेटवर्क में हिस्सेदारों के साथ हुई कई बातचीत से हमें पता चला कि इस शुरुआती डिज़ाइन में कुछ समस्याएं हैं.
SameParty एट्रिब्यूट के ज़रिए पैसिव कुकी के ऐक्सेस की मदद से, निजता से जुड़ी चुनौतियां
अन्य ब्राउज़र वेंडर को प्राथमिकता देते हैं तीसरे पक्ष की कुकी ऐक्सेस करने के एक सक्रिय तरीके को एक ऐसी सीमा तय करने के बजाय जिसमें पैसिव कुकी का ऐक्सेस बनाए रखा जा सके. कुकी के ऐक्सेस के लिए सक्रिय अनुरोधों से, ब्राउज़र को अनुमति देने और उसे कंट्रोल करने में मदद मिलती है. इससे तीसरे पक्ष की कुकी के ज़रिए, छिपी हुई ट्रैकिंग के जोखिम को कम किया जा सकता है. इसके अलावा, इस तरह की कुकी के ऐक्सेस की अनुमति से ब्राउज़र, उपयोगकर्ताओं को कुकी के ऐक्सेस को अनुमति देने या ब्लॉक करने का विकल्प दे पाएंगे.
सभी ब्राउज़र में वेब इंटरऑपरेबिलिटी (दूसरे सिस्टम के साथ काम करना) और निजता से जुड़े फ़ायदों में सुधार करने के लिए, हमने इस दिशा में काम करने का फ़ैसला किया.
प्रस्तावित नीति को लागू करने में आने वाली चुनौतियां
मूल नीति में डोमेन के लिए तीन शर्तें सुझाई गई थीं, जिन्हें एक ही सेट में रखना होगा: "सामान्य मालिकाना हक", "सामान्य निजता नीति", और "सामान्य ग्रुप आइडेंटिटी".
बड़े नेटवर्क से, हमें चार मुख्य थीम पर नीति के बारे में मिले सुझाव मिले.
सामान्य मालिकाना हक बहुत सीमित है
"सामान्य मालिकाना हक" की ज़रूरत के मामले में, हमें सुझाव मिला कि सिर्फ़ कॉर्पोरेट मालिकाना हक पर फ़ोकस करने वाले एफ़पीएस का मतलब है कि छोटी कंपनियों की तुलना में, बड़ी कंपनियों को अलग-अलग डोमेन और उपयोगकर्ता को मिलने वाली सेवाओं में डेटा पूल करने की सुविधा मिलेगी. हमारा लक्ष्य पूरे नेटवर्क के लिए प्राइवसी सैंडबॉक्स बनाना है. इसलिए, हमने इस सुझाव पर गंभीरता से गौर किया और ऐसी समाधान को प्राथमिकता दी जिसमें ज़्यादा से ज़्यादा लोग शामिल हो सकें.
एक ही नीति लागू होने पर, अलग-अलग मामलों के इस्तेमाल की अनुमति को सीमित किया जा सकता है
सीमा को कंट्रोल करने के लिए, एक बेहतर नीति बनाने का मकसद था, अलग-अलग तरह के ऐसे डोमेन के लिए सुविधाजनक सुविधा उपलब्ध कराना जिन्हें किसी संगठन के एफ़पीएस में होना चाहिए. हालांकि, हमने पाया कि इस्तेमाल के कुछ बेहद अहम मामले इस नीति के डिज़ाइन को पूरा नहीं कर सके. उदाहरण के लिए, सेवा डोमेन (जैसे, जो उपयोगकर्ता का जनरेट किया गया कॉन्टेंट होस्ट करते हैं) को उपयोगकर्ताओं की पुष्टि करने या उनकी पहचान करने के लिए, तीसरे पक्ष की कुकी के ऐक्सेस की ज़रूरत पड़ सकती है. ऐसे डोमेन में शायद ही कभी कोई ऐसा होम पेज होता है जिसे उपयोगकर्ता ऐक्सेस कर सकता हो. इसलिए, एक ही FPS (फ़्रेम प्रति सेकंड) में मौजूद अन्य डोमेन के साथ, "सामान्य ग्रुप आइडेंटिटी" या "सामान्य निजता नीति" की ज़रूरी शर्तों को पूरा नहीं किया जा सकता.
ग्रुप की पहचान के बारे में उपयोगकर्ताओं की राय और समझ अलग हो सकती है
हमने मूल रूप से कुछ नियमों का प्रस्ताव दिया था. इनकी मदद से, एक सेट में डोमेन के दायरे में आने वाले डोमेन को "सामान्य ग्रुप की पहचान" के तौर पर परिभाषित किया जा सकता है. ये नियम उन डोमेन के दायरे में आते हैं जिन्हें किसी सामान्य ग्रुप की पहचान के साथ आसानी से जोड़ा जा सके. हालांकि, यह मापने और आकलन करने के लिए, हम ऐसा तकनीकी तरीका तय नहीं कर पाए जिसे "उपयोगकर्ता आसानी से खोज सकते" हैं. इससे बुरा बर्ताव हो सकता था और नीति उल्लंघन ठीक करने के तरीके के बारे में सवाल पूछने लगे थे.
हमें सुझाव भी मिला
सब्जेक्टिव नीति को बड़े पैमाने पर लागू करना मुश्किल है
हमें ज़्यादा जानकारी वाले दिशा-निर्देशों के लिए कई अनुरोध मिले. ये अनुरोध, कुछ खास शर्तों (जैसे कि "सामान्य ग्रुप की पहचान") में शामिल हैं. साथ ही, इसमें दूसरों के लिए ("सामान्य निजता नीति" के बारे में) अपवादों या गंभीर मामलों को शामिल करने की शर्त को भी ध्यान में रखा गया है.
यह पक्का करने के लिए कि इस नीति को समान तरीके से और लगातार लागू किया जाए, Chrome को साइट के लेखकों को ज़्यादा खास दिशा-निर्देश देने होते थे. हमने यह तय किया कि सख्त दिशा-निर्देशों को बनाने से, नेटवर्क को नुकसान हो सकता है.
हालांकि, हमने शुरुआत में यह प्रस्ताव दिया था कि नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) वाली एक स्वतंत्र इकाई, जांच करने और नीति के पालन को लागू करने की ज़िम्मेदारी लेती है, लेकिन मौजूदा नेटवर्क में, नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) वाली एक स्वतंत्र इकाई ढूंढना, जिसके पास निष्पक्ष तरीके से ये ज़िम्मेदारियां निभानी हों. इसके बजाय, हमने एक ऐसी नीति बनाने की कोशिश की जिसे तकनीकी तौर पर लागू किया जा सके. इससे यह पक्का किया जा सकेगा कि लागू करने की प्रोसेस सही तरीके से और सही तरीके से लागू की जा सके.
विकास
आपके सुझाव, शिकायत या राय के जवाब में, हमने एफ़पीएस को दोबारा डिज़ाइन किया है. हमने उन समस्याओं को देखा जिनका हम समाधान करने की कोशिश कर रहे थे. साथ ही, हमने इस प्रस्ताव को सीधे तौर पर उन खास मामलों के लिए तैयार करने का फ़ैसला किया जिन्हें हम हल कर रहे थे.
मुख्य इस्तेमाल के उदाहरणों के लिए समाधान पाना
Chrome ने वेब पर खास इस्तेमाल के उदाहरणों को पूरा करने के लिए, तीन अलग-अलग मकसद से बनाए गए "सबसेट" डेवलप किए हैं. सबसेट के तरीके में सुधार हुआ है. पुराने तरीके को ज़्यादा निजी, सटीक, और लागू करने में ज़्यादा आसान बनाया गया है.
- "ccTLD" (देश के कोड के हिसाब से टॉप लेवल डोमेन) — संगठन, अलग-अलग ccTLD वाली साइटों का स्थानीय भाषा में इस्तेमाल कर सकते हैं. साथ ही, इन साइटों को शेयर की गई सेवाओं और इन्फ़्रास्ट्रक्चर का ऐक्सेस चाहिए.
- "सेवा" डोमेन — सुरक्षा या परफ़ॉर्मेंस के मकसद से, साइटें अलग-अलग डोमेन का इस्तेमाल कर सकती हैं. साथ ही, इन साइटों को अपने काम करने के लिए, उपयोगकर्ता की पहचान के ऐक्सेस की ज़रूरत हो सकती है.
- "असोसिएट किए गए" डोमेन — संगठन अलग-अलग, मिलते-जुलते ब्रैंड या प्रॉडक्ट के लिए कई साइटें मैनेज कर सकते हैं. ऐसा हो सकता है कि वे मिलती-जुलती साइटों पर उपयोगकर्ता के सफ़र के आंकड़े जैसे इस्तेमाल के मामलों के लिए क्रॉस-साइट कुकी का ऐक्सेस चाहें. इससे उन्हें यह समझने में मदद मिलेगी कि संगठन का उपयोगकर्ता आधार उनकी साइटों से कैसे इंटरैक्ट करता है. इसके अलावा, वह उसी लॉगिन इन्फ़्रास्ट्रक्चर पर निर्भर मिलती-जुलती साइट पर, किसी उपयोगकर्ता के लॉग इन किए हुए होने की स्थिति को याद रखने के लिए भी ऐसा कर सकता है.
इस्तेमाल के हर उदाहरण के लिए, नीति से जुड़ी अलग-अलग ज़रूरी शर्तें, तकनीकी पुष्टि जांचों से जुड़ी शर्तें, और ब्राउज़र को इस्तेमाल करने का खास तरीका होता है (ज़्यादा जानकारी के लिए सबमिट करने के दिशा-निर्देश देखें). ये बदलाव मूल प्रस्ताव में बताई गई कमियों को दूर करते हैं. इनमें "सभी के लिए एक ही साइज़" वाले डिज़ाइन को शामिल नहीं किया गया है और अलग-अलग सेक्शन में रखा गया है और केस-आधारित फ़्रेमवर्क का इस्तेमाल किया गया है.
तीसरे पक्ष की कुकी ऐक्सेस के चालू अनुरोधों के ज़रिए, इंटरऑपरेबिलिटी (दूसरे सिस्टम के साथ काम करना) की सुविधा
वेब प्लैटफ़ॉर्म को बेहतर बनाए रखने के लिए, Chrome दूसरे ब्राउज़र के साथ इंटरऑपरेबिलिटी को बढ़ावा देना चाहता है. Safari, Firefox, और Edge जैसे दूसरे ब्राउज़र फ़िलहाल कुकी के सक्रिय अनुरोधों को आसान बनाने के लिए, Storage Access API (SAA) का इस्तेमाल करते हैं. इसलिए, हमने Chrome में SAA का इस्तेमाल करने का विकल्प चुना, ताकि हमें मिलने वाले मुख्य सुझावों के साथ-साथ वेब इंटरऑपरेबिलिटी (दूसरे सिस्टम के साथ काम करने की क्षमता) को भी बेहतर बनाया जा सके.
डेवलपर को ज़्यादा सुविधा देने और SAA की पहले से मालूम सीमाओं को ठीक करने के लिए, हमने requestStorageAccessForOrigin एपीआई का भी प्रस्ताव दिया है.
Storage Access API और FPS (फ़्रेम प्रति सेकंड) को एक साथ इस्तेमाल करने की सुविधा
Storage Access API (SAA) लागू करते समय, ब्राउज़र सीधे उपयोगकर्ताओं से अनुमति मांग सकते हैं. साथ ही, अन्य ब्राउज़र अनुमति के अनुरोध के बिना कुछ ही अनुरोधों को अनुमति दे सकते हैं.
Chrome का मानना है कि FPS (फ़्रेम प्रति सेकंड) की मदद से, SAA के मुकाबले पारदर्शी लेयर मिल सकती है. इसके लिए, उपयोगकर्ताओं को ऐप्लिकेशन इस्तेमाल करने में आने वाली समस्याओं को कम किया जाता है. साथ ही, सीमित इस्तेमाल के मामलों में, उपयोगकर्ता को तुरंत काम करने में परेशानी नहीं होती है. एफ़पीएस (फ़्रेम प्रति सेकंड) से, ब्राउज़र को यह तय करने में मदद मिलती है कि उपयोगकर्ताओं को सेट की गई सदस्यता के बारे में ज़्यादा जानकारी देनी चाहिए.
FPS (फ़्रेम प्रति सेकंड) की मदद से, डेवलपर को अपनी उन साइटों का पता लगाने का मौका मिलता है जिन पर इस समस्या का असर हुआ है. इसकी मदद से, डेवलपर यह अनुमान लगा सकते हैं कि उनकी साइटें उपयोगकर्ताओं के लिए कैसे काम करेंगी. साथ ही, वे एफ़पीएस या तीसरे पक्ष की कुकी के विकल्प का इस्तेमाल करके, उपयोगकर्ता अनुभव पर पड़ने वाले असर को सीमित करने के लिए कदम उठा सकते हैं. इसके अलावा, FPS के तहत, डेवलपर प्लैटफ़ॉर्म का अनुमान लगाने की सुविधा मिलती है. वहीं, समय के साथ यह बदलाव हो सकता है और अलग-अलग उपयोगकर्ताओं के व्यवहार भी अलग-अलग हो सकते हैं.
इसके अलावा, जो डेवलपर Chrome में FPS के लिए काम करने के लिए SAA को लागू करते हैं वे भी दूसरे ब्राउज़र पर अपनी साइट की परफ़ॉर्मेंस के लिए SAA का इस्तेमाल कर सकते हैं. वे ब्राउज़र भी अपनी साइटों की परफ़ॉर्मेंस बेहतर बनाते हैं जो एफ़पीएस को शिप नहीं करते.
बातचीत जारी रखने वाली प्रक्रिया
हमारा मानना है कि हमारा नया प्रस्ताव, उपयोगकर्ताओं और डेवलपर की ज़रूरतों को ध्यान में रखते हुए, कारोबार के ऐसे चुनौती भरे माहौल में सही संतुलन बनाने में कामयाब होता है. हम वेब नेटवर्क के हिस्सेदारों से मिले सुझावों की सराहना करते हैं. इनसे हमें एफ़पीएस प्रस्ताव को बेहतर बनाने में मदद मिली.
हम मानते हैं कि वेब नेटवर्क के हिस्सेदार, अभी भी अपडेट किए गए प्रस्ताव के बारे में जान रहे हैं. कृपया हमसे जुड़ें, ताकि हम डिज़ाइन को इस तरह से बेहतर बना सकें जो डेवलपर के लिए ज़्यादा काम का हो और वेब पर निजता को बेहतर बनाने के लिए लगातार काम कर सके. Google यह पक्का करने के लिए यूके की कॉम्पिटिशन ऐंड मार्केट्स अथॉरिटी (सीएमए) के साथ भी काम करता रहेगा कि वादों का पालन हो रहा हो.
जुड़ने के लिए, यहां दिए गए संसाधनों को देखें:
- डब्ल्यूआईसीजी में इन्क्यूबेशन
- एफ़पीएस जांच के निर्देश
- पहले पक्ष के सेट: इंटिग्रेशन गाइड
- एफ़पीएस सबमिट करने के दिशा-निर्देश
नेटवर्क के साथ काम करना
Salesforce और CafeMedia जैसी कंपनियों को अहम फ़ीडबैक और पहले पक्ष के सेट के डेवलपमेंट में दिलचस्पी लेते हुए देखना बहुत अच्छा लगता है. इस टेक्नोलॉजी को बेहतर बनाने में इन दोनों ने अहम भूमिका निभाई है. कई अन्य लोगों ने भी वेब नेटवर्क के साथ काम करने के लिए, पहले पक्ष के सेट और Chrome की कोशिशों के बारे में अपने विचार शेयर किए:
"Chrome, पहले-पक्ष के ऐसे सेट डेवलप कर रहा है जो हमारे इस्तेमाल के कई उदाहरणों के मुताबिक हों. जैसे, उपयोगकर्ताओं के अनुभव को सुरक्षित रखना. इससे पता चलता है कि Google की टीम, वेब पर साइट मालिकों की अलग-अलग तरह की ज़रूरतों को समझने के लिए काम कर रही है." - मेरकादो लिब्रे
"VWO में, हम निजता के मानकों को बेहतर बनाने की Google की कोशिशों की सराहना करते हैं. साथ ही, यह पक्का करते हैं कि असली इस्तेमाल के मामलों को हैंडल किया जाए. यह अच्छी बात है कि टीम, डेवलपर नेटवर्क के साथ मिलकर काम कर रही है. साथ ही, पहले पक्ष के सेट के प्रस्ताव को लागू करने के तरीके को लगातार बेहतर बना रही है. ऐसा वेब के हिस्सेदारों से मिले सुझावों के आधार पर किया जा रहा है. हमें इस बात की खुशी है कि हम इस प्रस्ताव की टेस्टिंग का हिस्सा बने. हम उम्मीद करते हैं कि इस प्रस्ताव को ब्राउज़र में शामिल किया जाएगा." - नीतीश मित्तल, डायरेक्टर ऑफ़ इंजीनियरिंग, VWO