साल 2023 की पहली तिमाही की तिमाही रिपोर्ट, जिसमें 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 APIs की टेस्टिंग पूरी नहीं होती है, तो सीएमए के आकलन के बारे में बताने के लिए टेस्टिंग की ज़रूरत | Privacy Sandbox के एपीआई को तेज़ी से डेवलप किया जा रहा है.
ये सुविधाएं, टेस्टिंग के लिए Origin Trial में पहले से ही उपलब्ध हैं. आम तौर पर, ये इस गर्मी में 100% ट्रैफ़िक के लिए उपलब्ध होंगी. इसके अलावा, हमने कुछ सुविधाओं के लिए समयसीमा तय की है. जैसे, FLEDGE इवेंट-लेवल रिपोर्टिंग, iframes के साथ FLEDGE रेंडरिंग. इन सुविधाओं पर साल 2026 से पहले कोई असर नहीं पड़ेगा. हम एपीआई को टेस्ट करने के लिए, नेटवर्क को बढ़ावा देते हैं. साथ ही, तीसरे पक्ष की कुकी के बंद होने के बाद, टेस्टर किस पर भरोसा कर सकते हैं, इस आधार पर सीएमए को सुझाव/राय देते हैं. इससे, तीसरे पक्ष की कुकी के काम न करने से होने वाले संभावित असर का आकलन करने में मदद मिल सकती है. |
| उपयोगकर्ता नियंत्रण | प्राइवसी सैंडबॉक्स एपीआई के उपयोगकर्ता कंट्रोल के असर के बारे में, नेटवर्क को साफ़ तौर पर निर्देश देना | हम इस बारे में कानूनी सलाह नहीं दे सकते कि उपयोगकर्ता के किन कंट्रोल का इस्तेमाल, नेटवर्क कर सकता है. साथ ही, Chrome कुछ उपयोगकर्ताओं को Privacy Sandbox ("बेहतर विज्ञापन निजता") के अपडेट किए गए उपयोगकर्ता कंट्रोल दिखाने की सुविधा दे रहा है. ऐसा, Privacy Sandbox की टेक्नोलॉजी को बेहतर बनाने के लिए किया जा रहा है. इन अपडेट में, आसान भाषा और मददगार लेआउट शामिल किए गए हैं. जब Chrome इन सुधारों का आकलन कर लेगा और यह तय कर लेगा कि उन्हें ज़्यादा लोगों के लिए उपलब्ध कराना है या नहीं, तब वह इकोसिस्टम के साथ ज़्यादा जानकारी शेयर कर सकता है. |
| डेटा लीक | ब्राउज़र के हैक होने पर, पहले पक्ष के डेटा के Google और अन्य पक्षों के पास लीक होने का जोखिम | FLEDGE के बारे में जानकारी देने वाले हमारे लेख से पता चलता है कि किसी विज्ञापन टेक्नोलॉजी का डेटा सिर्फ़ उसी विज्ञापन टेक्नोलॉजी के साथ शेयर किया जाता है. जैसे, उसके वर्कलेट या भरोसेमंद सर्वर के साथ. इसके अलावा, जब विज्ञापन टेक्नोलॉजी, डेटा को साफ़ तौर पर शेयर करती है, तब भी ऐसा किया जा सकता है. जैसे, जब कोई खरीदार, सेलर को वह विज्ञापन यूआरएल दिखाता है जिसे उसे दिखाना है. हालांकि, एक अपवाद है. यह है कि क-निजता की जांच, ग्लोबल सेंट्रलाइज़्ड सर्वर से की जानी चाहिए. हम इस क्षेत्र में लगातार ज़्यादा से ज़्यादा संसाधनों का इस्तेमाल करते रहे हैं. निजता को लेकर हमारी नीति के बारे में ज़्यादा जानने के लिए, K-anonymity के बारे में जानकारी देखें. इसके अलावा, हम इस बारे में ज़्यादा जानकारी देने के लिए तैयार हैं कि क-निजता बनाए रखने वाले सर्वर के डिज़ाइन में, विज्ञापन टेक्नोलॉजी से जुड़ी सुरक्षा कैसे काम करती है. |
| चर्चा के लिए अन्य फ़ोरम | W3C से एक और फ़ोरम बनाने का अनुरोध, ताकि गैर-तकनीकी ईकोसिस्टम के खिलाड़ी सुझाव/राय/शिकायत शेयर कर सकें | निजता Sandbox के बारे में सुझाव, शिकायत या राय देने के लिए फ़ॉर्म, सामान्य और खास टिप्पणियों, तकनीकी और गैर-तकनीकी टिप्पणियों के लिए सही है. वेब विज्ञापन कारोबार को बेहतर बनाने वाला ग्रुप, हर हफ़्ते होने वाले कॉल और GitHub रेपो के ज़रिए चर्चा करने के लिए एक फ़ोरम है. Privacy Sandbox के सुझाव/राय/शिकायत पेज पर, सुझाव/राय/शिकायत देने और चर्चा में हिस्सा लेने के अन्य तरीकों के बारे में बताया गया है. Chrome, सवाल पूछने और कॉन्टेंट शेयर करने के लिए, ऑफ़िस में कामकाज के घंटों के दौरान होने वाले सार्वजनिक इवेंट भी आयोजित करता रहता है. इसके अलावा, Chrome ने पिछली तिमाही में एक दर्जन से ज़्यादा इंडस्ट्री इवेंट होस्ट किए हैं या उनमें हिस्सा लिया है. |
| टाइमलाइन के बारे में साफ़ तौर पर बताई गई जानकारी | साल 2023 की तीसरी तिमाही में, सामान्य तौर पर उपलब्ध होने की तारीख के बारे में जानकारी | PrivacySandbox.com पर पब्लिश की गई टाइमलाइन के मुताबिक, Chrome के वर्शन 115 के रिलीज़ होने के साथ ही, सामान्य रूप से उपलब्ध होने की सुविधा को रोल आउट किया जाएगा. |
| reCAPTCHA | reCATPCHA के स्पैम की पहचान करने वाले इस्तेमाल के उदाहरण के लिए, सैंडबॉक्स एपीआई का असर | हमें समय-समय पर reCAPTCHA से सुझाव मिलते रहते हैं. इससे हमें यह पक्का करने में मदद मिलती है कि निजता सैंडबॉक्स के प्रस्तावों से, वेब की सुरक्षा या धोखाधड़ी पर काफ़ी असर न पड़े. वे तीसरे पक्ष की कुकी के इस्तेमाल को रोकने के लिए, खुद का प्लान बना रहे हैं. इसलिए, यह सवाल उनसे पूछा जाना चाहिए. |
| Chrome एक्सटेंशन | क्या Privacy Sandbox की टेक्नोलॉजी, जैसे कि छिपकर ट्रैकिंग को रोकने (ACT) के उपाय, Chrome एक्सटेंशन पर लागू होंगे? | हमने इस बारे में कोई एलान नहीं किया है कि ACT, Chrome एक्सटेंशन पर लागू हो सकता है या नहीं. हालांकि, अगर कोई टेक्नोलॉजी किसी उपयोगकर्ता की जानकारी चुपके से इकट्ठा करती है, तो यह हमारे निजता के सिद्धांतों के मुताबिक नहीं होगा. |
काम का कॉन्टेंट और विज्ञापन दिखाना
विषय
| सुझाव, शिकायत या राय की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| टैग के डिज़ाइन की समीक्षा | TAG ने Topics के डिज़ाइन की शुरुआती समीक्षा रिलीज़ की है. | हम Topics के लिए प्रतिबद्ध हैं. हमने नए अपडेट वाले पेज और इस अंक में, अपनी प्रतिबद्धता के बारे में अपडेट शेयर किया है. हमने TAG की समीक्षा के हर बिंदु का जवाब दिया है. साथ ही, अपने ज़्यादा बेहतर विज़न को यहां शेयर किया है. Topics API, उन एपीआई के कलेक्शन का हिस्सा बना रहेगा जिनकी जांच, विज्ञापन नेटवर्क को 2023 में करनी चाहिए. हमें उम्मीद है कि टेस्टिंग के दौरान मिले सुझाव और शिकायतों के साथ-साथ, एपीआई को लागू करने के अनुभव से, इस क्षेत्र में क्रॉस-ब्राउज़र स्टैंडर्ड के काम को आगे बढ़ाने में मदद मिलेगी. हम Topics API को क्रॉस-ब्राउज़र कंपैटिबिलिटी के साथ, एक मानक के तौर पर इस्तेमाल करने के लिए, नेटवर्क के साथ काम करना जारी रखेंगे. |
| विषयों के लिए रणनीति | Topics API को डेवलप करने के लिए, Chrome के ओपन ऐप््रोच के साथ काम करने की सुविधा | हमें आपके सुझावों की सराहना है. हम Topics API को बेहतर बनाने के लिए, इंडस्ट्री ग्रुप के साथ मिलकर काम करना जारी रखेंगे. इससे, पूरे नेटवर्क को फ़ायदा मिलेगा. |
| (इसकी शिकायत तीसरी तिमाही 2022 में भी की गई थी) विषय के लिए टैक्सोनॉमी ज़रूरत के मुताबिक नहीं है |
बड़े विषयों के टैक्सोनॉमी में, ज़्यादा जानकारी वाले विषय शामिल नहीं होते. इनमें क्षेत्र के हिसाब से बने विषय भी शामिल हैं. | पहली तिमाही का अपडेट: टैक्सोनॉमी को बेहतर बनाने की हमारी कोशिशें लगातार जारी हैं. हम दूसरी तिमाही में, Topics API के लिए अपडेट की गई टैक्सोनॉमी का एलान करेंगे. इस नए टैक्सोनॉमी को तैयार करने के लिए, हमने पूरे नेटवर्क की कंपनियों के साथ मिलकर काम किया. हम टैक्सोनॉमी के बारे में लगातार सुझाव, राय या राय देने के लिए अनुरोध कर रहे हैं. इससे हमें यह तय करने में मदद मिलेगी कि ईकोसिस्टम के लिए कौनसी टैक्सोनॉमी सबसे ज़्यादा काम की होगी. विषयों की संख्या बढ़ाने या ज़्यादा जानकारी वाले विषयों को शामिल करने के बारे में तय करते समय, कुछ बातों का ध्यान रखना ज़रूरी है. जैसे, 1) निजता पर पड़ने वाले संभावित असर (ज़्यादा विषयों की वजह से फ़िंगरप्रिंटिंग का खतरा बढ़ सकता है) और 2) पहले से निगरानी में रखे गए विषयों को वापस पाने की सुविधा (ज़्यादा विषयों की वजह से, विज्ञापन टेक्नोलॉजी को चुने गए विषय को पहले देखे जाने की संभावना कम हो सकती है). |
| (इसकी जानकारी 2022 की चौथी तिमाही में भी दी गई थी) पहले पक्ष के सिग्नल पर असर |
Topics सिग्नल काफ़ी अहम हो सकता है. इस वजह से, दिलचस्पी के आधार पर पहले पक्ष के अन्य सिग्नल की वैल्यू कम हो जाती है. | हमारा मानना है कि दिलचस्पी के मुताबिक विज्ञापन दिखाना, वेब के लिए एक अहम इस्तेमाल का उदाहरण है. Topics को इसी इस्तेमाल के उदाहरण के हिसाब से डिज़ाइन किया गया है. हम समझते हैं कि कुछ बड़े पब्लिशर को इस बात की चिंता है कि Topics की वजह से, पहले पक्ष के डेटा से जुड़ी उनकी रणनीतियों पर बुरा असर पड़ेगा. हम नेटवर्क की जांच करने के लिए उत्साहित हैं. इससे हमें यह जानकारी मिलेगी कि Topics का पब्लिशर पर क्या असर पड़ा है. |
| विज्ञापन से जुड़े विषयों के इस्तेमाल के उदाहरण | दिलचस्पी के मुताबिक विज्ञापन दिखाने के अलावा, विषयों का इस्तेमाल अन्य कामों के लिए करना | Topics को दिलचस्पी के हिसाब से विज्ञापन दिखाने के उदाहरण को ध्यान में रखकर डिज़ाइन किया गया है. हमें लगता है कि यह मुफ़्त और खुले वेब के लिए एक अहम उदाहरण है. फ़िलहाल, हम अन्य इस्तेमाल के उदाहरणों के बारे में सुझाव, राय या शिकायतें मांग रहे हैं और उनका आकलन कर रहे हैं. |
| डिफ़ॉल्ट ऑप्ट-इन स्टेटस | क्षेत्रीय कानूनों का असर, Topics के लिए सहमति की डिफ़ॉल्ट सेटिंग पर | कानूनी राय पर टिप्पणी करना हमारी ज़िम्मेदारी नहीं है. |
| (इसकी शिकायत 2022 की तीसरी तिमाही में भी की गई थी) गलत कैटगरी में शामिल की गई साइटें |
जब किसी साइट के लिए विषयों को गलत कैटगरी में रखा गया हो, तब विज्ञापन टारगेटिंग | पहली तिमाही का अपडेट: हम दूसरी तिमाही में, Topics API के लिए अपडेट किए गए क्लासिफ़ायर का एलान करेंगे. साथ ही, इस पर नेटवर्क के साथ जुड़ने के लिए उत्साहित हैं. मौजूदा सुझाव/राय के आधार पर, साइटों को अलग-अलग कैटगरी में बांटा जाता है. इसके लिए, सबसे लोकप्रिय साइटों की सूची और डिवाइस पर मौजूद एमएल मॉडल का इस्तेमाल किया जाता है. Chrome, विषयों को अलग-अलग कैटगरी में बांटने में मदद करने के लिए, साइटों के विकल्पों का आकलन करता रहता है. किसी भी सुविधा में सुधार करते समय, निजता और गलत इस्तेमाल से जुड़े जोखिमों को ध्यान में रखना ज़रूरी है. उदाहरण के लिए, कुछ जोखिमों में ये शामिल हैं: अलग-अलग (और संभवतः संवेदनशील) मतलब को कोड में बदलने के लिए, खुद को लेबल करने की सुविधा का इस्तेमाल करने वाली साइटें; वित्तीय फ़ायदा पाने के लिए, अपने विषयों को गलत तरीके से पेश करने वाली साइटें; दूसरों के लिए विषयों की उपयोगिता को कम करने के लिए, उन पर हमला करने वाली साइटें (उदाहरण के लिए, उपयोगकर्ता के विषयों पर बेमतलब की बातें करके स्पैम करना). chrome://topics-internals या इस colab की मदद से, सभी लोग इन कॉम्पोनेंट की जांच कर सकते हैं. टेस्टिंग की मदद से, हमें उम्मीद है कि समय के साथ कैटगरी तय करने की प्रोसेस बेहतर होगी. साथ ही, हम उन साइटों के उदाहरणों के सुझाव, शिकायत या राय का स्वागत करते हैं जिन्हें गलत कैटगरी में रखा गया हो. |
| Topics की कैटगरी तय करने वाला टूल | डीबग करने के मकसद से, कॉल करने वाले व्यक्ति को "कोई विषय नहीं" दिखाए जाने पर, वजहें बताने वाली ज़्यादा जानकारी दिखाने का अनुरोध | हम समझते हैं और इस बात की सराहना करते हैं कि डीबग करने वाले टूल, डेवलपर के लिए मददगार होते हैं. ऐसा इसलिए, क्योंकि वे अपने सिस्टम में Topics API को इंटिग्रेट करने के लिए काम करते हैं. हालांकि, ज़्यादा जानकारी (जैसे, कोई विषय न मिलने की वजह) ज़ाहिर करने पर, हम गलती से ऐसी जानकारी शेयर कर सकते हैं जिससे तीसरे पक्ष को ज़्यादा जानकारी मिल सकती है. उदाहरण के लिए, अगर कोई उपयोगकर्ता गुप्त मोड में है, एपीआई बंद कर दिया है वगैरह. इससे उपयोगकर्ता की निजता को नुकसान पहुंच सकता है. फ़िलहाल, हम डीबग करने के लिए और टूल उपलब्ध नहीं करा रहे हैं. हालांकि, हम इस बारे में सुझाव, शिकायत या राय देने के लिए हमेशा तैयार हैं कि कौनसे टूल काम के होंगे. |
| निजी जानकारी वापस पाने से जुड़ा प्रोटोकॉल (पीआईआर) | निजी जानकारी वापस पाने से जुड़ा प्रोटोकॉल अपनाने के लिए, Topics API के लिए अनुरोध | हमने पहले भी पीआईआर का इस्तेमाल करने की जांच की है और इसके फ़ायदे और नुकसान यहां शेयर किए हैं. |
| बिड स्ट्रीम | क्या बिड स्ट्रीम में, विषयों को सेलर की तय की गई ऑडियंस से अलग दिखाया जाएगा? | Topics API, Privacy Sandbox का एक प्रस्ताव है. इसे Chrome ने डेवलप किया है. यह IAB Tech Lab के सेलर की तय की गई ऑडियंस के प्रस्ताव से अलग है. हमें उम्मीद है कि बिड स्ट्रीम में, दोनों को अलग-अलग दिखाया जाएगा. जानें कि विषयों को OpenRTB बिड रिक्वेस्ट में कैसे दिखाया जाएगा. |
Protected Audience API (पहले इसे FLEDGE के नाम से जाना जाता था)
| सुझाव, शिकायत या राय की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| FLEDGE की सुविधा की उपलब्धता | FLEDGE की सुविधाओं को टेस्ट करने और लागू करने के लिए, समयसीमा के बारे में जानकारी. जैसे, फ़ेंस किए गए फ़्रेम को लागू करना, K-Anonymity वगैरह. | हमने FLEDGE की अलग-अलग सुविधाओं के बारे में स्टेटस शेयर किया है. साथ ही, यह भी बताया है कि ये सुविधाएं कब उपलब्ध होंगी. हम इस सुविधा के बारे में आपके सुझाव, राय या शिकायतों का स्वागत करते हैं. हम FLEDGE को लगातार बेहतर बना रहे हैं. |
| प्रॉडक्ट रेंडर करने से जुड़ी पाबंदियां | FLEDGE फ़ेंस किए गए फ़्रेम के लिए, एक से ज़्यादा हिस्सों वाले विज्ञापनों पर लगी पाबंदियों को हटाने का अनुरोध | हमने फ़रवरी में एलान किया था कि कम से कम 2026 तक, फ़ेंस किए गए फ़्रेम का इस्तेमाल करना ज़रूरी नहीं होगा. साथ ही, urn-iframes की मदद से iframes का व्यवहार काम करेगा. हम इस विषय पर आगे भी चर्चा करने के लिए तैयार हैं. |
| स्केलेबल बनाने से जुड़ी समस्याएं | इस्तेमाल के स्केल के हिसाब से FLEDGE की परफ़ॉर्मेंस | हम सुझावों और राय पर लगातार काम कर रहे हैं. साथ ही, हम इस बारे में ज़्यादा जानकारी इकट्ठा कर रहे हैं, ताकि हम आपको काम के समाधान दे सकें. सबसे पहले, हमने सुझावों और राय को दो कैटगरी में बांटा:
|
| (इसकी शिकायत 2022 की तीसरी तिमाही में भी की गई थी) बिडिंग लॉजिक की जानकारी |
डीएसपी बिडिंग लॉजिक को JavaScript में एक्सपोज़ होने की चिंता | पहला क्वॉर्टर अपडेट: हमने एक प्रस्ताव शेयर किया है. इससे, नुकसान पहुंचाने वाले लोग या ग्रुप, एक्सप्लोरेटिव (फ़ोर्स ब्राउज़िंग) तरीके से, सर्वर से डेटा का अनुरोध नहीं कर पाएंगे. हम इकोसिस्टम के लोगों या ग्रुप का स्वागत करते हैं, ताकि वे इस प्रस्ताव के बारे में अपना सुझाव, राय या शिकायत शेयर कर सकें. |
| जांच से जुड़ी समस्याएं | छोटे डीएसपी, FLEDGE की सही तरीके से जांच कर सकते हैं. साथ ही, इस जोखिम को कम कर सकते हैं कि विज्ञापन देने वाले सिर्फ़ बड़े डीएसपी के साथ जांच करना चाहते हैं | हम छोटे डीएसपी के साथ काम करने के लिए प्रतिबद्ध हैं. साथ ही, हम सभी तरह के डीएसपी और विज्ञापन देने वालों के बीच ज़्यादा से ज़्यादा टेस्टिंग करने का सुझाव देते हैं, क्योंकि FLEDGE अब सभी के लिए उपलब्ध है. हमें यह जानने में दिलचस्पी है कि हम, पारिस्थितिक तंत्र में मौजूद अन्य लोगों के साथ FLEDGE को टेस्ट करने में, उनकी सबसे अच्छी तरह से मदद कैसे कर सकते हैं. साथ ही, हम विज्ञापन देने वालों को छोटे डीएसपी के साथ टेस्ट करने के लिए, उद्योग के सुझावों और कोशिशों का स्वागत करते हैं. |
| डायनामिक रीमार्केटिंग | क्या तीसरे पक्ष की कुकी के बंद होने के बाद भी, FLEDGE की मदद से डाइनैमिक रीमार्केटिंग की सुविधा का इस्तेमाल किया जा सकेगा? | हम इस सवाल का जवाब देने पर विचार कर रहे हैं. साथ ही, हम पारिस्थितिकी तंत्र के खिलाड़ियों को इस बारे में ज़्यादा जानकारी देने के लिए कहते हैं कि वे डाइनैमिक रीमार्केटिंग का इस्तेमाल कैसे करना चाहते हैं. |
| धोखाधड़ी/गलत इस्तेमाल | इकोसिस्टम, इन जोखिमों को कैसे कम कर सकता है और बुरे मकसद से काम करने वाले लोगों या खरीदारों को, अपनी पहचान को काम की ऑडियंस के तौर पर पेश करने से कैसे रोक सकता है? | हम धोखाधड़ी और गलत इस्तेमाल को रोकने के लिए, नेटवर्क के सभी प्लेयर के साथ मिलकर काम करना चाहते हैं. साथ ही, इस बारे में हमें ज़्यादा सुझाव, राय या शिकायतें भेजें. |
| उपयोगकर्ता प्राथमिकताएं | उपयोगकर्ता की प्राथमिकताएं सेव करने और विज्ञापन चुनने में उनका इस्तेमाल करने की प्रोसेस | खास विज्ञापनों के लिए, काम की विज्ञापन टेक्नोलॉजी वाली कंपनी ही यह कंट्रोल कर सकती है कि कौनसे क्रिएटिव दिखाए जाएं या उन्हें कैसे चुना जाए. |
| क्वांटिटेटिव टेस्टिंग का प्रस्ताव | संख्या के हिसाब से टेस्टिंग को सही बनाने के लिए, क्या तीसरे पक्ष की कुकी के बिना ट्रैफ़िक पर या सिर्फ़ FLEDGE का इस्तेमाल करने वाले एसएसपी के साथ टेस्ट किया जाना चाहिए? तीसरे पक्ष की कुकी से मिले सिग्नल को आपस में मिक्स होने से कैसे रोका जा सकता है? | हमें आपका सुझाव/राय मिलना अच्छा लगा. हम सीएमए के साथ मिलकर ऐसे एक्सपेरिमेंट डिज़ाइन कर रहे हैं जिनसे यह पता चल सके कि तीसरे पक्ष की कुकी के इस्तेमाल को बंद करने और Privacy Sandbox के प्रस्तावों को लागू करने से, नेटवर्क पर क्या असर पड़ेगा. हमारा सुझाव है कि सीएमए के क्वांटिटेटिव टेस्टिंग के प्रस्ताव के बारे में ज़्यादा सुझाव, सीधे सीएमए के साथ शेयर किए जाएं. |
| बेहतर दस्तावेज़ | नीलामी के कॉन्फ़िगरेशन के बारे में ज़्यादा जानकारी देने वाले दस्तावेज़ का अनुरोध | आने वाले हफ़्तों में, हम FLEDGE नीलामी रिपोर्टिंग के बारे में ज़्यादा जानकारी देने वाली एक ब्लॉग पोस्ट शेयर करेंगे. |
| एक साथ कई प्रोसेस चलाना | क्या बिडिंग और नीलामी (बीए) सेवा, एक साथ कई प्रोसेस करने की सुविधा के साथ काम करेगी? | बिडिंग / नीलामी सर्वर का इस्तेमाल करने वाली विज्ञापन टेक्नोलॉजी, कई सर्वर शुरू कर सकती है, जो एक साथ नतीजे दिखा सकते हैं. |
| बुरे बर्ताव को कम करना | क्या प्राइवेट स्टेट टोकन का इस्तेमाल करने वाला FLEDGE k-anonymity सर्वर, उपयोगकर्ता की निजता को बनाए रखने के लिए काफ़ी होगा? | क-अनामिटी का मकसद, माइक्रोटारगेटिंग पर कम और उस बीच के फ़ेज़ में कुछ बैकस्टॉप पर ज़्यादा ध्यान देना है जहां FLEDGE, इवेंट-लेवल की रिपोर्टिंग की अनुमति देता है. हमने इस बारे में ज़्यादा जानकारी शेयर की है. साथ ही, अगर आपके पास कोई और सुझाव, राय या शिकायत है, तो हमें बताएं. |
| ES मॉड्यूल कॉन्फ़्लिक्ट | generateBid को ग्लोबल फ़ंक्शन के तौर पर हटाने का अनुरोध, क्योंकि यह ES मॉड्यूल के साथ काम नहीं करता |
हम इस अनुरोध पर विचार कर रहे हैं. अगर आपके पास कोई और सुझाव, राय या शिकायत है, तो हमें बताएं. |
| कॉम्पोनेंट की नीलामी | पब्लिशर के लिए, नीलामी के डिज़ाइन पर ज़्यादा कंट्रोल का अनुरोध | कॉम्पोनेंट की नीलामी के लिए बिडिंग और नीलामी प्लान, डिवाइस पर Chrome की तरह ही. |
| B&A टाइमलाइन | B&A सर्वर की टेस्टिंग में दिलचस्पी रखने वाले विज्ञापन टेक्नोलॉजी के लिए, टाइमलाइन के बारे में जानकारी | हमने हाल ही में, बीए और ए के बारे में जानकारी देने वाले पेज को अपडेट किया है. साथ ही, टाइमलाइन सेक्शन को अपडेट किया है, ताकि सीएमए के साथ अलाइन करने के बाद, Chrome-बीए और ए टेस्टिंग के अलग-अलग चरणों के लिए टाइमलाइन की साफ़ तौर पर परिभाषाएं शामिल की जा सकें. |
| टाइम आउट कंट्रोल स्कीम | फ़िलहाल, FLEDGE के लिए उपलब्ध टाइम आउट कंट्रोल स्कीम को बेहतर बनाना | यह एक दिलचस्प प्रस्ताव है. हम इसे स्टडी के लिए सुझावों की सूची में जोड़ेंगे और आगे की प्रोसेस के बारे में आपको बताएंगे. |
| क्रिएटिव बिड स्ट्रीम | क्रिएटिव के आधार पर, विजेता बिड की समीक्षा करने और उसे फ़िल्टर करने की सुविधा | यह एक दिलचस्प प्रस्ताव है. हम इसे स्टडी के लिए सुझावों की सूची में जोड़ेंगे और आगे की प्रोसेस के बारे में आपको बताएंगे. |
reportWin |
reportWin फ़ंक्शन में विजेता के अलावा, किसी दूसरे इंटरेस्ट ग्रुप के मालिक की सबसे ज़्यादा स्कोर वाली बिड के बारे में ज़्यादा जानकारी देने का प्रस्ताव |
यह एक दिलचस्प प्रस्ताव है. हम एग्रीगेट रिपोर्टिंग में ज़्यादा सिग्नल जोड़ने पर विचार करेंगे. साथ ही, अगर आपके पास कोई और सुझाव है, तो यहां बताएं. |
| इवेंट किस तरह के हैं | FLEDGE के साथ इंटिग्रेट करने पर, मेज़रमेंट एपीआई में इवेंट टाइप को स्टैंडर्ड बनाना | यह एक दिलचस्प प्रस्ताव है. हम इसे स्टडी के लिए सुझावों की सूची में जोड़ेंगे और आगे की प्रोसेस के बारे में आपको बताएंगे. इसके लिए, इस क्षेत्र में हमारे बड़े प्रयासों के साथ समन्वय करना ज़रूरी होगा, क्योंकि इससे FLEDGE के अलावा Privacy Sandbox के अन्य एपीआई पर भी असर पड़ेगा. अगर आपके पास कोई और सुझाव/राय/शिकायत है, तो यहां बताएं. |
| इवेंट-लेवल की रिपोर्टिंग के लिए लंबे समय तक काम करने वाले समाधान | तीसरे पक्ष की कुकी के बंद होने के बाद भी, highestScoringOtherBid जैसे कुछ डेटा को उपलब्ध रखने में दिलचस्पी |
जैसा कि हमने फ़रवरी की ब्लॉग पोस्ट में बताया था, इवेंट-लेवल पर नीलामी में जीतने की रिपोर्टिंग, "कम से कम 2026" तक काम करेगी. फ़िलहाल, हमारे पास ज़्यादा जानकारी शेयर करने के लिए कुछ नहीं है. हालांकि, तीसरे पक्ष की कुकी के बंद होने के बाद भी कुछ डेटा उपलब्ध रखने की ज़रूरत क्यों है, इस बारे में हमें ज़्यादा सुझाव/राय दें. |
| एक जैसी दिलचस्पी वाले ग्रुप की सीमा | किसी ऑरिजिन के लिए, एक ब्राउज़र को कितने इंटरेस्ट ग्रुप में जोड़ा जा सकता है? | Chrome पर, हर मालिक के पास अपनी पसंद के ज़्यादा से ज़्यादा 1,000 ग्रुप बनाने की अनुमति होती है. साथ ही, ज़्यादा से ज़्यादा 1,000 लोगों के पास अपनी पसंद के ग्रुप बनाने की अनुमति होती है. ये गार्डरिल के तौर पर काम करते हैं, न कि सामान्य तौर पर इस्तेमाल किए जाने वाले आइटम के तौर पर. |
| इवेंट-लेवल के सिग्नल | generateBid और reportWin के लिए इवेंट-लेवल के सिग्नल देने के प्रस्ताव के लिए सहायता, जिसका इस्तेमाल मशीन लर्निंग ट्रेनिंग में किया जा सकता है |
हमने ब्राउज़र से डिज़ाइन किए गए सिग्नल और विज्ञापन टेक्नोलॉजी से तय किए गए सिग्नल के लिए अपना फ़ैसला यहां शेयर किया है. साथ ही, हम आपके सुझाव, राय या शिकायतों का स्वागत करते हैं. |
| बिडिंग स्क्रिप्ट | बिडिंग स्क्रिप्ट के यूआरएल में उपयोगकर्ता आईडी शामिल करें. | ऐसा नहीं किया जा सकता, क्योंकि FLEDGE के लिए यह ज़रूरी है कि विज्ञापन दिखाने के लिए, इंटरेस्ट ग्रुप के मालिक, बिडिंग स्क्रिप्ट के यूआरएल, और रेंडर किए गए क्रिएटिव का ट्यूपल, k-anonymous होना चाहिए. |
| K-anon एनफ़ोर्समेंट | क्या (componentAd, size) पेयर पर के-ऐनॉनिमिटी (निजता सुरक्षित करने का स्तर) लागू है? | हां, ऐसा होगा. turtledove/issues/312 पर जाएं. |
| बिडिंग और नीलामी से जुड़ी सेवाओं की ज़रूरी शर्तें | B&A Services, डिवाइस पर मौजूद FLEDGE और B&A सेवाओं के साथ इंटिग्रेट करने वाले लोगों की मदद कैसे करती है? | हम अब भी डिज़ाइन को फ़ाइनल कर रहे हैं. इस बारे में हमें और सुझाव, राय या शिकायत भेजें. |
| पोस्ट-व्यू एट्रिब्यूशन | क्या पोस्ट-व्यू एट्रिब्यूशन काम करेगा? | फ़िलहाल, हमारे पास विज्ञापन दिखने की कोई स्टैंडर्ड परिभाषा नहीं है. साथ ही, व्यू इवेंट को मार्क करने के लिए, हम क्रिएटिव पर भरोसा करते हैं. turtledove/issues/452 पर जाएं. |
| मिलती-जुलती ऑडियंस के हिसाब से टारगेटिंग | क्या Privacy Sandbox में "मिलती-जुलती ऑडियंस को टारगेट करने की सुविधा" काम करती है? | हम इस्तेमाल के उदाहरण के बारे में यहां चर्चा कर रहे हैं. साथ ही, हमें इस बारे में और सुझाव, राय या शिकायतें भेजने में खुशी होगी. |
| रीयल-टाइम मॉनिटरिंग एपीआई | रीयल-टाइम में FLEDGE मॉनिटरिंग के तरीके का प्रस्ताव | हम इस प्रस्ताव पर चर्चा कर रहे हैं. इस बारे में हमें और सुझाव, राय या टिप्पणियां भेजें. |
| FLEDGE रिपोर्टिंग | reportWin और reportResult को रैंडम क्रम में बनाया जाना चाहिए, ताकि ज़्यादा या कम रिपोर्टिंग से बचा जा सके. |
खरीदार को reportWin() सेट करने से पहले, सेलर को reportResult() सेट करना होगा, ताकि reportResult() से सेलर के सिग्नल reportWin() में शामिल किए जा सकें. ज़्यादा जानकारी के लिए, एक्सप्लेनर देखें. |
| कस्टम की-वैल्यू (K/V) सर्वर | क्या आने वाले समय में कस्टम K/V सर्वर काम करेंगे? | हम इस सवाल पर यहां चर्चा कर रहे हैं और आपके किसी भी सुझाव का स्वागत करते हैं. |
| टॉप-लेवल ऑक्शन | क्या टॉप-लेवल नीलामी के तरीके चलाने के लिए, विज्ञापन सर्वर होना ज़रूरी है? | FLEDGE एपीआई में यह नहीं बताया गया है कि इसे किस पक्ष को कॉल करना चाहिए. FLEDGE के डिज़ाइन में इस तरह की कोई ज़रूरी शर्त नहीं है. कोई भी व्यक्ति FLEDGE नीलामी (इसमें कई सेलर की नीलामियां भी शामिल हैं) चला सकता है. 2022 की चौथी तिमाही की रिपोर्ट में बताया गया है कि FLEDGE की मदद से, हर पब्लिशर अपनी नीलामी का स्ट्रक्चर चुन सकता है. इसमें टॉप-लेवल और कॉम्पोनेंट सेलर को चुनने का विकल्प भी शामिल है. |
| एपीआई का दायरा | क्या FLEDGE, पहले पक्ष (ग्राहक) के डेटा के साथ काम करता है? | हम साल 2023 की दूसरी तिमाही में कॉन्टेंट पब्लिश करेंगे. इसमें हम यह बताएंगे कि पहले पक्ष (ग्राहक) का डेटा, FLEDGE के साथ इस्तेमाल किया जा सकता है. इसका इस्तेमाल, 1) दिलचस्पी के ग्रुप की सदस्यता तय करने के लिए लॉजिक के तौर पर और 2) बिडिंग लॉजिक जनरेशन के बाद इस्तेमाल करने के लिए, उपयोगकर्ता बिडिंग सिग्नल के तौर पर किया जा सकता है. |
| क्रॉस-डोमेन के हिसाब से एक जैसी दिलचस्पी वाले ग्रुप | अलग-अलग डोमेन के लिए, दिलचस्पी के हिसाब से ग्रुप बनाने की सुविधा | किसी ब्राउज़र को इंटरेस्ट ग्रुप में जोड़ते समय उपलब्ध किसी भी जानकारी का इस्तेमाल, उस ऑडियंस को सूचना देने के लिए किया जा सकता है. तीसरे पक्ष की कुकी बंद होने के बाद, अलग-अलग साइटों के डेटा की उपलब्धता सीमित हो जाएगी. इससे, दिलचस्पी के हिसाब से ग्रुप बनाने के बारे में जानकारी नहीं मिल पाएगी. |
| क्लाइंट-साइड बिडिंग लॉजिक | मौजूदा सर्वर-साइड बिडिंग लॉजिक को क्लाइंट-साइड पर पोर्ट करना | हमें इस बारे में ज़्यादा जानना है कि पोर्ट करने की प्रोसेस में किन चीज़ों में समस्या आ रही है या फ़िलहाल कौनसी चीज़ें मौजूद नहीं हैं. साथ ही, अन्य सुझाव, राय या जानकारी भी हमारे लिए काम की है. |
| K/V सर्वर वैल्यू | क्या K/V सर्वर की वैल्यू, स्ट्रिंग टाइप की होनी चाहिए? | वैल्यू एक स्ट्रिंग होनी चाहिए, लेकिन वे ऑब्जेक्ट को JSON या प्रोटोकॉल बफ़र में सेव कर सकते हैं और उन्हें स्ट्रिंग में सीरियलाइज़ कर सकते हैं. |
| विज्ञापन देने वाले की ब्लॉकलिस्ट | विज्ञापन देने वाले की ब्लॉकलिस्ट के लिए, खरीदार को कौनसे सिग्नल देने चाहिए? | सही जगह auctionSignals या
perBuyerSignals में से किसी एक में होनी चाहिए. |
| बिडिंग यूनिट | सीपीआई और सीपीएम जैसी अलग-अलग बिडिंग यूनिट के लिए सहायता | हम इस बारे में ज़्यादा जानना चाहते हैं कि मौजूदा डिज़ाइन के हिसाब से, ऐसा क्यों ज़रूरी है. साथ ही, हमें अन्य सुझाव/राय/शिकायत भी मिल सकती है. |
| नीलामी का लॉजिक | क्या नीलामी के विजेता को ब्राउज़र या विज्ञापन सर्वर तय करता है? | विजेताओं को चुनने की प्रोसेस, सैंडबॉक्स में पूरी की जाती है. साथ ही, सभी फ़ैसले सेलर के कोड के हिसाब से लिए जाते हैं. ब्राउज़र सिर्फ़ एक सीलबंद और निजी एनवायरमेंट उपलब्ध कराता है, जिसमें खरीदार और सेलर का कोड चलता है. |
| Permissions-Policy | क्या ऑरिजिन ट्रायल खत्म होने के बाद भी, FLEDGE की मौजूदा अनुमतियों की नीति लागू रहेगी? | ऑरिजिन ट्रायल के लिए, दोनों सुविधाओं की मौजूदा डिफ़ॉल्ट अनुमति सूचियां कुछ समय के लिए ही उपलब्ध हैं. इनमें बदलाव किया जाएगा. हमें यह जानना है कि इस बदलाव को लागू करने से पहले, विज्ञापन टेक्नोलॉजी विशेषज्ञों को कितने समय की ज़रूरत होगी. |
| सिग्नल के साइज़ की सीमा | भरोसेमंद बिडिंग सिग्नल के अनुरोधों को एक ही trustedBiddingSignalsUrl वाले कई इंटरेस्ट ग्रुप में जोड़ दिया जाता है. हालांकि, 2 एमबी के साइज़ की सीमा एक समस्या है. |
यह पाबंदी, डिवाइस पर कॉल करने वालों के लिए है, ताकि डिवाइस पर ज़्यादा संसाधनों का इस्तेमाल न हो. B&A सर्वर से कॉल करने वालों पर ज़्यादा पाबंदी नहीं होगी. |
| रिपोर्टिंग सिग्नल | हर इंटरेस्ट ग्रुप के मालिक और हर computeBid या reportWin / reportResult के हिसाब से, क्लाइंट-साइड की गड़बड़ियों की संख्या को वापस पाने के लिए, स्क्रिप्ट-गड़बड़ियां वाला एक और सिग्नल जोड़ें. |
हम इस प्रस्ताव से जुड़ी निजता से जुड़ी संभावित समस्याओं पर विचार कर रहे हैं. साथ ही, हम इकोसिस्टम के उन लोगों का स्वागत करते हैं जो इस बारे में ज़्यादा जानकारी शेयर करना चाहते हैं कि ऐसा क्यों ज़रूरी है. |
| K-Anon विंडो का साइज़ | K-Anon विंडो का साइज़, सात दिन की मौजूदा सीमा से बढ़ाएं. | हम इस पर विचार कर रहे हैं. फ़िलहाल, हम इकोसिस्टम से ज़्यादा जानकारी का इंतज़ार कर रहे हैं. |
| डिवाइस के हिसाब से परफ़ॉर्मेंस | अगर उपयोगकर्ता कई इंटरेस्ट ग्रुप में शामिल है, तो FLEDGE डिवाइस की परफ़ॉर्मेंस को कैसे मैनेज करता है? | FLEDGE, एसएसपी और डीएसपी के लिए टाइम आउट, प्राथमिकता तय करने, और सीमित करने के कई विकल्प उपलब्ध कराता है. इनकी मदद से, विज्ञापन टेक्नोलॉजी को उन स्थितियों में बेहतर तरीके से कंट्रोल करने में मदद मिलती है जहां डिवाइस की परफ़ॉर्मेंस, नीलामी में हिस्सा लेने की सीमा तय करने की एक वजह हो सकती है. ऐसा तब होता है, जब डिवाइस कई इंटरेस्ट ग्रुप में शामिल हो. |
| B&A Services की जांच | टेस्टिंग के दौरान, नेटवर्क में शामिल प्लेयर से अपने सर्वर का इस्तेमाल करने का अनुरोध करना, ताकि डीबग करने के लिए ज़्यादा लॉग उपलब्ध हों | B&A की मदद से, उपयोगकर्ता मंज़ूरी पा चुके क्लाउड प्रोवाइडर के सर्वर लॉन्च कर सकते हैं और उनका स्केल बढ़ा सकते हैं. उपयोगकर्ता की निजता बनाए रखने के लिए, हम ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) में ही प्रोसेस करने की ज़रूरी शर्त लागू करते हैं. हम जल्द ही B&A टीईई को डीबग करने के बारे में जानकारी देने वाला एक वीडियो रिलीज़ करने वाले हैं. साथ ही, हम इस सुविधा के साथ काम करने वाली सुविधाएं भी डेवलप कर रहे हैं. हम इस विषय पर ज़्यादा सुझाव/राय/शिकायत पाना चाहते हैं. |
| कानूनी ज़रूरी शर्तें | क्या FLEDGE, स्थानीय कानूनी ज़रूरी शर्तों का पालन करने के लिए, अलग-अलग देशों में क्लाउड सेवा देने वाली कंपनियों के साथ काम करेगा? | हम क्लाउड सेवा देने वाली अन्य कंपनियों के सुझावों को हमेशा स्वीकार करते हैं. हालांकि, फ़िलहाल तीसरे पक्ष की कुकी की सुविधा बंद होने के बाद, हम कम से कम GCP और AWS के साथ काम करने की योजना बना रहे हैं. ज़्यादा जानकारी के लिए, इस जानकारी को पढ़ें. |
डिजिटल विज्ञापनों की परफ़ॉर्मेंस का आकलन करना
एट्रिब्यूशन रिपोर्टिंग (और अन्य एपीआई)
| सुझाव, शिकायत या राय की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| ग़ैर-ज़रूरी आवाज़ों के असर का डेटा विश्लेषण | ग़ैर-ज़रूरी डेटा के असर का डेटा विश्लेषण करने का तरीका | हमने ग़ैर-ज़रूरी आवाज़ों और ग़ैर-ज़रूरी आवाज़ों और डिज़ाइन से जुड़े फ़ैसलों के बारे में ज़्यादा दस्तावेज़ शेयर किए हैं. इनका इस्तेमाल, विज्ञापन टेक्नोलॉजी डेटा पर ग़ैर-ज़रूरी आवाज़ों के असर को बदलने के लिए किया जा सकता है. ज़्यादा जानकारी वाली गाइड भी उपलब्ध है. |
| शून्य रिपोर्टिंग | शून्य रिपोर्ट लागू करने के बारे में जानकारी | फ़िलहाल, हम शून्य रिपोर्ट लागू करने के प्रस्ताव पर काम कर रहे हैं. इस बारे में जल्द ही ज़्यादा जानकारी शेयर की जाएगी. शून्य रिपोर्ट लागू करने से, निजता से समझौता किए बिना, रिपोर्ट में होने वाली देरी को कम करने में मदद मिलेगी. |
| शोर का लेवल | एट्रिब्यूशन विंडो की लंबाई के आधार पर, शोर के लेवल को अडजस्ट करना | हम इस प्रस्ताव का स्वागत करते हैं और इसे स्पेसिफ़िकेशन में जोड़ने पर काम कर रहे हैं. अन्य सुझाव/राय/शिकायत यहां भेजें. |
| ट्रिगर डेटा का साइज़ | ट्रिगर डेटा का साइज़ तीन बिट तक ही क्यों सीमित है? | इसका साइज़ 3 बिट और आठ अलग-अलग वैल्यू तक सीमित है. इससे यह पक्का किया जा सकता है कि किसी उपयोगकर्ता के बारे में, अलग-अलग साइटों/कॉन्टेक्स्ट की जानकारी सीमित हो. हम इकोसिस्टम के प्लेयर का स्वागत करते हैं. वे इस बारे में सुझाव/राय दें कि इवेंट-लेवल रिपोर्टिंग के लिए, मौजूदा पैरामीटराइज़ेशन सही है या नहीं. |
| इवेंट-लेवल की रिपोर्टिंग ट्रिगर | डुप्लीकेट कॉपी हटाने वाले पासकोड में प्राथमिकता तय करने की सुविधा | हम इस समस्या के समाधान ढूंढ रहे हैं और आपसे और सुझाव, शिकायत या राय पाने के लिए तैयार हैं. |
| डीबग करने से जुड़ी सहायता | तीसरे पक्ष की कुकी के इस्तेमाल को बंद करने के बाद, डीबग करने के बारे में जानकारी | हम तीसरे पक्ष की कुकी के बंद होने के बाद, डीबग करने की सुविधा देना चाहते हैं. इसके लिए, हम अलग-अलग विकल्पों पर विचार कर रहे हैं. हम ज़्यादा सुझाव और राय चाहते हैं. |
| क्लिक-थ्रू कन्वर्ज़न के विकल्प | क्लिक मिलने के बाद होने वाले कन्वर्ज़न के विकल्पों के बारे में ज़्यादा जानकारी पाने का अनुरोध करना | हमारा सुझाव है कि एकोसिस्टम, कन्वर्ज़न मेज़रमेंट के इस्तेमाल के उदाहरणों के लिए, Attribution Reporting API का इस्तेमाल एक बेहतर निजी मेज़रमेंट सिस्टम के तौर पर करे. इसके अलावा, विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली कंपनियों को अपनी निजता और उपयोगिता की ज़रूरतों के हिसाब से, सही समाधान तय करना होगा. |
| बिलिंग के इस्तेमाल के उदाहरण | एट्रिब्यूशन रिपोर्टिंग, कन्वर्ज़न पर आधारित बिलिंग के इस्तेमाल के उदाहरणों के साथ किस हद तक काम करेगी, इस बारे में साफ़ तौर पर जानकारी | हम सार्वजनिक तौर पर पोस्ट करने पर काम कर रहे हैं, ताकि बिलिंग के लिए Attribution Reporting API के दायरे के बारे में साफ़ तौर पर बताया जा सके. एट्रिब्यूशन रिपोर्टिंग एपीआई को शुरू में इस तरह से स्कोप नहीं किया गया था कि वह सीपीए बिलिंग के साथ सीधे तौर पर काम कर सके. यह सीपीसी और सीपीएम बिलिंग के साथ काम करता है. ज़्यादातर विज्ञापन टेक्नोलॉजी कंपनियां, बिलिंग के लिए इसी स्ट्रक्चर का इस्तेमाल करती हैं. अगर हमें इकोसिस्टम से इस बारे में और सुझाव मिलते हैं, तो हम आने वाले समय में इस सुविधा को उपलब्ध करा सकते हैं. |
| इस्तेमाल के उदाहरण से जुड़ी सहायता | मेज़रमेंट एपीआई के इस्तेमाल के उदाहरण का दस्तावेज़ | हम प्राइवसी सैंडबॉक्स के सभी रिपोर्टिंग प्लैटफ़ॉर्म के दस्तावेज़ों को साफ़ तौर पर समझाने की कोशिश कर रहे हैं. |
| क्लिक गुणवत्ता | किसी विज्ञापन पर जान-बूझकर किए गए क्लिक और अनजाने में किए गए क्लिक के बीच अंतर करने के लिए, सिग्नल जोड़ने का अनुरोध करना | हम अनुरोध पर चर्चा कर रहे हैं और हमें इस बारे में और सुझाव, राय या शिकायतें भेजने में खुशी होगी. |
| मेज़रमेंट सलूशन | एक से ज़्यादा डीएसपी में मेज़रमेंट सलूशन के लिए सहायता | मेज़रमेंट की सेवा देने वाली कंपनियां, Attribution Reporting API का इस्तेमाल करके, एक से ज़्यादा डीएसपी के बीच डुप्लीकेट डेटा हटा सकती हैं. इसके अलावा, attributionsrc में यूआरएल की सूची के लिए, हम यह सुझाव दे रहे हैं कि
मेज़रमेंट प्रोवाइडर के Attribution Reporting API के अनुरोधों को डीएसपी आसानी से पूरा कर पाएं. ऊपर दिए गए प्रस्ताव के बारे में, हमें और सुझाव, शिकायत या राय भेजें. |
| इवेंट-लेवल की रिपोर्टिंग | रिपोर्ट भेजने से पहले, उसके उपलब्ध होने की तारीख की जानकारी पाने का अनुरोध करना | विज्ञापन टेक्नोलॉजी, फ़िलहाल उपलब्ध जानकारी का इस्तेमाल करके, इस अनुरोध का हिसाब पहले ही लगा सकती हैं. हमें इस अनुरोध के बारे में, नेटवर्क से जुड़े किसी और व्यक्ति या कंपनी से कोई सुझाव, राय या शिकायत नहीं मिली है. हालांकि, हम इस बारे में सुझाव, राय या शिकायत सुनने को तैयार हैं. |
source_registration_time |
इवेंट-लेवल एट्रिब्यूशन रिपोर्टिंग में source_registration_time जोड़ें. |
हम इस अनुरोध पर विचार कर रहे हैं. साथ ही, इस बारे में और सुझाव, राय या शिकायत भेजने का न्योता देते हैं कि क्या नेटवर्क के प्लेयर को यह सुविधा काम की लगती है. |
| गुप्त मोड | क्या उपयोगकर्ता के गुप्त मोड में होने पर, मेज़रमेंट के समाधान उपलब्ध होंगे? | नहीं, जब कोई उपयोगकर्ता गुप्त मोड में होगा, तब मेज़रमेंट के समाधान उपलब्ध नहीं होंगे. गुप्त मोड में, तीसरे पक्ष की कुकी डिफ़ॉल्ट रूप से बंद रहती हैं. |
| डेटा सुरक्षित रखने से जुड़ी सेवा | क्या मेज़रमेंट एपीआई, क्लीन रूम के साथ काम करेंगे? | डेटा क्लीन रूम एक ऐसा प्लैटफ़ॉर्म है जहां अलग-अलग सोर्स से मिले आइडेंटिफ़ायर डेटा को डेटाबेस में अपलोड किया जाता है. इसके बाद, उस डेटा को मर्ज करके विश्लेषण किया जाता है. Privacy Sandbox APIs के लिए, इवेंट-लेवल की रिपोर्ट और खास जानकारी वाली रिपोर्ट, ये दोनों मेज़रमेंट फ़्रेमवर्क उपलब्ध हैं. इवेंट-लेवल की रिपोर्ट में, विज्ञापन टेक्नोलॉजी से मिला इवेंट-आईडी होता है. इसका इस्तेमाल, डेटा क्लीनरूम में किया जा सकता है. हालांकि, इससे जुड़ी कन्वर्ज़न-साइड की जानकारी सीमित और ग़ैर-ज़रूरी होगी. एग्रीगेट की जा सकने वाली एन्क्रिप्ट की गई रिपोर्ट का इस्तेमाल, सीधे क्लीन रूम में नहीं किया जा सकता. हालांकि, एग्रीगेशन सेवा से मिली खास जानकारी के नतीजों का इस्तेमाल, आपके विश्लेषण के इनपुट या अतिरिक्त जानकारी के तौर पर किया जा सकता है. |
एग्रीगेशन सेवा
| सुझाव, शिकायत या राय की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| (इसकी शिकायत साल 2022 की चौथी तिमाही में भी की गई थी) रिपोर्टिंग में देरी |
रिपोर्टिंग में कितनी देरी हो सकती है? | साल 2023 की पहली तिमाही का अपडेट: पार्टनर से मिले सुझावों के आधार पर, हमने देरी को कम करने और देरी के असर को कम करने के लिए सुझाव शेयर किए हैं. WICG कॉल के दौरान, विज्ञापन टेक्नोलॉजी से जुड़े विशेषज्ञों ने दोनों प्रस्तावों का समर्थन किया है. |
| डुप्लीकेट का कोई नियम नहीं | अगर एग्रीगेट की जा सकने वाली ऐसी रिपोर्ट पहले ही प्रोसेस हो चुकी हैं जिनका शेयर किया गया आईडी एक ही है, तो "देर से एग्रीगेट की जा सकने वाली रिपोर्ट" को कैसे मैनेज किया जाता है? | हमने एग्रीगेट की जा सकने वाली रिपोर्ट की शेयर की गई जानकारी में, रिपोर्ट में देरी को जोड़ने के लिए एक प्रस्ताव शेयर किया है. साथ ही, एग्रीगेशन सेवा के लिए शेयर किए गए आईडी की परिभाषा भी शेयर की है. इससे, एग्रीगेट एपीआई पर देरी के असर को कुछ हद तक कम किया जा सकता है. इस प्रस्ताव के बारे में आपके सुझाव, राय या शिकायत का हमें इंतज़ार रहेगा. |
| डेटा प्रोसेसिंग | निजता बजट का इस्तेमाल करके, डिफ़रेंशियल निजता का सम्मान करते हुए, डेटा के कई पास के लिए सहायता चालू करने का अनुरोध | हम इस इस्तेमाल के उदाहरण को चालू करने के लिए, प्राइवसी बजट को इस्तेमाल करने के ज़्यादा सुविधाजनक तरीके के बारे में चर्चा कर रहे हैं. साथ ही, अन्य सुझाव/राय/शिकायत का स्वागत करते हैं. |
| (इसकी जानकारी दूसरी तिमाही 2022 में भी दी गई थी) क्वेरी के इस्तेमाल में आसानी | कुंजियों के एग्रीगेट के लिए क्वेरी करने की सुविधा चालू करें. | साल 2023 की पहली तिमाही का अपडेट: इस सुविधा के अनुरोध पर अब भी विचार किया जा रहा है. हालांकि, फ़िलहाल हमारे पास इस बारे में कोई सुझाव शेयर करने के लिए उपलब्ध नहीं है. |
| ऑरिजिन ट्रायल की सीमाएं | एग्रीगेशन सेवा के दायरे के बारे में साफ़ तौर पर बताएं. जैसे, "डुप्लीकेट नहीं होना वाला नियम", जो फ़िलहाल ऑरिजिन ट्रायल में लागू नहीं है. | हम अपने दस्तावेज़ को अपडेट करने पर काम कर रहे हैं, ताकि यह साफ़ तौर पर बताया जा सके कि ऑरिजिन ट्रायल के मुकाबले GA में क्या उपलब्ध होगा. |
Private Aggregation API
| सुझाव, शिकायत या राय की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| निजी एग्रीगेशन के लिए योगदान का बजट | L1 योगदान का बजट बहुत सीमित है. | निजी एग्रीगेशन एपीआई को किए गए हर कॉल को योगदान कहा जाता है. उपयोगकर्ता की निजता को बनाए रखने के लिए, किसी व्यक्ति से इकट्ठा किए जा सकने वाले योगदान की संख्या सीमित होती है. सभी एग्रीगेशन बटन की सभी एग्रीगेट की जा सकने वाली वैल्यू को जोड़ने पर, उसका योग, योगदान बजट से कम होना चाहिए. मौजूदा डिज़ाइन के तहत, हमने किसी खास रिपोर्टिंग ऑरिजिन के लिए, पिछले ~24 घंटों में (रोलिंग विंडो के तौर पर) योगदान की सीमा तय की है. यह, सुझाव/राय/शिकायत में बताए गए L1 योगदान का बजट है. हमारा सुझाव है कि डेवलपर, अनुमानित वॉल्यूम के आधार पर, अपनी योगदान वाली वैल्यू को बढ़ाएं. इसका मतलब है कि सिर्फ़ 1 वैल्यू का इस्तेमाल न करें. इसलिए, बजट खत्म होने से बचने के लिए, आम तौर पर होने वाले इवेंट के लिए कम वैल्यू का इस्तेमाल करना सही रहेगा. फ़िलहाल, हम निजी एग्रीगेशन एपीआई के योगदान के बजट के बारे में कुछ सुझाव/राय या शिकायत चाहते हैं. इसमें संख्या और दायरे, दोनों के बारे में सुझाव/राय या शिकायत शामिल है. हम दायरे को हर ऑरिजिन से हर साइट पर ले जाने पर विचार कर रहे हैं. साथ ही, मौजूदा बाउंड को 10 मिनट की विंडो पर ले जाकर, रोज़ के बाउंड को बड़ा कर रहे हैं. |
गुप्त ट्रैकिंग को सीमित करना
यूज़र-एजेंट रिडक्शन/यूज़र-एजेंट क्लाइंट-हिंट
| सुझाव, शिकायत या राय की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| UA-R का इस्तेमाल | यूनाइटेड किंगडम की टॉप 10,000 साइटों में से, प्रोग्रामैटिक विज्ञापन का इस्तेमाल करने वाली सिर्फ़ 1% साइटें एचटीटीपी क्लाइंट हिंट भेज रही हैं. जिन डीएसपी ने ट्रांसफ़र नहीं किया है उन पर धोखाधड़ी रोकने की सुविधाओं पर असर पड़ सकता है. | उसी डेटा सेट पर विश्लेषण करने के बाद, हमें पता चला है कि अगर एचटीएमएल <meta> टैग और JavaScript एपीआई का इस्तेमाल करके UA-CH के इस्तेमाल का हिसाब लगाया जाता है, तो UA-CH का इस्तेमाल करने वाली साइटों की संख्या, फ़ीडबैक में दिए गए 1% के आंकड़े से काफ़ी ज़्यादा है. इस और अन्य बातों के आधार पर, हमें भरोसा है कि हम पब्लिश की गई समयावधि के मुताबिक, UA को कम करने के छठे चरण को धीरे-धीरे रोल आउट कर पाएंगे. साथ ही, हम सीएमए को इसकी जानकारी देते रहेंगे. हमने देखा है कि साइटों को ट्रांज़िशन के लिए तैयार होने में करीब दो साल का समय मिला है. साथ ही, जिन साइटों को लगता है कि वे ट्रांज़िशन के लिए तैयार नहीं हैं उनके लिए, अब भी बंद होने से पहले इस्तेमाल करने की सुविधा उपलब्ध है. |
| डिवाइस के अन्य नाप या आकार के लिए सलाह | UA-CH के लिए, टीवी, वीआर जैसे डिवाइसों के साइज़, डाइमेंशन या कॉन्फ़िगरेशन के हिसाब से बनाई गई रिलीज़ उपलब्ध कराने का अनुरोध | हम इस सुझाव का स्वागत करते हैं और इसे डिज़ाइन में शामिल करने पर काम कर रहे हैं. अन्य सुझाव, शिकायत या राय भेजने के लिए, हम आपका स्वागत करते हैं. |
| अपने-आप होने वाली जांच | UAR के छठे चरण के शिप होने से पहले, बिना ग्राफ़िक यूज़र इंटरफ़ेस वाले Chrome में UA-CH बग को ठीक करने का अनुरोध | जिस गड़बड़ी की शिकायत की गई थी उसे ठीक कर दिया गया है. |
| iOS पर UA-CH की सहायता | विज्ञापनों के इस्तेमाल के उदाहरणों के लिए, ज़्यादा जानकारी वाली UA जानकारी पर निर्भर रहने वाली साइट, यह नोट करती है कि iOS पर Chrome काम नहीं करता. | Safari के अलावा iOS के अन्य ब्राउज़र (इनमें iOS पर Chrome भी शामिल है) के लिए, UA-CH को चालू करने से पहले, WebKit प्रोजेक्ट को इसकी सुविधा जोड़नी होगी. ऐसा इसलिए, क्योंकि ये ब्राउज़र नेटवर्क स्टैक को कंट्रोल करते हैं. |
आईपी प्रोटेक्शन (पहले इसे Gnatcatcher कहा जाता था)
| सुझाव, शिकायत या राय की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| (चौथी तिमाही में भी रिपोर्ट की गई) जगह की जानकारी के इस्तेमाल के उदाहरण | आईपी प्रोटेक्शन की सुविधा की वजह से, आने वाले समय में जगह की जानकारी के सही इस्तेमाल से जुड़े उदाहरण काम नहीं कर सकते. जैसे, जगह की जानकारी के आधार पर कॉन्टेंट को उपयोगकर्ता के हिसाब से बनाना. | साल 2022 की चौथी तिमाही में दिए गए हमारे जवाब में कोई बदलाव नहीं हुआ है: "हम उन लोगों के साथ काम कर रहे हैं जो इस मामले में दिलचस्पी रखते हैं. इससे यह पक्का किया जा सकेगा कि Chrome, आईपी पतों के सही इस्तेमाल के उदाहरणों के लिए काम करता रहे. हम आईपी की भौगोलिक जगह की जानकारी के बारे में ज़्यादा जानकारी के लिए, इकोसिस्टम से सुझाव/राय मांग रहे हैं." |
| नियामक अनुपालन | अगर किसी इलाके की जनसंख्या एक मिलियन से कम है, तो आईपी पते की सुरक्षा के लिए एक मिलियन का मौजूदा थ्रेशोल्ड, वेबसाइटों को नियमों का पालन करने के लिए आईपी पते का इस्तेमाल करने से रोकेगा. | हम उन लोगों के साथ मिलकर काम कर रहे हैं जो इस बदलाव से जुड़े हैं. इससे यह पक्का किया जा सकेगा कि Chrome, आईपी पतों के सही इस्तेमाल के उदाहरणों के लिए काम करता रहेगा. हम आईपी की सुरक्षा से जुड़े नियमों का पालन करने के बारे में, नेटवर्क के उपयोगकर्ताओं से सुझाव/राय/शिकायत/राय मांग रहे हैं. |
| बुरे बर्ताव को कम करना | पार्टियां, दूसरों के साथ बिना मास्क वाले आईपी पते शेयर करके, आईपी पते की सुरक्षा से बच सकती हैं. | हम इस जोखिम को समझते हैं कि आईपी पते की सुरक्षा के लिए मौजूदा सुझाव, तकनीकी तौर पर पार्टियों को दूसरों के साथ बिना मास्क वाले आईपी पते शेयर करने से नहीं रोक सकता. हम इस समस्या को कम करने के लिए काम कर रहे हैं, ताकि इसका गलत इस्तेमाल न किया जा सके. हम इस प्रस्ताव पर काम कर रहे हैं. इसलिए, हमारा सुझाव है कि आप हमें ज़्यादा सुझाव, राय या शिकायत भेजें और इस बारे में चर्चा करें. खास तौर पर, हमें ऐसे इस्तेमाल के उदाहरणों के बारे में जानना है जहां पार्टियों को लगता है कि उन्हें अन्य पार्टियों के साथ बिना मास्क वाले आईपी पते शेयर करने होंगे. |
| नेटवर्क ब्लॉकिंग | आईपी प्रोटेक्शन प्रॉक्सी का इस्तेमाल करके, पक्ष नेटवर्क ब्लॉकिंग को गच्चा दे सकते हैं. | ब्लॉक करने वाली इकाई को इस स्थिति में, आईपी पते की सुरक्षा की सुविधा बंद करनी होगी. हमने समस्या का जवाब दे दिया है और हमें आपके और सुझाव, राय या शिकायतें मिल सकती हैं. |
| आईपी पते की ब्लॉक सूचियां, जिन पर आईपी सुरक्षा के प्रस्ताव का असर पड़ा है | कई विज्ञापन टेक्नोलॉजी कंपनियां, आईपी पतों की बुनियादी ब्लॉक सूची का इस्तेमाल करती हैं. जैसे, TAG डेटासेंटर की आईपी सूची. इससे, ऐसी विज्ञापन इन्वेंट्री पर बिडिंग करने से रोका जा सकता है जिसमें धोखाधड़ी की संभावना ज़्यादा होती है या कम से कम उससे कमाई नहीं की जा सकती. अगर कोई विज्ञापन टेक्नोलॉजी कंपनी, ट्रैकर भी है और आईपी की सुरक्षा के प्रस्ताव के दायरे में आ सकती है, तो हो सकता है कि वह कंपनी विज्ञापन इन्वेंट्री खरीदने से पहले, विज्ञापनों की बुनियादी जांच न कर पाए. | हम आईपी प्रोटेक्शन के प्रस्ताव से जुड़ी संभावित समस्याओं और उनके समाधानों के बारे में ज़्यादा सुझाव/राय और चर्चा का सुझाव देते हैं. एक विकल्प यह है कि आईपी प्रोटेक्शन के लिए, ऐसी ही सूचियां लागू की जाएं, ताकि हम पहले फ़्लैग किए गए आईपी पतों से आने वाले क्लाइंट को प्रॉक्सी न कर सकें. |
अलग-अलग साइटों पर निजता की सीमाओं को बेहतर बनाना
पहले पक्ष के सेट
| सुझाव, शिकायत या राय की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| (चौथी तिमाही में भी रिपोर्ट की गई) डोमेन की सीमा | खाते से जुड़े डोमेन की संख्या बढ़ाने का अनुरोध करना | हमारा जवाब, साल 2022 की चौथी तिमाही से अब तक नहीं बदला है: "हमने WICG कॉल में साफ़ तौर पर बताया है कि Chrome, उपयोगकर्ताओं की निजता को ध्यान में रखते हुए, काम का समाधान उपलब्ध कराने के लिए प्रतिबद्ध है. इसलिए, हम कम्यूनिटी से उन खास इस्तेमाल के उदाहरणों के बारे में सुझाव या राय पाना चाहेंगे जिन पर डोमेन की सीमा का असर पड़ सकता है. इससे हमारी टीम, उपयोगकर्ता की निजता को बनाए रखते हुए, इन इस्तेमाल के उदाहरणों को ठीक करने के तरीकों पर विचार कर पाएगी." |
| एफ़पीएस (फ़्रेम प्रति सेकंड) सबमिट करने का दूसरा तरीका | एफ़पीएस (फ़्रेम प्रति सेकंड) के लिए, ग्लोबल सूचियां सबमिट करने के वैकल्पिक तरीके का प्रस्ताव | फ़िलहाल, हम Chrome में फ़र्स्ट-पार्टी सेट (एफ़पीएस) को लॉन्च करने की तैयारी कर रहे हैं. साथ ही, सेट सबमिट करने के लिए, एक केंद्रीय GitHub रिपॉज़िटरी सेट अप किया है. हमें उम्मीद है कि तीसरे पक्ष की कुकी के बंद होने की तैयारी के लिए, एफ़पीएस मौजूदा वेब प्लैटफ़ॉर्म के समाधानों के बीच के अंतर को भर देगा. इसलिए, हमें उनसे यह जानने की उम्मीद है कि साइट के लेखक एफ़पीएस का इस्तेमाल कैसे करते हैं. समय के साथ सेट की सूची बढ़ती जाती है और पारिस्थितिकी तंत्र, तीसरे पक्ष की कुकी के बाद की दुनिया के हिसाब से ढल जाता है. इसलिए, हम इस प्रोसेस को इस हद तक बेहतर बना सकते हैं कि हम डिसेंट्रलाइज़्ड (बिना किसी केंद्रीय नियंत्रण वाली) अन्य योजनाओं पर विचार कर सकें. जैसे, यहां बताई गई योजना. मौजूदा प्रोसेस के तहत, हम ऐप्लिकेशन के लाइफ़टाइम को तय करेंगे. इससे हमें समय के साथ, ऐप्लिकेशन को शामिल करने की प्रोसेस को बेहतर बनाने में मदद मिलेगी. सबमिशन की प्रोसेस पूरी होने के बाद, हम इस विचार पर फिर से विचार कर सकते हैं. |
| रिपॉज़िटरी को मॉडरेट करना | गलत इस्तेमाल को रोकने के लिए, एफ़पीएस सबमिशन रिपॉज़िटरी को कम्यूनिटी मॉडरेशन के दायरे में लाएं. बुरे इरादे वाले लोग, सेट का प्रस्ताव देने के लिए बर्नर ऑरिजिन का इस्तेमाल करके, इस प्रोसेस को आसानी से खराब कर सकते हैं. साथ ही, अनुरोधों की संख्या बहुत ज़्यादा होने पर, सेट के असली प्रस्तावों के ऑपरेशन पर असर पड़ सकता है. | हम तकनीकी पुष्टि की जांचों पर भरोसा करके, जांचों को ज़्यादा से ज़्यादा निष्पक्ष बनाने की कोशिश कर रहे हैं. हमें लगता है कि सबमिशन की प्रोसेस के लिए, यह सबसे बेहतर तरीका है. इस लक्ष्य को ध्यान में रखते हुए, हम यह भी पक्का करेंगे कि इस प्रोसेस में स्पैम / बर्नर ईमेल सबमिट करने से रोका जा सके. |
| इससे जुड़े सबसेट | क्या एफ़पीएस, असोसिएट किए गए सबसेट के ज़रिए, तीसरे पक्ष के वेंडर/SaaS फ़्लो के इस्तेमाल के उदाहरणों के साथ काम कर पाएगा? | तीसरे पक्ष के वेंडर / SaaS फ़्लो, ऐसे इस्तेमाल के उदाहरण नहीं हैं जिन्हें फ़िलहाल फ़र्स्ट-पार्टी सेट के दायरे में माना जाता है. हम इन इस्तेमाल के उदाहरणों के लिए, क्रॉस-साइट कुकी के इस्तेमाल के तरीके के बारे में ज़्यादा सुझाव पाने के लिए तैयार हैं. |
| FPS + CHIPS इंटिग्रेशन | A/B टेस्टिंग जैसे इस्तेमाल के उदाहरणों के लिए, एफ़पीएस + चिप्स इंटिग्रेशन का अनुरोध करना | हम इस इस्तेमाल के उदाहरण के बारे में चर्चा कर रहे हैं. साथ ही, हम WICG कॉल में इस बारे में और भी चर्चा करने पर विचार कर रहे हैं. यहां और भी सुझाव/राय दें. |
| जीडीपीआर | जीडीपीआर के कॉन्सेप्ट के हिसाब से बनाए जाने वाले नए एफ़पीएस सबसेट का प्रस्ताव | हमने इस प्रस्ताव पर अपने अंदर चर्चा की है. साथ ही, इसे हमें मिले अन्य सुझाव/राय/शिकायतों और निजता से जुड़े अपने लक्ष्यों के हिसाब से तौला है. हमने जवाब दिया है, जिसमें बताया गया है कि फ़िलहाल, हम इस प्रस्ताव को लागू नहीं करेंगे. |
| मेमोरी | एफ़पीएस सूची को शामिल करने पर, ब्राउज़र मेमोरी के साइज़ में होने वाला अनुमानित बदलाव | ब्राउज़र में, इस तरह की सूचियों को स्टोर करने के उदाहरण पहले भी मौजूद हैं. इनसे मेमोरी पर कम से कम असर पड़ता है. जैसे, Disconnect की ट्रैकिंग से सुरक्षा पाने वाली सूची. फ़र्स्ट-पार्टी सेट की सूची को हर Chrome क्लाइंट में स्थानीय तौर पर कॉपी किया जाएगा. हालांकि, हम फ़ाइल के साइज़ पर नज़र बनाए रखेंगे. हमें भरोसा है कि हम मेमोरी फ़ुटप्रिंट को ऑप्टिमाइज़ कर सकते हैं. |
Fenced Frames API
| सुझाव, शिकायत या राय की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| फ़ेंस्ड फ़्रेम की सीमाएं | फ़ेंस किए गए फ़्रेम से जुड़ी सीमाओं के बारे में साफ़ तौर पर जानकारी | हमने मार्च में, फ़ेंस किए गए फ़्रेम के बारे में जानकारी देने वाले लेख को अपडेट किया था. इसमें, इस सुविधा की क्षमताओं के बारे में बताया गया है. हम अन्य सुझाव, शिकायत या राय का स्वागत करते हैं. |
| ऐक्सेस की जानकारी को बड़ा करना | आस-पास के फ़्रेम के बारे में जानकारी के ऐक्सेस को बढ़ाने का अनुरोध करना | हम इस बात को समझने की कोशिश कर रहे हैं कि यह ज़रूरी क्यों है कि आपका ऐप्लिकेशन, इकोसिस्टम की ज़रूरी शर्तों को पूरा करता हो. साथ ही, हम आपके किसी भी सुझाव, राय या शिकायत का स्वागत करते हैं. |
| फ़ेंस्ड फ़्रेम और iframe | फ़ेंस किए गए फ़्रेम और आइफ़्रेम के बीच सुविधाओं की समानता के बारे में सवाल | Privacy Sandbox के सभी उपलब्ध एपीआई और रिपोर्ट, iframes और FencedFrames के लिए एक ही तरह से उपलब्ध होंगी. |
| फ़ेंस्ड फ़्रेम का साइज़ बदलना | फ़्रेम के साइज़ में बदलाव करने पर पाबंदी लगाने से, कुछ खास इस्तेमाल के उदाहरणों पर असर पड़ता है. | हम उन इस्तेमाल के उदाहरणों के बारे में ज़्यादा जानना चाहते हैं जिन पर इस पाबंदी का असर पड़ा है. साथ ही, हमें अतिरिक्त सुझाव/राय/शिकायत भी भेजें. |
Shared Storage API
| सुझाव, शिकायत या राय की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| तीसरे पक्ष के वर्कलेट | क्या तीसरे पक्ष, ऑरिजिन के हिसाब से बांटकर बनाए गए शेयर किए गए स्टोरेज में डेटा सेव कर सकते हैं? या फिर तीसरे पक्ष के मेज़रमेंट के लिए, अन्य वर्कलेट को कॉल करें? | कोड को चलाने के लिए ब्राउज़िंग कॉन्टेक्स्ट का ऑरिजिन, यह तय करता है कि डेटा किसके शेयर किए गए स्टोरेज में सेव किया जाएगा. जब किसी पेज में तीसरे पक्ष का कोड जोड़ा जाता है, तो तीसरे पक्ष के कोड को अपने ब्राउज़िंग कॉन्टेक्स्ट के साथ iframe के तौर पर एम्बेड किया जा सकता है. इससे तीसरे पक्ष के कोड को अपने ऑरिजिन में लिखने की अनुमति मिलती है. तीसरे पक्ष के कोड को iframe के बजाय स्क्रिप्ट के तौर पर भी एम्बेड किया जा सकता है. इससे ब्राउज़िंग कॉन्टेक्स्ट नहीं बदलता और तीसरा पक्ष, एम्बेड करने वाले के शेयर किए गए स्टोरेज में लिख सकता है. ध्यान दें कि शेयर किए गए स्टोरेज का मालिक ही उसमें मौजूद डेटा को पढ़ सकता है. |
| डिडुप्लिकेशन | Chrome नेटवर्क के बाहर के इंटरैक्शन के लिए, डुप्लीकेट कॉपी हटाने की सुविधा काम नहीं करेगी. | शेयर किए गए स्टोरेज का मकसद, Chrome ब्राउज़र पर यूनीक रीच के आधार पर, Chrome में आउटपुट उपलब्ध कराना है. हम विज्ञापन टेक्नोलॉजी से जुड़ी कंपनियों के साथ मिलकर काम करना चाहते हैं, ताकि यह समझा जा सके कि इन आउटपुट का इस्तेमाल, ज़्यादा लोगों तक पहुंचने वाले मॉडल के हिस्से के तौर पर कैसे किया जा सकता है. हम समझते हैं कि आउटपुट में सिर्फ़ कुछ इंटरैक्शन शामिल हो सकते हैं. इसलिए, हम विज्ञापन टेक्नोलॉजी के साथ मिलकर काम करना चाहते हैं, ताकि मॉडलिंग के अन्य तरीकों को एक्सप्लोर किया जा सके. |
| कन्वर्ज़न लुकबैक विंडो | समय के साथ कन्वर्ज़न में हुए बदलावों को देखने के लिए, कन्वर्ज़न रेट के लिए लुकबैक विंडो का अनुरोध करना | इसे लागू करने के लिए, शेयर किए गए स्टोरेज का इस्तेमाल करके क्लाइंट साइड पर अलग-अलग कन्वर्ज़न पाथ को प्रोसेस किया जा सकता है. इससे, ब्राउज़र के सुरक्षित और बिना बंटे हुए स्टोरेज के मुकाबले, बेहतर आंकड़े पाने में ज़्यादा मदद मिलती है. |
| आइटम की समयसीमा खत्म होने की विंडो | कॉन्टेंट हटाने की समयसीमा को 90 दिनों तक बढ़ाने का अनुरोध करना | डेटा को सेव रखने की नीति को नवंबर 2022 में अपडेट किया गया था. इसमें बताया गया है कि आखिरी बार डेटा सेव करने के तीस दिन बाद, हर पासकोड मिटा दिया जाता है. हमें इस बारे में और सुझाव, राय या शिकायतें मिल सकती हैं कि नई नीति, इस पारिस्थितिक तंत्र के लिए काम करेगी या नहीं. |
| क्रिएटिव रोटेशन | क्रिएटिव रोटेशन के इस्तेमाल के उदाहरणों में, नीलामी के बाद की असल कार्रवाइयां नहीं दिखती हैं. | हम विज्ञापन देने वाली ज़्यादा कंपनियों से इस बारे में जानना चाहते हैं कि क्रिएटिव रोटेशन के दस्तावेज़ सही हैं या नहीं. |
CHIPs
इस तिमाही में कोई सुझाव, राय या शिकायत नहीं मिली.
FedCM
| सुझाव, शिकायत या राय की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| आइडेंटिटी एश्योरेंस एंडपॉइंट | पहचान की पुष्टि करने वाले एंडपॉइंट पर, मनमुताबिक अनुरोध करने की अनुमति दें. | हम इस पुल अनुरोध पर Mozilla के साथ मिलकर काम कर रहे हैं, ताकि वेबसाइटें उपयोगकर्ताओं को परेशान किए बिना, क्रेडेंशियल के साथ क्रॉस-ऑरिजिन अनुरोध चुपचाप कर सकें. साथ ही, हम अन्य सुझावों और राय की समीक्षा करते रहेंगे और उन पर कार्रवाई करते रहेंगे. |
| पहचान की जानकारी अपने-आप भरना | क्या FedCM का इस्तेमाल, साइन इन फ़ॉर्म में FedCM की सूची में शामिल, पहचान की पुष्टि करने वाली सेवा देने वाली कंपनी की जानकारी अपने-आप भरने के लिए किया जा सकता है? | इस इस्तेमाल के उदाहरण से जुड़ी चिंता यह है कि इससे जानकारी लीक हो सकती है. ऐसा तब हो सकता है, जब उपयोगकर्ता के साथ इंटरैक्ट न करने वाली कोई साइट, उपयोगकर्ता के आखिरी आईडीपी से क्वेरी कर सके. हम इस समस्या पर चर्चा कर रहे हैं. साथ ही, हमें इस बारे में और सुझाव, राय या शिकायतें भेजने में खुशी होगी. |
| कॉन्टेक्स्ट के हिसाब से खाता चुनना | खाता चुनने वाले यूज़र इंटरफ़ेस (यूआई) में, कॉन्टेक्स्ट के हिसाब से सिग्नल जोड़ने का प्रस्ताव | हम इस प्रस्ताव पर विचार कर रहे हैं. साथ ही, अतिरिक्त चर्चाओं का स्वागत करते हैं. |
स्पैम और धोखाधड़ी को रोकना
Private State Token API (और अन्य एपीआई)
| सुझाव, शिकायत या राय की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| सुविधाओं के बारे में जानकारी पाने के लिए सर्वे | हमने पहली तिमाही की शुरुआत में, अपने सर्वे के नतीजे इकट्ठा कर लिए हैं. इन नतीजों से पता चलता है कि धोखाधड़ी रोकने के लिए, किन अलग-अलग तरीकों का इस्तेमाल किया जा सकता है. साथ ही, हमने इन नतीजों को सार्वजनिक तौर पर शेयर किया है (मिनट, नतीजे) | हम इस सुझाव को शामिल करने की कोशिश करेंगे. साथ ही, धोखाधड़ी रोकने के लिए, खास मकसद के लिए बनाए गए और निजता बनाए रखने वाले एपीआई के लिए नए प्रपोज़ल और प्रोटोटाइप बनाएंगे. हमें उम्मीद है कि हम उन सुविधाओं को प्राथमिकता देंगे जिनकी ज़रूरत ज़्यादा है और जिनके लिए ऐसी मौजूदा टेक्नोलॉजी उपलब्ध है जिससे वेब पर इन सुविधाओं को उपलब्ध कराया जा सके. साथ ही, इन सुविधाओं को उपलब्ध कराते समय, उपयोगकर्ता की निजता को बनाए रखा जा सके. उदाहरण के लिए, डिवाइस और बूट की सुरक्षा को सबसे ज़्यादा प्राथमिकता दी गई थी. साथ ही, कई प्लैटफ़ॉर्म पर ऐसे मौजूदा एपीआई हैं जो डिवाइस की सुरक्षा का आकलन सुरक्षित तरीके से शेयर करते हैं. इसलिए, कम्यूनिटी ग्रुप में एक्सप्लोरेशन के लिए, यह एक अच्छा विकल्प है. |
| पीएसटी के लिए शिपिंग के इंटेंट से जुड़ा सुझाव, शिकायत या राय | प्रॉडक्ट शिप करने के मकसद से, हमें एक समस्या का पता चला है. इसकी वजह यह है कि हम Privacy Pass के पुराने वर्शन का इस्तेमाल कर रहे हैं. हमें यह सुझाव भी मिला है कि कुछ सेक्शन में स्पेसिफ़िकेशन साफ़ तौर पर नहीं बताया गया है. साथ ही, ब्राउज़र के साथ काम करने के लिए, इसमें सुधार किए जाने चाहिए. | हमारा प्लान है कि GA में शिप करने से पहले, हम स्पेसिफ़िकेशन में सुझाए गए कई बदलावों के साथ-साथ एपीआई में कुछ बदलाव भी लागू करें. हमें यह सुझाव, पहली तिमाही के आखिर में मिला था. इसलिए, हम github से जुड़ी समस्याओं पर खास जानकारी के साथ फ़ॉलो अप कर रहे हैं. साथ ही, हम लॉन्च के प्लान के बारे में भी अपडेट दे रहे हैं. इस सुझाव की रिपोर्ट पब्लिश होने तक, हम इस पर काम कर रहे हैं. हम एपीआई में बड़े बदलावों पर विचार करने के लिए तैयार हैं. हालांकि, हमें लगता है कि एपीआई को सभी के लिए उपलब्ध कराना और ज़्यादा डेवलपर से सुझाव/राय/शिकायत पाना सबसे सही तरीका है. हमें उम्मीद है कि हम इस चर्चा को जारी रखेंगे और ब्राउज़र को स्टैंडर्ड बनाने की दिशा में काम करेंगे. अगर कोई नया स्टैंडर्ड बनता है, तो हम उसे अपनाने और उस पर ट्रांज़िशन करने के लिए एक प्लान बनाएंगे. |