हम जानेंगे कि सीएचआईपीएस को लागू करने में Chrome टीम को दो चुनौतियों का सामना करना पड़ा. साथ ही, यह भी जाना कि किस तरह लोगों के सुझावों ने प्रस्ताव को डिज़ाइन करने में अहम भूमिका निभाई.
कुकी हैविंग इंडिपेंडेंट पार्टिशन्ड स्टेट (सीएचआईपीएस), प्राइवसी सैंडबॉक्स टेक्नोलॉजी है. इसकी मदद से डेवलपर, हर टॉप लेवल साइट के लिए अलग-अलग कुकी जार के साथ, "पार्टिशन्ड" स्टोरेज के लिए कुकी चुन सकते हैं.
सीएचआईपीएस के इस्तेमाल के उदाहरणों में, ऐसी स्थितियों को शामिल किया जाता है जहां क्रॉस-साइट सबरिसॉर्स को सेशन या परसिस्टेंट स्टेटस के बारे में कुछ जानकारी की ज़रूरत होती है. ये सेशन या स्थायी स्थिति, किसी टॉप लेवल साइट पर उपयोगकर्ता की गतिविधि तक सीमित होती हैं. जैसे, तीसरे पक्ष के चैट विजेट, मैप एम्बेड, सबरिसॉर्स सीडीएन लोड बैलेंसिंग, बिना ग्राफ़िक यूज़र इंटरफ़ेस वाले सीएमएस वगैरह.
CHIPS को ओपन वेब स्टैंडर्ड बनाने के मकसद से बनाया गया है. इस बारे में PrivacyCG में चर्चा की जा रही है. इसे शुरू करने के लिए, सात महीनों तक इसका ऑरिजिन ट्रायल किया जा रहा है. इस दौरान, Chrome की टीम को काम के सुझाव मिले हैं. डेवलपमेंट के दौरान टीम ने सुझाव को एक्सप्लोर करने के लिए, मुख्य हिस्सेदारों के साथ काम किया. इससे वेब नेटवर्क को बेहतर तरीके से इस्तेमाल करने के लिए डिज़ाइन में कुछ बदलाव किए गए.
आइए, उन दो चुनौतियों के बारे में जानते हैं जो Chrome टीम को सीएचआईपीएस को लागू करने में हुई. साथ ही, यह भी देखते हैं कि प्रस्ताव डिज़ाइन को बेहतर बनाने में समुदाय के सुझावों ने किस तरह अहम भूमिका निभाई.
होस्ट-प्रीफ़िक्स को हटाया जा रहा है और Domain की कोई ज़रूरत नहीं है
सुरक्षा के अच्छे तरीकों को बढ़ावा देने के लिए, सीएचआईपीएस डिज़ाइन के लिए ज़रूरी है कि कुकी सिर्फ़ सुरक्षित प्रोटोकॉल से सेट की जाएं और भेजी जाएं. साथ ही, अलग-अलग कुकी को Secure के साथ सेट किया जाना चाहिए.
इन ज़रूरी शर्तों के साथ ही, शुरुआती प्रस्ताव में पार्टिशन्ड कुकी के लिए Domain एट्रिब्यूट की अनुमति नहीं दी गई. कुकी पर Domain को छोड़ने से, उन्हें किसी पार्टीशन में मौजूद तीसरे पक्ष के अलग-अलग सबडोमेन के बीच शेयर करने की सुविधा बंद हो गई है.
ऑरिजिन ट्रायल के दौरान, Chrome की टीम को पार्टनर और अन्य हिस्सेदारों से पता चला कि डोमेन न रखने की वजह से, सबडोमेन वाली साइटों के लिए सीएचआईपीएस लागू करना मुश्किल हो गया है. उदाहरण के लिए, इससे shop.example.com और pay.example.com के लिए अलग-अलग कुकी जार को शेयर करना मुश्किल हो जाएगा. अन्य मामलों में, एम्बेड किए गए कॉन्टेक्स्ट में पुष्टि करने की प्रक्रिया मुश्किल हो गई.
Chrome की टीम ने इस सुझाव की जांच की और इस नतीजे पर पहुंचे कि डोमेन नो-डोमेन की ज़रूरत को हटाने से निजता से जुड़ी कोई समस्या नहीं होगी. हालांकि, इससे इसे बेहतर तरीके से इस्तेमाल करने में मदद मिलेगी. इस वजह को लेकर, CHIPS की प्रॉडक्ट टीम ने GitHub पर एक चर्चा शुरू की. इसमें, इस ज़रूरी शर्त को हटाने के बारे में और सुझाव दिए गए. सीएचआईपीएस की टेस्टिंग कर रही कई कंपनियों ने जवाब दिया. साथ ही, अपने इस्तेमाल के उदाहरण के लिए इस बदलाव की अहमियत के बारे में सार्वजनिक तौर पर टिप्पणी की.
Chrome ने इस सुझाव को W3C के प्राइवसी कम्यूनिटी ग्रुप में ले जाया और अपडेट किया गया प्रस्ताव पेश किया. Firefox और Edge ने इस बदलाव को मंज़ूरी दे दी और Safari ने इस पर कोई सवाल नहीं उठाया. अगले दिन, Chrome टीम ने Blink-Dev को अपडेट किया और CHIPS GitHub रिपॉज़िटरी पर शर्त को हटाने का प्लान पेश किया.
सीएचआईपीएस की टीम ने शुरुआत में इस शर्त का सुझाव दिया था. इस शर्त की मदद से यह पक्का किया जा सकता है कि साइटों को, नुकसान पहुंचाने वाले या छेड़छाड़ किए गए सबडोमेन से क्रॉस-साइट कुकी न मिलें. साथ ही, उन्होंने सबडोमेन में डेटा लीक करने के लिए, चैनल के तौर पर डोमेन कुकी के इस्तेमाल की संभावना को कम करने के लिए भी सुझाव दिया था.
इससे सुरक्षा के अतिरिक्त फ़ायदे मिले. हालांकि, टेबलो ने बताया कि यह सीएचआईपीएस को अपनाने में चुनौतियां पेश करता है. ऐसा इसलिए, क्योंकि कुछ मौजूदा ऐप्लिकेशन आर्किटेक्चर में, सबडोमेन के बीच कुकी शेयर करने की सुविधा का इस्तेमाल किया जाता है.
Chrome के ज़रिए यह बदलाव करने के बाद, विज़ुअल ऐनलिटिक्स प्लैटफ़ॉर्म पर काम करने वाली कंपनी टेबलो, अब Salesforce के मालिकाना हक में है, इसने शेयर किया:
नाम में बदलाव करने पर, `SameSite=None` एट्रिब्यूट और ज़्यादा 'जाने-पहचाने' एट्रिब्यूट जोड़ने के लिए, पिछले बदलावों की ज़रूरत और ज़्यादा इनलाइन हो जाती है. हम आपके सुझाव, शिकायत या राय सुनने, नतीजों पर नज़र डालने, और बदलाव करने में शुक्रगुज़ार हैं. इससे Google को यह समझने में मदद मिलेगी कि बदलाव को आसानी से बदला जा सकता है या नहीं. ली ग्रैबर, सॉफ़्टवेयर इंजीनियरिंग आर्किटेक्ट, टेबलो
इस प्रोसेस की मदद से, हिस्सेदारों के लिए सीएचआईपीएस को लागू करना आसान बनाया गया. साथ ही, उपयोगकर्ताओं की निजता को बनाए रखा गया.
कुकी की स्टैटिक सीमा के बजाय डाइनैमिक कुकी का इस्तेमाल करना
सीएचआईपीएस को लागू करने में दूसरी चुनौती थी, स्टैटिक कुकी सीमा.
कुकी के लिए ज़्यादा मेमोरी फ़ुटप्रिंट को रोकने के लिए, शुरुआती डिज़ाइन में हर साइट के लिए, हर पार्टीशन के लिए 10 कुकी की संख्या का सुझाव दिया गया था.
Akamai ने सार्वजनिक सुझाव दिया है कि हो सकता है कि सेगमेंट में बांटी गई कुकी के लिए सुझाई गई सीमा, अपने ग्राहकों का कॉन्टेंट होस्ट करने के लिए टॉप लेवल डोमेन की सुविधा देने वाले सीडीएन जैसी सेवाओं के लिए काफ़ी न हो. जैसे, customer.cdn.xyz. उदाहरण के लिए, customer1.cdn.xyz और customer2.cdn.xyz, दोनों ही तीसरे पक्ष का कॉन्टेंट डिलीवर कर सकती हैं. साथ ही, वे दोनों अपनी-अपनी अलग-अलग कुकी सेट कर सकते हैं. अगर इस तरह की कई ग्राहक साइटें किसी दूसरी वेबसाइट पर एम्बेड की जाती हैं, तो वे हर सेगमेंट के लिए 10 कुकी की सीमा तक पहुंच सकती हैं.
Chrome टीम ने पार्टनर मीटिंग और W3C की चर्चा में अन्य फ़ोरम पर भी इसी तरह के सुझाव सुने. इसलिए, उन्होंने इस्तेमाल के इन उदाहरणों में कुकी लिमिट की वजह से आने वाली चुनौती को हल करने के सबसे सही तरीकों पर विचार किया.
कम्यूनिटी से मिले सुझावों को लागू करने के बाद, Chrome ने TPAC 2022 में एक नया आइडिया पेश किया. इसमें बताया गया कि सीएचआईपीएस को मेमोरी के आधार पर, स्टैटिक 10 कुकी की सीमा से _डाइनैमिक _10 केबी की सीमा पर ले जाया जाएगा. विश्लेषण से पता चला कि इस बदलाव में, वेब पर इस्तेमाल के 99% उदाहरण शामिल होने चाहिए. साथ ही, इस बदलाव से उन निजता सिद्धांतों का पालन होना चाहिए जिन्हें Chrome हासिल करने की कोशिश कर रहा था. साथ ही, मुख्य इस्तेमाल को बनाए रखते हुए, क्रॉस-साइट के बारे में शेयर की गई बहुत ज़्यादा जानकारी को सीमित किया जाना चाहिए.
अन्य ब्राउज़र वेंडर ने इस बात पर सहमति जताई कि वे अपडेट किए गए समाधान से सहमत हैं. यह ऐसा समाधान है जिससे यह पक्का किया जाता है कि सीएचआईपीएस, PrivacyCG में क्रॉस-ब्राउज़र सपोर्ट को बनाए रखे.
इस वजह से, Chrome ने नई सीमा लागू की और इस समाधान को सीएचआईपीएस डिज़ाइन में शामिल किया.
इंडस्ट्री में काम करना
सीएचआईपीएस के डेवलपमेंट के दौरान, हमें कई पार्टनर से सुझाव मिले. वेब पर निजता की सुरक्षा को बेहतर बनाने के लिए, साथ मिलकर काम करना अहम रहा है.
अकामाई, Google जैसे दूसरे इंडस्ट्री लीडर के साथ कई मोर्चे पर मिलकर काम करते हैं. सीएचआईपीएस प्रोग्राम के मामले में हमने जो सुझाव दिए हैं वे काफ़ी मामूली लग सकते हैं, लेकिन यह बदलाव बहुत मददगार साबित होगा. इससे, अपने लक्ष्य को हासिल करने के साथ-साथ इस्तेमाल के अच्छे उदाहरणों पर कम से कम असर पड़ेगा. हमारे संबंधित संगठन अपने तरीके से इंटरनेट को तेज़ और ज़्यादा सुरक्षित बनाने के लिए काम कर रहे हैं. साथ ही, जब हम साथ मिलकर काम करते हैं, तो इंटरनेट बेहतर तरीके से काम करता है. मार्टिन मेयर, Akamai Technologies में सीनियर आर्किटेक्ट
सीएचआईपीएस से पता चला है कि प्राइवसी सैंडबॉक्स की टेक्नोलॉजी को बेहतर बनाने के लिए, नेटवर्क से मिलने वाले सुझाव ज़रूरी हैं. वेब बातचीत को GitHub, W3C मीटिंग में खोलें, और Chrome टीम के साथ चल रहे जुड़ाव ने सीधे उन बदलावों में योगदान दिया जिन्हें अब Chrome के स्टेबल वर्शन में रोल आउट किया गया है. Chrome टीम अलग-अलग प्रस्तावों के लिए इस फ़ीडबैक को सुनने के लिए उत्सुक है और टेक्नोलॉजी को डेवलप करने और वेब पर रोल आउट करने के तरीके में इससे बड़ा फ़र्क़ पड़ता है.