साल 2023 की दूसरी तिमाही की तिमाही रिपोर्ट, जिसमें Privacy Sandbox के प्रपोज़ल और Chrome से मिले जवाबों के बारे में नेटवर्क से मिले सुझाव, शिकायत या राय की खास जानकारी दी गई है.
CMA के साथ किए गए वादे के आधार पर, Google ने सार्वजनिक तौर पर कॉन्टेंट उपलब्ध कराने के लिए सहमति दी है प्राइवसी सैंडबॉक्स के लिए, स्टेकहोल्डर के जुड़ाव की प्रोसेस की तिमाही रिपोर्ट प्रस्ताव (अनुच्छेद 12 और 17(c)(ii) के संदर्भ में के आपकी प्रतिबद्धताएं). प्राइवसी सैंडबॉक्स के सुझाव, शिकायत या राय की खास जानकारी वाली ये रिपोर्ट, Chrome को अलग-अलग सोर्स से मिले सुझाव, जैसे कि सुझाव, शिकायत या राय में बताए गए हैं खास जानकारी, जिसमें GitHub शामिल है, लेकिन इसमें इनके अलावा, और भी चीज़ें शामिल हो सकती हैं समस्याएं, सुझाव, शिकायत या राय के लिए फ़ॉर्म privacysandbox.com, इंडस्ट्री के लोगों के साथ मीटिंग करते हैं पार्टनर, और वेब स्टैंडर्ड फ़ोरम. Chrome आपके फ़ीडबैक का स्वागत करता है लगातार सीखने के साथ-साथ, तय करने में मदद मिलती है.
सुझाव, शिकायत या राय से जुड़ी थीम, हर एपीआई के हिसाब से लोकप्रियता के हिसाब से रैंक की जाती हैं. ऐसा करने के लिए, Chrome टीम को मिले फ़ीडबैक की कुल संख्या दिया गया है और मात्रा के घटते क्रम में व्यवस्थित किया जा सकता है. सामान्य फ़ीडबैक पब्लिक मीटिंग में होने वाली चर्चा के विषयों की समीक्षा करके, थीम की पहचान की गई (W3C, PatCG, IETF), सीधे तौर पर फ़ीडबैक दें, GitHub, और अक्सर पूछे जाने वाले सवाल अपनी खबरों को Google की इंटरनल टीम और पब्लिक फ़ॉर्म के ज़रिए पब्लिश किया जा सकता है.
खास तौर पर, वेब स्टैंडर्ड मीटिंग के लिए मीटिंग के मिनट Google के 1:1 स्टेकहोल्डर मीटिंग के रिकॉर्ड की समीक्षा की गई और सीधे सुझाव के लिए, व्यक्तिगत इंजीनियर, API की ईमेल सूची, और लोगों से मिले ईमेल सुझाव, शिकायत या राय वाले फ़ॉर्म पर विचार किया गया. इसके बाद Google ने दोनों टीमों के बीच तालमेल बनाया इन अलग-अलग आउटरीच गतिविधियों में शामिल हैं. हर एपीआई के संबंध में उभरती हुई थीम का प्रसार.
सुझाव, राय या शिकायत के लिए Chrome के जवाबों की जानकारी, पब्लिश किए गए पब्लिकेशन से ली गई है अक्सर पूछे जाने वाले सवाल, हिस्सेदारों की बताई गई समस्याओं पर असल में दिए गए जवाब, और यह तय करना कि नहीं किया जा सकेगा. डेवलपमेंट और टेस्टिंग के मौजूदा फ़ोकस, सवाल, और सुझाव, शिकायत या राय पर ध्यान देना खास तौर पर, Topics, Protected Audience, और एट्रिब्यूशन के बारे में मिले Reporting API.
ऐसा हो सकता है कि मौजूदा रिपोर्टिंग अवधि के खत्म होने के बाद मिले सुझाव, शिकायत या राय में Chrome रिस्पॉन्स को माना जाता है.
शॉर्ट फ़ॉर्म की शब्दावली
- सीएचआईपीएस
- कुकी की इंडिपेंडेंट पार्टिशन्ड स्टेट
- डीएसपी
- मांग-साइड प्लैटफ़ॉर्म
- FedCM
- फ़ेडरेटेड क्रेडेंशियल मैनेजमेंट
- FPS
- पहले पक्ष के सेट
- IAB
- इंटरैक्टिव विज्ञापन ब्यूरो
- IDP
- पहचान देने वाली सेवा
- आईईटीएफ़
- इंटरनेट इंजीनियरिंग टास्क फ़ोर्स
- आईपी
- इंटरनेट प्रोटोकॉल पता
- openRTB
- रीयल-टाइम बिडिंग
- OT
- ऑरिजिन ट्रायल
- PatCG
- प्राइवेट विज्ञापन टेक्नोलॉजी कम्यूनिटी ग्रुप
- प्रतिबंधित पार्टी
- भरोसेमंद पार्टी
- SSP
- सप्लाई-साइड प्लैटफ़ॉर्म
- टीईई
- भरोसेमंद एक्ज़ीक्यूशन एनवायरमेंट
- UA
- उपयोगकर्ता एजेंट स्ट्रिंग
- UA-CH
- यूज़र-एजेंट क्लाइंट हिंट
- W3C
- वर्ल्ड वाइड वेब कंसोर्टियम
- WIPB
- विलफ़ुल आईपी ब्लाइंडनेस
सामान्य फ़ीडबैक, कोई विशिष्ट API/तकनीक नहीं
| सुझाव की थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| डेटा को मैनेज करना और नियामक अनुपालन | प्राइवसी सैंडबॉक्स के इस्तेमाल के बारे में ईकोसिस्टम के दिशा-निर्देश, जो कानूनी शर्तों का पालन करता हो. | किसी भी नई टेक्नोलॉजी की तरह, हर कंपनी को यह पक्का करना होगा कि वह Privacy Sandbox का इस्तेमाल कानून के मुताबिक करे; Google, अन्य लोगों को कानूनी सलाह नहीं दे सकता. हालांकि, हम जानते हैं कि नेटवर्क में यह एक अहम हिस्सा है. हर एपीआई के लिए, हमने पूरा तकनीकी दस्तावेज़ पब्लिश किया है. इससे, ज़रूरी कानूनी आकलन के लिए आधार बनाया जा सकता है. हम कंपनियों की मदद करने के लिए, अतिरिक्त कॉन्टेंट उपलब्ध कराने पर काम कर रहे हैं कानूनी समझौते की शर्तों का पालन करने की पूरी कोशिश की जाएगी. |
| CMA क्वांटिटेटिव टेस्टिंग प्रस्ताव | सीएमए के आंकड़ों वाले टेस्टिंग प्रस्ताव के बारे में ज़्यादा जानकारी | हम सीएमए के साथ मिलकर ऐसे एक्सपेरिमेंट डिज़ाइन कर रहे हैं जिनसे तीसरे पक्ष की कुकी के बंद होने के असर और नेटवर्क पर प्राइवसी सैंडबॉक्स के प्रपोज़ल के बारे में जानकारी मिलेगी. अप्रैल में, सीएमए ने जून में ज़्यादा जानकारी वाले दिशा-निर्देश पब्लिश किए थे. इनमें बताया गया था कि टेस्टिंग और ट्रायल की अवधि के दौरान क्या उम्मीद की जा सकती है. इसके बाद, जून में ज़्यादा जानकारी वाले दिशा-निर्देश पब्लिश किए गए थे. हम चाहते हैं कि सीएमए के क्वांटिटेटिव टेस्टिंग प्रस्ताव से जुड़े सवाल या सुझाव, राय या शिकायत को सीधे सीएमए के साथ शेयर किया जाए. |
| Chrome के साथ काम करने वाले टेस्टिंग मोड | टेस्टिंग के शेड्यूल के बारे में ज़्यादा जानकारी और साफ़ तौर पर जानकारी | हमने 18 मई को एक ब्लॉग पोस्ट पब्लिश किया था. इसमें, Chrome की मदद से टेस्टिंग करने के दो मोड के बारे में ज़्यादा जानकारी शेयर की गई थी. फ़िलहाल, यह जानकारी फ़ाइनल नहीं है. हम 2023 की तीसरी तिमाही में, इस सुविधा को लागू करने के दिशा-निर्देश पब्लिश करेंगे. |
| पार्टिशन्ड स्टोरेज | क्या Chrome की टेस्टिंग के दौरान, स्टोरेज के लिए इस्तेमाल किए जाने वाले हिस्से का इस्तेमाल होगा? | तीसरे पक्ष की कुकी का इस्तेमाल बंद करने के एक्सपेरिमेंट से पहले, स्टोरेज के बंटवारे की सुविधा सभी उपयोगकर्ताओं को भेज दी जाएगी. इसलिए, इसे प्रयोग के सभी ग्रुप के लिए चालू कर दिया जाएगा. इस समयावधि में, साइटों के लिए उपलब्ध स्टोरेज को फिर से पाने के लिए, सुविधा को बंद करने वाला ट्रायल चालू करने का विकल्प होगा. |
| प्रोडक्शन सपोर्ट | Privacy Sandbox से जुड़ी तकनीकी समस्याओं और नेटवर्क पर असर डालने वाली समस्याओं को हल करने में Chrome के लिए क्या प्रोसेस है? | Google कई चैनल उपलब्ध कराता है, ताकि विज्ञापन टेक्नोलॉजी से जुड़ी कंपनियों को समस्याओं की शिकायत करने और उन्हें सूचना देने की सुविधा मिल सके. अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है हमें सार्वजनिक और निजी फ़ोरम पर सुझाव, शिकायत या राय भेजने और अपनी समस्या के बारे में ज़्यादा जानकारी पाने के लिए, हमारी डेवलपर पोस्ट देखें. |
| रजिस्ट्रेशन की टाइमलाइन | रजिस्ट्रेशन के लिए मौजूदा समयसीमा बहुत कम है | हम अब भी नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) की समयसीमा का आकलन कर रहे हैं. साथ ही, हम नेटवर्क से जानना चाहते हैं कि इसके लिए कौनसी समयावधि सही रहेगी. |
| डीयूएनएस नंबर | रजिस्ट्रेशन और पुष्टि करने के लिए डीयूएनएस नंबर की ज़रूरी शर्तों के बारे में ज़्यादा जानकारी | डीयूएनएस नंबर पाने से जुड़ी ज़रूरी शर्तों के बारे में जानने के लिए, Dun & Bradstreet की वेबसाइट पर जाएं. मार्केट के हिसाब से ज़रूरी शर्तें अलग-अलग हो सकती हैं. इसलिए, यह ज़रूरी है कि हिस्सा लेने वाले लोग, किसी खास मार्केट के लिए वेबसाइट पर आएं. आम तौर पर, इसमें हिस्सा लेने वाले लोगों को अपने कारोबार के बारे में बुनियादी जानकारी देनी होगी. जैसे, कारोबार का नाम, पता, और कारोबार के मालिक या मैनेजर की संपर्क जानकारी. हिस्सा लेने वालों से, कारोबार की सालाना आय जैसी वित्तीय जानकारी देने के लिए भी कहा जा सकता है. आवेदन पूरा होने के बाद, D&B उसकी समीक्षा करेगा और आवेदन स्वीकार होने पर डीयूएनएस नंबर जारी करेगा. |
| ऑरिजिन ट्रायल से सामान्य तौर पर उपलब्धता में बदलना | क्या ऑरिजिन ट्रायल की जगह सामान्य रूप से उपलब्ध कराने की सुविधा में ट्रांज़िशन का असर, ऑरिजिन ट्रायल के लिए इस्तेमाल किए जाने वाले मौजूदा टेस्टर पर पड़ेगा? | जुलाई से, टेस्टर सामान्य रूप से उपलब्धता और मेज़रमेंट एपीआई को ऐक्सेस कर पाएंगे. इससे, ऑरिजिन ट्रायल की उपलब्धता और सामान्य रूप से उपलब्ध होने के बीच एक अंतर दिखेगा. |
| AdExchanger स्टडी | सर्वे के काम करने के तरीके के बारे में ज़्यादा जानकारी | सर्वे में जवाब देने वालों से अपने कारोबारों के लिए सिंक दरों और आय का अनुमान लगाने के लिए कहा गया. जवाब देने वाले लोग ज़रूरत के हिसाब से उनके अलग-अलग सवालों के जवाब देने का तरीका उन्हें तय करता था. |
| पैरामीटर के मान | गै़र-ज़रूरी डेटा का लेवल, पहचान छिपाने के थ्रेशोल्ड, और निजता बजट जैसे पैरामीटर वैल्यू कैसे तय की जाती हैं? | GitHub की जानकारी देने वाला यह दस्तावेज़, प्राइवसी सैंडबॉक्स एपीआई के सामान्य सिद्धांतों के बारे में बताता है. कई वैल्यू अब भी तय की जा रही हैं. हम इस विषय पर अपने सुझाव/शिकायत/राय का स्वागत करते हैं. |
काम का कॉन्टेंट दिखाएं और की है
विषय
| सुझाव की थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| निजता संरक्षण | निजता की सुरक्षा के लिए Topics API का आकलन करना | हम रिसर्च कम्यूनिटी में शामिल हैं. यहां हम Topics API की निजता से जुड़ी विशेषताओं पर अपनी रिसर्च को पेपर, रिपोर्ट, और वर्कशॉप प्रज़ेंटेशन में पेश करते हैं. हमें खुशी है कि रिसर्च कम्यूनिटी के बाहरी सदस्य, इस क्षेत्र में काम कर रहे हैं. अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है Topics API, उपयोगकर्ताओं को वेब पर सामान्य ट्रैकिंग से बचाता है, क्योंकि इससे बड़े पैमाने पर लोगों को ट्रैक करना बहुत मुश्किल हो जाता है. इन पेपर से पता चलता है कि हम Topics API की मदद से ऐसा कर रहे हैं. यह तीसरे पक्ष की कुकी की तुलना में ज़्यादा निजी होती है. साथ ही, यह उपयोगकर्ताओं की उन साइटों को सुरक्षित रखती है जिन पर वे जाते हैं. |
| विषयों की अलग-अलग कैटगरी में पूरी जानकारी नहीं है | बड़े विषयों की अलग-अलग कैटगरी में, किसी खास इलाके के हिसाब से भी जानकारी को शामिल नहीं किया जाता. | नेटवर्क से मिले पिछले सुझावों के जवाब में, हमने 15 जून को एक ब्लॉग पोस्ट पब्लिश किया था. इसमें, अपडेट की गई एक नई कैटगरी की जानकारी दी गई थी. इस अपडेट में, नेटवर्क से मिले सुझावों के बाद किए गए कई सुधार शामिल हैं. अपडेट की गई टेक्सॉनमी पर काम के तहत, हमने पूरे नेटवर्क में मौजूद कई कंपनियों के साथ काम किया. जैसे, Raptive (पहले CafeMedia) और Criteo. अपडेट की गई टेक्सॉनमी में, ऐसी कैटगरी को हटा दिया जाता है जो संभावित तौर पर संवेदनशील विषयों को बाहर रखने की हमारी प्रतिबद्धता को बनाए रखते हुए, विज्ञापन देने वाले लोगों या कंपनियों की दिलचस्पी से ज़्यादा मेल खाने वाली कैटगरी के लिए ज़्यादा फ़ायदेमंद नहीं होतीं. अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है हम नेटवर्क को नई कैटगरी की समीक्षा करने और इन बदलावों पर सुझाव देने के लिए बढ़ावा देते हैं. |
| टेक्सॉनमी और क्लासिफ़ायर अपडेट करने की प्रोसेस | टॉपिक टेक्सॉनमी और कैटगरी तय करने वाले टूल की रिलीज़ के बीच ज़्यादा जानकारी पाएं. साथ ही, यह भी जानें कि कंपनियां ऐसे अपडेट के लिए कैसे तैयारी कर सकती हैं. | जैसा कि हाल ही के ब्लॉग पोस्ट में बताया गया है, हम उम्मीद करते हैं कि समय के साथ, अलग-अलग कैटगरी में बदलाव होगा. साथ ही, इस कैटगरी को मैनेज करने की प्रोसेस आगे चलकर ऐसी बाहरी पार्टी पर ट्रांसफ़र हो जाएगी जो इंडस्ट्री के हिस्सेदारों का प्रतिनिधित्व करती है. हमने रैंप-अप प्लान को विषयों की जानकारी वाले ग्रुप में भी शेयर किया है. |
| पहले पक्ष (ग्राहक) के सिग्नल पर असर | हाल ही में हुए टेक्सॉनमी अपडेट में, Topics की संख्या में काफ़ी बढ़ोतरी हो सकती है. इसकी वजह से, पहले-पक्ष की दिलचस्पी के आधार पर अन्य सिग्नल की वैल्यू कम हो जाती है. | साल 2023 की पहली तिमाही की रिपोर्ट में, सीएमए ने टिप्पणी की. "हम समझते हैं कि Google, विज्ञापन टेक्नोलॉजी की सप्लाई चेन से जुड़े मार्केट के कई लोगों के साथ, अपनी प्रस्तावित नई टेक्सॉनमी पर चर्चा कर रहा है. कुछ बड़े पब्लिशरों ने कहा है कि विषयों का ज़्यादा इस्तेमाल करने से, उनके पहले पक्ष के डेटा पर आधारित समाधानों पर प्रतिस्पर्धा बढ़ सकती है. हमारा शुरुआती नज़रिया यह है कि प्रतिस्पर्धा के लिए ज़्यादा सुविधाएं बेहतर होती हैं. खास तौर पर, तीसरे पक्ष की कुकी की सुविधा बंद होने के बाद भी, छोटे पब्लिशर अपनी इन्वेंट्री से कमाई जारी रख सकते हैं". हमारा नज़रिया, सीएमए की इस टिप्पणी के मुताबिक है. |
| अलग-अलग तरह के हिस्सेदारों के लिए उपयोगिता | एसएसपी और डीएसपी के तौर पर काम करने वाली विज्ञापन टेक्नोलॉजी से, नेटवर्क में शामिल अन्य उपयोगकर्ताओं की तुलना में ज़्यादा फ़ायदा हो सकता है. | पिछली तिमाहियों के मुकाबले हमारे जवाब में कोई बदलाव नहीं हुआ है: अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है Google ने प्राइवसी सैंडबॉक्स के प्रपोज़ल को इस तरह से डिज़ाइन और लागू करने के लिए प्रतिबद्ध है कि Google के खुद के कारोबार को खुद को प्राथमिकता देकर, प्रतिस्पर्धा में रुकावट न डाले. साथ ही, डिजिटल विज्ञापन के साथ-साथ पब्लिशर और विज्ञापन देने वाली कंपनियों पर पड़ने वाले असर को ध्यान में रखता है. भले ही, उनका साइज़ कुछ भी हो. हम सीएमए के साथ मिलकर काम कर रहे हैं, ताकि यह पक्का किया जा सके कि हमारा काम इन वादों का पालन करता हो. प्राइवसी सैंडबॉक्स की टेस्टिंग के दौरान, हम कई अहम सवालों के जवाब देने के साथ-साथ यह जानने की कोशिश करेंगे कि नई टेक्नोलॉजी, अलग-अलग तरह के हिस्सेदारों के लिए कैसा परफ़ॉर्म कर रही हैं. इस मामले में सुझाव या राय अहम है. खास तौर पर, इस बारे में सुझाव/राय देना या शिकायत करना, इससे हमें तकनीकी डिज़ाइन को और बेहतर बनाने में मदद मिल सकती है. हमने आंकड़ों वाले डेटा की जांच करने के अपने तरीके को डेवलप करने के लिए, सीएमए के साथ काम किया है. हम, बाज़ार में हिस्सा लेने वालों को ज़्यादा जानकारी देने और सुझाए गए तरीकों पर टिप्पणी करने का मौका देने के लिए, एक्सपेरिमेंट के डिज़ाइन पर नोट पब्लिश करने वाले सीएमए की मदद करते हैं." |
| डिसेंडेंट विषय | विषय चुनने की शर्तें, ब्राउज़र विज़िट की फ़्रीक्वेंसी होने की वजह से, क्या सेगमेंट फ़्रैगमेंटेशन डिसेंडेंट विषय को पेज पर सबसे ऊपर कभी नहीं दिखाएगा? | फ़िलहाल, Chrome रैंकिंग को बेहतर बनाने के अन्य तरीकों की जांच कर रहा है. साथ ही, रैंकिंग को बेहतर बनाने वाले अन्य सिग्नल एक्सप्लोर कर रहा है. आने वाले समय में, हम अपने बदलावों के बारे में नेटवर्क को जानकारी देंगे. |
| संवेदनशीलता | Topics API का लक्ष्य यह पक्का करना होना चाहिए कि Topics API से मिली या हासिल की गई उपयोगकर्ता जानकारी, आज के ट्रैकिंग तरीकों का इस्तेमाल करके मिल सकने वाली जानकारी की तुलना में व्यक्तिगत तौर पर कम संवेदनशील होनी चाहिए. | हमारा मानना है कि Topics API, मौजूदा टेक्नोलॉजी की तुलना में ज़्यादा निजी है. साथ ही, इसे संवेदनशील विषयों को बाहर रखने के लिए डिज़ाइन किया गया है, ताकि लोगों की पहचान ज़ाहिर न हो पाए. हम स्वीकार करते हैं कि संवेदनशील कैटगरी बनाने के लिए, विषयों को पहले पक्ष (ग्राहक) के डेटा के साथ जुड़ा या जोड़ा जा सकता है. हालांकि, हमारा मानना है कि Topics API, लोगों की निजता बनाए रखने की दिशा में एक कदम है. साथ ही, हम एपीआई को बेहतर बनाने के लिए लगातार काम कर रहे हैं. |
| टेक्सॉनमी स्ट्रक्चर | विषयों की अलग-अलग कैटगरी में आईडी, वर्शन, और अन्य मेटाडेटा स्ट्रक्चर जोड़ें | फ़िलहाल, हम एपीआई से मिले जवाब में टेक्सॉनमी आईडी शामिल कर रहे हैं. जैसे-जैसे हम लंबे समय के लिए सिस्टम को मैनेज करने की तरफ़ बढ़ रहे हैं, Topics ऑब्जेक्ट की समीक्षा करना सही रहता है. साथ ही, ज़रूरत पड़ने पर वर्शन से जुड़ा अतिरिक्त मेटाडेटा भी शामिल करना सही रहता है. |
| पब्लिशर कंट्रोल | पब्लिशर को यह तय करना चाहिए कि उनकी साइटों को किन विषयों के तहत रखा जाए. | अगर साइटों को गलत कैटगरी में रखा जाता है, तो सिग्नल के तौर पर Topics का सिग्नल थोड़ा कम काम का हो सकता है. हालांकि, जिन साइटों को गलत कैटगरी में रखा जाता है उन्हें अन्य साइटों के मुकाबले, ज़्यादा नुकसान नहीं पहुंचता. ऐसा इसलिए होता है, क्योंकि किसी साइट की विषय से जुड़ी जानकारी, उसकी साइट पर नीलामियों के लिए हमेशा उपलब्ध रहेगी. इससे सही विषय के साथ तुलना करने लायक जानकारी मिलेगी, भले ही उसे गलत कैटगरी में रखा गया हो. हम इस विषय पर यहां फ़ीडबैक का स्वागत करते हैं. अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है पब्लिशर को अपने डेटा की कैटगरी तय करने की अनुमति देने में कुछ जोखिम हो सकते हैं. ऐसा हो सकता है कि साइटें, जान-बूझकर अपनी साइटों की कैटगरी को गलत तरीके से कैटगरी में बांट दें. ऐसा हो सकता है कि वे सभी के लिए काम के न हों. इसके अलावा, कम इस्तेमाल होने वाले विषयों में संवेदनशील जानकारी को कोड में बदल सकते हैं, जिससे उपयोगकर्ता की निजता को नुकसान पहुंच सकता है. |
| Chrome एक्सटेंशन | Chrome एक्सटेंशन को कुकी मैनेजमेंट के मौजूदा एक्सटेंशन से मिलते-जुलते विषयों को मैनेज और फ़िल्टर करने की अनुमति दें | जैसा कि GitHub पर चर्चा हुई है, पहले से ऐसा किया जा सकता है. हालांकि, हम नेटवर्क से आपके अन्य सुझावों का भी स्वागत करते हैं. |
| सामान्य रूप से उपलब्ध होने की सुविधा पर स्विच करना | ऑरिजिन ट्रायल से सामान्य उपलब्धता में बदलने पर, क्या Topics API पर कोई असर पड़ेगा? | ऑरिजिन ट्रायल से सामान्य उपलब्धता पर स्विच करने वाले उपयोगकर्ताओं का कोई डेटा गायब नहीं होगा. |
| निजता | होस्ट के नाम में ऐसी निजी जानकारी हो सकती है जो Topics API की मदद से ज़ाहिर की जा सकती है | निजता को पक्का करने के लिए, हमने कई पाबंदियां लागू की हैं, जैसा कि यहां बताया गया है. |
| धोखाधड़ी और गलत इस्तेमाल | वेबसाइट पर धोखाधड़ी करके, Topics में बदलाव करने से रोकने का तरीका | खतरों को कम करने के बारे में यहां बताया गया है. |
| विषयों की कैटगरी तय करने वाला टूल | क्या वेबसाइटें, अपने Topics के क्लासिफ़िकेशन को बदलने का अनुरोध कर सकती हैं? | हम इस विषय पर हमारे नेटवर्क से जानना चाहते हैं. हम यहां अपने सुझाव देना चाहते हैं. |
| विषय देने वाली साइटें | कई विषयों का कॉन्टेंट होस्ट करने वाली कुछ वेबसाइटों को "खास विषय देने वाली साइटों" के तौर पर तय करना और उन्हें वेब पेजों पर दिए गए टैग के आधार पर ट्रेनिंग दें. | हम यहां इस प्रस्ताव पर चर्चा कर रहे हैं. आपके पास अन्य सुझाव, शिकायत या राय का भी इस्तेमाल करने का विकल्प है. |
Protected Audience API (पुराना नाम FLEDGE है)
| सुझाव की थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| ट्रैफ़िक शेपिंग | क्वेरी-प्रति-सेकंड (क्यूपीएस) लोड को ऑप्टिमाइज़ करने के लिए, एसएसपी की मदद से फ़िल्टर करने की सुविधा की परफ़ॉर्मेंस पर असर | हमने ट्रैफ़िक को आकार देने के बारे में सोचने में काफ़ी समय लगाया है और हम एसएसपी को कैश मेमोरी का फ़ायदा लेने का सुझाव देते हैं. |
| जांच के लिए वॉल्यूम | Protected Audience को टेस्ट करना चुनौती भरा है, क्योंकि एसएसपी और डीएसपी को ज़्यादा ट्रैफ़िक पाने में समस्या आ रही है. | सुरक्षित ऑडियंस को अपनाने और उनकी जांच करने के लिए, हम एसएसपी और डीएसपी पार्टनर से लगातार जुड़ रहे हैं. सभी के लिए इसे उपलब्ध कराने की सुविधा शुरू हो गई है. हमें भरोसा है कि पीए की सुविधा चालू होने पर, ट्रैफ़िक का प्रतिशत हमारे पार्टनर के लिए आसान हो जाएगा. |
| जटिलता | Protected Audience API को लागू करने के लिए, ज़्यादा मेहनत और लागत की ज़रूरत होती है. | हम मानते हैं कि नई टेक्नोलॉजी को अपनाना मुश्किल है. जैसे, प्राइवसी सैंडबॉक्स. Privacy Sandbox की टीम कई तरह के हिस्सेदारों के साथ मिलकर काम कर रही है, ताकि उन्हें अपनी कोशिशों के बारे में जानकारी दी जा सके और उन्हें मदद मिल सके. साथ ही, नेटवर्क को अपनाने में मदद करने के लिए, Privacy Sandbox की टीम लगातार काम कर रही है. |
| भरोसेमंद एक्ज़ीक्यूशन एनवायरमेंट | गैर-सार्वजनिक क्लाउड एनवायरमेंट में ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) के लिए सहायता | हम क्लाउड-आधारित समाधान के अलावा, अन्य विकल्पों पर भी काम कर रहे हैं. हालांकि, फ़िलहाल हम कंपनी के मालिकाना हक वाले टीईई के साथ काम नहीं कर सकते. ऐसा इसलिए है, क्योंकि हम अपने संगठन के अंदर ही सुरक्षा से जुड़ी सीमाएं लागू कर रहे हैं. इस तरह, Privacy Sandbox का आकलन करने में काफ़ी समय लगेगा. Privacy Sandbox की सुरक्षा से जुड़ी ज़रूरी शर्तों और कंपनी के ऑफ़िस में डिप्लॉयमेंट से जुड़ी बड़ी चुनौतियों को देखते हुए, हमारा मानना है कि क्लाउड-आधारित डिप्लॉयमेंट को बढ़ाना और बेहतर बनाना नेटवर्क के लिए सबसे फ़ायदेमंद है. उदाहरण के लिए, AWS के साथ-साथ GCP की सेवाएं देना. हालांकि, हम इस बारे में अतिरिक्त सुझाव भी दे सकते हैं कि इस तरह की ज़रूरत क्यों पड़ी. |
| लागत का स्ट्रक्चर | बोली और नीलामी से जुड़ी सेवाओं के प्रस्ताव की मदद से, क्लाइंट-साइड मॉडल की तुलना में, विज्ञापन टेक्नोलॉजी से जुड़ी सेवाओं के लिए लागत और जटिलता को बढ़ाया जा सकता है. | फ़िलहाल, हम बिडिंग और नीलामी प्रोसेस में, बिडिंग और नीलामी वर्कफ़्लो की लागत का अनुमान लगाने के लिए एक गाइड तैयार कर रहे हैं हमारे डिज़ाइन का एक लक्ष्य पूरा करने के लिए, नीलामी सर्वर को विज्ञापन टेक्नोलॉजी के इस्तेमाल से जोड़ा जाएगा. |
| के-एनॉन टाइमलाइन्स | `renderUrl` पर, पहले से तय की गई के-एनॉनिमिटी से जुड़ी पाबंदियों को कब लागू किया जाएगा? | हम नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) की टाइमलाइन की जानकारी देने पर काम कर रहे हैं. इसे जल्द ही रिलीज़ किया जाएगा. |
| रनविज्ञापन नीलामी से जुड़ी पाबंदियां | क्या Chrome runAdAuction को सिर्फ़ मुख्य पेज से कॉल करने लायक बनाने के लिए प्रतिबंधित कर सकता है? |
जबकि हमारा डिज़ाइन runAdAuction को शीर्ष पेज से कॉल करने योग्य बनाने के लिए पूरी तरह से समर्थन करता है, फिर भी हम इसे केवल शीर्ष डोमेन से कॉल करने योग्य बनाने से प्रकाशकों को ज़्यादा नुकसान पहुंचाते हैं.अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है हमें खास तौर पर नेटवर्क से यह पता चला है कि प्राइवसी सैंडबॉक्स से पब्लिशर और विज्ञापन देने वाले लोगों या कंपनियों पर पड़ने वाला बोझ कम करना पड़ेगा. यह सुझाव वेब डेवलपमेंट के उस सामान्य सिद्धांत के साथ मेल खाता है जिसके मुताबिक साइट के मालिक अपनी साइटें चलाने के लिए तीसरे पक्ष के टूल का इस्तेमाल कर सकते हैं. प्राइवसी सैंडबॉक्स का मकसद, एक ऐसे नेटवर्क को बढ़ावा देना है जो सुरक्षित है. इसलिए, हमें यह लिखने की ज़रूरत नहीं होती कि पब्लिशर और विज्ञापन टेक्नोलॉजी कैसे काम करती हैं. अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है पब्लिशर को उनकी साइट पर runAdAuction को कॉल और कॉल करने का तरीका चुनने की अनुमति देने से, हमारा मानना है कि पब्लिशर को उनकी ज़रूरतों के हिसाब से सबसे सही पाथ खोजने में मदद मिलती है. |
| लागू करने में मदद | क्या Chrome, एक से ज़्यादा सेलर वाली नीलामी को ओपन सोर्स लागू कर सकता है या उसमें योगदान दे सकता है? | प्राइवसी सैंडबॉक्स का मकसद, निजता बनाए रखने वाली ऐसी टेक्नोलॉजी डेवलप करना है जो तीसरे पक्ष की कुकी या अन्य क्रॉस-साइट आइडेंटिफ़ायर पर निर्भर नहीं होती हैं. हम एक बेहतर नेटवर्क को बढ़ावा देना चाहते हैं. इसके लिए, हम यह नहीं चाहते कि विज्ञापन टेक्नोलॉजी को किस तरह से काम करने की ज़रूरत है. अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है हमने इस बारे में दिशा-निर्देश पब्लिश किए हैं कि GitHub रिपॉज़िटरी में एपीआई कैसे काम करता है. साथ ही, हम इंडस्ट्री के साथ मिलकर काम करने के लिए तैयार हैं. अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है हम किसी खास सुविधा को लागू करने के बारे में नहीं सोच रहे हैं, क्योंकि हमारा मुख्य मकसद प्लैटफ़ॉर्म टेक्नोलॉजी तैयार करना है, न कि इन टेक्नोलॉजी के इस्तेमाल के लिए रणनीतियां तय करना. हमारी टेक्नोलॉजी, विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली कंपनियों को उनके ग्राहकों को बेहतर सेवा देने में मदद करेंगी. इसके लिए, उपभोक्ताओं के लिए निजता के सही नियम लागू किए जाएंगे. |
| एक से ज़्यादा सेलर वाली नीलामी | क्या Chrome, "संदर्भ के हिसाब से" फ़ाइलें शेयर करने के लिए बाध्य करेगा कॉम्पोनेंट नीलामियों में विजेता रहे? | Protected Audience API, ऐसे एपीआई को डिज़ाइन किया गया है जिससे एक से ज़्यादा सेलर के लिए नीलामी शुरू करने वाले पक्ष, कॉम्पोनेंट नीलामी में जानकारी भेज सकें. ध्यान दें: नीलामी शुरू करने से पहले ही, ऐसा करें. अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है हालांकि, हमें ब्राउज़र के लिए यह पता लगाने का कोई तरीका नहीं पता कि जानकारी का कोई हिस्सा प्रासंगिक है या नहीं. इसलिए, हम ब्लॉक करने या कुछ जानकारी की ज़रूरत को लागू नहीं कर सके. |
| सहमति ट्रैक करने के लिए उपयोगकर्ता की प्राथमिकता | AdTech की ओर से, पीए से पूछा जा रहा है कि उपयोगकर्ता की सहमति को सही तरीके से ट्रैक करने का तरीका क्या है | हमारे जवाब में वह शामिल है जो हमने पहली तिमाही में कहा था: "कुछ खास विज्ञापनों के लिए, काम की विज्ञापन टेक्नोलॉजी ही वह पक्ष है जो यह कंट्रोल कर सकता है कि कौनसे क्रिएटिव दिखाए जाएं या उन्हें कैसे चुना जाए." अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है हमने मई WICG Protected Audience मीटिंग के दौरान, इस समस्या से जुड़ी कई स्थितियों पर चर्चा की. साथ ही, हम इस समस्या पर आपके सुझाव, शिकायत या राय का स्वागत करते हैं. |
| कस्टम ऑडियंस | क्या एसएसपी, कस्टम ऑडियंस बनाने से जुड़े मामलों का इस्तेमाल, Protected Audience API के साथ करेगा? | Protected Audience API, एसएसपी और विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली अन्य कंपनियों को कस्टम ऑडियंस बनाने और उन्हें मैनेज करने की अनुमति देता है. इस बारे में आगे के दिशा-निर्देश दिए जा रहे हैं कि SSP, PA API के साथ कैसे इंटिग्रेट हो सकता है. इसके अलावा, SSP और विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली अन्य कंपनियों को भी यह जानकारी उपलब्ध कराई जा सकेगी, ताकि उन्हें इंटिग्रेशन के लिए मदद मिल सके. |
| फ़ॉर्मैट | क्या वीडियो Protected Audience API के साथ काम करता है? | वीडियो विज्ञापन दो में से एक तरीके से दिखाए जाते हैं: VAST XML या HTML के रूप में (एक आउटस्ट्रीम विज्ञापन, जो आखिर में VAST XML को वीडियो प्लेयर में भी लोड कर सकता है). खरीदार, रेंडर यूआरएल की मदद से किसी भी फ़ॉर्मैट में कॉन्टेंट दिखा सकते हैं. Attribution Reporting API के साथ काम करने के लिए VAST (वीडियो विज्ञापन देने के लिए टेंप्लेट) का स्पेसिफ़िकेशन हाल ही में अपडेट किया गया था. वीडियो विज्ञापन दिखाने वाली साइटों को, Protected Audience API की मदद से विज्ञापन दिखाने के तरीके के हिसाब से तैयारी करनी होगी. इसका मतलब है कि यह पक्का करना होगा कि प्लेसमेंट टैग, यूआरएल को सुरक्षित ऑडियंस iframe से वीडियो प्लेयर में भेज सकते हैं. हम फ़ेंस किए गए फ़्रेम के लिए, फ़ेंस किए गए फ़्रेम का इस्तेमाल करने से पहले, वीडियो से जुड़ी ज़रूरतों को पूरा करने के लिए काम करेंगे. हालांकि, यह 2026 से पहले की तारीख नहीं है. |
| वीडियो की स्पीड | पेसिंग के इस्तेमाल का उदाहरण, Protected Audience API के साथ कैसे काम करता है? | हम सुझाव की सराहना करते हैं. हम इस अनुरोध से जुड़े ऐसे और मामले देखना चाहते हैं जिनके बारे में ज़्यादा जानकारी एसएसपी पार्टनर से ली जाए. हम चाहते हैं कि अब तक यह समस्या, डीएसपी को ध्यान में रखकर की गई हो. |
| अपडेट आवृत्ति | कुछ मामलों में, dailyUpdate से आने वाले कॉल की फ़्रीक्वेंसी (हर रुचि ग्रुप के लिए एक दिन में ज़्यादा से ज़्यादा एक) काफ़ी नहीं हो सकती. जैसे, प्रॉडक्ट की जानकारी अपडेट करना. |
हम सुझाव की सराहना करते हैं. ऐसे कुछ अन्य समाधान भी हैं जिनकी मदद से विज्ञापन टेक्नोलॉजी, K/V लुकअप जैसे अलग-अलग समय में रीफ़्रेश किए गए सिग्नल इस्तेमाल कर सकती हैं. |
| विज्ञापन क्वालिटी कंट्रोल | पब्लिशर, विज्ञापन क्वालिटी कंट्रोल को कैसे लागू करते हैं? | फ़िलहाल, Protected Audience API, पब्लिशर को अपने एसएसपी को कुछ ऐसे कंट्रोल के बारे में बताने की सुविधा देता है जिन्हें नीलामी से पहले कॉन्फ़िगर करने के लिए, प्री-बिड यानी विज्ञापनों से जुड़े लेबल के आधार पर ब्लॉकलिस्ट के तौर पर सेट किया जा सकता है. नेटवर्क के लिए ज़रूरी किसी भी अतिरिक्त सुविधा के बारे में हम अपने सुझाव, शिकायत या राय का स्वागत करते हैं. |
| डीबग करना | forDebuggingOnly की सुविधा कब हटाई जाएगी? |
तीसरे पक्ष की कुकी का इस्तेमाल बंद होने से, नुकसान होने वाले इवेंट के लिए हम forDebuggingOnly को बंद करने वाले हैं. हम forDebuggingOnly को बंद करने जा रहे हैं, ताकि साल 2026 में इवेंट जीत सकें. |
| क्रॉस-डिवाइस इंटरेस्ट ग्रुप | पुष्टि किए गए उपयोगकर्ता एजेंट के लिए, क्रॉस-डिवाइस इंटरेस्ट ग्रुप चालू करने का प्रस्ताव | हम इस प्रस्ताव की जांच कर रहे हैं. हालांकि, क्रॉस-डिवाइस टारगेटिंग की ज़्यादा सटीक जानकारी, निजता से जुड़ी गंभीर समस्याएं पैदा करती है. इसके बारे में GitHub की इस समस्या में बताया गया है. |
| (पहली तिमाही में भी रिपोर्ट की गई) डाइनैमिक रीमार्केटिंग | क्या तीसरे पक्ष की कुकी का इस्तेमाल बंद होने के बाद भी, Protected Audience API का इस्तेमाल करके डाइनैमिक रीमार्केटिंग की जा सकती है? | हमारा मानना है कि जैसा कि यहां बताया गया है, Protected Audience से जुड़े इस्तेमाल के इस उदाहरण का इस्तेमाल किया जा सकता है. |
| क्लिक से जुड़ा डेटा | browserSignals. में क्लिक से जुड़ा डेटा जोड़ें |
फ़िलहाल, हम इस बारे में साफ़ तौर पर जानना चाहते हैं कि क्लिक को शुरुआती स्थिति कब दी गई थी. |
| (2022 की चौथी तिमाही में भी रिपोर्ट की गई) Protected Audience से जुड़ी उपयोगकर्ता की ओर से तय किए गए फ़ंक्शन | Protected Audience API में, उपयोगकर्ता के तय किए गए फ़ंक्शन (यूडीएफ़) कैसे काम करेंगे? इन फ़ंक्शन को असली उपयोगकर्ता, एपीआई की सुविधाओं को बढ़ाने के लिए प्रोग्राम कर सकते हैं. | विज्ञापन टेक्नोलॉजी से जुड़ी जिस विज्ञापन टेक्नोलॉजी ने यह समस्या बताई थी उसने यह भी बताया कि वह अब भी इस बात का आकलन कर रही है कि यूडीएफ़ की मदद से क्या-क्या किया जा सकता है. इसलिए, हमें इस पर कोई कार्रवाई करने की ज़रूरत नहीं है. ऐसा तब तक नहीं होगा, जब तक सभी के लिए यह सुविधा सभी के लिए उपलब्ध न हो. |
| मुद्रा | मुद्रा की रकम को फ़्लोटिंग पॉइंट का इस्तेमाल करके नहीं दिखाया जाना चाहिए. | हमने इस समस्या को यहां विस्तार से हल किया है. |
| नॉन-डीएसपी विज्ञापन चुनने की सुविधाएं | Protect Audience API से जुड़ी नीलामियों में, विज्ञापन सर्वर क्या भूमिका निभाते हैं? | हम जानते हैं कि विज्ञापन सर्वर के अनुरोध के बाद, बिड के बाद वाले विज्ञापन चुनने की सेटिंग / डाइनैमिक क्रिएटिव ऑप्टिमाइज़ेशन सेवाओं को लगातार जारी रखा जाता है. फ़िलहाल, हम मौजूदा Protected Audience API और इन अनुरोधों के बीच के गैप विश्लेषण का आकलन कर रहे हैं. |
| GenerateBid | Google Ads का सहायता केंद्र generateBid से हर विज्ञापन रुचि समूह के लिए एक से ज़्यादा उम्मीदवार के विज्ञापन दिखाने और उन उम्मीदवारों के स्कोर `scoreAd` में देने का प्रस्ताव. |
फ़िलहाल, इसका आकलन किया जा रहा है. हम यहां आपके अतिरिक्त सुझाव का स्वागत करते हैं. |
| नीलामी का ऑर्डर | क्या Protected Audience API नीलामी को सबसे आखिर में चलाया जाना ज़रूरी है, ताकि यह अन्य सभी नीलामियों के नतीजों से जानकारी ले सके? | Protected Audience API को लंबे समय तक चलाने के लिए, किसी तकनीकी ज़रूरत की ज़रूरत नहीं है. |
| गैर-उपयोगकर्ता ने नेविगेशन की प्रोसेस शुरू की | उपयोगकर्ता की ओर से शुरू किए गए नेविगेशन को सार्वजनिक करें | हम इस अनुरोध की समीक्षा कर रहे हैं और इस पर चर्चा कर रहे हैं . हम आपके अलावा, कोई और सुझाव भी दे सकते हैं. |
| कैश मेमोरी में सेव करना | उपयोगकर्ता की स्थिति बदलने पर, एसएसपी को कैश मेमोरी से दिए गए डीएसपी के हर खरीदार के सिग्नल नहीं बनाने चाहिए. | हम समझते हैं कि कैश मेमोरी में सेव करने की सुविधा, हर खरीदार के सिग्नल के इस्तेमाल के मामले में काम नहीं करती. इसके अलावा, हम दूसरे विकल्पों का आकलन कर रहे हैं. हम नेटवर्क से मिलने वाले किसी भी अतिरिक्त सुझाव का स्वागत करते हैं और यह जानना चाहते हैं कि कैश मेमोरी में सेव किए गए डेटा का इस्तेमाल उनके इस्तेमाल के लिए किया जा सकता है या नहीं. |
| एट्रिब्यूशन रिपोर्टिंग और सुरक्षित ऑडियंस | Attribution Reporting API और Protected Audience Audience API, एक साथ कैसे काम कर सकते हैं? | फ़िलहाल, Protected Audience API के लिए इंटिग्रेशन, Attribution Reporting API मोड (इवेंट-लेवल और खास जानकारी वाली रिपोर्ट), दोनों के लिए उपलब्ध है. हमने 1 जून को बेहतर Protected Audience API और Attribution Reporting इंटिग्रेशन के बारे में ज़्यादा जानकारी शेयर की थी. इनके बारे में यहां पढ़ें. |
| सर्वर एंडपॉइंट | क्या आखिर में सर्वर एंडपॉइंट, भरोसेमंद एग्रीगेशन सर्वर होगा? | सर्वर एंडपॉइंट, विज्ञापन टेक्नोलॉजी से मैनेज किया जाने वाला ऐसा एंडपॉइंट है जो इकट्ठा की गई और बदली गई रिपोर्ट को प्रोसेस करने के लिए इस्तेमाल किए जाने वाले भरोसेमंद एग्रीगेशन सर्वर से अलग होता है. फ़िलहाल, रिपोर्टिंग एंडपॉइंट में कोई बदलाव नहीं किया गया है. मौजूदा डिज़ाइन का मकसद यह पक्का करना है कि एग्रीगेशन वाली रिपोर्ट (एन्क्रिप्ट किए गए पेलोड के साथ) क्रॉस-साइट डेटा लीक न हों. इसलिए, भरोसेमंद एंडपॉइंट की ज़रूरत नहीं होनी चाहिए. इसमें एक समस्या यह भी है कि अलग-अलग विज्ञापन टेक्नोलॉजी में, बैच बनाने की अलग-अलग रणनीतियां हो सकती हैं. हम यहां आपके अतिरिक्त सुझाव का स्वागत करते हैं. |
| WebIDL | Protected Audience API की मौजूदा खास बातें, WebIDL की खास बातों के साथ काम नहीं करती हैं. | हम इस सुझाव, शिकायत या राय की समीक्षा कर रहे हैं और समस्या के बारे में यहां चर्चा कर रहे हैं. |
| सहमति मैनेजमेंट | Protected Audience API में, सहमति के सिग्नल पास होने की सुविधा को कैसे मैनेज किया जाएगा? | काम की जानकारी, Protected Audience API के दायरे में नहीं आती. हम इस समस्या पर चर्चा कर रहे हैं. अन्य सुझाव, शिकायत या राय का स्वागत है. |
| खाता आधारित मार्केटिंग | क्या खाते के हिसाब से, मार्केटिंग के लिए इस्तेमाल के उदाहरण लिए जा सकते हैं? | Protected Audience API, ऑडियंस पर आधारित मार्केटिंग के अलग-अलग इस्तेमाल के उदाहरणों के साथ काम करता है. हम लगातार यह समझ रहे हैं कि Protected Audience API, इस्तेमाल के इस खास मामले में आपकी मदद कैसे कर सकता है. इसलिए, हम नेटवर्क से इस समस्या के बारे में अतिरिक्त सुझाव/राय देने या शिकायत करने का अनुरोध करते हैं. |
| कॉम्पोनेंट नीलामी | कॉम्पोनेंट में नीलामी में हिस्सा लेने वालों का क्या स्कोर होता है? | कॉम्पोनेंट नीलामियों के लिए, दिलचस्पी के ग्रुप को सीधे तौर पर स्कोर नहीं किया जाता. इसके बजाय, वे उन विज्ञापनों और बिड को स्कोर देते हैं जिन्हें डीएसपी generateBid फ़ंक्शन से सबमिट करता है. generateBid() फ़ंक्शन, हर इंटरेस्ट ग्रुप के हिसाब से चलता है और जनरेट बिड लागू करते समय डीएसपी यह वैल्यू दिखाता है:
return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| बाहरी योगदान | Key/Value Server GitHub कोड बेस पर, बाहरी योगदान की सुविधा देने का अनुरोध करें. | हम GitHub कोड में बाहरी योगदान को बढ़ावा देने के लिए, इससे जुड़ी प्रोसेस को अपडेट कर रहे हैं. |
| एक जैसी दिलचस्पी वाले ग्रुप का साइज़ | IG, ज़्यादा से ज़्यादा कितनी कुंजियों के साथ काम कर सकता है? | फ़िलहाल, एक IG का साइज़ 50 केबी है और उसी के हिसाब से चाबियों को गिना जाता है. हम ऐप्लिकेशन के साइज़ की सीमा के बारे में चर्चा करना चाहते हैं. |
| बैच बनाना | के/वी सर्वर कॉल की संख्या को कैसे कम किया जा सकता है? | के/वी कॉल की संख्या को कम करने के लिए, एचटीटीपी कैश-कंट्रोल हेडर का इस्तेमाल करें. उदाहरण के लिए, इसे कॉम्पोनेंट नीलामियों में और एक पेज पर मौजूद विज्ञापन स्लॉट में भी कैश किया जा सकता है. |
| वर्शन कंट्रोल | विज्ञापन टेक्नोलॉजी के कोड के कई वर्शन के साथ काम करता है | बिडिंग और नीलामी से जुड़ी सेवाओं में, विज्ञापन टेक्नोलॉजी कोड के कई वर्शन काम करेंगे. बिडिंग और नीलामी एपीआई में, SelectAd अनुरोध, नीलामी के अनुरोध के लिए इस्तेमाल किए जाने वाले कोड के वर्शन के बारे में बता सकता है. जैसे, बिडिंग / नीलामी और रिपोर्टिंग के लिए. |
| शेयर किया गया स्टोरेज | बिडिंग और नीलामी सेवा में, Shared Storage के लिए सहायता पाने का विकल्प. | फ़िलहाल, बिडिंग और नीलामी से जुड़ी सेवाएं, Shared Storage के साथ काम नहीं करतीं. हालांकि, हमारे नेटवर्क के लिए इस तरह के इस्तेमाल के उदाहरण ज़रूरी क्यों हैं, इस बारे में अन्य सुझाव, शिकायत या राय दी जा सकती है. |
| वेब-टू-ऐप्लिकेशन | एक जैसी दिलचस्पी वाले ग्रुप के लिए, वेब से ऐप्लिकेशन में फ़ाइलें शेयर करने की सुविधा चालू करें. | फ़िलहाल, Chrome और Android पर Protected Audience API के डिप्लॉयमेंट में वेब-टू-ऐप्लिकेशन का दायरा नहीं है. हालांकि, हम इस्तेमाल के इस उदाहरण की अहमियत के बारे में नेटवर्क से जानकारी पाने में दिलचस्पी रखते हैं. |
| के-एनॉनिमिटी | के-एनॉनिमिटी फ़ॉलबैक मैनेज करने का तरीका | हम इस समस्या पर चर्चा कर रहे हैं. अन्य सुझाव, शिकायत या राय का स्वागत है. |
डिजिटल विज्ञापनों को मेज़र करना
Attribution Reporting (और दूसरे एपीआई)
| सुझाव की थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| वैकल्पिक VTC इवेंट लेवल रिपोर्ट कॉन्फ़िगरेशन | वैकल्पिक VTC इवेंट-लेवल रिपोर्ट कॉन्फ़िगरेशन के बारे में सुझाव, शिकायत या राय | हमें आपके कुछ सुझाव मिले हैं कि मौजूदा इवेंट-लेवल के कॉन्फ़िगरेशन सबसे सही नहीं हैं. इसलिए, हम सबसे बेहतर ग्लोबल कॉन्फ़िगरेशन के बारे में सुझाव मांग रहे हैं. इस बारे में हम आपके सुझाव, शिकायत या राय का इंतज़ार कर रहे हैं. हमें लगता है कि इवेंट के लेवल पर उपलब्ध जानकारी से भी हमें इस समस्या को हल करने में मदद मिलेगी. |
| ज़रूरत के हिसाब से इवेंट लेवल के कॉन्फ़िगरेशन | इवेंट-लेवल पर ज़रूरत के हिसाब से कॉन्फ़िगरेशन की सुविधा की क्या स्थिति है? | हमने फ़्लेक्सिबल इवेंट-लेवल कॉन्फ़िगरेशन के बारे में दस्तावेज़ शेयर किए हैं. इस सुविधा पर अब भी काम चल रहा है. हमें इस बारे में अन्य सुझाव, शिकायत या राय चाहिए कि यह सुविधा नेटवर्क के लिए फ़ायदेमंद साबित होगी या नहीं. |
| ज़रूरत के हिसाब से इवेंट लेवल के कॉन्फ़िगरेशन | अलग-अलग पक्षों की विरोधी रिपोर्ट का समाधान कैसे किया जा सकता है? | रिपोर्टिंग के ज़्यादातर मामलों को एग्रीगेट रिपोर्ट के इस्तेमाल से हल किया जाता है. वहीं, इवेंट-लेवल के कॉन्फ़िगरेशन का वैकल्पिक प्रस्ताव, खास तौर पर इवेंट-लेवल की रिपोर्ट में ज़रूरत के हिसाब से बदलाव करने के लिए है. इनका इस्तेमाल, ऑप्टिमाइज़ेशन के इस्तेमाल के उदाहरणों के लिए किया जाता है. हम इस स्थिति से जुड़े नेटवर्क पर किसी भी तरह की अतिरिक्त टिप्पणी/सुझाव/राय देने या शिकायत करने का स्वागत करते हैं. |
| सोर्स रजिस्ट्रेशन | अगर सोर्स रजिस्ट्रेशन, ट्रिगर रजिस्ट्रेशन के बाद होता है, तो क्या होगा? | फ़िलहाल, अगर सोर्स रजिस्ट्रेशन, ट्रिगर रजिस्ट्रेशन के बाद होता है, तो सोर्स और ट्रिगर को एक-दूसरे से एट्रिब्यूट नहीं किया जा सकेगा. ऐसा लगता है कि यह एक किनारे वाला मामला है. हम इस समस्या के बारे में आपके किसी भी अतिरिक्त सुझाव का स्वागत करते हैं और अगर कोई ऐसी स्थिति है, तो बहुत से विज्ञापन तकनीक का सामना करने की स्थिति में हम इसका समाधान करने की कोशिश करेंगे. |
| कई विज्ञापन एजेंसियों के साथ काम करना | अगर विज्ञापन देने वाला कई विज्ञापन एजेंसियों के साथ काम कर रहा है, तो डीएसपी एट्रिब्यूशन रिपोर्टिंग एपीआई का इस्तेमाल कैसे कर सकते हैं? | एपीआई, रीडायरेक्ट के साथ काम करता है. इसलिए, विज्ञापन देने वाला जब कई विज्ञापन एजेंसियों के साथ काम कर रहा हो, तब भी इसका इस्तेमाल किया जा सकता है. इसके अलावा, रीडायरेक्ट से जुड़ी कुछ सीमाएं हैं, ताकि यह पक्का किया जा सके कि एपीआई की निजता को बेहतर बनाया जा रहा है. हमने विज्ञापन टेक्नोलॉजी की ओर से बताई गई खास स्थितियों के लिए, Shared Storage API का इस्तेमाल करने का एक संभावित तरीका भी पता लगाया है. हम इस स्थिति से जुड़े आपके किसी भी अतिरिक्त सुझाव का स्वागत करते हैं और उस सुझाव के आधार पर इसे दोहराना जारी रखेंगे. |
| डेस्टिनेशन की सीमाएं | अपने-आप रीफ़्रेश होने वाले विज्ञापनों के इस्तेमाल के उदाहरण पर, डेस्टिनेशन की सीमाएं लागू होने की वजह से असर पड़ सकता है. | हमने डब्ल्यूआईसीजी की 1 मई की मीटिंग में इस समस्या पर चर्चा की थी. साथ ही, हम जानना चाहते हैं कि इसे लागू करने के लिए उचित सीमा क्या होगी. हमने इवेंट-लेवल की रिपोर्ट के बारे में जानकारी देने वाली एट्रिब्यूशन रिपोर्टिंग में जानकारी जोड़ी है. इसमें बताया गया है कि ब्राउज़र, सोर्स साइटों से दिखाए जाने वाले `डेस्टिनेशन` eTLD+1 की संख्या को सीमित कर सकता है. (पुल का अनुरोध देखें). |
| एट्रिब्यूशन रिपोर्टिंग और सुरक्षित ऑडियंस | Attribution Reporting API और Protected Audience Audience API, एक साथ कैसे काम कर सकते हैं? | फ़िलहाल, Protected Audience API के लिए इंटिग्रेशन, Attribution Reporting API मोड (इवेंट-लेवल और खास जानकारी वाली रिपोर्ट), दोनों के लिए उपलब्ध है. हमने 1 जून को बेहतर Protected Audience API और Attribution Reporting इंटिग्रेशन के बारे में ज़्यादा जानकारी शेयर की थी. इनके बारे में यहां पढ़ें. |
| ज़रूरत के हिसाब से इवेंट लेवल के कॉन्फ़िगरेशन | नॉइज़ सिम्युलेशन के सबसे सही तरीके अब शेयर करें, क्योंकि पैरामीटर को कॉन्फ़िगर किया जा सकता है. | हमने GitHub पर कोड शेयर किया है. इसका इस्तेमाल करके कोई भी व्यक्ति, जानकारी पाने और शोर के असर का आकलन कर सकता है. किसी भी सुविधाजनक इवेंट-लेवल कॉन्फ़िगरेशन की जांच करने के लिए, वह इसका इस्तेमाल कर सकता है. हम उन लोगों की राय जानना चाहेंगे जो कोड का इस्तेमाल करके टेस्ट करने का विकल्प चुनते हैं और अपने सुझाव या राय देना चाहते हैं. |
| क्रॉस-ऐप्लिकेशन और वेब एट्रिब्यूशन मेज़रमेंट | क्रॉस-ऐप्लिकेशन और वेब एट्रिब्यूशन मेज़रमेंट कब उपलब्ध होगा? | हमने 9 मई को Attribution Reporting API के ज़रिए क्रॉस-ऐप्लिकेशन और वेब एट्रिब्यूशन मेज़रमेंट के लिए एक एक्सपेरिमेंट का एलान किया था. Chrome 115 में, काम के एपीआई और मेज़रमेंट एपीआई के लिए, सामान्य रूप से उपलब्ध होने की योजना बनाई गई है. हालांकि, फ़िलहाल क्रॉस ऐप्लिकेशन और वेब एट्रिब्यूशन मेज़रमेंट की सुविधा, Chrome 115 के साथ सामान्य रूप से उपलब्ध होने के लिए नहीं बनाई गई है. |
| कन्वर्ज़न की डुप्लीकेट कॉपी हटाएं | ARA के साथ, मेज़रमेंट के स्वतंत्र समाधानों का मिलान कैसे किया जा सकता है? | मौजूदा स्टैंडर्ड तरीके के मुताबिक, कन्वर्ज़न रिपोर्टिंग की डुप्लीकेट कॉपी हटाने के लिए, विज्ञापन देने वाले लोग या कंपनियां, तीसरे पक्ष की स्वतंत्र मेज़रमेंट सेवा देने वाली कंपनी के साथ काम करेंगी. हमने इवेंट लेवल की रिपोर्टिंग के लिए, कन्वर्ज़न की डुप्लीकेट कॉपी हटाने के तरीके के बारे में संसाधन उपलब्ध कराए हैं. |
| एट्रिब्यूशन रिपोर्टिंग के डेटाबेस के अपडेट के दौरान डेटा मिट जाना | जब Chrome, एट्रिब्यूशन रिपोर्टिंग डेटाबेस को एलान के मुताबिक अपडेट करेगा, तब क्या डेटा का नुकसान होगा? | Chrome Stable 115 और इसके बाद के वर्शन में, हम Chrome के कुछ उपयोगकर्ताओं के लिए, 'काम का है और मेज़रमेंट एपीआई' डिफ़ॉल्ट रूप से चालू करना शुरू कर देंगे. संभावित समस्याओं पर नज़र रखने के दौरान, यह सुविधा सामान्य रूप से उपलब्ध होगी. हमारा लक्ष्य है कि साल 2023 की तीसरी तिमाही तक, प्रॉडक्ट की उपलब्धता 100% हो जाए. ऐसा, 'काम की है' और 'मेज़रमेंट' के ऑरिजिन ट्रायल के बाद खत्म हो जाएगा. जुलाई से, टेस्टर सामान्य रूप से उपलब्ध इन एपीआई का ऐक्सेस पाने के लिए रजिस्टर कर सकेंगे. इससे, ऑरिजिन ट्रायल की उपलब्धता और रजिस्टर करने के दौरान, सामान्य तौर पर उपलब्धता के बीच ओवरलैप होगा. आपका ऑरिजिन ट्रायल टोकन 19 सितंबर तक मान्य रहेगा. हालांकि, हमारा सुझाव है कि आप समयसीमा खत्म होने से पहले, एपीआई के लिए रजिस्टर करें. इससे, पहले से चल रहे टेस्ट में किसी तरह की रुकावट के बिना, ऑरिजिन ट्रायल से आसानी से ट्रांज़िशन किया जा सकेगा. अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है जैसा कि इस एलान में बताया गया है, अपडेट होने के बाद, M113 और उससे पहले के वर्शन में रजिस्टर किया गया डेटा माइग्रेट नहीं किया जाएगा. इसलिए, इससे डेटा का नुकसान हो सकता है. डेटा लीक होने की यह प्रोसेस, डीबग रिपोर्टिंग में नहीं दिखेगी. साथ ही, हम 114 से 115 के बीच डेटा लीक होने से रोकने की कोशिश करेंगे. |
| बिलिंग | हर कन्वर्ज़न की लागत बिलिंग के लिए एट्रिब्यूशन रिपोर्टिंग का इस्तेमाल करना | जैसा कि इस लेख में बताया गया है, इवेंट-लेवल और खास जानकारी वाली रिपोर्ट में ज़्यादा डेटा शामिल होने की वजह से, हो सकता है कि Attribution Reporting API, हर कन्वर्ज़न की लागत वाली बिलिंग की ज़रूरतों के लिए सही न हो. हम नेटवर्क के खिलाड़ियों को बढ़ावा देते हैं कि वे GitHub पर Attribution Reporting API से, अलग-अलग बिलिंग मॉडल पर पड़ने वाले असर के बारे में सुझाव शेयर करें. |
एग्रीगेशन सेवा
| सुझाव की थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| रिपोर्ट में होने वाली देरी को इकट्ठा करने की सुविधा में बदलाव | नेटवर्क से मिले सुझाव के बाद, एग्रीगेटेबल रिपोर्ट में देरी को [10-60 मिनट] से [0 से 10 मिनट] करने के प्रस्ताव पर सकारात्मक प्रतिक्रिया दी गई | हमें इस प्रस्तावित बदलाव पर सकारात्मक प्रतिक्रिया देकर खुशी हो रही है. साथ ही, हम नेटवर्क को अपने प्रस्तावों पर सुझाव देते रहने के लिए प्रोत्साहित करते हैं. |
| कंपनी की इमारत में समाधान | क्या एग्रीगेशन सेवा को कंपनी की इमारत में मौजूद डेटा सेंटर में डिप्लॉय किया जा सकता है? | हम क्लाउड-आधारित समाधान के अलावा, अन्य विकल्पों पर भी काम कर रहे हैं. हालांकि, फ़िलहाल हम कंपनी के मालिकाना हक वाले टीईई के साथ काम नहीं कर सकते. ऐसा इसलिए है, क्योंकि हम अपने संगठन के अंदर ही सुरक्षा से जुड़ी सीमाएं लागू कर रहे हैं. इस तरह, Privacy Sandbox का आकलन करने में काफ़ी समय लगेगा. Privacy Sandbox की सुरक्षा से जुड़ी ज़रूरी शर्तों और कंपनी के ऑफ़िस में डिप्लॉयमेंट से जुड़ी बड़ी चुनौतियों को देखते हुए, हमारा मानना है कि क्लाउड-आधारित डिप्लॉयमेंट को बढ़ाना और बेहतर बनाना नेटवर्क के लिए सबसे फ़ायदेमंद है. उदाहरण के लिए, AWS के साथ-साथ GCP की सेवाएं देना. हालांकि, हम इस बारे में अतिरिक्त सुझाव भी दे सकते हैं कि इस तरह की ज़रूरत क्यों पड़ी. |
| अलग-अलग समयावधि के लिए रिपोर्ट फिर से प्रोसेस करना | अलग-अलग समयावधि के लिए रिपोर्ट को फिर से प्रोसेस करने की सुविधा | हमें इस तरह के अनुरोध मिले हैं कि हम तारीख की अलग-अलग सीमाओं के हिसाब से बैच को बांट सकें. एक सुझाव यह है कि शेयर किए गए आईडी को, विज्ञापन टेक्नोलॉजी से जुड़े किसी लेबल के साथ बढ़ाया जा सके, ताकि रिपोर्ट को अलग-अलग बैच में बांटा जा सके. हम इस प्रक्रिया का आकलन करने की शुरुआती प्रक्रिया में हैं. जैसे-जैसे इस प्रस्ताव में बदलाव होंगे, हम नेटवर्क को अपडेट करते रहेंगे. |
| भरोसेमंद एक्ज़ीक्यूशन एनवायरमेंट की निजता से जुड़ी नीतियां | भरोसेमंद एक्ज़ीक्यूशन एनवायरमेंट की निजता सेटिंग के बारे में सकारात्मक भावना | हमें अपने प्रस्तावों के बारे में नेटवर्क से सकारात्मक प्रतिक्रियाएं जानकर खुशी हुई. हम इस बारे में लगातार सुझाव दे रहे हैं और इसे बेहतर बनाने के लिए लगातार काम कर रहे हैं. |
| सेवा की शर्तें | एग्रीगेशन सेवा की सेवा की शर्तें स्वीकार करने की आखिरी तारीख क्या है? | हमने अभी तक नियम और शर्तें स्वीकार करने की कोई समयसीमा तय नहीं की है. हालांकि, हम नेटवर्क कंपनियों को ये नियम और शर्तें जल्द से जल्द स्वीकार करने के लिए बढ़ावा देंगे, ताकि रजिस्ट्रेशन में देरी न हो. अगर कंपनियों का कोई सवाल है, तो हम उनसे संपर्क करने के लिए प्रोत्साहित करते हैं. |
| कुंजी की खोज | खोज के नतीजों की कुंजी की सुविधा के ज़रिए, जांच करने वाले लोग कुंजी के संभावित कॉम्बिनेशन की साफ़ तौर पर जानकारी दिए बिना, एग्रीगेट रिपोर्ट से क्वेरी कर सकते हैं. इससे, क्रॉस-नेटवर्क एट्रिब्यूशन की खास जानकारी वाली रिपोर्ट को प्रोसेस किया जा सकता है, ताकि बेहतर परफ़ॉर्मेंस और सटीक जानकारी मिल सके. | फ़िलहाल, हम संभावित समाधान और समाधान ढूंढ रहे हैं. साथ ही, हम नेटवर्क से आपके अन्य सुझाव, शिकायत या राय का स्वागत करते हैं. |
Private Aggregation API
| सुझाव की थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| रिपोर्टिंग का ऑरिजिन | रिपोर्टिंग के ऑरिजिन को कैसे तय किया जाता है? | रिपोर्टिंग ऑरिजिन, हमेशा प्राइवेट एग्रीगेशन कॉलर का स्क्रिप्ट ऑरिजिन होता है. |
| 128 बिट की कुंजी वाला स्पेस | साफ़ तौर पर 128-बिट कुंजी वाले बटन में स्पेस की सीमा क्या है | हम कीस्पेस की इस सीमा को साफ़ तौर पर समझाएंगे और पेजों में अंतर को ठीक करेंगे. हमारा सुझाव है कि इस कीस्पेस के दायरे में रहने के लिए, हैशिंग रणनीतियों का इस्तेमाल करें. |
| प्रति रिपोर्ट अधिकतम योगदान | हर रिपोर्ट में 20 योगदान देने की मौजूदा सीमा बहुत कम है. | योगदान की संख्या को बढ़ाने के बजाय, हम रिपोर्ट को छोटे-छोटे हिस्सों में बांटने के बारे में सोच रहे हैं. इस प्रस्ताव में आगे बढ़ने पर, हम नेटवर्क से जुड़े रहेंगे. |
| पहुंच रिपोर्टिंग | क्रॉस-प्लैटफ़ॉर्म/क्रॉस-डिवाइस रिपोर्टिंग तक पहुंचने का अनुरोध. पहुंच, ब्रैंड विज्ञापन की बुनियादी मेट्रिक है. विज्ञापन देने वाले, अपने कैंपेन का विश्लेषण करने और खर्च के बंटवारे के लिए, पहुंच और फ़्रीक्वेंसी की रिपोर्टिंग के लिए क्रॉस-प्लैटफ़ॉर्म/क्रॉस-डिवाइस अनुमानों पर भरोसा करते हैं. रीच मॉडल, तीसरे पक्ष के प्लैटफ़ॉर्म पर दिखाए गए विज्ञापनों की परफ़ॉर्मेंस को मेज़र करने के लिए, तीसरे पक्ष की कुकी का इस्तेमाल करते हैं. इसलिए, तीसरे पक्ष की कुकी के बंद होने पर, विज्ञापन टेक्नोलॉजी से जुड़ी कंपनियों ने किसी अन्य समाधान का अनुरोध किया है. |
प्राइवसी सैंडबॉक्स की टीम, ऐसी सुविधाओं पर काम कर रही है जो तीसरे पक्ष की कुकी के बंद होने के बाद, क्रॉस-डोमेन रीच को बेहतर बनाने में मदद करेंगी. अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है हम नेटवर्क से आपके अतिरिक्त सुझाव, शिकायत या राय का स्वागत करते हैं. |
कवर ट्रैकिंग को सीमित करें
उपयोगकर्ता एजेंट को कम करने की सुविधा/उपयोगकर्ता एजेंट क्लाइंट हिंट
| सुझाव की थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| (2023 की पहली तिमाही में भी रिपोर्ट की गई) अन्य डिवाइस टाइप के लिए संकेत | टीवी, वीआर जैसे अन्य डिवाइस टाइप उपलब्ध कराने के लिए, यूज़र एजेंट क्लाइंट हिंट (UA-CH) का अनुरोध | हम अब भी डिज़ाइन से जुड़े कुछ अहम पहलुओं पर काम कर रहे हैं (चाहे "टीवी" जैसा कोई एक मान देना हो या डिवाइस के नाप या आकार के लिए इस्तेमाल होने वाले तरीकों की सूची उपलब्ध करानी हो), लेकिन इस आइडिया के प्रोटोटाइप बनाने में हमारी दिलचस्पी बनी रहेगी. |
| निजता बजट | बहुत ज़्यादा अनुरोध भेजे जाने पर, निजता बजट की पाबंदियों की वजह से UA-CH अनुरोध, तय नहीं किए जा सकते हैं. | फ़िलहाल, हमारे पास निजता बजट प्रस्ताव के बारे में कोई नया अपडेट नहीं है. हालांकि, हम तीसरे पक्ष की कुकी के बंद होने से पहले, UA क्लाइंट के संकेतों के अनुरोधों पर पाबंदी नहीं लगाएंगे. |
| साइट कंपैटबिलिटी | वेबसाइटें, कुछ ब्राउज़र को साइटों को ऐक्सेस करने से रोकने के लिए UA-CH ब्रैंड का इस्तेमाल कर रही हैं. | ब्रैंड की सूची बनाने के लिए, इस्तेमाल के मान्य उदाहरण दिए गए हैं. इनमें से कोई एक, ब्रैंड की सूची के साथ काम करता है. इन समस्याओं के समाधान के लिए, UA में कई ब्रैंड शामिल किए जा सकते हैं. इसके लिए, कोई शुल्क नहीं लिया जाता. |
आईपी सुरक्षा (पहले इसे Gnatcatcher कहा जाता था)
| सुझाव की थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| धोखाधड़ी और गलत इस्तेमाल के मामले | कंपनियां किस तरह आईपी सुरक्षा की मदद से धोखाधड़ी रोकने के तरीके सेट कर सकती हैं? | हम धोखाधड़ी रोकने के लिए, इस्तेमाल के उदाहरणों की अहमियत और उन मामलों में उनके संभावित असर को समझते हैं. हम इस गर्मी के मौसम में, धोखाधड़ी से बचने की कोशिशों के बारे में ज़्यादा जानकारी पब्लिश करने की योजना बना रहे हैं. हम नेटवर्क से इस बारे में सुझाव मांग रहे हैं कि धोखाधड़ी से बचने के लिए, हम बेहतर तरीके से कैसे मदद कर सकते हैं. |
| GeoIP | GeoIP के लिए टेस्ट करने और डिप्लॉयमेंट की समयावधि के बारे में ज़्यादा जानकारी | Chrome ने हाल ही में हमारे GeoIP प्लान के बारे में नई जानकारी पब्लिश की है. हम तीसरी तिमाही में डिप्लॉयमेंट की टाइमलाइन के बारे में ज़्यादा जानकारी पब्लिश करने की योजना बना रहे हैं. हम उम्मीद करते हैं कि शुरुआत में, ट्रैफ़िक के छोटे से हिस्से पर, उपयोगकर्ता के लिए ऑप्ट-इन करने की सुविधा के तौर पर आईपी सुरक्षा की सुविधा लॉन्च की जाएगी. इसकी वजह यह है कि हम मानते हैं कि इस प्रस्ताव में कंपनियों के लिए कुछ अहम बदलाव शामिल हो सकते हैं. इसलिए, हम इस सुविधा को बड़े पैमाने पर रोल आउट करने से पहले, नेटवर्क को इनके हिसाब से काम करने का समय देना चाहते हैं. |
| खाता प्रमाणीकरण | प्रॉक्सी सर्वर के साथ खाते का प्रमाणीकरण सटीक रूप से कैसे काम करेगा? | हम इस गर्मी के मौसम में, खाते की पुष्टि करने के बारे में ज़्यादा जानकारी पब्लिश करने की योजना बना रहे हैं. हालांकि, हमने शुरुआती बातें पहले ही बता दी हैं. |
बाउंस ट्रैकिंग को कम करने की सुविधा
| सुझाव की थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| टेस्ट से जुड़े दिशा-निर्देश | बाउंस ट्रैकिंग पर लागू होने वाली पाबंदियां की जांच करने के तरीके के बारे में जानकारी | हमने मई में एक ब्लॉग पोस्ट पब्लिश किया था. इसमें बाउंस ट्रैकिंग पर लागू होने वाली पाबंदी की जांच करने के तरीके के बारे में ज़्यादा जानकारी दी गई थी. |
| दस्तावेज़ | बाउंस ट्रैकिंग प्रपोज़ल में साफ़ तौर पर जानकारी देना | इस मौजूदा प्रस्ताव पर काफ़ी काम चल रहा है. Chrome लगातार इस प्रस्ताव को अपडेट कर रहा है, ताकि नेटवर्क को साफ़ तौर पर जानकारी दी जा सके और जानकारी दी जा सके. हम ज़्यादा जानकारी देने के लिए काम कर रहे हैं. आपके किसी भी अन्य सुझाव, शिकायत या राय का स्वागत है. |
| कुकी मिटाना | क्या बाउंस ट्रैकिंग पर लागू होने वाली पाबंदियां, किसी डोमेन की सभी कुकी मिटा देंगी? | बाउंस ट्रैकिंग की क्षमता को कंट्रोल करने की सुविधा (बीटीएम) से, डिवाइस का स्टोरेज और सारी कैश मेमोरी मिट जाएगी. इसके बारे में यहां बताया गया है. |
| बाउंस ट्रैकिंग पर लागू होने वाली पाबंदी को गच्चा देना | बाउंस ट्रैकर की कैटगरी तय करने से बचने के लिए, पॉप-अप या नए टैब की मदद से रीडायरेक्ट किए जा सकते हैं. | बाउंस ट्रैकिंग पर लागू होने वाली पाबंदियां तय करने की प्रोसेस पर अब भी काम चल रहा है. हमने अब तक ज़्यादातर एक ही टैब पर रीडायरेक्ट करने पर फ़ोकस किया है, लेकिन आने वाले समय में पॉप-अप फ़्लो पर काम करने की हमारी योजना है. हम यहां आपके अतिरिक्त सुझाव का स्वागत करते हैं. |
निजता बजट
| सुझाव की थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| समीपवर्ती लक्ष्यीकरण | निजता बजट का असर, नज़दीकी टारगेटिंग को इस्तेमाल करने के मामलों पर पड़ सकता है. | हमें इस समस्या के बारे में सुझाव मिल चुके हैं. हम इस बारे में ज़्यादा जानना चाहते हैं कि इस नेटवर्क पर क्या असर पड़ सकता है. |
अलग-अलग साइटों पर निजता की सीमाएं मज़बूत होती हैं
पहले पक्ष के सेट
| सुझाव की थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| (पिछली तिमाहियों में भी रिपोर्ट की गई) डोमेन सीमा | जुड़े हुए डोमेन की संख्या बढ़ाने का अनुरोध करें | Chrome, इससे जुड़े सबसेट के लिए संख्या की सही सीमा का आकलन कर रहा है. यह सीमा, इस्तेमाल के ऐसे मामलों में डेटा की निजता और उपयोगिता के बीच संतुलन बनाएगी जिनकी पहचान की गई है. Chrome ने शुरुआत से ही आउटसेट से जानकारी दी थी कि इससे जुड़े सबसेट की सटीक संख्या अभी तय नहीं की गई है. |
| एम्बेड किया गया इस्तेमाल का उदाहरण | एम्बेड किए गए इस्तेमाल के ऐसे उदाहरणों के लिए सहायता जिनके लिए पहले पक्ष के सेट, सीएचआईपी, और शेयर किया गया स्टोरेज की ज़रूरत होती है | Chrome को इस्तेमाल के इस उदाहरण पर सुझाव मिल गया है और टीम जांच कर रही है. साथ ही, टीम अतिरिक्त सुझाव का स्वागत करती है. |
| डेटा स्टोर करने की जगह का मैनेजमेंट | अगर डेटा में कोई अंतर होता है या उसे नज़रअंदाज़ किया जाता है, तो GitHub की डेटा स्टोर करने की जगह से पहले पक्ष के सेट को हटाने से जुड़ी नीतियों के बारे में जानकारी | Chrome को इस्तेमाल के इस उदाहरण पर सुझाव मिला है. टीम इस समस्या की जांच कर रही है. टीम के पास और सुझाव देने का भी विकल्प है. |
| उपयोगकर्ता शिक्षा | इस्तेमाल करने के लिए Chrome को पहले पक्ष के सेट के बारे में उपयोगकर्ता की जागरूकता और समझ को बढ़ाना चाहिए. | Chrome, उपयोगकर्ताओं को पहले पक्ष के सेट के बारे में जानकारी देता है. इसके लिए, उसने सहायता केंद्र का एक लेख पब्लिश किया है. यह लेख Chrome के यूज़र इंटरफ़ेस (यूआई) से लिंक किया गया है. Chrome का मकसद यह भी जानना है कि इस्तेमाल करने वाले लोगों को सही परिस्थितियों में सबसे सही जानकारी कैसे दी जाए. |
| पोस्ट 3PCD | तीसरे पक्ष की कुकी के बंद होने के बाद, तीसरे पक्ष की कुकी, पहले पक्ष के सेट में मौजूद रहेंगी. | हालांकि, साफ़ तौर पर बताए गए इस्तेमाल के उदाहरणों के लिए, requestStorageAccess और requestStorageAccessFor तीसरे पक्ष की कुकी फिर से उपलब्ध कराते हैं. हालांकि, अब उन्हें तीसरे पक्ष की कुकी (Chrome में) की मौजूदा स्थिति की तरह, डिफ़ॉल्ट रूप से उपलब्ध होने के बजाय, साइट पर ऐक्टिवेशन की ज़रूरत होती है.अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है हालांकि, किसी एक सेट में इस सुविधा को शुरू करने के लिए उपयोगकर्ता की अनुमति की ज़रूरत नहीं होगी. हालांकि, उपयोगकर्ता 'सेटिंग' में जाकर, इस व्यवहार से ऑप्ट-आउट करके इसे रोक सकते हैं. अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है उपयोगकर्ताओं के लिए, सहायता केंद्र का लेख (Chrome यूज़र इंटरफ़ेस से लिंक किया गया) में ज़्यादा जानकारी उपलब्ध है. हम मौजूदा डेवलपर गाइड को अन्य एफ़पीएस (फ़्रेम प्रति सेकंड) तक पहुंचाने की कोशिश कर रहे हैं. |
| पहले पक्ष के सेट सबमिट करना | .json एक्सटेंशन को शामिल करने के लिए, ज़रूरी .well-known/first-party-set का नाम बदलें. |
हमने यह बदलाव इसलिए किया है, ताकि यह पक्का किया जा सके कि वेब होस्टिंग के कुछ प्लान काम करते हैं. |
| आईएएनए रजिस्ट्रेशन | first_party_sets.JSON, IANA के साथ रजिस्टर होना चाहिए |
हम प्रस्ताव पर विचार कर रहे हैं और यहां अतिरिक्त फ़ीडबैक का स्वागत करते हैं. |
फ़ेंस किए गए फ़्रेम एपीआई
| सुझाव की थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| विज्ञापन ब्लॉकिंग | फ़ेंस किए गए फ़्रेम की मदद से, विज्ञापन रोकने वाले सॉफ़्टवेयर, विज्ञापनों को आसानी से ब्लॉक कर सकते हैं. | एक्सटेंशन, फ़ेंस किए गए फ़्रेम के साथ उसी तरह इंटरैक्ट कर सकते हैं जिस तरह वे iframe के साथ इंटरैक्ट करते हैं. फ़ेंस किए गए फ़्रेम के जिस असल यूआरएल पर नेविगेट किया जाना है वह एक्सटेंशन में भी दिखेगा. इसलिए, ब्लॉक करने के लिए यूआरएल मैचिंग के किसी भी नियम को लागू किया जा सकता है, जैसा कि वे iframe में करते हैं. बिना किसी शर्त के सभी फ़ेंस किए गए फ़्रेम को ब्लॉक करने से, बिना विज्ञापन वाले फ़्रेम के इस्तेमाल के उदाहरण टूट सकते हैं. |
Shared Storage API
| सुझाव की थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| बड़े पैमाने पर अपनाए जाने वाले तरीके | शेयर किया गया स्टोरेज, सभी ब्राउज़र के लिए उपलब्ध स्टैंडर्ड होना चाहिए. | हम इस सुझाव का स्वागत करते हैं और इसे स्वीकार करते हैं. प्रस्ताव को बढ़ावा देने, सुझाव पाने, और अपनाने के लिए बढ़ावा देने के लिए, Chrome लगातार W3C फ़ोकस में हिस्सा ले रहा है. |
| आउटपुट गेट | शेयर किए गए स्टोरेज के आउटपुट के गेट बहुत सीमित हैं. | हम इस सुझाव पर विचार कर रहे हैं. साथ ही, हम इस बारे में नेटवर्क से जुड़े अतिरिक्त सुझाव/राय या शिकायत का स्वागत करते हैं कि आउटपुट सीमित क्यों हैं. |
| नियामक अनुपालन | शेयर किया गया स्टोरेज, डेटा के रखरखाव की नीतियों जैसे नियमों के पालन को कैसे मैनेज करेगा? | शेयर किए गए स्टोरेज की मदद से, किसी भी सेव किए गए डेटा के लाइफ़टाइम और उसकी समयसीमा खत्म होने को कंट्रोल करने के लिए, लॉजिक को लागू और कस्टमाइज़ किया जा सकता है. विज्ञापन की टेक्नोलॉजी, लिखने के टाइमस्टैंप के आधार पर, शेयर किए गए स्टोरेज के डेटा को अपडेट या मिटा सकती हैं. |
| A/B परीक्षण | Shared Storage और Protected Audience API के लिए, A/B टेस्टिंग कैसे की जा सकती है? | हम इस मामले पर अतिरिक्त दिशा-निर्देश पब्लिश करने पर काम कर रहे हैं. साथ ही, हम आने वाले समय में ज़्यादा जानकारी शेयर करेंगे. |
| शेयर किए गए स्टोरेज की सीमा | शेयर किए गए स्टोरेज की सीमा पूरी होने पर क्या होगा? | अगर यह सीमा पूरी हो जाती है, तो कोई और इनपुट सेव नहीं किया जाएगा. |
| एक ही पेज लोड पर एक से ज़्यादा ऐक्सेस | अगर शेयर किए गए स्टोरेज को एक ही पेज लोड पर कई बार ऐक्सेस किया जाता है, तो क्या होता है? | इसे मैनेज करने का सबसे अच्छा तरीका window.sharedStorage.append(key, value) फ़ंक्शन है. हर विज्ञापन के लिए वैल्यू अपडेट करने के बजाय, क्योंकि कई विज्ञापन होने पर टकराव हो सकते हैं. जोड़ें फ़ंक्शन पहले से मौजूद वैल्यू के आखिर में नई वैल्यू जोड़ देगा. |
| iframe फ़ंक्शनलिटी | तीसरे पक्ष की कुकी का इस्तेमाल बंद होने के बाद, क्या शेयर किया गया स्टोरेज कुछ iframe फ़ंक्शन के साथ काम करेगा? | तीसरे पक्ष की कुकी का इस्तेमाल बंद होने के बाद, iframe में मौजूद लोकल स्टोरेज को टॉप लेवल की साइट के हिसाब से बांटा जाएगा. हालांकि, iframe को ब्लॉक नहीं किया जाएगा. iframe के लोकल स्टोरेज में मौजूद डेटा को कई टॉप लेवल साइटों में कॉपी नहीं किया जा सकता, लेकिन iframe में डेटा का इस्तेमाल अब भी किया जा सकता है. |
सीएचआईपी
| सुझाव की थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| विभाजन सीमा | सेगमेंट में बांटी गई हर साइट के लिए 10 केबी का साइज़ अब भी काफ़ी है. इसलिए, मुझे चाहिए कि इसे कम किया जाए. | Firefox ने पहले ही CHIPS पर पॉज़िटिव पोज़िशन दिखाया है. Webkit से जुड़ी सहायता के लिए, हम डेवलपर को GitHub की इस समस्या के बारे में सीधे Apple को सुझाव/राय देने या शिकायत करने का सुझाव देते हैं. ऐसा उन मामलों में किया जाता है जहां सेगमेंट में बांटी गई कुकी के बजाय, सेगमेंट में बांटी गई कुकी को प्राथमिकता दी जाती है. |
| पुष्टि किए गए एम्बेड | अलग-अलग पार्टिशनिंग से पुष्टि किए गए एम्बेड पर असर होने की वजह से सीएचआईपी, मौजूदा एसएसओ (SSO) साइन-इन फ़्लो पर असर डाल सकता है. | हम पुष्टि किए गए एम्बेड के इस्तेमाल के उदाहरण को सपोर्ट करने के लिए, Storage Access API (उपयोगकर्ता के प्रॉम्प्ट के साथ) का इस्तेमाल करना चाहते हैं. साथ ही, हमने हाल ही में एक इंटेंट-टू-प्रोटोटाइप भी भेजा है. |
| लाइफ़टाइम नीतियां | क्या संभावित लाइफ़टाइम नीतियां पहले-पक्ष की कुकी पर लागू होंगी? | फ़िलहाल, पहले-पक्ष की कुकी के लिए लाइफ़टाइम सीमाएं लागू करने की हमारी कोई योजना नहीं है. |
FedCM
| सुझाव की थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| OAuth अनुमति देने से जुड़ी सहायता | गैर-प्रोफ़ाइल Oauth दायरे को मंज़ूरी देने पर अलाइन करें | हम W3C FedID CG के ज़रिए, Web Identity कम्यूनिटी से जानकारी मांग रहे हैं. इससे हमें तीसरे पक्ष की कुकी का इस्तेमाल बंद होने के बाद, पुष्टि करने के बुनियादी तरीकों के अलावा, अन्य तरीकों के बारे में जानकारी पाने में मदद मिलेगी. |
| एसएएमएल के लिए सहायता | एसएएमएल से जुड़ी सहायता के लिए ज़रूरी शर्तों को पूरा करें | तीसरे पक्ष की कुकी का इस्तेमाल बंद होने के बाद, यह टीम रिसर्च और शिक्षा से जुड़े समुदायों से, एसएएमएल से जुड़ी सहायता की ज़रूरतों के बारे में जानकारी मांग रही है. साथ ही, यह भी जानना चाहती है कि उपयोगकर्ताओं के लिए, OpenID-कनेक्ट की सहायता भी क्यों नहीं होनी चाहिए. |
स्पैम और धोखाधड़ी से बचें
प्राइवेट स्टेट टोकन एपीआई और अन्य एपीआई
| सुझाव की थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| नए सिग्नल एक्सप्लोर करना | कई पार्टनर ने ब्राउज़र की मदद से तैयार किए गए, डिवाइस इंटिग्रिटी या उपयोगकर्ता के भरोसे से जुड़े सिग्नल को एक्सप्लोर करने के बारे में सकारात्मक राय दी है. आम तौर पर, वे इस बारे में भी सतर्क रहते हैं कि नए मकसद के लिए बने सिग्नल, धोखाधड़ी का पता लगाने के मौजूदा लेवल को बनाए रखने के लिए काफ़ी हैं. | हम धोखाधड़ी रोकने और वेब सुरक्षा से जुड़े समुदाय के साथ मिलकर, नए प्रस्ताव तैयार करने की कोशिश कर रहे हैं. साथ ही, हम उनकी समस्याओं को स्वीकार करते हैं और उनके बारे में बताते हैं. यही वजह है कि "स्पैम और धोखाधड़ी से बचाव" की यही वजह है प्राइवसी सैंडबॉक्स का मुख्य वर्कस्ट्रीम रहा है. हम उपयोगकर्ता की निजता को बेहतर बनाने की कोशिश कर रहे हैं. इसलिए, हम वेब की सुरक्षा को बनाए रखने के लिए लगातार काम कर रहे हैं. |
| पीएसटी के बारे में अच्छा फ़ीडबैक | कई पार्टनर ने धोखाधड़ी रोकने या वेब की सुरक्षा के लिए, अलग-अलग तरह के मामलों में पीएसटी की जांच करने या इनका इस्तेमाल करने में दिलचस्पी दिखाई है. | हमें इस बात की खुशी है कि पीएसटी का इस्तेमाल करने वाले नए समाधानों के बारे में आपकी मदद की जा रही है और हम उन्हें आगे बढ़ाने में दिलचस्पी दिखा रहे हैं. हमारे पास Chrome डेवलपर साइट पर संसाधन और सैंपल कोड उपलब्ध हैं. हम आपके सुझाव, शिकायत या राय का स्वागत करते हैं. |
| धोखाधड़ी और गलत इस्तेमाल | आइडेंटिफ़ायर की सुविधा उपलब्ध न होने पर, तीसरे पक्ष की कुकी का इस्तेमाल बंद होने के बाद, विज्ञापनों से होने वाली धोखाधड़ी की रोकथाम / मेज़रमेंट में इसका पता लगाने के लिए दिशा-निर्देश. | हमने प्राइवेट स्टेट टोकन जैसे टूल लॉन्च किए हैं. इनकी मदद से, धोखाधड़ी से बचाव के मकसद से तीसरे पक्ष की कुकी की वजह से हुए नुकसान को वापस पाया जा सकता है. हालांकि, इसके लिए निजता सेटिंग के नए तरीके उपलब्ध कराए गए हैं. हम धोखाधड़ी और गलत इस्तेमाल को रोकने के लिए नए प्रपोज़ल पर लगातार काम कर रहे हैं, ताकि प्राइवसी सैंडबॉक्स में किए गए अन्य बदलावों के साथ-साथ सुविधाओं को सुरक्षित रखा जा सके. |
| ऑरिजिन की जानकारी जारी करने वाले व्यक्ति की दर | यूनीक उपयोगकर्ताओं की पहचान करने के लिए, जारी करने वाले से मूल जानकारी की दर काफ़ी ज़्यादा है. | हमने नियम को अपडेट किया है, ताकि यह साफ़ तौर पर पता चल सके कि प्राइवेट स्टेट टोकन का इस्तेमाल करके, उपयोगकर्ता का कौनसा डेटा शेयर किया जा सकता है. डिज़ाइन के हिसाब से, एक बार में छह सार्वजनिक कुंजियों का इस्तेमाल किया जा सकता है. ये "राज्य" का प्रतिनिधित्व कर सकते हैं एक अहम पॉइंट होता है. कुंजियों के ये सेट सिर्फ़ हर 60 दिनों में अपडेट किए जा सकते हैं. हालांकि, कुछ मामलों में आपातकालीन कुंजी को बदलना ज़रूरी नहीं होता है. इससे, समय के साथ उपयोगकर्ता का अतिरिक्त डेटा जोड़ने की संभावना कम हो जाती है. किसी भी नए वेब एपीआई के साथ, उपलब्ध कराई जाने वाली सुविधाएं और नए उपयोगकर्ता की कुल जानकारी होती है. हमारा अनुमान है कि पीएसटी से उपयोगकर्ता की निजता की सुरक्षा का पूरा ध्यान रखा जाता है. साथ ही, तीसरे पक्ष की कुकी का इस्तेमाल बंद होने से, धोखाधड़ी रोकने के लिए इस्तेमाल होने वाले मुख्य मामलों को भी चालू किया जाता है. |
| इंटिग्रेशन फ़ेच करें | fetch इंटिग्रेशन जटिल और ज़रूरी नहीं है. |
fetch का इस्तेमाल करने के अपने फ़ायदे और नुकसान हैं. साथ ही, हम वेब नेटवर्क में और मानक तय करना चाहते हैं. हालांकि, हमें लगता है कि यह बदलाव करना अभी बहुत जल्दी होगा, जब तक कि हमें साफ़ तौर पर यह पता नहीं चल जाता कि स्टैंडर्ड कैसा होगा. अगर और जब भी ऐसा कोई स्टैंडर्ड लागू होता है, तो हम वेब डेवलपर को भी ज़िम्मेदारी के साथ उस स्टैंडर्ड का पालन करने का वादा करते हैं. |
| सेव करने की जगह | प्राइवेट स्टेट टोकन के मुख्य कॉन्फ़िगरेशन उसी जगह पर सेव किए जाने चाहिए जहां PrivacyPass प्रोटोकॉल है. | ऑरिजिन ट्रायल के दौरान टेस्ट के दौरान, डेवलपर ने बताया कि वे अपनी कुंजियों को .well-known डायरेक्ट्री के बजाय, सामान्य यूआरएल पर सेव करने की सुविधा को प्राथमिकता दे रहे हैं. PrivacyPass का पासकोड का फ़ॉर्मैट, खास तौर पर ऐसे वर्शन के लिए सही नहीं है जिसमें कीसेट को इंप्लिसिट "सार्वजनिक मेटाडेटा" के तौर पर उपलब्ध कराया गया हो वैल्यू. अगर PrivacyPass का कोई वैरिएंट सार्वजनिक मेटाडेटा के साथ स्टैंडर्ड हो जाता है (जैसे कि POPRF, आंशिक आरएसए ब्लाइंडिंग या कीसेट), तो हम उसके साथ काम करने के लिए पीएसटी के आने वाले वर्शन का इस्तेमाल कर सकते हैं. |
| एपीआई को हेडर पर लागू करना | एपीआई के हेडर को लागू करने से जुड़े सवाल | जैसे-जैसे एपीआई का स्टैंडर्ड वर्शन तय होता है और इस एपीआई का नेटवर्क का इस्तेमाल बेहतर होता जा रहा है, वैसे-वैसे हम इस एपीआई के बिना हेडर वाले स्टैंडर्ड वर्शन के साथ काम कर सकते हैं. साथ ही, अगर काफ़ी कम इस्तेमाल होता है या ज़रूरी संख्या में डेवलपर टूल/रिडेंप्शन अनुरोध मिलते हैं, तो हेडर वर्शन को बंद किया जा सकता है. हम इस समस्या के बारे में यहां चर्चा कर रहे हैं. |
| रजिस्ट्रेशन | क्या जारी करने वालों को ब्राउज़र वेंडर के साथ रजिस्टर कराना सही है? | हमने प्राइवेट स्टेट टोकन जारी करने वाले व्यक्ति या कंपनी के रजिस्ट्रेशन की प्रोसेस के बारे में बताने के लिए, शर्तों में बदलाव किए हैं. यह अपनी प्रोसेस का इस्तेमाल करता है, लेकिन यह Privacy Sandbox के बाकी काम के लिए रजिस्ट्रेशन प्लान की तरह ही है. इसमें हम सेवा देने वाली कंपनियों से यह बताने के लिए कहते हैं कि वे पीएसटी का इस्तेमाल कैसे करना चाहते हैं और उपयोगकर्ता की निजता को सुरक्षित रखने वाली तकनीकी पाबंदियों को स्वीकार करना चाहते हैं. |