Privacy Sandbox में प्रपोज़ल का लाइफ़साइकल

वेब प्लैटफ़ॉर्म की सुविधाएं बनाने के लिए, Privacy Sandbox के प्रपोज़ल एक अहम कदम हैं.

वेब प्लैटफ़ॉर्म की ये सुविधाएं, वेब स्टैंडर्ड (जिन्हें स्पेसिफ़िकेशन या स्पेक भी कहा जाता है) बन सकती हैं. ये तकनीकी दस्तावेज़ होते हैं, जिनमें वेब टेक्नोलॉजी के काम करने के तरीके के बारे में पूरी जानकारी होती है. साथ ही, इनमें यह भी बताया जाता है कि इंजीनियरों को वेब ब्राउज़र में टेक्नोलॉजी को कैसे लागू करना चाहिए. उदाहरण के लिए, ऐक्सेसिबल रिच इंटरनेट ऐप्लिकेशन (WAI-ARIA) स्टैंडर्ड (जिसे आम तौर पर "ARIA" कहा जाता है) में, वेब को दिव्यांगों के लिए ज़्यादा ऐक्सेस करने लायक बनाने के तकनीकी तरीके बताए गए हैं. ये खास जानकारी, वर्ल्ड वाइड वेब कंसोर्टियम (W3C) के लिए और उसके ज़रिए तैयार की जाती है. यह एक अंतरराष्ट्रीय कम्यूनिटी है, जिसमें फ़ुल टाइम स्टाफ़, सदस्य संगठन, और आम लोगों से मिले सुझाव/राय शामिल होते हैं.

चर्चा, टेस्टिंग, और बड़े पैमाने पर इस्तेमाल के बाद, Privacy Sandbox के कुछ प्रस्ताव और एपीआई, स्पेसिफ़िकेशन बन जाएंगे. यह ज़रूरी है कि हमें डेवलपर और इंडस्ट्री के लीडर से सुझाव/राय मिले. इससे हमें यह पक्का करने में मदद मिलेगी कि हम उपयोगकर्ताओं के लिए, वेब की ऐसी सुविधाएं उपलब्ध कराएं जो लंबे समय तक काम करें, जिनका इस्तेमाल कई कामों के लिए किया जा सके, और जिनसे उनकी निजता को सुरक्षित रखा जा सके.

सुविधाओं को डेवलप करने और टेस्ट करने की टाइमलाइन के हिसाब से, उन्हें सामान्य तौर पर उपलब्ध कराने की प्रोसेस पूरी की जाती है.
पहली इमेज: इस इमेज में, सुविधाओं के डेवलपमेंट और टेस्टिंग से लेकर, उन्हें सभी के लिए उपलब्ध कराने तक की टाइमलाइन दिखाई गई है. इंटेंट, तय सीमा होती हैं. कुछ कार्रवाइयां करने से पहले, इनकी ज़रूरत होती है. उदाहरण के लिए, एक्सपेरिमेंट करने का इंटेंट पोस्ट होने और अनुमतियां मिलने तक, जांच शुरू नहीं की जा सकती. इन ज़रूरी शर्तों के बारे में ज़्यादा जानें.

Chromium (कई आधुनिक ब्राउज़र के पीछे मौजूद ओपन सोर्स प्रोजेक्ट) ने उन सभी टेक्नोलॉजी के लिए, सुविधा डेवलप करने की प्रोसेस के बारे में लिखा है जिनका मकसद वेब स्टैंडर्ड बनना है. वेब पर निजता और सुरक्षा काफ़ी अहम है. इसलिए, हम चाहते हैं कि टेस्टिंग शुरू होने से पहले, इस बारे में ज़्यादा से ज़्यादा चर्चा की जाए और सुझाव, राय, और शिकायतें दी जाएं.

प्रस्ताव से वेब स्टैंडर्ड तक

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

बातचीत से शुरू करें

प्रोटोटाइप बनाने के लिए इंटेंट से बातचीत शुरू होती है.
दूसरी इमेज: प्रोटोटाइप बनाने के लिए, बातचीत की शुरुआत करने वाला इंटेंट.

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

W3C के कई ग्रुप हैं जिनमें शामिल हुआ जा सकता है या जिन्हें मॉनिटर किया जा सकता है. यह इस बात पर निर्भर करता है कि आपको किन इस्तेमाल के उदाहरणों में दिलचस्पी है:

चर्चा के चरण में ज़्यादा समय लग सकता है.

उदाहरण के लिए, Protected Audience (पहले इसे FLEDGE कहा जाता था) एक ऐसा प्रपोज़ल है जो क्रॉस-साइट ट्रैकिंग के बिना, दिलचस्पी के आधार पर विज्ञापन दिखाने की सुविधा देता है. निजता के अधिकारों के समर्थकों और इंडस्ट्री के कई हिस्सेदारों के सुझावों के आधार पर, Protected Audience API को दो पुराने प्रस्तावों (PIGIN और TURTLEDOVE) से तैयार किया गया है. मौजूदा वर्शन को बेहतर बनाने के लिए, 100 से ज़्यादा लोगों ने W3C की मीटिंग में हिस्सा लिया है. साथ ही, 300 से ज़्यादा ऑनलाइन चर्चा वाली थ्रेड में भी हिस्सा लिया है.

इसी समाधान के लिए, अन्य कंपनियों ने भी आधा दर्जन से ज़्यादा प्रस्ताव दिए हैं. हमें उम्मीद है कि साथ मिलकर काम करने से, हम आगे की राह तय कर पाएंगे.

Protected Audience और अन्य एपीआई की टेस्टिंग, Chrome फ़्लैग के पीछे उपलब्ध है, ताकि डेवलपर उन्हें जल्दी ऐक्सेस कर सकें.

हर प्रस्ताव को, सुरक्षित ऑडियंस की तरह ही लंबे समय तक इंक्यूबेट नहीं किया जाता. कुछ प्रस्तावों को तुरंत मंज़ूरी मिल जाती है. हालांकि, हर एपीआई को पूरे नेटवर्क से इनपुट मिलता है. ये नए आइडिया हैं और इन्हें सही तरीके से लागू करने में काफ़ी मेहनत लग सकती है.

डेवलपर, एक्सपेरिमेंट को टेस्ट करते हैं और सुझाव, शिकायत या राय शेयर करते हैं

एक्सपेरिमेंट के लिए इंटेंट, फ़ंक्शन और स्केल की गई टेस्टिंग के लिए होते हैं.
तीसरी इमेज: एक्सपेरिमेंट का मकसद, फ़ंक्शनल और स्केल की गई टेस्टिंग के लिए है.

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

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

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

Privacy Sandbox ने काम के और मेज़रमेंट एपीआई के लिए, एक ही ऑरिजिन ट्रायल चलाया था. यह ट्रायल अब पूरा हो चुका है.

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

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

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

चाहे आपने अपनी जांच की जानकारी, W3C जैसी सार्वजनिक जगहों पर शेयर की हो, सुझाव/राय देने वाले फ़ॉर्म के ज़रिए शेयर की हो या सीधे तौर पर पार्टनरशिप वाले चैनलों के ज़रिए शेयर की हो, हमें आपसे सुनने का इंतज़ार रहेगा.

नई टेक्नोलॉजी के काम करने के तरीके को जानने के लिए, ब्राउज़र में टेस्टिंग करना ही एकमात्र तरीका नहीं है. कुछ कंपनियां, Privacy Sandbox के कॉन्सेप्ट के आधार पर सिम्युलेशन भी बना रही हैं.

बड़े पैमाने पर इस्तेमाल के लिए लॉन्च करना

'शिप करने का इंटेंट' से पता चलता है कि एपीआई को बड़े पैमाने पर इस्तेमाल करने के लिए उपलब्ध कराने का अनुरोध किया गया है.
चौथा इलस्ट्रेशन: 'शिप करने का इंटेंट' से पता चलता है कि एपीआई को बड़े पैमाने पर इस्तेमाल करने के लिए उपलब्ध कराने का अनुरोध किया गया है.

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

हमने पहले ही कई अहम माइलस्टोन को पूरा कर लिया है और आने वाले समय में और भी माइलस्टोन पूरे किए जाएंगे. ये टेक्नोलॉजी अब उपलब्ध हैं:

  • User-Agent के ज़रिए जानकारी इकट्ठा करने की समस्या को कम करना: पैसिव तरीके से शेयर किए गए ब्राउज़र डेटा को सीमित करें. इससे, संवेदनशील जानकारी का वॉल्यूम कम हो जाता है, जिससे फ़िंगरप्रिंट बनने की संभावना कम हो जाती है. हमने मई 2022 में इन वैल्यू को कम करना शुरू किया था. हमारा प्लान है कि मई 2023 तक इसे पूरा कर लिया जाए.
  • सीएचआईपीएस: डेवलपर, किसी कुकी को अलग-अलग स्टोरेज में सेव करने के लिए ऑप्ट-इन कर सकते हैं. साथ ही, हर टॉप-लेवल साइट के लिए एक अलग कुकी जार भी सेट कर सकते हैं. CHIPS, फ़रवरी 2023 में स्टेबल वर्शन में उपलब्ध हो गया.
  • पहले पक्ष के सेट: Storage Access API का इस्तेमाल करके, क्रॉस-साइट कुकी को सीमित तौर पर ऐक्सेस करने की अनुमति देने के लिए, साइटों के बीच के संबंधों के बारे में एलान करें. फ़र्स्ट-पार्टी सेट की सुविधा, इस हफ़्ते Chrome के स्थिर वर्शन 113 के साथ धीरे-धीरे लॉन्च की जा रही है.
  • फ़ेडरेटेड क्रेडेंशियल मैनेजमेंट (FedCM): इसकी मदद से, उपयोगकर्ता के ईमेल पते या पहचान से जुड़ी अन्य जानकारी को तीसरे पक्ष की सेवा या वेबसाइट के साथ शेयर किए बिना, फ़ेडरेटेड आइडेंटिटी की सुविधा का इस्तेमाल किया जा सकता है. हालांकि, ऐसा तब ही किया जा सकता है, जब उपयोगकर्ता ने साफ़ तौर पर इसकी अनुमति दी हो. FedCM की सुविधा नवंबर 2022 में लॉन्च की गई थी.

जुलाई 2023 में, काम के कॉन्टेंट और मेज़रमेंट एपीआई, बड़े पैमाने पर इस्तेमाल के लिए उपलब्ध हो गए. इसका मतलब है कि ये एपीआई, Chrome में डिफ़ॉल्ट रूप से उपलब्ध हो गए हैं. डेवलपर अब ब्राउज़र फ़्लैग या ऑरिजिन ट्रायल में हिस्सा लिए बिना, इन टेक्नोलॉजी का इस्तेमाल कर सकते हैं.

कुल मिलाकर, ये एपीआई बड़े पैमाने पर, प्रोडक्शन एनवायरमेंट में 99 प्रतिशत उपयोगकर्ताओं के लिए तैयार हैं.

अलग-अलग चरणों में लॉन्च करना

कुछ टेक्नोलॉजी धीरे-धीरे उपलब्ध कराई जाती हैं. इससे हमारी टीम और डेवलपर, संभावित समस्याओं को मॉनिटर कर सकते हैं और उन्हें हल कर सकते हैं. साथ ही, पूरी उपलब्धता का मतलब यह नहीं है कि 100% ट्रैफ़िक के लिए एपीआई चालू हैं.

उदाहरण के लिए, Chrome में User-Agent Client Hints (UA-CH) को 2021 में धीरे-धीरे लॉन्च किया गया. उपयोगकर्ता-एजेंट को कम करने की प्रोसेस अप्रैल 2022 में शुरू हुई और मार्च 2023 में पूरी हो गई. इससे डेवलपर को अपनी साइटों को User-Agent स्ट्रिंग पर निर्भरता से हटाने के लिए, काफ़ी समय मिला.

एपीआई कंट्रोल

काम के कॉन्टेंट और मेज़रमेंट एपीआई जैसे कुछ एपीआई में, उपयोगकर्ता के लिए कॉन्फ़िगरेशन के विकल्प होते हैं. इसमें इन एपीआई को चालू और बंद करने की सुविधा भी शामिल है.

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

ब्राउज़र की सुविधाओं के लिए, अनुमतियों की नीति का इस्तेमाल करके, फ़र्स्ट-पार्टी और तीसरे पक्ष के ऐक्सेस को कंट्रोल करें.

सुझाव/राय दें या शिकायत करें

हम आपको इस बारे में जानकारी देते रहेंगे कि क्या हो रहा है. साथ ही, हम आपको ज़्यादा से ज़्यादा जानकारी देने की कोशिश करेंगे. हम आपको इसमें शामिल होने के लिए बढ़ावा देंगे और आपके सुझावों को सुनेंगे.