साल 2022 की दूसरी तिमाही की तिमाही रिपोर्ट, जिसमें प्राइवसी सैंडबॉक्स के प्रपोज़ल और Chrome से मिले जवाब के बारे में नेटवर्क से मिले सुझावों की खास जानकारी दी गई है.
सीएमए को लेकर अपनी जवाबदेही के तहत, Google ने प्राइवसी सैंडबॉक्स के प्रपोज़ल के लिए, पार्टनर के जुड़ाव की प्रोसेस की तीन महीने में तीन रिपोर्ट सार्वजनिक तौर पर उपलब्ध कराने की सहमति दी है. कमीमेंट के पैराग्राफ़ 12 और 17(c)(ii) देखें. प्राइवसी सैंडबॉक्स से जुड़ी फ़ीडबैक की खास जानकारी वाली ये रिपोर्ट, अलग-अलग सोर्स से मिले सुझावों को इकट्ठा करके जनरेट की जाती हैं. इन सोर्स की जानकारी फ़ीडबैक खास जानकारी में दी गई है. इसमें इनके अलावा, और भी चीज़ें शामिल हो सकती हैं: GitHub समस्याएं, privacysandbox.com पर उपलब्ध कराए गए सुझाव फ़ॉर्म. Chrome, नेटवर्क से मिले सुझाव, शिकायत या राय का स्वागत करता है. साथ ही, वह डिज़ाइन से जुड़े फ़ैसलों में सीखने के तरीकों को शामिल करने के तरीके खोज रहा है.
सुझाव, शिकायत या राय की थीम, हर एपीआई की संख्या के हिसाब से रैंक की जाती हैं. इसके लिए, Chrome टीम को मिले सुझाव, शिकायत या राय को किसी तय थीम के आधार पर इकट्ठा करके और उन्हें घटते हुए क्रम में व्यवस्थित किया जाता है. फ़ीडबैक से जुड़ी सामान्य थीम की पहचान करने के लिए, हमने सार्वजनिक मीटिंग (W3C, PatCG, IETF), सीधे तौर पर सुझाव/शिकायत/राय, GitHub पर चर्चा के विषयों और Google की इंटरनल टीम और पब्लिक फ़ॉर्म की मदद से अक्सर पूछे जाने वाले सवालों की समीक्षा की.
खास तौर पर, वेब स्टैंडर्ड बॉडी मीटिंग के लिए तय किए गए समय की समीक्षा की गई और सीधे सुझाव के लिए, Google के 1:1 हिस्सेदारों की मीटिंग के रिकॉर्ड, अलग-अलग इंजीनियर को मिले ईमेल, एपीआई ईमेल पाने वाले लोगों की सूची, और लोगों के सुझाव देने वाले फ़ॉर्म पर विचार किया गया. इसके बाद, Google ने टीम के बीच इन अलग-अलग आउटरीच गतिविधियों को शामिल किया, ताकि यह पता लगाया जा सके कि हर एपीआई के बारे में उभर रही थीम की लोकप्रियता कितनी है.
फ़ीडबैक पर Chrome ने क्या जवाब दिए, यह जानने के लिए अक्सर पूछे जाने वाले सवालों, हिस्सेदारों की ओर से उठाए गए मुद्दों पर असल जवाब, और खास तौर पर सार्वजनिक रिपोर्टिंग की प्रोसेस के लिए एक स्थिति तय की गई है. डेवलपमेंट और टेस्टिंग के मौजूदा फ़ोकस को दिखाते हुए, हमें खास तौर पर Topics, फ़्लैज, और एट्रिब्यूशन रिपोर्टिंग एपीआई के बारे में सवाल और सुझाव मिले.
हो सकता है कि मौजूदा रिपोर्टिंग अवधि के खत्म होने के बाद मिलने वाले फ़ीडबैक को अभी तक Chrome के जवाब के तौर पर न माना जाए.
संक्षिप्त नाम की शब्दावली
- सीएचआईपीएस
- कुकी, इंडिपेंडेंट पार्टिशन्ड स्टेट है
- डीएसपी
- डिमांड-साइड प्लैटफ़ॉर्म
- FedCM
- फ़ेडरेटेड क्रेडेंशियल मैनेजमेंट
- FPS (फ़्रेम प्रति सेकंड)
- पहले पक्ष के सेट
- IAB
- इंटरैक्टिव विज्ञापन ब्यूरो
- आईडीपी
- पहचान देने वाली कंपनी
- आईईटीएफ़
- इंटरनेट इंजीनियरिंग टास्क फ़ोर्स
- IP
- इंटरनेट प्रोटोकॉल पता
- openRTB
- रीयल-टाइम बिडिंग
- OT
- ऑरिजिन ट्रायल
- PatCG
- प्राइवेट ऐडवर्टाइज़िंग टेक्नोलॉजी कम्यूनिटी ग्रुप
- RP
- भरोसेमंद पार्टी
- एसएसपी
- सप्लाई-साइड प्लैटफ़ॉर्म
- TEE
- भरोसेमंद तरीके से एक्ज़ीक्यूशन एनवायरमेंट
- UA
- उपयोगकर्ता एजेंट स्ट्रिंग
- UA-CH
- उपयोगकर्ता-एजेंट क्लाइंट हिंट
- W3C
- वर्ल्ड वाइड वेब कंसोर्टियम
- डब्ल्यूआईपीबी
- विलफ़ुल आईपी ब्लाइंडनेस
सामान्य सुझाव, किसी खास एपीआई/टेक्नोलॉजी के आधार पर नहीं
| सुझाव की थीम
(लोकप्रियता के हिसाब से रैंक की गई) |
सवालों और समस्याओं के बारे में खास जानकारी | Chrome रिस्पॉन्स |
| समयावधि के बारे में साफ़ तौर पर जानकारी पाएं | प्राइवसी सैंडबॉक्स टेक्नोलॉजी के लिए, रिलीज़ के शेड्यूल ज़्यादा साफ़ और ज़्यादा जानकारी के साथ. | हमने privacysandbox.com पर शेड्यूल के लिए अपनी मौजूदा योजनाएं बनाई हैं और उसे हर महीने अपडेट किया जाता है. इनमें Chrome और वेब डेवलपर, दोनों के लिए डेवलपमेंट में लगने वाले समय को ध्यान में रखा जाता है. साथ ही, इनके लिए ज़रूरी समय पर पूरे नेटवर्क से हमें नई टेक्नोलॉजी की जांच करने और उन्हें अपनाने का सुझाव भी मिलता है. हर टेक्नोलॉजी, टेस्टिंग से लेकर रिलीज़ (लॉन्च) तक, कई चरणों से गुज़रती है. साथ ही, हर चरण के सही समय को इस आधार पर तय किया जाता है कि हमने पिछले चरण में क्या सीखा. फ़िलहाल, हमारे पास कोई रिलीज़ तय नहीं है. हालांकि, हम privacysandbox.com पर अपनी सार्वजनिक टाइमलाइन को अपडेट करेंगे. |
| अलग-अलग तरह के हिस्सेदारों के लिए उपयोगिता | यह चिंता की बात है कि प्राइवसी सैंडबॉक्स टेक्नोलॉजी, बड़े डेवलपर को पसंद आती है. साथ ही, सामान्य (बड़ी) साइटों के मुकाबले, खास (छोटी) साइटों का योगदान ज़्यादा होता है. | हम जानते हैं कि कुछ डेवलपर, प्राइवसी सैंडबॉक्स से जुड़ी टेक्नोलॉजी के असर को लेकर चिंतित हैं. Google का वादा है कि सीएमए, प्राइवसी सैंडबॉक्स के प्रपोज़ल को इस तरह डिज़ाइन या लागू नहीं करेगा जिससे वह खुद को प्राथमिकता देते हुए Google के कारोबार को प्राथमिकता दे सके. साथ ही, डिजिटल विज्ञापन और पब्लिशर और विज्ञापन देने वाले लोगों या कंपनियों पर पड़ने वाली प्रतिस्पर्धा के असर को ध्यान में रखा जाएगा. साथ ही, निजता से जुड़े नतीजों और उपयोगकर्ता अनुभव पर पड़ने वाले असर को भी ध्यान में रखा जाएगा. हम यह पक्का करने के लिए सीएमए के साथ मिलकर काम करते रहते हैं कि हमारा काम इन प्रतिबद्धताओं का पालन करे.
प्राइवसी सैंडबॉक्स की टेस्टिंग के दौरान, हम इस अहम सवाल का आकलन करेंगे कि अलग-अलग तरह के हिस्सेदारों के लिए नई टेक्नोलॉजी कैसा परफ़ॉर्म कर रही है. इस मामले में सुझाव, राय या शिकायत बहुत अहम है. खास तौर पर, सटीक और कार्रवाई करने लायक सुझाव, शिकायत या राय की मदद से हम तकनीकी डिज़ाइन को और बेहतर बना सकते हैं. |
| तीसरे पक्ष की कुकी के बंद होने की टाइमलाइन | तीसरे पक्ष की कुकी के इस्तेमाल को रोकने में देरी से बचने के अनुरोध | हमें कुछ हिस्सेदारों से पता चला है कि Chrome में तीसरे पक्ष की कुकी को बिना किसी देरी के बंद किया जा सकता है. हमें ऐसे लोगों से भी पता चला है जो प्राइवसी सैंडबॉक्स से जुड़ी टेक्नोलॉजी को आज़माने और अपनाने के लिए ज़्यादा समय चाहते हैं. टेक्नोलॉजी की जटिलता और सही तरीके से काम करने के नेटवर्क की अहमियत को ध्यान में रखते हुए, हम ज़िम्मेदारी के साथ आगे बढ़ने के लिए प्रतिबद्ध हैं. इस प्रोसेस के लिए, इंडस्ट्री और रेगुलेटर के सुझाव, शिकायत या राय अहम रहे हैं. |
| तीसरे पक्ष की कुकी के बंद होने की टाइमलाइन | तीसरे पक्ष की कुकी के इस्तेमाल को रोकने और एपीआई की जांच करने के लिए ज़्यादा समय देने के अनुरोध. | हमें कुछ हिस्सेदारों से पता चला है कि Chrome में तीसरे पक्ष की कुकी को बिना किसी देरी के बंद किया जा सकता है. हमें ऐसे लोगों से भी पता चला है जो प्राइवसी सैंडबॉक्स से जुड़ी टेक्नोलॉजी को आज़माने और अपनाने के लिए ज़्यादा समय चाहते हैं. टेक्नोलॉजी की जटिलता और सही तरीके से काम करने के नेटवर्क की अहमियत को ध्यान में रखते हुए, हम ज़िम्मेदारी के साथ आगे बढ़ने के लिए प्रतिबद्ध हैं. इस प्रोसेस के लिए, इंडस्ट्री और रेगुलेटर के सुझाव, शिकायत या राय अहम रहे हैं. |
| दस्तावेज़ के अनुरोध | टेस्टिंग, विश्लेषण, और लागू करने के तरीके को मैनेज करने के तरीके की जानकारी देने वाले ज़्यादा संसाधनों के अनुरोध. | हमें खुशी है कि डेवलपर को हमारा मौजूदा कॉन्टेंट मददगार लगा. हम आने वाले हफ़्तों और महीनों में, डेवलपर के काम के घंटों के साथ ही तकनीकी दस्तावेज़ वगैरह उपलब्ध कराने के लिए प्रतिबद्ध हैं, ताकि डेवलपर नई टेक्नोलॉजी उनके लिए कैसे काम कर सकते हैं, इसे लगातार समझ सकें.
हमने डेवलपर के लिए, ऑफ़िस में कामकाज के घंटे के दौरान सार्वजनिक तौर पर होने वाले सेशन आयोजित किए हैं. इन सेशन में, प्रॉडक्ट और इंजीनियरिंग लीड के साथ सवाल-जवाब के सेशन शेयर किए जाएंगे. साथ ही, प्रॉडक्ट और इंजीनियरिंग टीम के लोगों के साथ सवाल-जवाब के सेशन शेयर किए गए, ताकि लोग लाइव चर्चा/सवालों के जवाब दे सकें. |
| उद्योग से जुड़ी विशेषज्ञता | मानकों पर काम करने वाली Chrome टीम के पास विज्ञापन नेटवर्क में ऐसे विशेषज्ञ नहीं हैं जो निजता और उपयोगिता के बीच संतुलन बनाने के लिए ज़रूरी हैं. | हम मानते हैं कि हमारी एक बड़ी ज़िम्मेदारी है. इसलिए, इसे सही तरीके से लागू करने के लिए, हम खास फ़ीडबैक के आधार पर काम करते हैं. हम निजता और इसके असर, दोनों को ही डिज़ाइन के लिए काफ़ी अहम मानते हैं. वेब के लिए प्राइवसी सैंडबॉक्स पर काम करने वाली पूरी टीम के कुल मिलाकर, विज्ञापन नेटवर्क में काम किए गए कुल सालों की संख्या सैकड़ों साल है. |
काम का कॉन्टेंट और विज्ञापन दिखाएं
विषय
| सुझाव की थीम
(लोकप्रियता के हिसाब से रैंक की गई) |
सवालों और समस्याओं के बारे में खास जानकारी | Chrome रिस्पॉन्स |
| अलग-अलग तरह के हिस्सेदारों के लिए उपयोगिता | साइटों के लिए उस वैल्यू को बनाने और उसके डिस्ट्रिब्यूशन को लेकर चिंता बढ़ गई है. यह चिंता इस बात पर निर्भर करती है कि साइट के ट्रैफ़िक का लेवल क्या है या उनके कॉन्टेंट की खासियत क्या है. | टेस्टिंग के ज़रिए यह पता लगाया जाएगा कि यह एपीआई काम का है या नहीं. Chrome को उम्मीद है कि जांच के नतीजों के आधार पर अलग-अलग कैटगरी और अन्य पैरामीटर में बदलाव होगा. कैटगरी या पैरामीटर के क्रमिक विकास के लिए, हो सकता है कि पुराने सिस्टम के साथ काम न करने वाले बदलावों की ज़रूरत न पड़े. इसके अलावा, Chrome को उम्मीद है कि तीसरे पक्ष की कुकी के बंद होने के बाद भी, Topics API के डेवलपमेंट पर असर पड़ता रहेगा. |
| टेक्सॉनमी | इंडस्ट्री के हिस्सेदार, टेक्सॉनमी को लागू करने के लिए आवाज़ उठाना चाहते हैं. | Chrome, अलग-अलग कैटगरी पर जानकारी देने के लिए खुला रहता है. Chrome, टेक्सॉनॉमी को संशोधित करने के लिए गवर्नेंस मॉडल पर फ़ीडबैक पाने और इस बात की चर्चा करने में बेहद दिलचस्पी रखता है कि किस तरह अन्य औद्योगिक निकाय लंबी अवधि में टेक्सॉनमी को डेवलप करने और उसे बनाए रखने में ज़्यादा सक्रिय भूमिका निभा सकते हैं. |
| ज़रूरत के मुताबिक ब्राउज़िंग इतिहास नहीं है | अगर उपयोगकर्ता के पास सबसे हाल के हफ़्ते में पांच विषय बनाने के लिए ज़रूरत के मुताबिक ब्राउज़िंग इतिहास नहीं है, तो कॉलर के पिछले हफ़्तों में देखे गए विषयों को दिखाने का प्रस्ताव | हमारे मौजूदा डिज़ाइन के लिए, इन्हें बिना किसी क्रम के चुना जाता है. हम पुराने विषयों से जुड़े संबंधों की जांच करेंगे और इस बात पर विचार करेंगे कि क्या इसे शामिल किया जा सकता है. हालांकि, ऐसा हो सकता है कि इसकी निजता से जुड़े विषय पर बुरा असर पड़े. |
| किसी पब्लिशर की ओर से विषयों को कॉल करना | क्या सेवा देने वाली तीसरे पक्ष की कंपनी, किसी पब्लिशर के साथ Topics शेयर कर सकती है? | हां, इस तरीके से हम Topics के इस्तेमाल की उम्मीद करते हैं. |
| संभावित अटैक वेक्टर | शोर वाले विषयों की पहचान करना | नेटवर्क में मौजूद कई लोगों से मिले सुझावों के आधार पर, Chrome ने विषयों को फ़िल्टर करने और ग़ैर-ज़रूरी आवाज़ों को शामिल करने का विकल्प चुना. ये फ़ैसले निजता को ध्यान में रखते हुए लिए गए थे. इसका मकसद, उन लोगों तक जानकारी का ऐक्सेस सीमित करना था जिनके पास इस तरह की जानकारी का ऐक्सेस नहीं होता. साथ ही, इससे लोगों के लिए इस तरह की जानकारी को गलत साबित करने का खतरा बना रहता. हम मानते हैं कि उन फ़ैसलों में कमियां हैं, जैसे कि यहां बताया गया अटैक वेक्टर. हालांकि, हमारा आकलन है कि निजता से जुड़े फ़ायदे संभावित जोखिमों से कहीं ज़्यादा हैं. हम इस फ़ैसले पर सार्वजनिक चर्चा का स्वागत करते हैं. |
| ऑरिजिन ट्रायल की ज़रूरी शर्तें | क्या यह पता लगाने का कोई तरीका है कि कोई उपयोगकर्ता ऑरिजिन ट्रायल के लिए ज़रूरी शर्तें पूरी करता है या नहीं? | ऐसा हो सकता है कि ब्राउज़र की सेटिंग या अन्य वजहों से, उपयोगकर्ता के लिए ऑरिजिन ट्रायल की सुविधा उपलब्ध न हो. भले ही, उपयोगकर्ता किसी ऐसे वेब पेज पर जा रहे हों जिस पर कोई मान्य ट्रायल टोकन दिया जाता है. साथ ही, उसका ब्राउज़र उस ग्रुप में शामिल हो जिसके लिए मुफ़्त में आज़माने की सुविधा चालू है.
इसलिए, सुविधा की पहचान का इस्तेमाल हमेशा यह जांचने के लिए किया जाना चाहिए कि ऑरिजिन ट्रायल की सुविधा उपलब्ध है या नहीं. |
| परफ़ॉर्मेंस पर असर | Topics API के इस्तेमाल में आने वाली समस्याओं और इंतज़ार के समय से जुड़ी समस्याएं | हम महंगे और धीमे x-ऑरिजिन iframe से बचने के तरीकों के लिए सुझाव/राय दे रहे हैं. साथ ही, Topics API को अलग करने के सुझाव भी दे रहे हैं, ताकि विषय मिलने से ब्राउज़िंग की स्थिति में कोई बदलाव न हो. |
| 'स्प्लिट विषय' एपीआई की सुविधा | एपीआई के तीन अलग-अलग पहलुओं पर ज़्यादा कंट्रोल देकर, | हम इस्तेमाल के उदाहरण को समझते हैं और हमने GitHub में इसे ठीक करने के लिए एक संभावित तरीका सुझाया है. फ़िलहाल, हमें नेटवर्क से इस बारे में सुझाव मिलने का इंतज़ार है कि इस सुविधा को तैयार करना है या नहीं. अभी चल रही चर्चा यहां देखें. |
| क्लासिफ़ायर की टाइमलाइन और दस्तावेज़ | डेवलपर ने क्लासिफ़ायर के बारे में ज़्यादा जानकारी मांगी है. | हमने क्लासिफ़ायर के बारे में सार्वजनिक रूप से ज़्यादा जानकारी यहां दी है.
साथ ही, यहां और यहां. |
| उपयोगकर्ता के कंट्रोल और सुरक्षा | कुछ विषय, संवेदनशील ग्रुप के लिए प्रॉक्सी हो सकते हैं. इसलिए, नेगेटिव नतीजों को रोकने के लिए, लोगों को ज़्यादा कंट्रोल की ज़रूरत होती है. | विषय, उपयोगकर्ता के कंट्रोल और पारदर्शिता बनाए रखने की दिशा में किए जा रहे अहम कदम को दिखाते हैं. उपयोगकर्ता, विषयों से ऑप्ट आउट कर सकते हैं. साथ ही, उन्हें असाइन किए गए विषयों की समीक्षा कर सकते हैं और विषयों को हटा सकते हैं. साथ ही, यह भी समझ सकते हैं कि दिए गए पेज पर उनके विषयों के साथ कौनसी कंपनियां इंटरैक्ट कर रही हैं. इसके अलावा, उपयोगकर्ता अपना ब्राउज़िंग इतिहास मिटाकर भी अपने Topics पर असर डाल सकते हैं. हम उपयोगकर्ता के लिए, डेवलपर के सुझाए गए कंट्रोल जैसे बेहतर कंट्रोल के बारे में लगातार होने वाली चर्चा का स्वागत करते हैं. हालांकि, हमें यह पक्का करना होगा कि इस गड़बड़ी में बताई गई समस्याओं को हल करने से ही जोखिम खत्म हो जाए (उदाहरण के लिए, सिर्फ़ 'विदेशी भाषा के लिए स्टडी' विषय को हटाना, लेकिन ब्राउज़िंग इतिहास से विषय जनरेट करने वाली वेबसाइटों को हटाने से उपयोगकर्ता पूरी तरह सुरक्षित नहीं होगा). |
| prebid.js वाली साइटों पर विषयों का इस्तेमाल | क्या prebid.js वाली वेबसाइटों पर Topics API का इस्तेमाल किया जा सकता है? | छोटा जवाब हां है. ज़्यादा जानकारी यहां पब्लिश की गई है. |
| सुझाव के विजेट में Topics API का इस्तेमाल करना | क्या हम सुझाए गए विजेट (जैसे, आउटब्रेन) में Topics API का इस्तेमाल कर सकते हैं | एपीआई कॉल करने के बाद, हम फिर से हासिल किए गए Topics के इस्तेमाल के मामले को सीमित नहीं करते. यह हर डेवलपर की डेटा नीति पर निर्भर करता है. |
| निजता / नीति | कॉल करने वाले (कॉलर) के हिसाब से जवाबों को फ़िल्टर करने से जुड़े सवाल. क्या तीसरे पक्ष के लोग कॉल करने वाले किसी भी व्यक्ति के साथ अपने विषय शेयर करते हैं. | नेटवर्क के कई लोगों से मिले सुझावों के आधार पर, Chrome ने इस डिज़ाइन को उन लोगों के लिए जानकारी का ऐक्सेस सीमित करने के लिए चुना है जो शायद लोगों को इस तरह की जानकारी का ऐक्सेस नहीं देते. बेशक, Topics पाने वाले पब्लिशर और तीसरे पक्ष, खुद यह तय कर सकते हैं कि वे अपनी साइट पर पक्षों के साथ कौनसी जानकारी शेयर करेंगे. अगर वे इस तरह का डेटा शेयर करते हैं, तो Chrome उन्हें सुझाव देता है कि वे इस तरह की जानकारी अपने उपयोगकर्ताओं के साथ शेयर न करें. साथ ही, इस तरह की गतिविधियों को कंट्रोल करने की सुविधा उपलब्ध कराएं. |
| शोर करने वाले सिग्नल | बिना किसी क्रम के विषय के बारे में 5% बार जानकारी देने से, हो सकता है कि बहुत ज़्यादा शोर या गलत सिग्नल जनरेट हो. | इस्तेमाल करने वालों की निजता की सुरक्षा के लिए, ग़ैर-ज़रूरी आवाज़ों को इस्तेमाल करना एक अहम तरीका है. साथ ही, टेस्ट में यह पता लगाया जाएगा कि शोर का लेवल क्या है और यह किस तरह का है. |
फ़्लेज
| सुझाव की थीम
(लोकप्रियता के हिसाब से रैंक की गई) |
सवालों और समस्याओं के बारे में खास जानकारी | Chrome रिस्पॉन्स |
| टेस्ट कोऑर्डिनेशन | परफ़ॉर्मेंस और रेवेन्यू पर पड़ने वाले असर का टेस्ट करना | डब्ल्यूआईसीजी की सार्वजनिक मीटिंग में, FLEDGE की परफ़ॉर्मेंस और ऑरिजिन ट्रायल के साथ-साथ सामान्य रूप से उपलब्ध होने की सुविधा के दौरान नेटवर्क टेस्टिंग में बेहतर तरीके से मदद करने के तरीके के बारे में खास तौर पर बात की जा रही है. |
| FLEDGE के लिए भरोसेमंद सर्वर | विश्वसनीय सर्वर परीक्षण के लिए कब उपलब्ध होगा? | हमें इस सुझाव, शिकायत या राय का इंतज़ार है. हम ज़्यादा जानकारी देने वाले प्लान पर काम कर रहे हैं, ताकि FLEDGE में भरोसेमंद सर्वर इस्तेमाल किए जा सकें. |
| प्रोटोकॉल का स्टैंडर्ड तय करना | क्या SSP और DSP के बीच डेटा पास करने के लिए कोई सामान्य प्रोटोकॉल होगा, जैसे कि इंटरेस्ट ग्रुप के लिए एक जैसे लेबल? | हम DSP, SSP, और विज्ञापन नेटवर्क से मिलने वाले सुझावों का स्वागत करते हैं, ताकि खास जानकारी के संभावित मानक तय किए जा सकें. इस समय शुरुआती टेस्टिंग के लिए, हमारा सुझाव है कि आप सीधे अपने टेस्टिंग पार्टनर से संपर्क करें, क्योंकि वे अलग-अलग तरीके अपना रहे हैं. हम विज्ञापन व्यापार संगठनों को भी मानक बनाने के लिए प्रोत्साहित करते हैं और उनके साथ काम करते रहने की योजना बनाते हैं. |
| फ़्रीक्वेंसी कैपिंग | कैंपेन और विज्ञापन ग्रुप में, हर उपयोगकर्ता के हिसाब से फ़्रीक्वेंसी कंट्रोल. | FLEDGE, डिवाइस पर होने वाली नीलामियों के साथ-साथ काम के / ब्रैंडिंग कैंपेन के लिए भी फ़्रीक्वेंसी कैपिंग का इस्तेमाल करेगा. अतिरिक्त फ़्रीक्वेंसी कैपिंग कंट्रोल के लिए, शेयर किया गया स्टोरेज और साइट के लिए खास कैप का इस्तेमाल भी किया जा सकता है. |
| परफ़ॉर्मेंस पर FLEDGE का असर | FLEDGE नीलामी में, कम समय में ज़्यादा बिडिंग करने वाले बिडर | Chrome, साइट की परफ़ॉर्मेंस पर पड़ने वाले संभावित असर के बारे में, डेवलपर के साथ बातचीत कर रहा है. Chrome, टेस्टिंग के दौरान ज़्यादा जानने के मौके का स्वागत करता है. |
| FLEDGE को अन्य सुविधाओं के साथ टेस्ट किया जा रहा है | Attribution Reporting API और FLEDGE से मिली इवेंट-लेवल रिपोर्ट, एक साथ कैसे फ़िट होंगी? | इस बारे में, हाल ही में हुए WICG/conversion-measurement-api कॉल में यहां ज़्यादा जानकारी देने वाले लिंक के साथ चर्चा की गई थी.
मीटिंग की खास जानकारी के मुताबिक, फ़ेंस किए गए फ़्रेम वाले विज्ञापन की रिपोर्टिंग के मौजूदा डिज़ाइन की मदद से, फ़ेंस किए गए फ़्रेम में जनरेट किए गए आईडी को, काम की जानकारी से जोड़ा जा सकता है. इसलिए, फ़ेंस किए गए फ़्रेम में जनरेट की गई इवेंट-लेवल की रिपोर्ट में, सर्वर पर मौजूद काम की जानकारी को जोड़ा जा सकेगा. इसके लिए, एक के बजाय दो सर्वर-साइड जॉइन का इस्तेमाल किया जाएगा. |
| इंप्रेशन की गिनती | खरीदार और विक्रेताओं के बीच इंप्रेशन गिनने के किस तरीके का इस्तेमाल किया जाना चाहिए या किया जाना चाहिए | FLEDGE API, नीलामी के दौरान सेलर और खरीदार के बीच काम करने के तरीके को अलाइन करने के लिए पहले से ही काम करता है. हमें अन्य तरीकों को लागू करने के सुझाव मिले हैं. हालांकि, हमें यह नहीं पता चला है कि हमारा मौजूदा डिज़ाइन, नेटवर्क के साथ काम क्यों नहीं कर सकता. |
| एक से ज़्यादा विज्ञापन दिखाए जा रहे हैं | क्या किसी फ़ेंस किए गए फ़्रेम में, एक नीलामी में एक से ज़्यादा विज्ञापन दिखाए जा सकते हैं | फ़िलहाल, ऐसा कॉम्पोनेंट विज्ञापनों के ज़रिए किया जा सकता है. इन्हें कॉम्पोनेंट नीलामियों के तौर पर माना जाए. ऐसा करने के लिए, सभी विज्ञापन एक ही इंटरेस्ट ग्रुप में होने चाहिए. |
| "सेलर से तय की गई ऑडियंस (SDA)" के बारे में खास जानकारी और FLEDGE | क्या FLEDGE एक ऐसा तरीका बन सकता है जिससे खरीदारों को, विज्ञापन अनुरोधों पर एसडीए की मदद से प्रोफ़ाइल बनाने से रोका जा सके? | FLEDGE को ऐसी जानकारी लीक होने से बचाने के लिए डिज़ाइन किया गया है जो तब काम का नहीं होता, जब पब्लिशर को यह पता हो कि उसके लोग एसडीए में क्या हैं और टारगेटिंग एक ही साइट पर है. अगर FLEDGE में बनाई गई सभी सुरक्षा के तहत SDA पर खरीदारी को बढ़ावा देना ज़रूरी है, तो विक्रेता के लिए एक समाधान हो सकता है कि वह डिवाइस पर होने वाली नीलामी में SDA लेबल पास करे. साथ ही, खरीदारी के पक्ष में विज्ञापन तकनीक को अपना इंटरेस्ट ग्रुप बनाएं, जिसका बिडिंग लॉजिक कहता है, "मुझे ऑडियंस X खरीदना है." |
| डॉलर के अलावा अन्य मुद्राओं के लिए सहायता | डॉलर के अलावा अन्य मुद्राओं के साथ FLEDGE की टेस्टिंग के लिए सहायता | हम इस कॉलआउट की सराहना करते हैं और हमने सुविधा अनुरोधों के हमारे बैकलॉग में अन्य मुद्राओं के लिए समर्थन शामिल किया है. हमें उम्मीद है कि यह सुविधा जल्द ही उपलब्ध हो जाएगी. |
| नेगेटिव इंटरेस्ट ग्रुप के हिसाब से टारगेटिंग के लिए सहायता | नेगेटिव आईजी टारगेटिंग के साथ काम करने वाला एपीआई: विज्ञापन को सिर्फ़ तब दिखाना, जब कोई उपयोगकर्ता किसी आईजी से जुड़ा न हो. | GitHub की समस्या पर चर्चा हो रही है. इसमें, मदद करने के लिए सुझाए गए कुछ विकल्प भी शामिल हैं. |
| FLEDGE में एक से ज़्यादा SSP | FLEDGE में मल्टी-लेवल नीलामियां लागू करते समय, Google को प्राथमिकता देने का जोखिम | FLEDGE में एक से ज़्यादा एसएसपी के लिए सहायता जोड़ी गई है, ताकि सबको समान रूप से मौके मिल सकें. Google ने वादा किया है कि प्राइवसी सैंडबॉक्स के प्रपोज़ल को इस तरह डिज़ाइन, डेवलप या लागू नहीं किया जाएगा. साथ ही, विज्ञापन प्रॉडक्ट और सेवाओं को खुद प्राथमिकता देकर प्रतिस्पर्धा को खत्म किया जाएगा. Google इसे गंभीरता से लेता है और टेक्नोलॉजी के खास पहलुओं के बारे में हिस्सेदारों की किसी भी चिंता पर चर्चा करने के लिए तैयार है. जानकारी के लिए, Chrome ने यहां कॉम्पोनेंट नीलामी के तरीके का सार्वजनिक तौर पर दस्तावेज़ दिया है. |
डिजिटल विज्ञापनों का आकलन करना
एट्रिब्यूशन रिपोर्टिंग (और दूसरे एपीआई)
| सुझाव की थीम
(लोकप्रियता के हिसाब से रैंक की गई) |
सवालों और समस्याओं के बारे में खास जानकारी | Chrome रिस्पॉन्स |
| मल्टी-टच एट्रिब्यूशन | मल्टी-टच एट्रिब्यूशन के लिए सहायता का अनुरोध करने वाले पब्लिशर | मल्टी-टच एट्रिब्यूशन के मौजूदा तरीकों के लिए, अलग-अलग वेबसाइटों पर उपयोगकर्ता के इंप्रेशन (इस वजह से, उनकी पहचान) को सीमित तौर पर एक साथ जोड़ना ज़रूरी है. इसलिए, मौजूदा फ़ॉर्म में यह सुविधा प्राइवसी सैंडबॉक्स के लक्ष्यों से मेल नहीं खाती. सैंडबॉक्स का मकसद, क्रॉस-साइट ट्रैकिंग के बिना, विज्ञापनों के इस्तेमाल के उदाहरणों को बेहतर बनाने में मदद करना है. कुछ मामलों में, अलग-अलग उपयोगकर्ताओं को ट्रैक किए बिना, क्रेडिट असाइनमेंट का अंदाज़ा लगाया जा सकता है. जैसे, वेटेड, किसी भी क्रम में दी गई प्राथमिकताओं का इस्तेमाल करके. |
| ग़ैर-ज़रूरी आवाज़ें जनरेट करना | रिपोर्ट में गै़र-ज़रूरी डेटा के स्तर के बारे में सवाल | हमारे शुरुआती एक्सपेरिमेंट की मदद से, डेवलपर अपने ऐप्लिकेशन के लिए अलग-अलग वैल्यू सेट कर सकते हैं. इससे, वे अनुभव कर सकते हैं कि गै़र-ज़रूरी डेटा के लेवल के हिसाब से रिपोर्ट में क्या बदलाव होते हैं. फ़िलहाल, डेवलपर के पास epsilon=64 तक का कोई एपिसोड चुनने का विकल्प है. हमने खास तौर पर ऐसा इसलिए किया है, ताकि डेवलपर आसानी से एपीआई की जांच कर सकें और एपीआई की सही वैल्यू पर सुझाव दे सकें.
हमने इस तरह के सुझाव के लिए सार्वजनिक अनुरोध भी किया है. |
| टेस्ट कोऑर्डिनेशन | क्या ओटी के लिए, लोकल टेस्टिंग टूल का इस्तेमाल किया जा सकता है? | हां, लोकल टेस्टिंग टूल का इस्तेमाल ओटी के दौरान किया जा सकता है. जब तक तीसरे पक्ष की कुकी उपलब्ध हैं, तब तक लोकल टेस्टिंग टूल का इस्तेमाल डीबग रिपोर्ट के साथ किया जा सकता है. |
| अर्गोनॉमिक्स से जुड़ी क्वेरी | कुंजी के एग्रीगेट के आधार पर क्वेरी करने की सुविधा चालू करता है | हम इस बात से सहमत हैं कि इससे एपीआई के अर्गोनॉमिक्स में सुधार होता है. इसमें निजता से जुड़ा खर्च भी कम होता है या साफ़ तौर पर नहीं दिखता. हम एक प्रस्ताव बनाकर देखेंगे कि इस बारे में व्यापक सहमति है कि यह समर्थन करने के लायक है या नहीं. |
| छोटी साइटों के लिए कम सटीक डेटा | छोटी साइटों या कैंपेन को मिलने वाला डेटा सटीक नहीं होता. | Chrome समझता है कि गै़र-ज़रूरी डेटा के आधार पर निजता सुरक्षा की सुविधा, डेटा के छोटे हिस्से पर ज़्यादा असर डालती है. हालांकि, लंबे समय तक इकट्ठा करने जैसे तरीकों से यह समस्या हल हो सकती है. यह भी समझ नहीं आता कि डेटा के बहुत छोटे हिस्सों (जैसे, एक या दो खरीदारी) पर आधारित नतीजे, विज्ञापन देने वालों के लिए काम के हैं या नहीं. ऑरिजिन ट्रायल के दौरान, Chrome, टेस्टर को निजता और शोर से जुड़े अलग-अलग पैरामीटर के साथ एक्सपेरिमेंट करने के लिए बढ़ावा देता है, ताकि वे इस समस्या के बारे में सटीक सुझाव दे सकें. |
कवर ट्रैकिंग को सीमित करें
उपयोगकर्ता एजेंट को कम करने की प्रोसेस
| सुझाव की थीम
(लोकप्रियता के हिसाब से रैंक की गई) |
सवालों और समस्याओं के बारे में खास जानकारी | Chrome रिस्पॉन्स |
| बॉट की सुरक्षा | बॉट सुरक्षा पर UA-R का असर | हम इस सुझाव की सराहना करते हैं. साथ ही, हम बॉट की सुरक्षा के लिए तरीकों के बारे में जानकारी इकट्ठा कर रहे हैं, ताकि आने वाले समय में हम अपने नए डिज़ाइन को और बेहतर बना सकें. |
| डिप्लॉयमेंट डिपेंडेंसी | स्ट्रक्चर्ड यूज़र एजेंट (एसयूए) डिप्लॉयमेंट डिपेंडेंसी को ठीक करना | हमने Chrome के 101 और उसके बाद के वर्शन का इस्तेमाल करने वाले सभी लोगों के लिए, "चौथा फ़ेज़" यानी माइनर वर्शन को रोल आउट कर दिया है. इसे माइनर वर्शन भी कहा जाता है. यहां अपडेट करें देखें. |
उपयोगकर्ता एजेंट क्लाइंट हिंट
| सुझाव की थीम
(लोकप्रियता के हिसाब से रैंक की गई) |
सवालों और समस्याओं के बारे में खास जानकारी | Chrome रिस्पॉन्स |
| इस्तेमाल किए जा सकने वाले सभी संकेतों की गिनती की जा रही है | प्रोग्राम के हिसाब से अपने-आप होने वाली प्रोसेस की मदद से, ब्राउज़र पर काम करने वाले सभी संकेतों के बारे में जानने में दिलचस्पी. | हम इस सुझाव, शिकायत या राय की सराहना करते हैं. साथ ही, सुविधा के अनुरोध की समीक्षा कर रहे हैं. हम यह जानना चाहते हैं कि क्या यह आम तौर पर इस्तेमाल किया जाता है. |
| UA-CH बनाम उपयोगकर्ता-एजेंट हेडर में फ़र्क़ | उपयोगकर्ता-एजेंट हेडर के लचीलेपन की तुलना में UA-CH ज़्यादा निर्देश देता है, जैसा कि RFC7231 ने तय किया है. | Chrome को लगता है कि UA स्ट्रिंग के लचीलेपन के मुकाबले, UA-CH हेडर के प्रिस्क्रिप्टिव नेचर को एक अहम सुधार के तौर पर देखा जाता है. क्रॉस-ब्राउज़र इंटरऑपरेबिलिटी (दूसरे सिस्टम के साथ काम करना) और उपयोगकर्ता की निजता सुरक्षा (हाई-एंट्रॉपी आइडेंटिफ़ायर को मनचाहे तरीके से जोड़े जाने से रोककर) को एक अहम सुधार माना जाता है.
अगर अन्य लोग भी इस समस्या पर अपनी राय देते हैं और सुझाव देना चाहते हैं, तो यह समस्या हल नहीं होगी. |
| UA-CH: धोखाधड़ी-विरोधी / गलत इस्तेमाल-विरोधी समस्याएं | UA-CH के ज़रिए मिलने वाली कुछ सुविधाएं: क्लिक रीडायरेक्ट ट्रैकर और धोखाधड़ी वाले क्लिक. | टीम धोखाधड़ी रोकने और मेज़रमेंट पार्टनर के साथ, इन संभावित समस्याओं की जांच कर रही है. |
| परफ़ॉर्मेंस | क्रिटिकल-CH (पहले पेज के लोड पर) से संकेत मिलने में लगने वाले समय को लेकर कुछ समस्याएं मौजूद हैं. | Chrome, परफ़ॉर्मेंस को बेहतर बनाने के तरीके खोज रहा है. |
नैटकैचर (काम जारी है)
| सुझाव की थीम
(लोकप्रियता के हिसाब से रैंक की गई) |
सवालों और समस्याओं के बारे में खास जानकारी | Chrome रिस्पॉन्स |
| इंतज़ार के समय से जुड़ी समस्याएं | अतिरिक्त हॉप जोड़ने से इंतज़ार के समय पर असर पड़ सकता है | हम दो-हॉप प्रॉक्सी का इस्तेमाल करने के बारे में सोच रहे हैं. साथ ही, ऐसे तरीके खोज रहे हैं जिनसे उपयोगकर्ता की निजता और इंतज़ार के समय के बीच सही संतुलन बनाया जा सके. हम आपके सुझाव, शिकायत या राय के लिए हमेशा तैयार हैं. साथ ही, हम W3C फ़ोरम में इस पर और चर्चा करना चाहेंगे. |
| धोखाधड़ी और बॉट से सुरक्षा | धोखाधड़ी और बॉट की सुरक्षा पर पड़ने वाला असर. इसमें कम विकसित देशों में भी इसका असर पड़ता है | सुरक्षा एक सबसे ज़रूरी शर्त है, क्योंकि हम उपयोगकर्ता की निजता को बेहतर बनाने के तरीके ढूंढ रहे हैं. जैसे, आईपी पतों को प्रॉक्सी करना. जानी-मानी कंपनियों के साथ दो हॉप करने वाली प्रॉक्सी पार्टनरशिप, उपयोगकर्ता की निजता की पुष्टि करने में मदद करती है. हम उपयोगकर्ताओं का भरोसा बढ़ाने के लिए, नए सिग्नल के लिए आइडिया भी जोड़ रहे हैं. |
| स्थानीय निजता कानूनों का पालन करना | देश-स्तरीय भौगोलिक डेटा रिपोर्टिंग ज़्यादा विस्तृत स्थानीय व्यवस्थाओं का अनुपालन करना कठिन बनाती है | हमने अपने सुझाए गए सिद्धांतों को सार्वजनिक रूप से पोस्ट किया है. इनमें ऐसे संभावित तरीके शामिल हैं जिनकी मदद से वेबसाइटें, स्थानीय ज़रूरी शर्तों का पालन कर सकेंगी. |
क्रॉस-साइट निजता की सीमाओं को मज़बूत बनाएं
पहले पक्ष के सेट
| सुझाव की थीम
(लोकप्रियता के हिसाब से रैंक की गई) |
सवालों और समस्याओं के बारे में खास जानकारी | Chrome रिस्पॉन्स |
| अलग-अलग तरह के हिस्सेदारों के लिए उपयोगिता | छोटे बनाम बड़े पब्लिशर पर FPS का असर | प्राइवसी सैंडबॉक्स का मुख्य मकसद, उपयोगकर्ता की निजता को बेहतर बनाना है. इसके लिए, मौजूदा तरीकों को ऐसे समाधान से बदला जाता है जो क्रॉस-साइट ट्रैकिंग मैकेनिज़्म पर निर्भर नहीं होते. हम चाहते हैं कि ये समाधान, अलग-अलग तरह के और अलग-अलग तरह के हिस्सेदारों के लिए ज़्यादा से ज़्यादा काम के हों. इन समाधानों को बेहतर कैसे बनाया जा सकता है, इस पर हम कार्रवाई करने लायक खास जानकारी का स्वागत करते हैं. हम उम्मीद करते हैं कि समुदाय की चर्चा और टेस्टिंग की मदद से, इन्हें लगातार बेहतर बनाया जाएगा. |
| निजता को बेहतर बनाना | एक ही सेट में बहुत ज़्यादा साइटों का इस्तेमाल करने पर, तीसरे पक्ष की कुकी की तरह नतीजे मिल सकते हैं | हम इस सुझाव की सराहना करते हैं और इस बात का आकलन कर रहे हैं कि सही सीमाएं तय की जा सकती हैं या नहीं. साथ ही, हम उपयोगकर्ताओं और डेवलपर, दोनों को ऐसे तरीके या सिग्नल देने की कोशिश कर रहे हैं जिनसे वे समझ पाएं कि इस सीमा पर कितना असर होगा. हमारे पास अभी शेयर करने के लिए कोई खास प्रस्ताव नहीं है, लेकिन हम जल्द ही मिलने की उम्मीद करते हैं. |
| FPS (फ़्रेम प्रति सेकंड) का नेटवर्क | निजता CG के बाहर, एफ़पीएस डेवलप करना जारी रखने में मदद करने के लिए जानकारी इकट्ठा करना | हम इस बात का ध्यान रखना चाहेंगे कि पहले पक्ष के सेट का प्रस्ताव PrivacyCG में रहे. हालांकि, हम डब्ल्यूआईसीजी में इस प्रस्ताव को आगे बढ़ाते रहेंगे. हमें फ़र्स्ट-पार्टी सेट और इसके इस्तेमाल के उदाहरणों के बारे में चर्चा करने को लेकर अपना समर्थन देने वाले कई बयानों से भी हमें प्रोत्साहित किया गया. Google ऐसे समाधान खोजने के लिए लगातार काम कर रहा है जिनकी मदद से, वेब को लगातार बेहतर बनाया जा सके और उसे बेहतर बनाया जा सके. इससे, उपयोगकर्ताओं की निजता को सुरक्षित रखा जा सकेगा और उनका सम्मान किया जा सकेगा. |
| ब्राउज़र इंटरऑपरेबिलिटी | दूसरे ब्राउज़र की मदद से लागू करना | हम डेवलपर के लिए ब्राउज़र इंटरऑपरेबिलिटी (दूसरे सिस्टम के साथ काम करने की क्षमता) की अहमियत को समझते हैं. साथ ही, FPS के स्टैंडर्ड तय करने के लिए, अन्य ब्राउज़र के साथ मिलकर काम करते रहेंगे. |
| निजता नीति से जुड़ी सामान्य शर्तें | एक ही सेट का हिस्सा बनने वाले सभी प्रॉडक्ट और अधिकार क्षेत्रों के लिए, एक जैसी निजता नीति बनाए रखना संभव नहीं होता. | Chrome अब भी नीति से जुड़ी ज़रूरी शर्तें तय कर रहा है. वह इस सुझाव/राय/शिकायत को ध्यान में रखेगा. |
फ़ेंस किए गए फ़्रेम का एपीआई
| सुझाव की थीम
(लोकप्रियता के हिसाब से रैंक की गई) |
सवालों और समस्याओं के बारे में खास जानकारी | Chrome रिस्पॉन्स |
| दस्तावेज़ का अनुरोध | सैंडबॉक्स किए गए iframes में अंतर | हम सुझाव और राय की सराहना करते हैं. GitHub पर इस बारे में मौजूदा चर्चा चल रही है. हमें उम्मीद है कि हमें अनुरोध पर पूरी तरह साफ़ तौर पर जानकारी मिल जाएगी, ताकि हम उसका पूरी तरह से आकलन कर सकें. सार्वजनिक चर्चा यहां उपलब्ध है. |
| क्रॉस-एपीआई क्षमताएं | फ़ेंस किए गए फ़्रेम में, एट्रिब्यूशन रिपोर्टिंग के लिए डिफ़ॉल्ट सहायता | हम उस प्रस्ताव पर सुझाव मांग रहे हैं जिससे एट्रिब्यूशन रिपोर्टिंग एपीआई को, डिफ़ॉल्ट रूप से फ़ेंस किए गए फ़्रेम के "ओपेक-विज्ञापन मोड" में अनुमति मिल सके. जिन डेवलपर को यह अहम लगता है उन्हें हम बातचीत में शामिल होने का सुझाव देते हैं. |
शेयर किया गया स्टोरेज एपीआई
| सुझाव की थीम
(लोकप्रियता के हिसाब से रैंक की गई) |
सवालों और समस्याओं के बारे में खास जानकारी | Chrome रिस्पॉन्स |
| डेटा की सीमाएं | क्या इस बात पर कोई पाबंदी होगी कि हर पार्टीशन के हिसाब से कितना डेटा सेव किया जा सकता है? | हां, इसकी सीमाएं होंगी. ज़्यादा जानकारी के लिए, GitHub से जुड़ी समस्या देखें. हमें स्टोरेज कोटा की ज़रूरत होगी. हमारा मौजूदा सुझाव है कि हर एंट्री के लिए साइज़ की सीमा 4 केबी की होनी चाहिए. कुंजी और वैल्यू, दोनों 1024 char16_t वर्णों तक सीमित होंगी. साथ ही, हर ऑरिजिन में 10,000 एंट्री वाले कैप को एक ऐसा तरीका दिया जाएगा जो ऑरिजिन की क्षमता पूरी होने पर अतिरिक्त एंट्री को काम करने से रोकता है. हम यहां बताई गई खास सीमाओं के बारे में सुझाव, शिकायत या राय ले रहे हैं. |
| उपयोगकर्ता पारदर्शिता | डेटा सोर्स बनाम डेटा खर्च के बारे में उपयोगकर्ता की पारदर्शिता | हम इस सुझाव/शिकायत/राय की सराहना करते हैं और हमें लगता है कि यह एक और दिलचस्प तरीका है. खास तौर पर, हम इस बात का आकलन कर रहे हैं कि क्या ऐसा करना मुमकिन है. साथ ही, उपयोगकर्ताओं को साफ़ तौर पर जानकारी दी जा सकती है. |
सीएचआईपीएस
| सुझाव की थीम
(लोकप्रियता के हिसाब से रैंक की गई) |
सवालों और समस्याओं के बारे में खास जानकारी | Chrome रिस्पॉन्स |
| अपनाने में रुकावट | क्या CHIPS में होस्टनेम का इस्तेमाल होना चाहिए? (डोमेन-डोमेन की ज़रूरत नहीं) | ओटी से यह ज़रूरी शर्त, हम ओटी से हटा रहे हैं. यह जानकारी ओटी से मिले सुझावों के आधार पर दी गई है. इसमें बताया गया है कि इस शर्त के लागू होने से और भी मुश्किल हो गई थी और सीएचआईपीएस को अपनाने में रुकावट भी आई थी.
हम निजता कम्यूनिटी ग्रुप में इस ज़रूरी शर्त के बारे में यहां बताएंगे. |
| सीएचआईपीएस के लिए, विज्ञापनों के इस्तेमाल के उदाहरण | क्या किसी एक साइट पर विज्ञापन दिखाने के लिए, सीएचआईपीएस का इस्तेमाल किया जा सकता है? | एक साइट में उपयोगकर्ता ट्रैकिंग को इस्तेमाल का अनुमति दी जा सकती है. इस्तेमाल के इस उदाहरण को हाइलाइट करने के लिए, हमने अपने डेवलपर लेख को अपडेट किया है. |
| पुष्टि किए गए एम्बेड | क्या साइन-ऑन स्थिति सीएचआईपीएस के साथ सुरक्षित रहती है? | 'साइन इन की गई' स्थिति को फ़िलहाल सेव नहीं किया गया है, लेकिन यह सीएचआईपीएस के इस्तेमाल के लिए सही नहीं है. हमें पुष्टि किए गए एम्बेड के इस्तेमाल के उदाहरण के बारे में पता है और हम समाधान ढूंढने के लिए काम कर रहे हैं. |
| टेस्ट कोऑर्डिनेशन | क्या पार्टीशन के बंटवारे की जांच करने के लिए, उपयोगकर्ता की कोई अन्य कार्रवाई ज़रूरी है? | जब तक ओटी टोकन मान्य है और देखे गए पेजों के हेडर में मौजूद है, तब तक यह सुविधा उपयोगकर्ताओं के लिए उपलब्ध होनी चाहिए. इसके लिए, उपयोगकर्ता को कोई दूसरी कार्रवाई करने की ज़रूरत नहीं होनी चाहिए |
| वेबसाइट का अलग-अलग ब्राउज़र पर चलना | यह जानने में दिलचस्पी कि अन्य ब्राउज़र ने कुकी के कई एट्रिब्यूट को अलग-अलग हिस्सों में कैसे हैंडल किया है. | Chrome, W3C जैसे सार्वजनिक मानकों वाले ग्रुप के तहत काम करना जारी रखता है, ताकि सभी ब्राउज़र पर काम करने वाले डिज़ाइन और उन्हें लागू करने की पहचान की जा सके. |
FedCM
| सुझाव की थीम
(लोकप्रियता के हिसाब से रैंक की गई) |
सवालों और समस्याओं के बारे में खास जानकारी | Chrome रिस्पॉन्स |
| संभावित अटैक वेक्टर | लिंक डेकोरेशन और टाइमिंग अटैक के ज़रिए संभावित अटैक वेक्टर | हम लगातार लोगों से जानकारी इकट्ठा कर रहे हैं और इस समस्या को हल करने के संभावित तरीकों का पता लगा रहे हैं. |
| एक से ज़्यादा आईडीपी (IdP) की अनुमति देने के लिए UX | एक बार में सिर्फ़ एक आईडीपी (IdP) प्रज़ेंट किया जा सकता है | हम एक से ज़्यादा आईडीपी (IDP) के साथ काम करने में भरोसा रखते हैं. साथ ही, हम सहायता करने के तरीकों पर लगातार काम कर रहे हैं |
| एक्सप्रेसिविटी | चिंता करें कि ब्राउज़र, फ़ेडरेटेड आइडेंटिटी फ़्लो के हिस्से को रेंडर करता है. इसलिए, उन सभी बारीकियों को कैप्चर करना मुश्किल है जो आईडीपी अपने उपयोगकर्ताओं को दिखाना चाहते हैं. | Chrome, ब्रैंडिंग में पसंद के मुताबिक बदलाव (जैसे कि लोगो, रंग) और स्ट्रिंग को पसंद के मुताबिक बनाने (जैसे कि "लॉगिन करें" के बजाय "इस लेख को ऐक्सेस करें") को शामिल कर रहा है.
Chrome, दोनों को एक-दूसरे के फ़ायदे समझते हैं और नेटवर्क के साथ काम करना जारी रखता है, ताकि वे ज़्यादा से ज़्यादा जानकारी दे सकें और ज़्यादा बेहतर तरीके से काम कर सकें. |
| लागू होने और इंटरऑपरेबिलिटी (दूसरे सिस्टम के साथ काम करना) | चिंता न करें कि दूसरे ब्राउज़र, FedCM को अपना या लागू नहीं करेंगे. | Chrome, FedID कम्यूनिटी ग्रुप में फ़ेडरेशन के लिए सामान्य समाधान खोजने के लिए, ब्राउज़र के अन्य वेंडर के साथ भी काम कर रहा है. |
| साइन-अप फ़्लो में, निजी डेटा से जुड़ी ज़रूरी शर्तों को हटाने का सुझाव | (1) एक ऐसा UX जो उपयोगकर्ता को यह बताता है कि वह कौनसा आईडीपी (IdP) चुन रहा है. साथ ही, उपयोगकर्ता की निजता को बनाए रखते हुए, उसका ईमेल, फ़ोटो, और नाम शेयर करने की जानकारी न दें
(2) उपयोगकर्ता अनुभव और आईडीपी (IdP) की मदद से दावे चुने जाने में, 'इस्तेमाल के उदाहरण' के लिए साइन-अप की सुविधा काफ़ी मुश्किल थी |
हमने इस पर सहमति जताई है. साथ ही, हम इस बात पर भी काम कर रहे हैं कि सुझाव, शिकायत या राय को उपयोगकर्ताओं के लिए, निजता और बेहतर तरीके से कैसे लागू किया जाए. |
| आईडीपी (IdP) के साथ उपयोगकर्ता का इंटरैक्शन | जोखिम की सीमा पार होने पर, उपयोगकर्ता और आईडीपी (IdP) के बीच सीधे तौर पर इंटरैक्शन करने की ज़रूरत | हम इस सुझाव की लगातार जांच कर रहे हैं. |
नेटवर्क स्टेट पार्टीशन
| सुझाव की थीम
(लोकप्रियता के हिसाब से रैंक की गई) |
सवालों और समस्याओं के बारे में खास जानकारी | Chrome रिस्पॉन्स |
| परफ़ॉर्मेंस | नेटवर्क की स्थिति को बांटने से, सीडीएन से ज़्यादा संसाधनों वाले कनेक्शन की संख्या बढ़ सकती है | हम अब भी नेटवर्क स्टेट पार्टीशन की परफ़ॉर्मेंस की विशेषताओं की जांच कर रहे हैं. इसमें कुंजी मैनेज करने वाली अलग-अलग संभावित स्कीम को मापना शामिल है. हमने अभी तक परफ़ॉर्मेंस, सुरक्षा, और निजता को ध्यान में रखते हुए कोई फ़ैसला नहीं लिया है. साथ ही, ज़्यादा डेटा इकट्ठा करने की ज़रूरत है. |
स्पैम और धोखाधड़ी को रोकना
Trust Tokens API
| सुझाव की थीम
(लोकप्रियता के हिसाब से रैंक की गई) |
सवालों और समस्याओं के बारे में खास जानकारी | Chrome रिस्पॉन्स |
| नियमों के पालन की शिकायत | लंबे समय के व्यवहार के बारे में, रेगुलेटर से साफ़ तौर पर मिले सिग्नल के बिना, ट्रस्ट टोकन में समय और संसाधनों के निवेश को लेकर चिंता | हमारा लक्ष्य ऐसी टेक्नोलॉजी बनाना है जो नेटवर्क के लिए काम करे. साथ ही, हम इस प्रक्रिया के लिए ज़रूरी उद्योग और रेगुलेटर से सुझाव लें. हम प्राइवसी सैंडबॉक्स बनाने और डेवलपर को प्रपोज़ल उपलब्ध कराने के लिए, दुनिया भर के रेगुलेटर से सलाह लेते रहेंगे. इन प्रपोज़ल में ट्रस्ट टोकन भी शामिल हैं. सभी नई टेक्नोलॉजी की तरह, कंपनियों को भी कानूनी शर्तों का आकलन खुद करने के आधार पर फ़ैसले लेने चाहिए. |
| लॉन्च का समय | GA के लिए ट्रस्ट टोकन कब लॉन्च किए जाएंगे? | हम privacysandbox.com पर अपने'सार्वजनिक टाइमलाइन' में, डिलीवरी के मौजूदा अनुमानों की जानकारी देते हैं. GA को इसकी डिलीवरी की तारीख पर आखिरी फ़ैसला लेते ही, हम उसे Chrome की रिलीज़ की प्रोसेस के ज़रिए सार्वजनिक तौर पर पोस्ट कर देंगे और वेबसाइट पर टाइमलाइन को अपडेट कर देंगे. |
| Trust Tokens बनाम अन्य | स्टैंडर्ड के मुताबिक तय किए जा रहे अन्य टोकन, जैसे कि प्राइवेट ऐक्सेस टोकन में ट्रस्ट टोकन क्या भूमिका निभाते हैं | हम मानक तय करने के लिए चर्चा कर रहे हैं और हमारा लक्ष्य है कि हम हर टेक्नोलॉजी के इस्तेमाल के लिए अलग-अलग तरीके उपलब्ध कराएं. साथ ही, हमारी कोशिश है कि हम अन्य कोशिशों के साथ भी काम करें. उदाहरण के लिए, ट्रस्ट टोकन और निजी ऐक्सेस टोकन, दोनों ही प्राइवसी पास प्रोटोकॉल पर निर्भर होते हैं. |
| डेटा की सीमाएं | हर पेज पर टोकन रिडीम करने के लिए, ज़्यादा से ज़्यादा दो लोग जारी कर सकते हैं. यह सीमित हो सकता है | हम लंबी अवधि के ऐसे विकल्पों की तलाश कर रहे हैं जिनकी मदद से, हम कंपनियों को सुरक्षित तरीके से टोकन रिडीम करने की अनुमति दे सकें. साथ ही, ऐसा करने से उपयोगकर्ता के ज़्यादा जोखिम के बिना, टोकन रिडीम करने के ऐक्सेस को बांटा जा सकता है. |
| ऐक्सेस से जुड़ी पाबंदियां | सिर्फ़ स्वीकार किए गए (और पुष्टि किए गए/नकली रेफ़रल देने वाले) के तौर पर पुष्टि किए गए ऑरिजिन, टोकन की मौजूदगी की पुष्टि और उसे रिडीम कर सकते हैं | हम टोकन देखने और उन्हें रिडीम करने के तरीके ढूंढ रहे हैं. |
| डिवाइस से जुड़ी सहायता | कुछ डिवाइसों पर JavaScript रनटाइम डिपेंडेंसी सीमित इस्तेमाल होती है. क्या अन्य प्रकार के डिवाइस पर काम करने के लिए TT समर्थन की व्यवस्था की जा सकती है? | इस पर हम आने वाले समय के डेवलपमेंट के लिए विचार कर सकते हैं. साथ ही, यह ऐसा विषय है जिसे हम W3C फ़ोरम में डेवलपर के ज़्यादा सुझाव, शिकायत या राय जानना चाहेंगे. हमारे पास एचटीटीपी हेडर से ट्रिगर किए गए टोकन रिडीम करने के बारे में चर्चा करने का भी एक सार्वजनिक समस्या है. हम इसके लिए सुझाव, शिकायत या राय भेजते हैं. |
| इस्तेमाल के उदाहरण | यह पता नहीं चल पा रहा है कि ट्रस्ट टोकन के इस्तेमाल के सही उदाहरण क्या हैं. इस सुविधा को इस्तेमाल करने के मकसद के बारे में ज़्यादा जानकारी नहीं दी गई है. | हमारा लक्ष्य धोखाधड़ी-विरोधी क्षेत्र में इनोवेशन को बढ़ावा देना है. साथ ही, यह समझना है कि हर कंपनी ट्रस्ट टोकन के साथ अपने मालिकाना हक वाली तकनीक का इस्तेमाल कर सकती है. इसलिए, हमने इसके इस्तेमाल के बारे में कोई निर्देश नहीं दिया है. हालांकि, हम अपने दस्तावेज़ों का दायरा बढ़ाने की कोशिश करेंगे, ताकि ज़्यादा उदाहरण शामिल किए जा सकें. ये उदाहरण उन पार्टनर के लिए शुरुआती बिंदु के तौर पर उपलब्ध होंगे जो कुछ नया करने या अपनाने के बारे में सोच रहे हैं. |
| ट्रस्ट टोकन कवरेज | 'ट्रस्ट-टोकन-रिडेंप्शन' सुविधा की इस नीति को हटाने से, ट्रस्ट टोकन का कवरेज काफ़ी बढ़ जाएगा. | इस पर विचार किया जा रहा है, क्योंकि हम ओटी से सुझाव लेते हैं और अगले चरणों के बारे में फ़ैसले लेते हैं. |
| जारी करने वाले का भरोसा | हमें भरोसेमंद टोकन जारी करने वाली वेबसाइटों पर क्यों भरोसा करना चाहिए? | कार्ड जारी करने वाले बैंक या कंपनी बनने के लिए कोई दिशा-निर्देश नहीं हैं. इसे कोई भी कर सकता है. यह उम्मीद की जाती है कि पब्लिशर, जारी करने वाले सिर्फ़ उन बैंक या कंपनियों के साथ काम करेंगे जिन पर उन्हें भरोसा है. इसके अलावा, विज्ञापन नेटवर्क में शामिल अन्य कानूनी लोग, संदिग्ध या अनजान जारी करने वालों से जुड़े ट्रैफ़िक पर रोक लगा देंगे या खरीदारी बंद कर देंगे. |
| 3P (तीसरे पक्ष का) एम्बेड की गई सेवाएं | क्या 3P (तीसरे पक्ष की) से एम्बेड की गई सेवाएं, ट्रस्ट टोकन को रिडीम और/या मांग सकती हैं? | हां, एम्बेड की गई 3P (तीसरे पक्ष की) सेवा, ट्रस्ट टोकन जारी कर सकती है और उन्हें रिडीम कर सकती है. |
| जारी करने वालों का नेटवर्क | अगर भरोसे के सिग्नल दूसरी कंपनियों के साथ शेयर किए जा सकते हैं, तो ज़्यादा बेहतर तरीके से काम किया जा सकता है | ट्रस्ट टोकन को इस तरह से डिज़ाइन किया गया है कि यह कम लेवल का हो. इसका इस्तेमाल, क्रेडिट जारी करने वालों/रिडीम करने वालों के साथ मिलकर काम करने वाले लोगों के साथ मिलकर, भरोसे/प्रतिष्ठा से जुड़े सिग्नल शेयर करने के लिए किया जा सकता है. |
| मेंटेनेंस ओवरहेड | Trust Token के क्रिप्टोग्राफ़िक इंप्लिमेंटेशन की वजह से, यह BoingSSL पर काम कर रही है. इसका रखरखाव Google ही करता है. लाइब्रेरी का रखरखाव कैसे मैनेज किया जाएगा? | Trust Tokens स्टैंडर्ड क्रिप्टोग्राफ़िक ऑपरेशन (प्राइवसी पास प्रोटोकॉल देखें) का इस्तेमाल करता है. इसे दूसरी लाइब्रेरी में भी लागू किया जा सकता है. हमारा सुझाव है कि डेवलपर अपनी पसंद की लाइब्रेरी में इन कार्रवाइयों के लिए सहायता का अनुरोध करें/डेवलप करें/रखकर काम करें. |
| मेंटेनेंस ओवरहेड | यह साफ़ तौर पर नहीं बताया गया है कि प्रोटोकॉल वर्शन कितने समय तक काम करेंगे | हम प्रोटोकॉल वर्शन के लिए, सहायता उपलब्ध कराने की अनुमानित समयसीमा के बारे में ज़्यादा जानकारी तैयार करने और रिकॉर्ड करने पर काम कर रहे हैं. |
| जारी करने वाले की सीमाएं | अगर आपका कारोबार इस चेन में बहुत नीचे है, तो हो सकता है कि आपको ट्रस्ट टोकन लागू करने का मौका न मिले | जैसे-जैसे ज़्यादा से ज़्यादा संगठन ट्रस्ट टोकन का इस्तेमाल करना शुरू कर देते हैं वैसे-वैसे हमें समय से जुड़े इस तरह के डाइनैमिक दिख सकते हैं. साथ ही, हम संभावित समाधानों का पता लगा सकते हैं. जैसा कि पहले बताया गया है, हम लंबी अवधि वाले ऐसे विकल्पों की तलाश कर रहे हैं जिनसे कंपनियों को, ज़्यादा उपयोगकर्ता एंट्रॉपी के जोखिम के बिना, सुरक्षित तरीके से टोकन रिडीम करने की अनुमति मिल सके. इससे, पेज पर जगह की जानकारी या ऑर्डर लोड होने की अहमियत कम हो जाएगी. |
इनक्यूबेशन के ख़िलाफ़ धोखाधड़ी रोकने के नए समाधान
| सुझाव की थीम
(लोकप्रियता के हिसाब से रैंक की गई) |
सवालों और समस्याओं के बारे में खास जानकारी | Chrome रिस्पॉन्स |
| डिवाइस इंटिग्रिटी को प्रमाणित करने के सिग्नल | डिवाइस को पूरी सुरक्षा देने की सुविधा के साथ, प्लैटफ़ॉर्म से प्रमाणित और वेब पर उपलब्ध कराए गए सिग्नल को लागू करने के लिए, आम तौर पर मज़बूत सपोर्ट | हम सुझाव इकट्ठा करते रहेंगे और प्रस्ताव को सार्वजनिक तौर पर डिज़ाइन करेंगे और बार-बार लागू करेंगे. |
| डिवाइस इंटिग्रिटी को प्रमाणित करने के सिग्नल | नए सिग्नल के ज़रिए, यूज़र एंट्रॉपी की मात्रा के बारे में जानकारी देने के साथ-साथ, यह भी सवाल है कि क्या इस्तेमाल के कुछ उदाहरण (जैसे, अपने बैंक में लॉगिन करने वाला उपयोगकर्ता) ज़्यादा एंट्रॉपी सिग्नल को सही साबित कर सकते हैं या नहीं. | उपयोगकर्ता की निजता को बनाए रखने के लिए, हम ज़्यादा से ज़्यादा उपयोगकर्ता एंट्रॉपी के साथ बेहतर सिग्नल उपलब्ध कराने की कोशिश करते हैं. |
| डिवाइस इंटिग्रिटी को प्रमाणित करने के सिग्नल | क्या यह सिग्नल, ओपन सोर्स/बदलाव किए गए प्लैटफ़ॉर्म या पुराने डिवाइसों के लिए ऐक्सेस को सीमित करेगा? | किसी भी नए सिग्नल को डेवलपमेंट के दौरान, यूनिवर्सल ऐक्सेस को एक अहम सिद्धांत के तौर पर देखना चाहिए. इंक्यूबेशन की प्रक्रिया जारी रखने के लिए, इन अहम सवालों के बारे में सबसे पहले बताया जाना चाहिए. |
| डिवाइस इंटिग्रिटी को प्रमाणित करने के सिग्नल | नए सिग्नल की वजह से, सुरक्षा और धोखाधड़ी रोकने वाली कंपनियों को ब्राउज़र और प्लैटफ़ॉर्म पर बहुत ज़्यादा भरोसा करना पड़ सकता था, यह चिंता की बात थी
|
किसी भी नए सिग्नल को पूरक डेटा के तौर पर देखा जाना चाहिए, न कि ब्राउज़र से "ट्रस्ट" को दिखाने के तौर पर. हम पूरी तरह से उम्मीद करते हैं कि सुरक्षा कंपनियां, अतिरिक्त इनपुट के तौर पर अपने मालिकाना हक वाले डेटा, मॉडल, और डिसिज़न इंजन की मदद से, डिवाइस से पुष्टि करने के तरीके का इस्तेमाल करती रहेंगी. हमें उम्मीद है कि किसी भी नए सिग्नल से पूरे नेटवर्क में उल्लंघन का पता लगाने की कोशिशों में सुधार होगा. साथ ही, धोखाधड़ी को अंजाम देना और मुश्किल हो जाएगा. |
| कुकी की उम्र का सिग्नल | यह कॉन्सेप्ट दिलचस्प है, लेकिन इसके इस्तेमाल के उदाहरणों के बारे में ज़्यादा जांच करने की ज़रूरत है. | दिलचस्पी के लेवल के आधार पर, Chrome इस कॉन्सेप्ट पर और आइडिया तैयार कर सकता है. साथ ही, आने वाले समय में नेटवर्क के बारे में सुझाव/राय देने या शिकायत करने के लिए इसका एक एक्सप्लेनेशन कर सकता है. |
| धोखाधड़ी के ख़िलाफ़ भरोसेमंद सर्वर | यह कॉन्सेप्ट दिलचस्प है, लेकिन इसके इस्तेमाल के उदाहरणों के बारे में ज़्यादा जांच करने की ज़रूरत है. | दिलचस्पी के लेवल के आधार पर, Chrome इस कॉन्सेप्ट पर और आइडिया तैयार कर सकता है. साथ ही, आने वाले समय में नेटवर्क के बारे में सुझाव/राय देने या शिकायत करने के लिए इसका एक एक्सप्लेनेशन कर सकता है. |