साल 2022 की दूसरी तिमाही की तिमाही रिपोर्ट, जिसमें Privacy Sandbox के प्रस्तावों और Chrome के जवाब पर मिले नेटवर्क के सुझाव/राय या शिकायतों की खास जानकारी दी गई है.
सीएमए के साथ किए गए अपने वादे के तहत, Google ने अपने निजता सैंडबॉक्स के प्रस्तावों के लिए, हिस्सेदारों के साथ जुड़ाव की प्रोसेस के बारे में सार्वजनिक तौर पर हर तीन महीने की रिपोर्ट देने पर सहमति दी है. समझौते के पैराग्राफ़ 12 और 17(c)(ii) देखें. Privacy Sandbox के सुझाव/राय/शिकायत/राय देने वाले फ़ॉर्म की खास जानकारी वाली ये रिपोर्ट, सुझाव/राय/शिकायत/राय देने वाले फ़ॉर्म की खास जानकारी में बताए गए अलग-अलग सोर्स से मिले सुझाव/राय/शिकायत/राय को इकट्ठा करके जनरेट की जाती हैं. इनमें ये सोर्स शामिल हैं, लेकिन इन तक ही सीमित नहीं हैं: GitHub पर मौजूद समस्याएं, privacysandbox.com पर उपलब्ध सुझाव/राय/शिकायत/राय देने वाला फ़ॉर्म, इंडस्ट्री के हिस्सेदारों के साथ हुई मीटिंग, और वेब स्टैंडर्ड फ़ोरम. Chrome, नेटवर्क से मिले सुझावों/शिकायतों/राय का स्वागत करता है. साथ ही, डिज़ाइन से जुड़े फ़ैसलों में, इन सुझावों/शिकायतों/राय को शामिल करने के तरीकों को लगातार एक्सप्लोर कर रहा है.
सुझाव, शिकायत या राय की थीम को हर एपीआई के हिसाब से, उनकी संख्या के आधार पर रैंक दी जाती है. ऐसा करने के लिए, Chrome की टीम को किसी थीम के बारे में मिले सुझावों, राय या शिकायतों की संख्या को इकट्ठा किया जाता है. इसके बाद, उन्हें संख्या के हिसाब से कम से ज़्यादा के क्रम में लगाया जाता है. आम तौर पर मिलने वाले सुझाव/राय/शिकायत/राय के विषयों की पहचान करने के लिए, सार्वजनिक मीटिंग (W3C, PatCG, IETF), सीधे सुझाव/राय/शिकायत/राय, GitHub, और Google की इंटरनल टीमों और सार्वजनिक फ़ॉर्म से पूछे जाने वाले आम सवालों के विषयों की समीक्षा की गई.
खास तौर पर, वेब स्टैंडर्ड बॉडी की मीटिंग के मिनट की समीक्षा की गई. साथ ही, सीधे फ़ीडबैक के लिए, Google के 1:1 हिस्सेदारों की मीटिंग के रिकॉर्ड, अलग-अलग इंजीनियरों को मिले ईमेल, एपीआई की मेलिंग सूची, और सार्वजनिक फ़ीडबैक फ़ॉर्म को ध्यान में रखा गया. इसके बाद, Google ने इन अलग-अलग आउटरीच गतिविधियों में शामिल टीमों के बीच समन्वय किया, ताकि यह पता लगाया जा सके कि हर एपीआई के लिए, कौनसी थीम सबसे ज़्यादा लोकप्रिय हैं.
Chrome पर मिले सुझाव, शिकायत या राय के जवाबों के बारे में जानकारी, पब्लिश किए गए अक्सर पूछे जाने वाले सवालों, हिस्सेदारों की ओर से उठाई गई समस्याओं के जवाबों, और सार्वजनिक तौर पर रिपोर्ट करने के मकसद से किसी खास बात पर फ़ैसला लेने के आधार पर दी गई है. डेवलपमेंट और टेस्टिंग पर फ़िलहाल फ़ोकस करने की वजह से, हमें Topics, Fledge, और एट्रिब्यूशन रिपोर्टिंग एपीआई के बारे में खास तौर पर सवाल और सुझाव मिले.
हो सकता है कि रिपोर्टिंग की मौजूदा अवधि खत्म होने के बाद मिले सुझाव/शिकायत/राय पर, Chrome ने अब तक कोई जवाब न दिया हो.
शॉर्ट फ़ॉर्म की ग्लॉसरी
- सीएचआईपीएस
- कुकीज़ हैविंग इंडिपेंडेंट पार्टिशन्ड स्टेट
- डीएसपी
- डिमांड-साइड प्लैटफ़ॉर्म
- FedCM
- फ़ेडरेटेड क्रेडेंशियल मैनेजमेंट
- एफ़पीएस
- फ़र्स्ट पार्टी सेट
- IAB
- Interactive Advertising Bureau
- IDP
- पहचान की पुष्टि करने वाली सेवा
- आईईटीएफ़
- इंटरनेट इंजीनियरिंग टास्क फ़ोर्स
- आईपी
- इंटरनेट प्रोटोकॉल पता
- openRTB
- रीयल-टाइम बिडिंग
- OT
- Origin ट्रायल
- PatCG
- निजी विज्ञापन टेक्नोलॉजी कम्यूनिटी ग्रुप
- आरपी
- भरोसा करने वाली पार्टी
- SSP
- सप्लाई-साइड प्लैटफ़ॉर्म
- टीईई
- ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट
- UA
- यूज़र एजेंट स्ट्रिंग
- UA-CH
- User-Agent Client Hints
- W3C
- वर्ल्ड वाइड वेब कंसोर्टियम
- WIPB
- जान-बूझकर आईपी ब्लाइंडनेस
सामान्य सुझाव, राय या शिकायत, किसी खास एपीआई/टेक्नोलॉजी के लिए नहीं
| सुझाव, राय या शिकायत की थीम
(आम तौर पर होने की वजह से रैंक) |
सवालों और समस्याओं की खास जानकारी | Chrome का जवाब |
| टाइमलाइन को साफ़ तौर पर दिखाना | Privacy Sandbox की टेक्नोलॉजी के रिलीज़ शेड्यूल के बारे में ज़्यादा जानकारी. | हमने privacysandbox.com पर, डिप्लॉयमेंट शेड्यूल के लिए अपने मौजूदा प्लान सेट किए हैं. साथ ही, हम इसे हर महीने अपडेट करते हैं. इनमें Chrome और वेब डेवलपर, दोनों के लिए डेवलपमेंट में लगने वाला समय शामिल होता है. साथ ही, नई टेक्नोलॉजी को टेस्ट करने और उन्हें अपनाने में लगने वाले समय के बारे में, बड़े नेटवर्क से मिले सुझावों और राय को भी ध्यान में रखा जाता है. हर टेक्नोलॉजी को टेस्टिंग से लेकर रिलीज़ (लॉन्च) तक कई चरणों से गुज़रना पड़ता है. साथ ही, हर चरण में लगने वाले समय के बारे में, पिछले चरण में मिली जानकारी से पता चलता है. फ़िलहाल, हमने रिलीज़ की कोई तारीख तय नहीं की है. हालांकि, जब भी हम कोई तारीख तय करेंगे, तो privacysandbox.com पर अपनी सार्वजनिक टाइमलाइन को अपडेट कर देंगे. |
| अलग-अलग तरह के हिस्सेदारों के लिए फ़ायदेमंद होना | Privacy Sandbox की टेक्नोलॉजी, बड़े डेवलपर के लिए फ़ायदेमंद हैं. साथ ही, खास (छोटी) साइटें, सामान्य (बड़ी) साइटों से ज़्यादा योगदान देती हैं. | हम समझते हैं कि कुछ डेवलपर को Privacy Sandbox टेक्नोलॉजी के असर को लेकर चिंता है. Google ने सीएमए को यह वादा किया है कि वह Privacy Sandbox के प्रस्तावों को इस तरह से डिज़ाइन या लागू नहीं करेगा कि Google अपने कारोबार को प्राथमिकता देकर, प्रतिस्पर्धा को गलत तरीके से प्रभावित करे. साथ ही, वह डिजिटल विज्ञापन में प्रतिस्पर्धा, पब्लिशर, और विज्ञापन देने वालों पर पड़ने वाले असर के साथ-साथ, निजता के नतीजों और उपयोगकर्ता अनुभव पर पड़ने वाले असर को भी ध्यान में रखेगा. हम सीएमए के साथ मिलकर काम करते रहेंगे, ताकि यह पक्का किया जा सके कि हमारा काम इन प्रतिबद्धताओं के मुताबिक हो.
Privacy Sandbox की टेस्टिंग के दौरान, हम इस बात का आकलन करेंगे कि अलग-अलग तरह के हिस्सेदारों के लिए, नई टेक्नोलॉजी कैसा परफ़ॉर्म करती हैं. इस मामले में सुझाव, शिकायत या राय देना ज़रूरी है. खास तौर पर, ऐसा सुझाव, शिकायत या राय देना जो काम की हो और जिस पर कार्रवाई की जा सके. इससे, हमें तकनीकी डिज़ाइन को और बेहतर बनाने में मदद मिलती है. |
| तीसरे पक्ष की कुकी के इस्तेमाल को रोकने की समयावधि | तीसरे पक्ष की कुकी के इस्तेमाल को बंद करने में और देरी न हो, इसके लिए अनुरोध | हमें कुछ हिस्सेदारों से पता चला है कि वे चाहते हैं कि Chrome, तीसरे पक्ष की कुकी इस्तेमाल करने की सुविधा को तुरंत बंद कर दे. वहीं, कुछ लोगों का मानना है कि Privacy Sandbox की टेक्नोलॉजी को टेस्ट करने और उन्हें अपनाने के लिए ज़्यादा समय चाहिए. हम पूरी ज़िम्मेदारी के साथ आगे बढ़ने के लिए प्रतिबद्ध हैं. ऐसा इसलिए, क्योंकि टेक्नोलॉजी की जटिलता और इकोसिस्टम के लिए सही चीज़ें करना ज़रूरी है. इस प्रोसेस में, इंडस्ट्री और रेगुलेटर का सुझाव, शिकायत या राय हमारे लिए अहम है. |
| तीसरे पक्ष की कुकी के इस्तेमाल को रोकने की समयावधि | तीसरे पक्ष की कुकी के इस्तेमाल पर रोक लगाने के लिए अनुरोध करना और एपीआई को टेस्ट करने के लिए ज़्यादा समय देना. | हमें कुछ हिस्सेदारों से पता चला है कि वे चाहते हैं कि Chrome, तीसरे पक्ष की कुकी इस्तेमाल करने की सुविधा को तुरंत बंद कर दे. वहीं, कुछ लोगों का मानना है कि Privacy Sandbox की टेक्नोलॉजी को टेस्ट करने और उन्हें अपनाने के लिए ज़्यादा समय चाहिए. हम पूरी ज़िम्मेदारी के साथ आगे बढ़ने के लिए प्रतिबद्ध हैं. ऐसा इसलिए, क्योंकि टेक्नोलॉजी की जटिलता और इकोसिस्टम के लिए सही चीज़ें करना ज़रूरी है. इस प्रोसेस में, इंडस्ट्री और रेगुलेटर का सुझाव, शिकायत या राय हमारे लिए अहम है. |
| दस्तावेज़ के अनुरोध | जांच, विश्लेषण, और लागू करने के तरीके के बारे में ज़्यादा संसाधनों के लिए अनुरोध. | हमें खुशी है कि डेवलपर को हमारा मौजूदा कॉन्टेंट मददगार लगा. आने वाले हफ़्तों और महीनों में, हम ज़्यादा कॉन्टेंट उपलब्ध कराएंगे. इसमें, डेवलपर के ऑफ़िस के खुले होने का समय और तकनीकी दस्तावेज़ शामिल हैं. इससे डेवलपर यह समझ पाएंगे कि नई टेक्नोलॉजी उनके लिए कैसे काम कर सकती हैं.
हमने बाहरी डेवलपर के लिए, ऑफ़िस में कामकाज के घंटों के दौरान सार्वजनिक सेशन भी आयोजित किए हैं. इनमें, प्रॉडक्ट और इंजीनियरिंग लीड के साथ सवाल-जवाब के साथ-साथ, सबसे सही तरीके और डेमो शेयर किए गए. इससे, लाइव चर्चा/सवाल पूछने की सुविधा मिलती है. |
| इंडस्ट्री के बारे में विशेषज्ञता | स्टैंडर्ड बनाने वाली संस्थाओं के साथ काम करने वाली Chrome की टीम के पास, विज्ञापन नेटवर्क के बारे में ज़रूरी जानकारी नहीं है. इस जानकारी की मदद से, निजता और उपयोगिता को सही तरीके से संतुलित किया जा सकता है. | हम समझते हैं कि हमारे पास एक बड़ी ज़िम्मेदारी है. इसे सही तरीके से पूरा करने के लिए, हम आपके सुझाव, राय या शिकायतों का इंतज़ार कर रहे हैं. हम निजता और असरदारता, दोनों को डिज़ाइन की ज़रूरी शर्तें मानते हैं. वेब के लिए प्राइवसी सैंडबॉक्स पर काम करने वाली टीम में, विज्ञापन नेटवर्क में काम करने का कुल अनुभव सैकड़ों सालों का है. |
काम का कॉन्टेंट और विज्ञापन दिखाना
विषय
| सुझाव, राय या शिकायत की थीम
(आम तौर पर होने की वजह से रैंक) |
सवालों और समस्याओं की खास जानकारी | Chrome का जवाब |
| अलग-अलग तरह के हिस्सेदारों के लिए फ़ायदेमंद होना | साइटों के लिए, ट्रैफ़िक के लेवल या उनके कॉन्टेंट के हिसाब से, बनाई गई वैल्यू और उसकी डिस्ट्रिब्यूशन को लेकर चिंता जताई गई है. | टेस्टिंग के ज़रिए, एपीआई के काम करने के तरीके के बारे में पता लगाया जाएगा. Chrome को उम्मीद है कि टेस्ट के नतीजों के आधार पर, टैक्सोनॉमी और अन्य पैरामीटर बेहतर होंगे. टैक्सोनॉमी या पैरामीटर में बदलाव करने के लिए, ऐसा हो सकता है कि आपको पुराने सिस्टम के साथ काम करने वाले बदलाव न करने पड़ें. साथ ही, Chrome को उम्मीद है कि तीसरे पक्ष की कुकी के बंद होने के बाद भी, सुझाव/राय/शिकायत से Topics API को बेहतर बनाने में मदद मिलेगी. |
| टैक्सनॉमी | इंडस्ट्री के हिस्सेदार, टैक्सोनॉमी को बनाने में अपनी भूमिका निभाना चाहते हैं. | Chrome, टैक्सोनॉमी के लिए इनपुट पाने के लिए हमेशा तैयार रहता है. Chrome, टैक्सोनॉमी में बदलाव करने के लिए, गवर्नेेंस मॉडल के बारे में सुझाव, राय या टिप्पणियां सुनने के लिए उत्सुक है. साथ ही, यह भी जानना चाहता है कि इंडस्ट्री के अन्य निकाय, लंबे समय तक टैक्सोनॉमी को डेवलप और मैनेज करने में कैसे ज़्यादा सक्रिय भूमिका निभा सकते हैं. |
| ब्राउज़िंग इतिहास काफ़ी नहीं है | अगर उपयोगकर्ता के पास हाल ही के हफ़्ते के लिए पांच विषय बनाने के लिए ज़रूरत के मुताबिक ब्राउज़िंग इतिहास नहीं है, तो कॉल करने वाले व्यक्ति को पिछले हफ़्तों में देखे गए विषयों को दिखाने का सुझाव | हमारे मौजूदा डिज़ाइन के लिए, इन्हें रैंडम तौर पर चुना जाता है. हम पिछले विषयों के साथ इस विषय के संबंध की जांच करेंगे और यह देखेंगे कि इसे शामिल किया जा सकता है या नहीं. हालांकि, इस विषय के साथ निजता से जुड़ी ऐसी बातें हो सकती हैं जिन पर ध्यान देने की ज़रूरत है. |
| किसी पब्लिशर की ओर से Topics को कॉल करना | क्या तीसरे पक्ष की सेवा देने वाली कंपनी, पब्लिशर के साथ Topics शेयर कर सकती है? | हां, हमें उम्मीद है कि Topics का इस्तेमाल इसी तरह किया जाएगा. |
| संभावित अटैक वेक्टर | ग़ैर-ज़रूरी विषयों की पहचान करना | Chrome ने अपने प्लैटफ़ॉर्म का इस्तेमाल करने वाले कई लोगों के सुझावों के आधार पर, विषयों को फ़िल्टर करने और नॉइज़ को शामिल करने का विकल्प चुना है. ये फ़ैसले निजता को ध्यान में रखकर लिए गए थे. इनसे, जानकारी का ऐक्सेस सिर्फ़ उन लोगों तक सीमित किया जा सकता है जिनके पास इस तरह की जानकारी का ऐक्सेस नहीं होता. साथ ही, उपयोगकर्ताओं को यह भी बताया जा सकता है कि वे इस जानकारी को स्वीकार नहीं करते. हम जानते हैं कि इन फ़ैसलों से कुछ समस्याएं आ सकती हैं. जैसे, यहां बताए गए अटैक वेक्टर. हालांकि, हमारा आकलन है कि निजता से जुड़े फ़ायदे, संभावित जोखिमों से ज़्यादा हैं. हम इस फ़ैसले पर सार्वजनिक तौर पर चर्चा करने के लिए तैयार हैं. |
| ऑरिजिन ट्रायल की ज़रूरी शर्तें | क्या यह पता लगाया जा सकता है कि कोई उपयोगकर्ता, ऑरिजिन ट्रायल की ज़रूरी शर्तें पूरी करता है या नहीं? | हो सकता है कि ब्राउज़र की सेटिंग या अन्य वजहों से, किसी उपयोगकर्ता के लिए ऑरिजिन ट्रायल की सुविधा उपलब्ध न हो. भले ही, वह किसी ऐसे वेब पेज पर जा रहा हो जो मान्य ट्रायल टोकन उपलब्ध कराता हो और उसका ब्राउज़र उस ग्रुप में शामिल हो जिसके लिए ट्रायल की सुविधा चालू है.
इसलिए, किसी ऑरिजिन ट्रायल की सुविधा का इस्तेमाल करने से पहले, यह पता लगाने के लिए हमेशा सुविधा की पहचान की जानी चाहिए कि वह उपलब्ध है या नहीं. |
| परफ़ॉर्मेंस पर असर | Topics की सुविधा से जुड़ी ओवरहेड और इंतज़ार के समय से जुड़ी समस्याएं | हम सुझाव, राय या टिप्पणी मांग रहे हैं. इनसे हमें, महंगे और धीमे एक्स-ऑरिजिन iframes से बचने के तरीकों के बारे में पता चलेगा. साथ ही, Topics API को अलग करने के प्रस्ताव के बारे में भी पता चलेगा, ताकि विषयों को पाने से ब्राउज़िंग की स्थिति में बदलाव न हो. |
| Topics API की सुविधाओं को अलग-अलग करना | एपीआई के तीन अलग-अलग पहलुओं पर ज़्यादा कंट्रोल देना | हम इस मामले को समझते हैं. साथ ही, हमने GitHub में इस समस्या को हल करने का एक संभावित तरीका भी सुझाया है. फ़िलहाल, हम इस सुविधा को बनाने के बारे में, कम्यूनिटी से ज़्यादा सुझाव और राय का इंतज़ार कर रहे हैं. चल रही चर्चा यहां देखें. |
| डेटा की कैटगरी तय करने की सुविधा की टाइमलाइन और दस्तावेज़ | डेवलपर ने क्लासिफ़ायर के बारे में ज़्यादा जानकारी का अनुरोध किया है. | हमने क्लासिफ़ायर के बारे में ज़्यादा जानकारी यहां सार्वजनिक तौर पर दी है.
साथ ही, यहां भी और यहां. |
| उपयोगकर्ता कंट्रोल और सुरक्षा | कुछ विषय, संवेदनशील ग्रुप के लिए प्रॉक्सी हो सकते हैं. साथ ही, खराब नतीजों से बचने के लिए, उपयोगकर्ताओं को ज़्यादा कंट्रोल की ज़रूरत होती है. | Topics, उपयोगकर्ता के कंट्रोल और पारदर्शिता के लिए एक अहम कदम है. उपयोगकर्ता, विषयों से ऑप्ट आउट कर पाएंगे. साथ ही, उन्हें असाइन किए गए विषयों की समीक्षा कर पाएंगे, विषयों को हटा पाएंगे, और यह समझ पाएंगे कि किसी पेज पर कौनसी कंपनियां उनके विषयों से इंटरैक्ट कर रही हैं. इसके अलावा, उपयोगकर्ता अपने ब्राउज़िंग इतिहास को मिटाकर भी, अपने विषयों पर असर डाल सकते हैं. हम उपयोगकर्ताओं के लिए ज़्यादा बेहतर कंट्रोल के बारे में लगातार चर्चा करते रहेंगे. जैसे, डेवलपर के सुझाव. हालांकि, हमें यह पक्का करना होगा कि इस गड़बड़ी से जुड़ी समस्याओं को ठीक करने के लिए, असल में जोखिम कम हो जाएं. उदाहरण के लिए, सिर्फ़ 'विदेशी भाषा सीखना' विषय को हटाने से, उपयोगकर्ता पूरी तरह से सुरक्षित नहीं रहेगा. ऐसा इसलिए, क्योंकि ब्राउज़िंग इतिहास से विषय जनरेट करने वाली वेबसाइटों को नहीं हटाया गया है. |
| prebid.js वाली साइटों पर विषयों का इस्तेमाल करना | क्या Topics API का इस्तेमाल, prebid.js वाली वेबसाइटों पर किया जा सकता है? | इसका जवाब हां है. ज़्यादा जानकारी यहां दी गई है. |
| सुझाव विजेट में Topics API का इस्तेमाल | क्या सुझाए गए विजेट (उदाहरण के लिए, Outbrain) में Topics API का इस्तेमाल किया जा सकता है | एपीआई को कॉल करने के बाद, हम खोजे गए विषयों के इस्तेमाल के उदाहरणों को सीमित नहीं करते. यह हर डेवलपर की डेटा नीति पर निर्भर करेगा. |
| निजता / नीति | कॉल करने वाले के हिसाब से जवाबों को फ़िल्टर करने के मकसद के बारे में सवाल. साथ ही, यह भी सवाल कि क्या तीसरे पक्ष, कॉल करने वाले किसी भी व्यक्ति के साथ अपने विषय शेयर करेंगे. | Chrome ने इस डिज़ाइन को इसलिए चुना है, ताकि जानकारी का ऐक्सेस सिर्फ़ उन लोगों तक सीमित हो जो इस तरह की जानकारी ऐक्सेस नहीं कर सकते. यह फ़ैसला, Chrome के इकोसिस्टम में शामिल कई लोगों के सुझावों के आधार पर लिया गया है. हालांकि, पब्लिशर और तीसरे पक्ष, खुद तय कर सकते हैं कि वे अपनी साइट पर किन पक्षों के साथ कौनसी जानकारी शेयर करेंगे. अगर वे इस तरह का डेटा शेयर करते हैं, तो Chrome उन्हें अपने उपयोगकर्ताओं को इस बारे में साफ़ तौर पर बताने और उन्हें कंट्रोल देने का सुझाव देता है. |
| ग़ैर-ज़रूरी सिग्नल | 5% समय के लिए किसी विषय के बारे में जानकारी देने से, बहुत ज़्यादा ग़लत सिग्नल या ग़ैर-ज़रूरी जानकारी मिल सकती है. | उपयोगकर्ता की निजता की सुरक्षा के लिए, ग़ैर-ज़रूरी कॉन्टेंट को हटाना एक अहम तरीका है. जांच के दौरान, ग़ैर-ज़रूरी कॉन्टेंट के लेवल और विषयों के काम के होने के बीच के अंतर का पता लगाया जाएगा. |
FLEDGE
| सुझाव, राय या शिकायत की थीम
(आम तौर पर होने की वजह से रैंक) |
सवालों और समस्याओं की खास जानकारी | Chrome का जवाब |
| टेस्ट कोऑर्डिनेशन | परफ़ॉर्मेंस और रेवेन्यू पर पड़ने वाले असर की जांच करना | WICG की सार्वजनिक मीटिंग में, FLEDGE की परफ़ॉर्मेंस और ओरिजिन ट्रायल के साथ-साथ सामान्य रूप से उपलब्ध होने के दौरान, हम इकोसिस्टम की टेस्टिंग को कैसे बेहतर बना सकते हैं, इस बारे में ज़्यादा से ज़्यादा चर्चा की जा रही है. |
| FLEDGE के लिए भरोसेमंद सर्वर | भरोसेमंद सर्वर की जांच कब से की जा सकेगी? | हमें आपका सुझाव/राय पसंद आई. हम इस बारे में ज़्यादा जानकारी देने के लिए लगातार काम कर रहे हैं, ताकि हम FLEDGE में भरोसेमंद सर्वर के इस्तेमाल के लिए, ज़्यादा जानकारी शेयर कर सकें. |
| प्रोटोकॉल को स्टैंडर्ड बनाना | क्या एसएसपी और डीएसपी के बीच डेटा भेजने के लिए, एक सामान्य प्रोटोकॉल होगा, जैसे कि दिलचस्पी के ग्रुप के लिए सामान्य लेबल? | हम स्पेसिफ़िकेशन को स्टैंडर्ड बनाने के बारे में डीएसपी, एसएसपी, और विज्ञापनों के बड़े नेटवर्क से सुझाव, राय या शिकायतें पाने के लिए तैयार हैं. हमारा सुझाव है कि शुरुआती टेस्टिंग के लिए, सीधे अपने टेस्टिंग पार्टनर के साथ काम करें, क्योंकि वे अलग-अलग तरीकों के साथ प्रयोग कर रहे हैं. हम विज्ञापन ट्रेड संगठनों के साथ काम करना जारी रखेंगे और उन्हें बढ़ावा देंगे, ताकि वे स्टैंडर्ड बनाने में मदद कर सकें. ऐसा तब किया जाएगा, जब यह उनकी सदस्य कंपनियों के लिए फ़ायदेमंद हो. |
| फ़्रीक्वेंसी कैपिंग | कैंपेन और विज्ञापन ग्रुप में, हर उपयोगकर्ता के लिए फ़्रीक्वेंसी कंट्रोल. | FLEDGE, ऑन-डिवाइस नीलामियों और संदर्भ के हिसाब से टारगेटिंग / ब्रैंडिंग कैंपेन के लिए भी फ़्रीक्वेंसी कैपिंग की सुविधा देगा. शेयर किए गए स्टोरेज और साइट के हिसाब से तय किए गए कैप का इस्तेमाल, फ़्रीक्वेंसी कैपिंग के अन्य कंट्रोल के लिए भी किया जा सकता है. |
| FLEDGE का परफ़ॉर्मेंस पर असर | FLEDGE नीलामी में, कंप्यूटेशनल तौर पर ज़्यादा काम करने वाले बिडर | Chrome, साइट की परफ़ॉर्मेंस पर पड़ने वाले संभावित असर के बारे में डेवलपर के साथ लगातार चर्चा कर रहा है. Chrome, टेस्टिंग के दौरान ज़्यादा जानने के लिए तैयार है. |
| अन्य सुविधाओं के साथ FLEDGE को टेस्ट करना | Attribution Reporting API और FLEDGE की इवेंट-लेवल रिपोर्ट एक साथ कैसे काम करेंगी? | इस बारे में हाल ही में WICG/conversion-measurement-api कॉल में चर्चा की गई थी. इस कॉल के मिनटों की ज़्यादा जानकारी के लिए, यहां क्लिक करें.
मीटिंग की खास जानकारी यह है कि फ़ेंस्ड फ़्रेम विज्ञापन रिपोर्टिंग के मौजूदा डिज़ाइन की मदद से, फ़ेंस्ड फ़्रेम में जनरेट किए गए आईडी को संदर्भ के हिसाब से जानकारी के साथ जोड़ा जा सकता है. इसलिए, फ़ेंस किए गए फ़्रेम में जनरेट की गई इवेंट-लेवल की रिपोर्ट, सर्वर पर मौजूद उसी संदर्भ से जुड़ी जानकारी से जुड़ी जा सकती हैं. इसके लिए, एक के बजाय दो सर्वर-साइड जॉइन का इस्तेमाल किया जाएगा. |
| इंप्रेशन की गिनती | खरीदारों और सेलर के बीच इंप्रेशन की गिनती करने के लिए किस तरीके का इस्तेमाल किया जाना चाहिए या किया जा सकता है | FLEDGE API, नीलामी के दौरान सेलर और खरीदार के बीच, तरीके को अलाइन करने की सुविधा पहले से ही देता है. हमें इस बारे में सुझाव मिले हैं कि इस सुविधा को लागू करने के लिए, दूसरे तरीके अपनाए जा सकते हैं. हालांकि, इन सुझावों में यह नहीं बताया गया है कि हमारा मौजूदा डिज़ाइन, इस पारिस्थितिकी तंत्र के लिए क्यों काम नहीं कर सकता. |
| एक से ज़्यादा विज्ञापन दिखाना | क्या किसी फ़ेंस किए गए फ़्रेम में, एक नीलामी में एक से ज़्यादा विज्ञापन दिखाए जा सकते हैं | फ़िलहाल, कॉम्पोनेंट विज्ञापनों की मदद से ऐसा किया जा सकता है. इसे कॉम्पोनेंट नीलामियों से न जोड़ें. ऐसा करने के लिए, सभी विज्ञापनों को एक ही इंटरेस्ट ग्रुप में होना चाहिए. |
| "सेलर की तय की गई ऑडियंस (एसडीए)" स्पेसिफ़िकेशन और FLEDGE | क्या FLEDGE, विज्ञापन अनुरोधों पर एसडीए से प्रोफ़ाइल बनाने से खरीदारों को रोकने का एक तरीका बन सकता है? | FLEDGE को इस तरह से डिज़ाइन किया गया है कि जब पब्लिशर को पहले से पता हो कि उसके वेबसाइट पर आने वाले लोग किस एसडीए में हैं और टारगेटिंग एक ही साइट पर की जा रही है, तब ऐसी जानकारी लीक न हो जो काम की न हो. अगर FLEDGE में मौजूद सभी सुरक्षा उपायों के साथ एसडीए पर खरीदारी करना ज़रूरी है, तो एक समाधान यह हो सकता है कि सेलर, डिवाइस पर होने वाली नीलामी में एसडीए लेबल पास करे. साथ ही, बाय-साइड विज्ञापन टेक्नोलॉजी, अपना इंटरेस्ट ग्रुप बनाए, जिसका बिडिंग लॉजिक "मुझे ऑडियंस X खरीदनी है" कहता हो. |
| डॉलर के अलावा अन्य मुद्राओं के लिए सहायता | डॉलर के अलावा अन्य मुद्राओं में FLEDGE को टेस्ट करने की सुविधा | हमें इस कॉलआउट की सराहना करते हुए खुशी हो रही है. हमने सुविधा के अनुरोधों के बैकलॉग में, अन्य मुद्रा के लिए भी सहायता जोड़ी है. हमें उम्मीद है कि यह सुविधा जल्द ही उपलब्ध हो जाएगी. |
| दिलचस्पी न रखने वाले ग्रुप को टारगेटिंग से बाहर रखने की सुविधा | नेगेटिव आईजी टारगेटिंग के लिए एपीआई: सिर्फ़ तब विज्ञापन दिखाना, जब कोई उपयोगकर्ता किसी आईजी से न जुड़ा हो. | GitHub पर मौजूद समस्या में, इस बारे में चल रही चर्चा. इसमें, इस समस्या को हल करने के लिए कुछ सुझाए गए विकल्प भी शामिल हैं. |
| FLEDGE में एक से ज़्यादा एसएसपी | FLEDGE में कई लेवल की नीलामियां लागू करते समय, Google को फ़ायदा पहुंचाने का जोखिम | FLEDGE में कई एसएसपी के लिए सहायता जोड़ी गई, ताकि सभी को एक जैसी सुविधाएं मिल सकें. Google ने जवाबदेही के तहत यह वादा किया है कि वह प्राइवसी सैंडबॉक्स के प्रस्तावों को इस तरह से डिज़ाइन, डेवलप या लागू नहीं करेगा कि अपने विज्ञापन प्रॉडक्ट और सेवाओं को प्राथमिकता देकर, प्रतिस्पर्धा को गलत तरीके से प्रभावित किया जा सके. Google इस बात को गंभीरता से लेता है. साथ ही, वह इस टेक्नोलॉजी के खास पहलुओं को लेकर, हिस्सेदारों की किसी भी चिंता पर चर्चा करने के लिए तैयार है. जानकारी के लिए, Chrome ने कॉम्पोनेंट की नीलामी के तरीके के बारे में सार्वजनिक तौर पर यहां जानकारी दी है. |
डिजिटल विज्ञापनों की परफ़ॉर्मेंस का आकलन करना
एट्रिब्यूशन रिपोर्टिंग (और अन्य एपीआई)
| सुझाव, राय या शिकायत की थीम
(आम तौर पर होने की वजह से रैंक) |
सवालों और समस्याओं की खास जानकारी | Chrome का जवाब |
| मल्टी-टच एट्रिब्यूशन | मल्टी-टच एट्रिब्यूशन के लिए सहायता का अनुरोध करने वाले पब्लिशर | मल्टी-टच एट्रिब्यूशन के मौजूदा तरीकों के लिए, अलग-अलग वेबसाइटों पर उपयोगकर्ता के इंप्रेशन (और इसलिए पहचान) को एक साथ जोड़ना ज़रूरी है. इसलिए, इस सुविधा का मौजूदा वर्शन, Privacy Sandbox के लक्ष्यों के मुताबिक नहीं है. Privacy Sandbox का मकसद, क्रॉस-साइट ट्रैकिंग के बिना विज्ञापनों के इस्तेमाल के मुख्य उदाहरणों को बेहतर बनाना है. कुछ मामलों में, अलग-अलग उपयोगकर्ताओं को ट्रैक किए बिना भी क्रेडिट असाइन किया जा सकता है. उदाहरण के लिए, अलग-अलग प्राथमिकताओं का इस्तेमाल करके. |
| नॉइज़ जनरेशन | रिपोर्ट में शोर के लेवल के बारे में सवाल | हमारे शुरुआती एक्सपेरिमेंट में, डेवलपर अपनी इप्सिलॉन वैल्यू सेट कर सकते हैं, ताकि वे यह देख सकें कि ग़ैर-ज़रूरी डेटा के लेवल के आधार पर रिपोर्ट में क्या बदलाव होता है. फ़िलहाल, डेवलपर epsilon=64 तक की वैल्यू चुन सकते हैं. हमने ऐसा खास तौर पर इसलिए किया है, ताकि डेवलपर आसानी से एपीआई की जांच कर सकें और हमें सही एप्सिलॉन वैल्यू के बारे में सुझाव/राय दे सकें.
हमने इस तरह के सुझाव, राय या शिकायत के लिए, सार्वजनिक तौर पर अनुरोध भी किया है. |
| टेस्ट कोऑर्डिनेशन | क्या स्थानीय टेस्टिंग टूल का इस्तेमाल ओटी के लिए किया जा सकता है? | हां, ओटी के दौरान लोकल टेस्टिंग टूल का इस्तेमाल किया जा सकता है. तीसरे पक्ष की कुकी उपलब्ध होने तक, डीबग रिपोर्ट के साथ लोकल टेस्टिंग टूल का इस्तेमाल किया जा सकता है. |
| क्वेरी एर्गोनॉमिक्स | कुंजियों के एग्रीगेट के लिए क्वेरी करने की सुविधा चालू करना | हम इस बात से सहमत हैं कि इससे एपीआई को इस्तेमाल करना आसान हो जाता है. साथ ही, निजता को कोई नुकसान नहीं पहुंचता या बहुत कम नुकसान पहुंचता है. हम एक प्रस्ताव बनाएंगे और देखेंगे कि क्या इस बात पर सभी सहमत हैं कि इसे आगे बढ़ाया जाना चाहिए. |
| छोटी साइटों के लिए कम सटीक डेटा | छोटी साइटों या कैंपेन को कम सटीक डेटा मिल सकता है. | Chrome को पता है कि ग़ैर-ज़रूरी डेटा को हटाकर निजता बनाए रखने की सुविधा, छोटे डेटा स्लाइस पर ज़्यादा असर डालती है. हालांकि, ऐसा हो सकता है कि लंबे समय तक डेटा इकट्ठा करने जैसे तरीकों से इस समस्या को हल किया जा सके. यह भी साफ़ नहीं है कि बहुत कम डेटा स्लाइस (जैसे, एक या दो खरीदारी) के आधार पर निकाले गए नतीजे, विज्ञापन देने वालों के लिए काम के हैं या नहीं. ऑरिजिन ट्रायल के दौरान, Chrome टेस्टर को निजता और शोर से जुड़े कई पैरामीटर के साथ प्रयोग करने की सुविधा का फ़ायदा उठाने के लिए बढ़ावा देता है. इससे वे इस समस्या के बारे में ज़्यादा सटीक सुझाव/राय/शिकायत दे सकते हैं. |
गुप्त ट्रैकिंग को सीमित करना
यूज़र-एजेंट रिडक्शन
| सुझाव, राय या शिकायत की थीम
(आम तौर पर होने की वजह से रैंक) |
सवालों और समस्याओं की खास जानकारी | Chrome का जवाब |
| बॉट से सुरक्षा | UA-R का बॉट से सुरक्षा करने की सुविधा पर असर | हमें आपका सुझाव/राय/शिकायत पसंद आई. हम आने वाले समय में अपने डिज़ाइन को बेहतर बनाने के लिए, बॉट से सुरक्षा के तरीकों के बारे में जानकारी इकट्ठा कर रहे हैं. |
| डिप्लॉयमेंट डिपेंडेंसी | स्ट्रक्चर्ड उपयोगकर्ता एजेंट (एसयूए) के डिप्लॉयमेंट की डिपेंडेंसी को हल करना | हमने "चौथा चरण" लॉन्च कर दिया है. इसे माइनर वर्शन का वर्शन कम करना भी कहा जाता है. इस चरण में, Chrome के 101 और उसके बाद के वर्शन का इस्तेमाल करने वाले 100% लोगों के लिए, माइनर वर्शन को कम किया गया है. अपडेट यहां देखें. |
User-Agent Client Hints
| सुझाव, राय या शिकायत की थीम
(आम तौर पर होने की वजह से रैंक) |
सवालों और समस्याओं की खास जानकारी | Chrome का जवाब |
| इस्तेमाल किए जा सकने वाले सभी सुझावों की सूची बनाना | किसी ब्राउज़र के लिए, काम करने वाले सभी हिंट जानने के लिए प्रोग्राम के हिसाब से काम करने वाले तरीके का इस्तेमाल करना. | हमें आपके सुझाव/राय/शिकायत/राय देने के लिए धन्यवाद. हम इस सुविधा के अनुरोध की समीक्षा कर रहे हैं. हमें यह जानना है कि क्या यह इस्तेमाल का सामान्य उदाहरण है. |
| UA-CH बनाम User-Agent हेडर की सुविधा | UA-CH, User-Agent हेडर की तुलना में ज़्यादा सख्त है. User-Agent हेडर में, rfc7231 के मुताबिक ज़्यादा विकल्प मिलते हैं. | Chrome, UA-CH हेडर की खास बातों को UA स्ट्रिंग की सुविधाओं के मुकाबले एक अहम सुधार के तौर पर देखता है. यह सुधार, अलग-अलग ब्राउज़र के साथ काम करने की सुविधा और उपयोगकर्ता की निजता की सुरक्षा, दोनों के लिहाज़ से अहम है. ऐसा, ज़्यादा एन्ट्रॉपी वाले आइडेंटिफ़ायर को मनमुताबिक जोड़ने से रोककर किया जाता है.
अगर कोई और भी इस समस्या से परेशान है और उसे इस बारे में सुझाव/राय देनी है या शिकायत करनी है, तो वह इस समस्या को 'समस्या का हल नहीं मिला' के तौर पर मार्क कर सकता है. |
| UA-CH: धोखाधड़ी / गलत इस्तेमाल से जुड़ी समस्याएं | UA-CH की मदद से काम करने वाली कुछ सुविधाएं: क्लिक रीडायरेक्ट ट्रैकर और धोखाधड़ी वाले क्लिक. | हमारी टीम, धोखाधड़ी रोकने और मेज़रमेंट से जुड़े हिस्सेदारों के साथ इन संभावित समस्याओं की जांच कर रही है. |
| परफ़ॉर्मेंस | पहले पेज लोड होने पर, Critical-CH के ज़रिए सुझाव मिलने में लगने वाले समय को लेकर समस्याएं हैं. | Chrome, परफ़ॉर्मेंस को बेहतर बनाने के तरीकों की जांच कर रहा है. |
Gnatcatcher (काम जारी है)
| सुझाव, राय या शिकायत की थीम
(आम तौर पर होने की वजह से रैंक) |
सवालों और समस्याओं की खास जानकारी | Chrome का जवाब |
| इंतज़ार के समय से जुड़ी समस्याएं | अतिरिक्त हॉप जोड़ने से, इंतज़ार का समय बढ़ सकता है | हम दो हॉप वाले प्रॉक्सी का इस्तेमाल करने पर विचार कर रहे हैं. साथ ही, उपयोगकर्ता की निजता और इंतज़ार के समय के बीच सही संतुलन बनाने के तरीकों को एक्सप्लोर कर रहे हैं. हम सुझाव, शिकायत या राय के लिए हमेशा तैयार हैं. साथ ही, हमें W3C के फ़ोरम में इस बारे में आगे की चर्चा करने में खुशी होगी. |
| धोखाधड़ी और बॉट से सुरक्षा | धोखाधड़ी और बॉट से सुरक्षा पर असर, कम विकसित देशों में भी | सुरक्षा एक मुख्य ज़रूरत है, क्योंकि हम उपयोगकर्ता की निजता को बेहतर बनाने के लिए काम करते हैं. जैसे, आईपी पतों को प्रॉक्सी करना. भरोसेमंद कंपनियों के साथ पार्टनरशिप वाली दो हॉप प्रॉक्सी, उपयोगकर्ता की निजता को सुरक्षित रखती है. हम उपयोगकर्ताओं का भरोसा जीतने के लिए, नए सिग्नल के आइडिया भी इकट्ठा कर रहे हैं. |
| निजता से जुड़े स्थानीय कानूनों का पालन करना | देश के लेवल पर जियो डेटा की रिपोर्टिंग करने से, ज़्यादा सटीक स्थानीय नियमों का पालन करना मुश्किल हो जाता है | हमने अपने सुझाए गए सिद्धांतों को सार्वजनिक तौर पर पोस्ट किया है. इनमें ऐसे संभावित तरीके शामिल हैं जिनसे वेबसाइटों को स्थानीय ज़रूरी शर्तों का पालन करने में मदद मिलेगी. |
अलग-अलग साइटों पर निजता की सीमाओं को बेहतर बनाना
पहले पक्ष के सेट
| सुझाव, राय या शिकायत की थीम
(आम तौर पर होने की वजह से रैंक) |
सवालों और समस्याओं की खास जानकारी | Chrome का जवाब |
| अलग-अलग तरह के हिस्सेदारों के लिए फ़ायदेमंद होना | छोटे और बड़े पब्लिशर पर एफ़पीएस (फ़्रेम प्रति सेकंड) के असर की तुलना | Privacy Sandbox का मुख्य मकसद, मौजूदा तरीकों को ऐसे समाधानों से बदलकर उपयोगकर्ता की निजता को बेहतर बनाना है जो क्रॉस-साइट ट्रैकिंग मैकेनिज़्म पर निर्भर नहीं होते. हम चाहते हैं कि ये समाधान, अलग-अलग तरह के और अलग-अलग साइज़ के हिस्सेदारों के लिए ज़्यादा से ज़्यादा काम के हों. इन समाधानों को बेहतर बनाने के बारे में, खास और काम के सुझाव या राय देने के लिए हम आपका स्वागत करते हैं. हमें उम्मीद है कि कम्यूनिटी की चर्चा और टेस्टिंग के साथ, ये समाधान बेहतर होते रहेंगे. |
| निजता को बेहतर बनाना | एक ही सेट में बहुत ज़्यादा साइटें होने पर, तीसरे पक्ष की कुकी से मिलते-जुलते नतीजे मिल सकते हैं | हमें आपका सुझाव/राय पसंद आई. हम इस बात का आकलन कर रहे हैं कि सही सीमा क्या हो सकती है. साथ ही, हम उपयोगकर्ताओं और डेवलपर, दोनों को इस तरह के सिग्नल या इलाज देने की कोशिश कर रहे हैं कि वे इस सीमा के पूरी होने पर समझ सकें. फ़िलहाल, हमारे पास कोई खास प्रस्ताव नहीं है. हालांकि, हमें उम्मीद है कि हम जल्द ही आपके साथ शेयर करेंगे. |
| एफ़पीएस (फ़्रेम प्रति सेकंड) के लिए, नेटवर्क के साथ काम करने की सुविधा | निजता सीजी के बाहर एफ़पीएस को डेवलप करने के लिए, सहायता और समस्याओं का कलेक्शन | हम चाहते थे कि पहले पक्ष के सेट का प्रस्ताव, PrivacyCG में ही बना रहे. हालांकि, हम WICG में इस प्रस्ताव को आगे बढ़ाने के लिए उत्साहित हैं. हमें फ़र्स्ट पार्टी सेट और उनके इस्तेमाल के उदाहरणों के बारे में लगातार चर्चा करने के लिए, कई लोगों से मिले समर्थन से भी काफ़ी हौसला मिला. Google, ऐसे समाधान ढूंढने के लिए लगातार काम कर रहा है जिनसे वेब को इस तरह आगे बढ़ाया जा सके कि उपयोगकर्ता की निजता को सुरक्षित रखा जा सके और उसका सम्मान किया जा सके. |
| ब्राउज़र इंटरऑपरेबिलिटी | अन्य ब्राउज़र में लागू करना | हम जानते हैं कि डेवलपर के लिए, ब्राउज़र के साथ काम करने की सुविधा का होना ज़रूरी है. इसलिए, हम एफ़पीएस को स्टैंडर्ड बनाने के लिए, दूसरे ब्राउज़र के साथ मिलकर काम करते रहेंगे. |
| निजता नीति से जुड़ी सामान्य ज़रूरी शर्तें | सभी प्रॉडक्ट और अधिकार क्षेत्रों के लिए एक ही निजता नीति को बनाए रखना मुश्किल है. | Chrome अब भी हमारी नीति की ज़रूरी शर्तों को तय कर रहा है. साथ ही, इस सुझाव को ध्यान में रखेगा. |
Fenced Frames API
| सुझाव, राय या शिकायत की थीम
(आम तौर पर होने की वजह से रैंक) |
सवालों और समस्याओं की खास जानकारी | Chrome का जवाब |
| दस्तावेज़ का अनुरोध | सैंडबॉक्स किए गए iframe से अंतर | आपके सुझाव और राय के लिए धन्यवाद. फ़िलहाल, GitHub पर इस बारे में चर्चा चल रही है. हमें उम्मीद है कि इस अनुरोध के बारे में पूरी जानकारी मिल जाएगी, ताकि हम उसका पूरी तरह से आकलन कर सकें. सार्वजनिक चर्चा यहां उपलब्ध है. |
| अलग-अलग एपीआई के साथ काम करने की सुविधाएं | फ़ेंस किए गए फ़्रेम में एट्रिब्यूशन रिपोर्टिंग के लिए डिफ़ॉल्ट सहायता | हम फ़ेंस किए गए फ़्रेम के "ओपेक-विज्ञापन मोड" में, एट्रिब्यूशन रिपोर्टिंग एपीआई को डिफ़ॉल्ट रूप से अनुमति देने के प्रस्ताव पर सुझाव/राय मांग रहे हैं. जिन डेवलपर को यह सुविधा काम की लगती है उन्हें इस बारे में ज़रूर बताना चाहिए. |
Shared Storage API
| सुझाव, राय या शिकायत की थीम
(आम तौर पर होने की वजह से रैंक) |
सवालों और समस्याओं की खास जानकारी | Chrome का जवाब |
| डेटा की सीमाएं | क्या हर पार्टीशन में कितना डेटा सेव किया जा सकता है, इस पर कोई पाबंदी होगी? | हां, इसकी सीमाएं होंगी. ज़्यादा जानकारी के लिए, GitHub पर मौजूद समस्या देखें. हमें स्टोरेज कोटा की ज़रूरत होगी. हमारा मौजूदा प्रस्ताव है कि हर एंट्री का साइज़ 4 केबी से ज़्यादा न हो. साथ ही, हर की और वैल्यू में 1024 char16_t वर्ण से ज़्यादा न हों. हर ऑरिजिन के लिए, एंट्री की संख्या 10,000 से ज़्यादा नहीं होनी चाहिए. साथ ही, यह भी ज़रूरी है कि ऑरिजिन की क्षमता पूरी होने पर, अतिरिक्त एंट्री को कमिट न किया जाए. हम यहां बताई गई सीमाओं के बारे में आपके सुझाव, राय या शिकायत चाहते हैं. |
| उपयोगकर्ता पारदर्शिता | डेटा सोर्स के लिए उपयोगकर्ता पारदर्शिता बनाम डेटा के इस्तेमाल के लिए उपयोगकर्ता पारदर्शिता | हमें आपका सुझाव/राय पसंद आई. हमें लगता है कि यह एक अच्छा तरीका है और इस पर काम किया जा सकता है. खास तौर पर, हम यह आकलन कर रहे हैं कि क्या ऐसा किया जा सकता है कि उपयोगकर्ताओं को पूरी पारदर्शिता के साथ जानकारी दी जा सके. |
सीएचआईपीएस
| सुझाव, राय या शिकायत की थीम
(आम तौर पर होने की वजह से रैंक) |
सवालों और समस्याओं की खास जानकारी | Chrome का जवाब |
| इसे अपनाने में आने वाली रुकावटें | क्या CHIPS को होस्टनेम से जोड़ा जाना चाहिए? (डोमेन की ज़रूरत नहीं है) | हम ओटी से इस शर्त को हटा रहे हैं. ऐसा, ओटी में हिस्सा लेने वाले लोगों के फ़ीडबैक के आधार पर किया जा रहा है. उनके मुताबिक, इस शर्त की वजह से प्रोसेस ज़्यादा मुश्किल हो गई है और सीएचआईपीएस को अपनाने में रुकावट आ रही है.
हम इस ज़रूरी शर्त के बारे में, निजता कम्यूनिटी ग्रुप में चर्चा करेंगे. यह चर्चा, स्टैंडर्ड को तैयार करने के लिए यहां की जाएगी. |
| CHIPS के लिए विज्ञापन के इस्तेमाल के उदाहरण | क्या किसी एक साइट पर, विज्ञापन के इस्तेमाल के उदाहरणों के लिए CHIPS का इस्तेमाल किया जा सकता है? | किसी एक साइट पर उपयोगकर्ता को ट्रैक करने की अनुमति है. इस इस्तेमाल के उदाहरण को हाइलाइट करने के लिए, हमने डेवलपर के लिए लेख को अपडेट किया है. |
| पुष्टि किए गए एम्बेड | क्या CHIPS के साथ साइन-ऑन की स्थिति सेव रहती है? | फ़िलहाल, साइन इन की स्थिति सेव नहीं की जाती. हालांकि, CHIPS का इस्तेमाल इस तरह से नहीं किया जाना चाहिए. हम पुष्टि किए गए एम्बेड के इस्तेमाल के उदाहरण के बारे में जानते हैं और हम इसका समाधान ढूंढने के लिए काम कर रहे हैं. |
| टेस्ट कोऑर्डिनेशन | क्या पार्टीशन करने की जांच करने के लिए, उपयोगकर्ता को कोई और कार्रवाई करनी होगी? | जब तक ओटी टोकन मान्य है और विज़िट किए गए पेजों के हेडर में मौजूद है, तब तक यह सुविधा लोगों के लिए उपलब्ध होनी चाहिए. इसके लिए, उन्हें कोई अन्य कार्रवाई करने की ज़रूरत नहीं है |
| ब्राउज़र के साथ काम करना | आपको यह जानना है कि अन्य ब्राउज़र ने, कुकी के अलग-अलग हिस्सों वाले एट्रिब्यूट को कैसे मैनेज किया है. | Chrome, W3C जैसे सार्वजनिक स्टैंडर्ड ग्रुप के साथ काम करता रहता है. इससे, सभी ब्राउज़र पर काम करने वाले डिज़ाइन और लागू करने के तरीकों की पहचान की जा सकती है. |
FedCM
| सुझाव, राय या शिकायत की थीम
(आम तौर पर होने की वजह से रैंक) |
सवालों और समस्याओं की खास जानकारी | Chrome का जवाब |
| संभावित अटैक वेक्टर | लिंक को सजाने और समय के हिसाब से हमले करने की सुविधा से जुड़े संभावित अटैक वेक्टर | हम लोगों से सुझाव, शिकायत या राय ले रहे हैं. साथ ही, इस समस्या को हल करने के संभावित तरीकों की जांच कर रहे हैं. |
| एक से ज़्यादा आईडीपी को अनुमति देने के लिए यूज़र एक्सपीरियंस | एक बार में सिर्फ़ एक आईडीपी दिखाया जा सकता है | हमारा मानना है कि एक से ज़्यादा आईडीपी के साथ काम करना चाहिए. इसलिए, हम इस सुविधा को उपलब्ध कराने के लिए लगातार काम कर रहे हैं |
| एक्सप्रेशन | ब्राउज़र, फ़ेडरेटेड आइडेंटिटी फ़्लो का कुछ हिस्सा रेंडर करता है. इसलिए, उन सभी बारीकियों को कैप्चर करना मुश्किल होता है जिन्हें आईडीपी अपने उपयोगकर्ताओं को दिखाना चाहते हैं. | Chrome, ब्रैंडिंग को पसंद के मुताबिक बनाने की सुविधा (जैसे, लोगो, रंग) और स्ट्रिंग को पसंद के मुताबिक बनाने की सुविधा (जैसे, "इस लेख को ऐक्सेस करें" के बजाय "इससे लॉगिन करें") को शामिल करने की संभावनाएं तलाश रहा है.
Chrome इस बात को समझता है कि यह बदलाव, उपयोगकर्ताओं के लिए अच्छा है या नहीं. इसलिए, वह इस बदलाव के साथ काम करता रहेगा, ताकि ज़्यादा से ज़्यादा लोगों तक पहुंचा जा सके और उन्हें बेहतर अनुभव दिया जा सके. |
| लागू होने की शर्तें और इंटरऑपरेबिलिटी (दूसरे सिस्टम के साथ काम करना) | यह चिंता कि अन्य ब्राउज़र, FedCM को अपना या लागू नहीं करेंगे. | Chrome, FedID कम्यूनिटी ग्रुप में फ़ेडरेशन के लिए सामान्य समाधान ढूंढने के लिए, अन्य ब्राउज़र वेंडर के साथ भी काम कर रहा है. |
| साइन अप फ़्लो में निजी डेटा की ज़रूरी शर्तों को हटाने का सुझाव | (1) उपयोगकर्ता को यह बताने वाला यूज़र एक्सपीरियंस कि वह कौनसा आईडीपी चुन रहा है. इसमें यह नहीं बताया जाता कि उसका ईमेल, फ़ोटो, और नाम शेयर किया जाएगा. इससे निजता को ज़्यादा सुरक्षित रखा जा सकता है
(2) उपयोग के उदाहरण-साइन-अप, उपयोगकर्ता अनुभव और IdP से दावों के चयन में कम है |
हम इस सुझाव से सहमत हैं. साथ ही, हम इस सुझाव को उपयोगकर्ताओं के लिए और निजता के लिहाज़ से ज़्यादा बेहतर तरीके से लागू करने के तरीकों पर काम कर रहे हैं. |
| उपयोगकर्ता का आईडीपी के साथ इंटरैक्शन | जोखिम थ्रेशोल्ड पार होने पर, उपयोगकर्ता और आईडीपी के बीच सीधे इंटरैक्शन की ज़रूरत | हम इस सुझाव की जांच कर रहे हैं. |
नेटवर्क स्टेट पार्टिशनिंग
| सुझाव, राय या शिकायत की थीम
(आम तौर पर होने की वजह से रैंक) |
सवालों और समस्याओं की खास जानकारी | Chrome का जवाब |
| परफ़ॉर्मेंस | नेटवर्क स्टेटस को अलग-अलग हिस्सों में बांटने से, सीडीएन के लिए ज़्यादा संसाधनों वाले कनेक्शन बढ़ सकते हैं | हम अब भी नेटवर्क स्टेटस पार्टिशनिंग की परफ़ॉर्मेंस की विशेषताओं की जांच कर रहे हैं. इसमें, अलग-अलग संभावित की स्कीम को मेज़र करना भी शामिल है. हमने अब तक परफ़ॉर्मेंस, सुरक्षा, और निजता के बीच किसी एक को चुनने का फ़ैसला नहीं लिया है. इसके लिए, हमें ज़्यादा डेटा इकट्ठा करना होगा. |
स्पैम और धोखाधड़ी को रोकना
Trust Tokens API
| सुझाव, राय या शिकायत की थीम
(आम तौर पर होने की वजह से रैंक) |
सवालों और समस्याओं की खास जानकारी | Chrome का जवाब |
| नियमों के पालन से जुड़ा सुझाव, शिकायत या राय | लंबे समय तक काम करने की संभावना के बारे में, रेगुलेटर से साफ़ तौर पर कोई संकेत न मिलने पर, ट्रस्ट टोकन में समय और संसाधनों का निवेश करने से जुड़ी चिंताएं | हमारा मकसद ऐसी टेक्नोलॉजी बनाना है जो ईकोसिस्टम के लिए काम करे. इसके लिए, इंडस्ट्री और रेगुलेटर से मिलने वाले सुझाव और राय, इस प्रोसेस के लिए अहम हैं. हम दुनिया भर के रेगुलेटर से सलाह लेते रहेंगे, ताकि Privacy Sandbox को बेहतर बनाया जा सके. साथ ही, हम डेवलपर के लिए प्रपोज़ल उपलब्ध करा सकें. इनमें ट्रस्ट टोकन भी शामिल हैं. सभी नई टेक्नोलॉजी की तरह, कंपनियों को कानूनी ज़रूरी शर्तों के आकलन के आधार पर फ़ैसले लेने चाहिए. |
| लॉन्च का समय | GA में Trust Token कब लॉन्च होंगे? | हम privacysandbox.com पर अपनी सार्वजनिक टाइमलाइन में, डिलीवरी के लिए मौजूदा अनुमान देते हैं. GA में इसकी डिलीवरी की तारीख का फ़ैसला लेते ही, हम इसे Chrome की रिलीज़ प्रोसेस के ज़रिए सार्वजनिक तौर पर पोस्ट करेंगे. साथ ही, वेबसाइट पर टाइमलाइन को अपडेट कर देंगे. |
| ट्रस्ट टोकन बनाम अन्य | प्राइवेट ऐक्सेस टोकन जैसे अन्य टोकन को स्टैंडर्ड बनाने की प्रक्रिया के दौरान, ट्रस्ट टोकन की क्या भूमिका है | हम स्टैंडर्ड बनाने के बारे में चर्चा कर रहे हैं. हमारा लक्ष्य, हर टेक्नोलॉजी के अलग-अलग इस्तेमाल के उदाहरणों को चालू करते हुए, ज़्यादा से ज़्यादा अन्य प्रयासों के साथ अलाइन करना है. उदाहरण के लिए, ट्रस्ट टोकन और निजी ऐक्सेस टोकन, दोनों Privacy Pass प्रोटोकॉल पर निर्भर करते हैं. |
| डेटा की सीमाएं | हर पेज पर ज़्यादा से ज़्यादा दो जारीकर्ता, टोकन रिडीम करने की सुविधा को सीमित कर सकते हैं | हम लंबे समय तक काम करने वाले ऐसे विकल्पों की तलाश कर रहे हैं जिनसे कंपनियों को टोकन रिडीम करने की अनुमति दी जा सके. साथ ही, टोकन रिडीम करने के ऐक्सेस को अलग-अलग हिस्सों में बांटकर, उपयोगकर्ताओं को ज़्यादा एन्ट्रापी का जोखिम न हो. |
| ऐक्सेस से जुड़ी पाबंदियां | सिर्फ़ अनुमति पा चुके (और पुष्टि किए गए/स्पैम वाले रेफ़रर) ऑरिजिन को टोकन की मौजूदगी की पुष्टि करने और उसे रिडीम करने की अनुमति होनी चाहिए | हम यह पता लगाने की कोशिश कर रहे हैं कि टोकन कौन देख सकता है और कौन उन्हें रिडीम कर सकता है. |
| डिवाइस से जुड़ी सहायता | JavaScript रनटाइम डिपेंडेंसी, कुछ डिवाइसों पर इस्तेमाल को सीमित करती हैं. क्या टीटी की सहायता को अन्य तरह के डिवाइसों पर काम करने के लिए बढ़ाया जा सकता है? | आने वाले समय में, हम इस सुविधा को डेवलप करने पर विचार कर सकते हैं. साथ ही, हमें W3C फ़ोरम में डेवलपर से इस विषय पर ज़्यादा सुझाव, राय या शिकायत मिलना पसंद होगा. हमारे पास एचटीटीपी हेडर से ट्रिगर किए गए टोकन रिडेंप्शन के बारे में चर्चा करने के लिए, एक ओपन समस्या भी है. हम इस पर सुझाव/राय/शिकायत/राय देने का न्योता देते हैं. |
| उपयोग के उदाहरण | यह साफ़ तौर पर नहीं बताया गया है कि Trust Token का इस्तेमाल किन कामों के लिए किया जा सकता है. डेटा के इस्तेमाल के बारे में साफ़ तौर पर जानकारी न देना. | हमारा लक्ष्य धोखाधड़ी रोकने के लिए इनोवेशन को बढ़ावा देना है. साथ ही, हम यह समझते हैं कि हर कंपनी, ट्रस्ट टोकन के साथ मालिकाना हक वाली तकनीकों का इस्तेमाल कर सकती है. इसलिए, हमने ट्रस्ट टोकन के इस्तेमाल के बारे में कोई निर्देश नहीं दिया है. हालांकि, हम अपने दस्तावेज़ों में ज़्यादा उदाहरण शामिल करेंगे, ताकि एक्सपेरिमेंट करने या इसे अपनाने पर विचार करने वाले पार्टनर, शुरुआत के लिए इनका इस्तेमाल कर सकें. |
| ट्रस्ट टोकन की कवरेज | 'भरोसे के टोकन को रिडीम करने' की सुविधा से जुड़ी इस नीति को हटाने से, भरोसे के टोकन की कवरेज काफ़ी बढ़ जाएगी. | हम ओटी से सुझाव, शिकायत या राय इकट्ठा कर रहे हैं. साथ ही, आगे की कार्रवाई के बारे में फ़ैसले ले रहे हैं. |
| जारी करने वाले का ट्रस्ट | हमें ट्रस्ट टोकन जारी करने वाली वेबसाइटों पर भरोसा क्यों करना चाहिए? | जारीकर्ता बनने के लिए कोई दिशा-निर्देश नहीं हैं - कोई भी ऐसा कर सकता है. उम्मीद है कि पब्लिशर सिर्फ़ उन जारीकर्ताओं के साथ काम करेंगे जिन पर उन्हें भरोसा है. इसके अलावा, विज्ञापन नेटवर्क में शामिल अन्य मान्य पक्ष, संदिग्ध या अज्ञात आइडेंटिफ़ायर से जुड़े ट्रैफ़िक को कम कीमत पर खरीदेंगे या खरीदना बंद कर देंगे. |
| तीसरे पक्ष की एम्बेड की गई सेवाएं | क्या तीसरे पक्ष की एम्बेड की गई सेवाएं, ट्रस्ट टोकन रिडीम कर सकती हैं और/या उनका अनुरोध कर सकती हैं? | हां, तीसरे पक्ष की एम्बेड की गई सेवा, ट्रस्ट टोकन जारी और रिडीम कर सकती है. |
| कार्ड जारी करने वाली कंपनियों का नेटवर्क | अगर भरोसे के सिग्नल को अन्य कंपनियों के साथ शेयर किया जा सकता है, तो ज़्यादा फ़ायदा मिल सकता है | ट्रस्ट टोकन को लो-लेवल प्रिमिटिव के तौर पर डिज़ाइन किया गया है. साथ ही, ट्रस्ट/साख के सिग्नल शेयर करने के लिए, सहयोग करने वाले जारीकर्ता/रिडीमर इसका इस्तेमाल कर सकते हैं. |
| रखरखाव से जुड़ी अतिरिक्त लागत | ट्रस्ट टोकन के ऑपरेशन के लिए, एन्क्रिप्शन की सुविधा BoringSSL में लागू की गई है. इस सुविधा को Google ही मैनेज करता है. लाइब्रेरी का रखरखाव कैसे किया जाएगा? | ट्रस्ट टोकन, स्टैंडर्ड क्रिप्टोग्राफ़िक ऑपरेशन (निजता पास प्रोटोकॉल देखें) पर निर्भर करता है. इन्हें अन्य लाइब्रेरी में भी लागू किया जा सकता है. हमारा सुझाव है कि डेवलपर अपनी पसंद की लाइब्रेरी में, इन कार्रवाइयों के लिए सहायता का अनुरोध करें/इसे डेवलप करें/इसे बनाए रखें. |
| रखरखाव से जुड़ी अतिरिक्त लागत | यह साफ़ तौर पर नहीं बताया गया है कि प्रोटोकॉल के वर्शन कब तक काम करेंगे | हम प्रोटोकॉल वर्शन के लिए, सहायता की अनुमानित समयसीमाओं के बारे में ज़्यादा जानकारी देने और उसे दस्तावेज़ में शामिल करने की कोशिश कर रहे हैं. |
| कार्ड जारी करने वाली कंपनी की सीमाएं | अगर आप चेन में आगे हैं, तो हो सकता है कि आपके पास ट्रस्ट टोकन लागू करने का मौका न मिले | ज़्यादा से ज़्यादा संगठनों के ट्रस्ट टोकन का इस्तेमाल करने से, हमें समय से जुड़ी इस तरह की समस्याएं ज़्यादा दिख सकती हैं. हम इस समस्या को हल करने के संभावित तरीकों की जांच कर रहे हैं. जैसा कि पहले बताया गया है, हम लंबे समय तक काम करने वाले ऐसे विकल्पों की तलाश कर रहे हैं जिनसे कंपनियां, उपयोगकर्ताओं को ज़्यादा एन्ट्रापी के जोखिम में डाले बिना, टोकन रिडीम कर सकें. इससे पेज पर जगह या लोड करने के क्रम की अहमियत कम हो जाएगी. |
धोखाधड़ी से बचाव के लिए नए समाधानों पर काम चल रहा है
| सुझाव, राय या शिकायत की थीम
(आम तौर पर होने की वजह से रैंक) |
सवालों और समस्याओं की खास जानकारी | Chrome का जवाब |
| डिवाइस इंटिग्रिटी की पुष्टि करने वाले सिग्नल | आम तौर पर, डिवाइस इंटिग्रिटी सिग्नल को पाने के लिए बेहतर सहायता मिलती है. इन सिग्नल की पुष्टि प्लैटफ़ॉर्म करते हैं और इन्हें वेब पर उपलब्ध कराया जाता है | हम सुझाव, राय या शिकायत इकट्ठा करते रहेंगे. साथ ही, सार्वजनिक डिज़ाइन और बार-बार सुधार करके, इस प्रस्ताव को आगे बढ़ाते रहेंगे. |
| डिवाइस इंटिग्रिटी की पुष्टि करने वाले सिग्नल | नए सिग्नल की मदद से, उपयोगकर्ता के बारे में कितनी जानकारी दी जा सकती है. साथ ही, क्या कुछ खास इस्तेमाल के उदाहरणों (जैसे, उपयोगकर्ता अपने बैंक में लॉग इन करना) से, ज़्यादा एन्ट्रापी सिग्नल की पुष्टि की जा सकती है. | हम उपयोगकर्ता की निजता को बनाए रखने के लिए, ज़्यादा से ज़्यादा उपयोगकर्ता एन्ट्रापी के साथ बेहतर सिग्नल देने की कोशिश करते हैं. |
| डिवाइस इंटिग्रिटी की पुष्टि करने वाले सिग्नल | क्या इस सिग्नल से पुराने डिवाइसों या ओपन-सोर्स/बदले गए प्लैटफ़ॉर्म के लिए ऐक्सेस सीमित हो जाएगा? | किसी भी नए सिग्नल को डेवलप करते समय, सभी के लिए ऐक्सेस को मुख्य सिद्धांत के तौर पर ध्यान में रखना चाहिए. इनक्यूबेशन प्रोग्राम के दौरान, इन सवालों को पहले से हल करना ज़रूरी है. |
| डिवाइस इंटिग्रिटी की पुष्टि करने वाले सिग्नल | हमें कुछ चिंता थी कि क्या नए सिग्नल की वजह से, सुरक्षा और धोखाधड़ी रोकने वाली कंपनियां ब्राउज़र और प्लैटफ़ॉर्म पर ज़्यादा भरोसा करेंगी
|
किसी भी नए सिग्नल को अतिरिक्त डेटा के तौर पर देखा जाना चाहिए, न कि ब्राउज़र से "भरोसे" के संकेत के तौर पर. हमें पूरी उम्मीद है कि सुरक्षा कंपनियां अपने मालिकाना डेटा, मॉडल, और डिसीज़न इंजन पर भरोसा करना जारी रखेंगी. साथ ही, डिवाइस की पुष्टि को अतिरिक्त इनपुट के तौर पर इस्तेमाल करेंगी. हमें उम्मीद है कि किसी भी नए सिग्नल से, पूरे नेटवर्क में धोखाधड़ी की पहचान करने की सुविधा को बेहतर बनाने में मदद मिलेगी. साथ ही, धोखाधड़ी को अंजाम देना ज़्यादा मुश्किल हो जाएगा. |
| कुकी की उम्र का सिग्नल | दिलचस्प कॉन्सेप्ट है, लेकिन लागू होने वाले इस्तेमाल के उदाहरणों के बारे में ज़्यादा जांच की ज़रूरत है. | लोगों की दिलचस्पी के लेवल के आधार पर, Chrome इस कॉन्सेप्ट पर और काम कर सकता है. साथ ही, आने वाले समय में, इकोसिस्टम से मिलने वाले सुझाव, शिकायत या राय के लिए, इसे एक एक्सप्लेनर के तौर पर तैयार कर सकता है. |
| धोखाधड़ी रोकने के लिए भरोसेमंद सर्वर | दिलचस्प कॉन्सेप्ट है, लेकिन लागू होने वाले इस्तेमाल के उदाहरणों के बारे में ज़्यादा जांच की ज़रूरत है. | लोगों की दिलचस्पी के लेवल के आधार पर, Chrome इस कॉन्सेप्ट पर और काम कर सकता है. साथ ही, आने वाले समय में, इकोसिस्टम से मिलने वाले सुझाव, शिकायत या राय के लिए, इसे एक एक्सप्लेनर के तौर पर तैयार कर सकता है. |