चिप को बेहतर बनाने के लिए, इंडस्ट्री के साथ मिलकर काम करना

इस वीडियो में, CHIPS को लागू करने के दौरान Chrome टीम को हुई दो चुनौतियों के बारे में बताया गया है. साथ ही, यह भी बताया गया है कि कम्यूनिटी के सुझावों और राय से, प्रस्ताव के डिज़ाइन को बेहतर बनाने में कैसे मदद मिली.

कुकीज़ हैविंग इंडिपेंडेंट पार्टिशन्ड स्टेट (सीएचआईपीएस), Privacy Sandbox की एक टेक्नोलॉजी है. इसकी मदद से, डेवलपर किसी कुकी को "अलग-अलग हिस्सों में बांटा गया" स्टोरेज में ऑप्ट इन कर सकते हैं. साथ ही, हर टॉप-लेवल साइट के लिए अलग-अलग कुकी जार इस्तेमाल किए जा सकते हैं.
CHIPS के इस्तेमाल के उदाहरणों में, ऐसे सभी मामले शामिल हैं जहां क्रॉस-साइट सब-रिसॉर्स को सेशन या पर्सिस्टेंट स्टेटस की ज़रूरत होती है. यह स्टेटस, किसी एक टॉप-लेवल साइट पर उपयोगकर्ता की गतिविधि के दायरे में होता है. जैसे, तीसरे पक्ष के चैट विजेट, मैप एम्बेड, सब-रिसॉर्स सीडीएन लोड बैलेंसिंग, हेडलेस सीएमएस प्रोवाइडर वगैरह.

CHIPS को ओपन वेब स्टैंडर्ड बनाने के मकसद से डेवलप किया जा रहा है. इस बारे में PrivacyCG में चर्चा की जा रही है. साथ ही, इसे सात महीने तक ऑरिजिन ट्रायल के तौर पर आज़माया गया है. इस दौरान, Chrome की टीम को मददगार सुझाव/राय मिली है. इस टूल को डेवलप करने के दौरान, टीम ने अहम हिस्सेदारों के साथ मिलकर उस सुझाव को एक्सप्लोर किया. इसकी वजह से, एक ऐसा अपडेट किया गया डिज़ाइन तैयार हुआ जो वेब नेटवर्क को बेहतर तरीके से काम करता है.

आइए, जानें कि CHIPS को लागू करने में Chrome की टीम को किन दो चुनौतियों का सामना करना पड़ा. साथ ही, यह भी जानें कि प्रस्ताव के डिज़ाइन को बेहतर बनाने में, कम्यूनिटी के सुझावों और राय ने कैसे अहम भूमिका निभाई.

होस्ट-प्रीफ़िक्स हटाना और Domain की ज़रूरत नहीं है

सुरक्षा के सही तरीकों को बढ़ावा देने के लिए, CHIPS डिज़ाइन के मुताबिक कुकी सिर्फ़ सुरक्षित प्रोटोकॉल से सेट की जानी चाहिए और उन्हें सुरक्षित प्रोटोकॉल से ही भेजा जाना चाहिए. साथ ही, पार्टिशन की गई कुकी को Secure के साथ सेट किया जाना चाहिए.

इन ज़रूरी शर्तों के साथ-साथ, शुरुआती प्रस्ताव में, अलग-अलग सेक्शन में बांटी गई कुकी पर Domain एट्रिब्यूट का इस्तेमाल करने की अनुमति नहीं दी गई थी. कुकी पर Domain को शामिल न करने से, उन्हें किसी पार्टीशन में तीसरे पक्ष के अलग-अलग सबडोमेन के बीच शेयर करने से रोका जा सकता है.

ऑरिजिन ट्रायल के दौरान, Chrome की टीम को पार्टनर और दूसरे हिस्सेदारों से पता चला कि बिना डोमेन वाली साइटों के लिए, सबडोमेन वाली साइटों पर CHIPS लागू करना मुश्किल है. उदाहरण के लिए, इससे shop.example.com और pay.example.com के लिए, अलग-अलग हिस्सों में बांटी गई कुकी के डिब्बे शेयर करना मुश्किल हो जाएगा. अन्य मामलों में, एम्बेड किए गए कॉन्टेक्स्ट में पुष्टि करने की प्रोसेस को मुश्किल बना दिया था.

pay.example.com और shop.example.com साइटों को दिखाने वाला डायग्राम

Chrome की टीम ने इस सुझाव का आकलन किया है. इसमें यह पाया गया है कि बिना डोमेन वाले खाते से साइन इन करने की ज़रूरी शर्त हटाने से, निजता से जुड़ी कोई समस्या नहीं होगी. साथ ही, इससे इस सुविधा को इस्तेमाल करना आसान हो जाएगा. इसके जवाब में, CHIPS की प्रॉडक्ट टीम ने GitHub पर एक चर्चा शुरू की. इसमें, इस ज़रूरी शर्त को हटाने के बारे में ज़्यादा सुझाव, राय या शिकायत देने के लिए कहा गया. CHIPS की टेस्टिंग कर रही कई कंपनियों ने इस बदलाव के बारे में सार्वजनिक तौर पर जवाब दिया और बताया कि उनके इस्तेमाल के उदाहरण के लिए, यह बदलाव कितना अहम है.

Chrome ने W3C के निजता कम्यूनिटी ग्रुप को सुझाव दिया और अपडेट किया गया प्रस्ताव पेश किया. Firefox और Edge ने इस बदलाव को मंज़ूरी दी और Safari ने कोई समस्या नहीं बताई. अगले दिन, Chrome टीम ने Blink-Dev को अपडेट किया और CHIPS Github रिपॉज़िटरी से ज़रूरी शर्त हटाने का प्लान पेश किया.

CHIPS टीम ने शुरुआत में इस ज़रूरी शर्त का प्रस्ताव इसलिए रखा था, ताकि यह पक्का किया जा सके कि साइटों को नुकसान पहुंचाने वाले या हैक किए गए किसी भी सबडोमेन से क्रॉस-साइट कुकी न मिलें. साथ ही, डोमेन कुकी का इस्तेमाल, सबडोमेन में डेटा लीक करने के लिए चैनल के तौर पर न किया जा सके.

इससे सुरक्षा से जुड़े अतिरिक्त फ़ायदे मिले, लेकिन Tableau ने हाइलाइट किया कि इससे CHIPS को अपनाने में समस्याएं आ सकती हैं. इसकी वजह यह है कि मौजूदा कुछ ऐप्लिकेशन आर्किटेक्चर, सबडोमेन के बीच कुकी शेयर करने पर निर्भर करते हैं.

Chrome में यह बदलाव होने के बाद, विज़ुअल ऐनलिटिक्स प्लैटफ़ॉर्म की कंपनी Tableau ने यह जानकारी शेयर की:

नाम बदलने की ज़रूरत को हटाने से, `SameSite=None` एट्रिब्यूट जोड़ने के लिए किए गए पिछले बदलावों के साथ ज़्यादा मेल खाता है. इसलिए, 'जानकारी' की संख्या ज़्यादा हो जाती है. हम Google की सराहना करते हैं कि उसने सुझावों को ध्यान में रखा, उनके असर को समझा, और आसानी से ट्रांज़िशन करने में मदद करने के लिए बदलाव किया. ली ग्रैबर, सॉफ़्टवेयर इंजीनियरिंग आर्किटेक्ट, Tableau

इस प्रोसेस की मदद से, उपयोगकर्ताओं की निजता को बनाए रखते हुए, हिस्सेदारों के लिए CHIPS को लागू करना आसान हो गया.

CHIPS को लागू करने में एक और समस्या, स्टैटिक कुकी की सीमा थी.
कुकी के लिए ज़्यादा मेमोरी फ़ुटप्रिंट से बचने के लिए, शुरुआती डिज़ाइन में हर साइट और हर पार्टीशन के लिए 10 कुकी की संख्या तय की गई थी.

Akamai ने सार्वजनिक तौर पर सुझाव दिया है कि पार्टिशन की गई कुकी के लिए सुझाई गई सीमा, सीडीएन जैसी सेवाओं के लिए शायद काफ़ी न हो. ये सेवाएं, अपने ग्राहकों के कॉन्टेंट को होस्ट करने के लिए टॉप लेवल डोमेन (जैसे, customer.cdn.xyz) उपलब्ध कराती हैं. उदाहरण के लिए, customer1.cdn.xyz और customer2.cdn.xyz, दोनों तीसरे पक्ष का कॉन्टेंट डिलीवर कर सकते हैं. साथ ही, दोनों अपनी कई कुकी सेट कर सकते हैं. अगर इस तरह की कई ग्राहक साइटें किसी दूसरी वेबसाइट पर एम्बेड की जाती हैं, तो वे हर पार्टीशन के लिए 10 कुकी की सीमा तक पहुंच सकती हैं.

Chrome की टीम को अन्य फ़ोरम, पार्टनर मीटिंग, और W3C की चर्चाओं में भी इसी तरह के सुझाव मिले. इसलिए, उन्होंने इन इस्तेमाल के उदाहरणों में कुकी की सीमा से जुड़ी समस्या को हल करने के सबसे सही तरीके ढूंढे.

डायग्राम में दिखाया गया है कि क्लाइंट के मशीनों पर, किसी एक डोमेन में ज़्यादा से ज़्यादा कितनी SameSite=None कुकी हो सकती हैं
एक डोमेन के क्लाइंट के मशीनों पर, SameSite=None एट्रिब्यूट वाली ज़्यादा से ज़्यादा कुकी की संख्या दिखाने वाला डायग्राम

कम्यूनिटी के सुझाव/शिकायत/राय को शामिल करने के तरीके पर विचार करने के बाद, Chrome ने TPAC 2022 में एक अपडेट किया गया आइडिया पेश किया. इसमें सुझाव दिया गया कि CHIPS को स्टैटिक 10 कुकी की सीमा से हटाकर, मेमोरी के आधार पर 10 केबी की _डाइनैमिक _सीमा पर ले जाया जाए. विश्लेषण से पता चला है कि इस बदलाव से, वेब पर इस्तेमाल के 99% उदाहरणों को कवर किया जा सकता है. साथ ही, इससे निजता के उन सिद्धांतों को भी बरकरार रखा जा सकेगा जिन्हें Chrome हासिल करने की कोशिश कर रहा था. जैसे, उपयोगकर्ताओं की अलग-अलग साइटों पर शेयर की जाने वाली ज़्यादा जानकारी को सीमित करना.

अन्य ब्राउज़र वेंडर ने अपना मत देते हुए कहा कि वे अपडेट किए गए समाधान से सहमत हैं. यह इस बात को पक्का करने के लिए ज़रूरी था कि PrivacyCG में CHIPS, अलग-अलग ब्राउज़र के साथ काम करता रहे.

इस वजह से, Chrome ने नई सीमा को अपना लिया और CHIPS के डिज़ाइन में समाधान को शामिल कर लिया.

इंडस्ट्री के साथ काम करना

CHIPS को डेवलप करने के दौरान, हमने कई पार्टनर से सुझाव और राय ली है. वेब पर निजता को बेहतर बनाने के लिए, साथ मिलकर काम करना ज़रूरी है.

Akamai, Google जैसी इंडस्ट्री के अन्य लीडर के साथ कई मोर्चों पर मिलकर काम करता है. CHIPS प्रोग्राम के लिए, हमने जो सुझाव दिया है वह मामूली लग सकता है. हालांकि, इस बदलाव से यह पक्का करने में मदद मिलेगी कि इस्तेमाल के सही उदाहरणों पर कम से कम बुरा असर पड़े. साथ ही, प्रोग्राम का मकसद भी पूरा हो पाएगा. हमारे संगठन, इंटरनेट को तेज़ और ज़्यादा सुरक्षित बनाने के लिए अपने-अपने तरीके से काम कर रहे हैं. साथ मिलकर काम करने से, इंटरनेट को बेहतर बनाने में मदद मिलती है. मार्टिन मेयर, Akamai Technologies में सीनियर आर्किटेक्ट

CHIPS से पता चला है कि Privacy Sandbox की टेक्नोलॉजी को बेहतर बनाने के लिए, नेटवर्क से जुड़े लोगों के सुझाव, शिकायत या राय लेना ज़रूरी है. GitHub पर वेब पर होने वाली बातचीत, W3C की मीटिंग, और Chrome की टीम के साथ लगातार जुड़ाव से, उन बदलावों में सीधे तौर पर मदद मिली है जिन्हें अब Chrome के स्टैबल वर्शन में रोल आउट किया गया है. Chrome की टीम, अलग-अलग तरह के सुझावों के लिए यह सुझाव सुनने को तैयार है. इससे, वेब पर टेक्नोलॉजी को डेवलप करने और उन्हें रोल आउट करने के तरीके में काफ़ी फ़र्क़ पड़ता है.