साल 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, Protected Audience, और एट्रिब्यूशन रिपोर्टिंग एपीआई के बारे में खास तौर पर सवाल और सुझाव मिले.
हो सकता है कि रिपोर्टिंग की मौजूदा अवधि खत्म होने के बाद मिले सुझाव/शिकायत/राय पर, Chrome ने अब तक कोई जवाब न दिया हो.
शॉर्ट फ़ॉर्म की ग्लॉसरी
- सीएचआईपीएस
- कुकीज़ हैविंग इंडिपेंडेंट पार्टिशन्ड स्टेट
- डीएसपी
- डिमांड-साइड प्लैटफ़ॉर्म
- FedCM
- फ़ेडरेटेड क्रेडेंशियल मैनेजमेंट
- एफ़पीएस
- फ़र्स्ट पार्टी सेट
- IAB
- Interactive Advertising Bureau
- IDP
- पहचान की पुष्टि करने वाली सेवा
- आईईटीएफ़
- इंटरनेट इंजीनियरिंग टास्क फ़ोर्स
- आईपी
- इंटरनेट प्रोटोकॉल पता
- openRTB
- रीयल-टाइम बिडिंग
- OT
- Origin ट्रायल
- PatCG
- निजी विज्ञापन टेक्नोलॉजी कम्यूनिटी ग्रुप
- आरपी
- भरोसा करने वाली पार्टी
- SSP
- सप्लाई-साइड प्लैटफ़ॉर्म
- टीईई
- ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट
- UA
- यूज़र एजेंट स्ट्रिंग
- UA-CH
- User-Agent Client Hints
- W3C
- वर्ल्ड वाइड वेब कंसोर्टियम
- WIPB
- जान-बूझकर आईपी ब्लाइंडनेस
सामान्य सुझाव, राय या शिकायत, किसी खास एपीआई/टेक्नोलॉजी के लिए नहीं
| सुझाव, शिकायत या राय की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| डेटा को मैनेज करना और नियमों का पालन करना | नियमों का पालन करते हुए, प्राइवसी सैंडबॉक्स का इस्तेमाल करने के बारे में नेटवर्क से जुड़े दिशा-निर्देश. | किसी भी नई टेक्नोलॉजी की तरह, यह पक्का करना हर कंपनी की ज़िम्मेदारी है कि Privacy Sandbox का इस्तेमाल कानून के मुताबिक हो. Google, दूसरों को कानूनी सलाह नहीं दे सकता. हालांकि, हमें पता है कि यह नेटवर्क के लिए एक अहम विषय है. हमने हर एपीआई के लिए, ज़्यादा से ज़्यादा तकनीकी दस्तावेज़ पब्लिश किए हैं. इनसे, ज़रूरी कानूनी आकलन करने में मदद मिलती है. साथ ही, हम नियमों से जुड़ी ज़रूरी शर्तों का पालन करने में कंपनियों की मदद करने के लिए, अन्य दस्तावेज़ उपलब्ध कराने पर काम कर रहे हैं. |
| सीएमए के लिए संख्यात्मक टेस्टिंग का प्रस्ताव | सीएमए की संख्यात्मक जांच के प्रस्ताव के बारे में ज़्यादा जानकारी | हम सीएमए के साथ मिलकर ऐसे एक्सपेरिमेंट डिज़ाइन कर रहे हैं जिनसे यह पता चल सके कि तीसरे पक्ष की कुकी के इस्तेमाल को बंद करने और Privacy Sandbox के प्रस्तावों को लागू करने से, नेटवर्क पर क्या असर पड़ेगा. अप्रैल में, सीएमए ने टेस्टिंग और ट्रायल की अवधि के दौरान क्या उम्मीद करनी चाहिए, इस बारे में ज़्यादा जानकारी वाला दिशा-निर्देश पब्लिश किया था. इसके बाद, जून में ज़्यादा जानकारी वाला दिशा-निर्देश पब्लिश किया गया. हमारा सुझाव है कि सीएमए के क्वांटिटेटिव टेस्टिंग के प्रस्ताव के बारे में सवाल या सुझाव सीधे सीएमए के साथ शेयर किए जाएं. |
| Chrome की मदद से होने वाली टेस्टिंग के मोड | टेस्टिंग शेड्यूल के बारे में ज़्यादा जानकारी और जानकारी | हमने 18 मई को एक ब्लॉग पोस्ट पब्लिश की थी. इसमें, Chrome की मदद से टेस्टिंग के दो मोड के बारे में ज़्यादा जानकारी दी गई थी. यह जानकारी पूरी तरह से तय नहीं है. साल 2023 की तीसरी तिमाही में, हम इसे लागू करने के बारे में ज़्यादा जानकारी पब्लिश करेंगे. |
| पार्टिशन किया गया स्टोरेज | क्या Chrome की मदद से होने वाली टेस्टिंग के दौरान, अलग-अलग सेक्शन में बांटा गया स्टोरेज इस्तेमाल किया जाएगा? | तीसरे पक्ष की कुकी के इस्तेमाल को बंद करने के एक्सपेरिमेंट से पहले, स्टोरेज को बांटने की सुविधा सभी उपयोगकर्ताओं के लिए उपलब्ध कराई जाएगी. इसलिए, यह एक्सपेरिमेंट के सभी ग्रुप के लिए चालू हो जाएगा. इस समयावधि के दौरान, साइटों के पास बिना सेक्शन वाले स्टोरेज को वापस पाने के लिए, बंद होने से पहले आज़माने की सुविधा चालू करने का विकल्प होगा. |
| प्रोडक्शन से जुड़ी सहायता | Chrome में, Privacy Sandbox से जुड़ी तकनीकी समस्याओं और इकोसिस्टम पर असर डालने वाली समस्याओं को हल करने के लिए क्या प्रोसेस अपनाई जाती है? | Google, विज्ञापन टेक्नोलॉजी विशेषज्ञों को समस्याओं की शिकायत करने और ज़रूरत पड़ने पर उन्हें आगे बढ़ाने के लिए, कई चैनल उपलब्ध कराता है. सुझाव/राय देने और शिकायत करने के लिए उपलब्ध सार्वजनिक और निजी फ़ोरम के बारे में ज़्यादा जानने के लिए, कृपया सुझाव/राय देने की सुविधा के बारे में खास जानकारी देखें. |
| रजिस्टर करने की टाइमलाइन | रजिस्टर करने की मौजूदा समयसीमा बहुत कम है | हम अब भी नीति उल्लंघन ठीक करने की समयसीमा का आकलन कर रहे हैं. साथ ही, हम ऐप्लिकेशन नेटवर्क से यह जानना चाहते हैं कि कौनसी समयसीमा ज़्यादा सही होगी. |
| डीयूएनएस नंबर | रजिस्टर करने और पुष्टि कराने के लिए, D-U-N-S नंबर की ज़रूरत के बारे में ज़्यादा जानकारी | डीयूएनएस नंबर पाने से जुड़ी ज़रूरी शर्तें जानने के लिए, Dun & Bradstreet की वेबसाइट पर जाएं. ज़रूरी शर्तें, मार्केट के हिसाब से अलग-अलग होती हैं. इसलिए, जिन मार्केट में लोगों की दिलचस्पी है उनके लिए वेबसाइट पर जाकर ज़रूरी शर्तें देखें. हालांकि, आम तौर पर, हिस्सा लेने वाले लोगों को अपने कारोबार के बारे में बुनियादी जानकारी देनी होगी. जैसे, कारोबार का नाम, पता, और कारोबार के मालिक या मैनेजर की संपर्क जानकारी. हिस्सा लेने वाले लोगों से वित्तीय जानकारी भी मांगी जा सकती है. जैसे, कारोबार का सालाना रेवेन्यू. आवेदन पूरा होने के बाद, D&B उसकी समीक्षा करेगा. अगर आवेदन को मंज़ूरी मिलती है, तो डीयूएनएस नंबर जारी किया जाएगा. |
| ऑरिजिन ट्रायल से सामान्य उपलब्धता पर स्विच करना | क्या ऑरिजिन ट्रायल से सामान्य उपलब्धता में ट्रांज़िशन होने से, ऑरिजिन ट्रायल में हिस्सा लेने वाले मौजूदा टेस्टर पर असर पड़ेगा? | जुलाई से, टेस्टर सामान्य रूप से उपलब्धता वाले काम के और मेज़रमेंट एपीआई को ऐक्सेस कर पाएंगे. इससे, मुफ़्त में आज़माने की सुविधा के उपलब्ध होने की अवधि और सामान्य तौर पर उपलब्ध होने की अवधि में ओवरलैप होगा. |
| AdExchanger की स्टडी | सर्वे के तरीके के बारे में ज़्यादा जानकारी | सर्वे में, जवाब देने वालों से अपने कारोबारों के लिए सिंक रेट और रेवेन्यू का अनुमान लगाने के लिए कहा गया था. जवाब देने वाले लोगों को यह तय करने की छूट थी कि वे अपने सवालों के जवाब कैसे देंगे. |
| पैरामीटर वैल्यू | शोर के लेवल, पहचान छिपाने के थ्रेशोल्ड, और निजता बजट जैसी पैरामीटर वैल्यू कैसे तय की जाती हैं? | GitHub पर मौजूद इस लेख में, Privacy Sandbox APIs के पीछे के सामान्य सिद्धांतों के बारे में बताया गया है. कई वैल्यू पर अब भी काम चल रहा है. इस विषय पर हमें आपके सुझाव/राय का इंतज़ार है. |
काम का कॉन्टेंट और विज्ञापन दिखाना
विषय
| सुझाव, शिकायत या राय की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| निजता बनाए रखना | निजता बनाए रखने के लिए, Topics API का आकलन करने वाली रिसर्च | हम रिसर्च कम्यूनिटी के साथ लगातार काम कर रहे हैं. हम पेपर, रिपोर्ट, और वर्कशॉप के प्रज़ेंटेशन में, Topics API की निजता से जुड़ी प्रॉपर्टी के बारे में अपनी रिसर्च पेश कर रहे हैं. हमें यह देखकर खुशी हो रही है कि रिसर्च कम्यूनिटी के बाहर के ज़्यादा से ज़्यादा लोग इस क्षेत्र में दिलचस्पी दिखा रहे हैं. Topics API, उपयोगकर्ताओं को वेब पर सामान्य तौर पर होने वाली ट्रैकिंग से बचाता है. ऐसा करके, यह बड़े पैमाने पर उपयोगकर्ताओं को ट्रैक करना बहुत मुश्किल बना देता है. इन पेपर से पता चलता है कि हम Topics API की मदद से ऐसा कर रहे हैं. यह तीसरे पक्ष की कुकी की तुलना में ज़्यादा निजी है. साथ ही, यह उपयोगकर्ताओं की निजता को सुरक्षित रखती है और उनकी पसंदीदा साइटों को काम करती है. |
| विषयों की टेक्सॉनमी ज़रूरत के मुताबिक नहीं है | बड़े विषयों के टैक्सोनॉमी में, ज़्यादा जानकारी वाले विषय शामिल नहीं होते. इनमें क्षेत्र के हिसाब से बने विषय भी शामिल हैं. | नेटवर्क से मिले पिछले सुझावों और राय के आधार पर, हमने 15 जून को एक ब्लॉग पोस्ट पब्लिश की थी. इसमें, टैक्सोनॉमी के नए वर्शन के बारे में बताया गया था. इसमें नेटवर्क से मिले सुझावों और राय के आधार पर कई सुधार किए गए हैं. टैक्सोनॉमी में किए गए बदलावों पर काम करने के लिए, हमने अपने पूरे नेटवर्क की कई कंपनियों के साथ काम किया है. इनमें Raptive (पहले इसका नाम CafeMedia था) और Criteo जैसी कंपनियां शामिल हैं. अपडेट किए गए टैक्सोनॉमी में, उन कैटगरी को हटा दिया गया है जो कम काम की हैं. साथ ही, विज्ञापन देने वालों की दिलचस्पी से मेल खाने वाली कैटगरी को शामिल किया गया है. साथ ही, संवेदनशील विषयों को बाहर रखने की हमारी प्रतिबद्धता को बनाए रखा गया है. हमारा सुझाव है कि नेटवर्क के सभी सदस्य, टैक्सोनॉमी के नए वर्शन की समीक्षा करें और बदलावों के बारे में सुझाव/राय दें. |
| टैक्सोनॉमी और क्लासिफ़ायर को अपडेट करने की प्रोसेस | Topics टैक्सोनॉमी और क्लासिफ़ायर रिलीज़ के कैडेंस के बारे में ज़्यादा जानकारी. साथ ही, इस बारे में भी जानकारी कि कंपनियां ऐसे अपडेट के लिए कैसे तैयारी कर सकती हैं. | हाल ही में पोस्ट किए गए ब्लॉग में बताया गया था कि टैक्सोनॉमी समय के साथ बेहतर होती जाएगी. साथ ही, टैक्सोनॉमी को मैनेज करने की ज़िम्मेदारी, इंडस्ट्री के सभी हिस्सेदारों का प्रतिनिधित्व करने वाली किसी बाहरी पार्टी को दे दी जाएगी. हमने topics-announce ग्रुप में, रैंप-अप प्लान भी शेयर किया है. |
| पहले पक्ष के सिग्नल पर असर | टैक्सोनॉमी के हाल ही के अपडेट में विषयों की संख्या में बढ़ोतरी बहुत अहम हो सकती है. इस वजह से, पहले पक्ष के अन्य दिलचस्पी के आधार पर मिलने वाले सिग्नल की वैल्यू कम हो जाती है. | साल 2023 की पहली तिमाही की रिपोर्ट में, सीएमए ने कहा था कि "हमें पता है कि Google, विज्ञापन टेक्नोलॉजी की सप्लाई चेन में शामिल कई लोगों के साथ, अपने प्रस्तावित नए टैक्सोनॉमी के बारे में बातचीत कर रहा है. कुछ बड़े पब्लिशर ने कहा है कि विषयों की ज़्यादा उपयोगिता से, पहले पक्ष (ग्राहक) के डेटा पर आधारित उनके समाधानों पर प्रतिस्पर्धा का दबाव बढ़ेगा. हालांकि, हमारा शुरुआती राय है कि ज़्यादा उपयोगिता, कुल मिलाकर प्रतिस्पर्धा के लिए बेहतर है. खास तौर पर, तीसरे पक्ष की कुकी के बंद होने के बाद, छोटे पब्लिशर के लिए अपनी इन्वेंट्री से कमाई करना जारी रखना". हमारा नज़रिया, सीएमए की इस टिप्पणी से मेल खाता है. |
| अलग-अलग तरह के हिस्सेदारों के लिए फ़ायदेमंद होना | एसएसपी और डीएसपी के तौर पर काम करने वाले विज्ञापन टेक्नोलॉजी प्लैटफ़ॉर्म को, अन्य प्लैटफ़ॉर्म की तुलना में ज़्यादा फ़ायदे मिल सकते हैं. | हमारी पिछली तिमाहियों के जवाब में कोई बदलाव नहीं हुआ है: "Google ने सीएमए को यह वादा किया है कि वह निजता सैंडबॉक्स के प्रस्तावों को इस तरह से डिज़ाइन और लागू करेगा कि Google अपने कारोबार को प्राथमिकता देकर, प्रतिस्पर्धा को गलत न बनाए. साथ ही, वह डिजिटल विज्ञापन में प्रतिस्पर्धा और पब्लिशर और विज्ञापन देने वालों पर पड़ने वाले असर को ध्यान में रखेगा. भले ही, उनके कारोबार का साइज़ कुछ भी हो. हम सीएमए के साथ मिलकर काम करते रहेंगे, ताकि यह पक्का किया जा सके कि हमारा काम इन प्रतिबद्धताओं के मुताबिक हो. Privacy Sandbox की टेस्टिंग के दौरान, हम इस बात का आकलन करेंगे कि अलग-अलग तरह के हिस्सेदारों के लिए, नई टेक्नोलॉजी कैसा परफ़ॉर्म करती हैं. इस मामले में, आपका सुझाव, राय या शिकायत हमारे लिए बहुत ज़रूरी है. खास तौर पर, ऐसा सुझाव, राय या शिकायत जो काम की हो और जिस पर कार्रवाई की जा सके. इससे हमें तकनीकी डिज़ाइन को और बेहतर बनाने में मदद मिलेगी. हमने संख्यात्मक जांच के लिए अपना तरीका विकसित करने के लिए, सीएमए के साथ काम किया है. साथ ही, हम एक्सपेरिमेंट डिज़ाइन के बारे में सीएमए का नोट पब्लिश करने के पक्ष में हैं, ताकि बाज़ार में हिस्सा लेने वाले लोगों को ज़्यादा जानकारी मिल सके और उन्हें सुझाए गए तरीकों पर टिप्पणी करने का मौका मिल सके." |
| डेसेंटेंट विषय | विषय चुनने की शर्त के तौर पर, ब्राउज़र पर आने की फ़्रीक्वेंसी को इस्तेमाल करने पर, क्या सेगमेंट के अलग-अलग होने की वजह से, डेसेंटेंट विषय कभी भी टॉप पर नहीं आएंगे? | फ़िलहाल, Chrome रैंकिंग के अन्य तरीकों का आकलन कर रहा है. साथ ही, ऐसे अन्य सिग्नल का भी पता लगा रहा है जिनसे रैंकिंग को बेहतर बनाया जा सकता है. हम समय-समय पर, बदले गए प्लान के बारे में नेटवर्क को बताते रहेंगे. |
| संवेदनशीलता | Topics API का लक्ष्य यह पक्का करना होना चाहिए कि Topics API से मिली या उससे ली गई उपयोगकर्ता की जानकारी, आज के ट्रैकिंग तरीकों से ली गई जानकारी के मुकाबले कम निजी और संवेदनशील हो. | हमारा मानना है कि Topics API, मौजूदा टेक्नोलॉजी के मुकाबले ज़्यादा निजी है. यह उपयोगकर्ताओं की पहचान का पता लगाने की प्रक्रिया को काफ़ी हद तक सीमित करता है. साथ ही, इसे संवेदनशील विषयों को बाहर रखने के लिए डिज़ाइन किया गया है. हम मानते हैं कि संवेदनशील कैटगरी बनाने के लिए, Topics API को पहले पक्ष (ग्राहक) के डेटा के साथ जोड़ा या मिलाया जा सकता है. हालांकि, हमारा मानना है कि Topics API, उपयोगकर्ता की निजता को बेहतर बनाने की दिशा में एक कदम है. हम इस एपीआई को बेहतर बनाने के लिए लगातार काम कर रहे हैं. |
| टैक्सनॉमी का स्ट्रक्चर | Topics टैक्सोनॉमी में आईडी, वर्शन, और अन्य मेटाडेटा स्ट्रक्चर जोड़ना | फ़िलहाल, एपीआई रिस्पॉन्स में हम टैक्सोनॉमी आईडी शामिल कर रहे हैं. हम लंबे समय तक कॉन्टेंट मैनेज करने की दिशा में आगे बढ़ रहे हैं. इसलिए, Topics ऑब्जेक्ट की समीक्षा करना और ज़रूरत पड़ने पर वर्शन के लिए अतिरिक्त मेटाडेटा शामिल करना सही रहेगा. |
| पब्लिशर कंट्रोल | पब्लिशर को यह तय करने का अधिकार होना चाहिए कि उनकी साइटों को किन विषयों के तौर पर बांटा जाए. | साइटों को गलत कैटगरी में डालने से, Topics सिग्नल को सिग्नल के तौर पर थोड़ा कम मददगार बना सकता है. हालांकि, गलत कैटगरी में डाली गई साइटों को किसी दूसरी साइटों की तुलना में ज़्यादा या कम नुकसान नहीं होता. ऐसा इसलिए है, क्योंकि किसी साइट की संदर्भ जानकारी, उसकी साइट पर होने वाली नीलामियों के लिए हमेशा उपलब्ध रहेगी. इससे, गलत कैटगरी में डाले जाने के मामले में भी, सही विषय के बारे में तुलना की जा सकने वाली जानकारी मिलती रहेगी. इस विषय पर सुझाव/राय देने या शिकायत करने के लिए, यहां क्लिक करें. पब्लिशर को अपने कॉन्टेंट की कैटगरी कंट्रोल करने की अनुमति देने से जोखिम हो सकते हैं. साइटें जान-बूझकर अपनी साइटों को गलत तरीके से कैटगरी में बांट सकती हैं. इससे, सभी के लिए साइट की उपयोगिता कम हो जाती है. इसके अलावा, साइटें कम इस्तेमाल होने वाले विषयों में संवेदनशील जानकारी को कोड में बदल सकती हैं. इससे, उपयोगकर्ता की निजता को नुकसान पहुंचता है. |
| Chrome एक्सटेंशन | Chrome एक्सटेंशन को विषयों को मैनेज और फ़िल्टर करने की अनुमति देना. यह सुविधा, कुकी मैनेजमेंट एक्सटेंशन की तरह ही काम करती है | GitHub पर चर्चा के मुताबिक, ऐसा पहले से ही किया जा सकता है. हालांकि, हम ईकोसिस्टम से इस बारे में और सुझाव, शिकायत या राय पाना चाहते हैं. |
| सामान्य रूप से उपलब्धता में बदलाव | क्या ऑरिजिन ट्रायल से सामान्य रूप से उपलब्धता में बदलाव होने पर, Topics API पर कोई असर पड़ेगा? | जिन उपयोगकर्ताओं ने Origin Trial में हिस्सा लिया है उन्हें सामान्य तौर पर उपलब्ध होने पर, अपना डेटा नहीं खोना पड़ेगा. |
| निजता | होस्ट नेम में निजी जानकारी हो सकती है, जिसे Topics API से ज़ाहिर किया जा सकता है | निजता को सुरक्षित रखने के लिए, हमारे पास कई तरीके हैं. इनके बारे में यहां बताया गया है. |
| धोखाधड़ी और गलत इस्तेमाल | धोखाधड़ी वाली विज़िट से Topics में बदलाव होने से रोकने का तरीका | इन समस्याओं को कम करने के बारे में यहां बताया गया है. |
| विषयों की कैटगरी तय करने वाला | क्या वेबसाइटें, विषयों के लिए तय की गई कैटगरी में बदलाव करने का अनुरोध कर सकती हैं? | हम इस विषय पर, इको सिस्टम से सुझाव, राय या शिकायतें सुनना चाहते हैं. इसके लिए, यहां जाएं. |
| विषयों की जानकारी देने वाली साइटें | कई विषयों के लिए कॉन्टेंट होस्ट करने वाली कुछ वेबसाइटों को "खास विषयों की जानकारी देने वाली साइटें" के तौर पर सेट करें. साथ ही, वेब पेजों पर दिए गए टैग के आधार पर, क्लासिफ़ायर को ट्रेन करें. | हम इस प्रस्ताव पर यहां चर्चा कर रहे हैं. अगर आपके पास कोई सुझाव, राय या शिकायत है, तो हमें बताएं. |
Protected Audience API (पहले इसे FLEDGE के नाम से जाना जाता था)
| सुझाव, शिकायत या राय की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| ट्रैफ़िक शेपिंग | हर सेकंड की क्वेरी (क्यूपीएस) लोड को ऑप्टिमाइज़ करने के लिए, एसएसपी से मिलने वाले फ़िल्टर का परफ़ॉर्मेंस पर असर | हमने ट्रैफ़िक शेपिंग के बारे में काफ़ी समय तक सोचा है. हमारा सुझाव है कि एसएसपी, कैश मेमोरी सेव करने की सुविधा का फ़ायदा लें. |
| वॉल्यूम की जांच करना | Protected Audience की जांच करना मुश्किल है, क्योंकि एसएसपी और डीएसपी को ज़्यादा ट्रैफ़िक नहीं मिल पा रहा है. | हम सुरक्षित ऑडियंस को अपनाने और उसकी जांच करने के लिए, एसएसपी और डीएसपी पार्टनर के साथ लगातार काम कर रहे हैं. यह सुविधा सभी के लिए उपलब्ध हो गई है. हमें भरोसा है कि PA की सुविधा चालू होने पर मिलने वाले ट्रैफ़िक की वजह से, पार्टनर को इसे टेस्ट करने में आसानी होगी. |
| जटिलता | सुरक्षित ऑडियंस के सलूशन लागू करने के लिए, ज़्यादा मेहनत और पैसे खर्च करने पड़ते हैं. | हम मानते हैं कि नई टेक्नोलॉजी को अपनाना मुश्किल है. इनमें Privacy Sandbox भी शामिल है. Privacy Sandbox की टीम, कई तरह के हिस्सेदारों के साथ मिलकर काम कर रही है, ताकि उन्हें प्राइवसी सैंडबॉक्स के बारे में जानकारी दी जा सके और उन्हें मदद मिल सके. साथ ही, यह टीम इस बात का लगातार आकलन कर रही है कि इसकी मदद से, इकोसिस्टम को कैसे बेहतर बनाया जा सकता है. |
| ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट | सार्वजनिक क्लाउड एनवायरमेंट के बजाय, निजी क्लाउड एनवायरमेंट में ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) के लिए सहायता | हम क्लाउड-आधारित समाधानों के अलावा, अन्य संभावित विकल्पों को भी एक्सप्लोर कर रहे हैं. हालांकि, फ़िलहाल ऑन-प्राइमिस टीईई का इस्तेमाल नहीं किया जा सकता. इसकी वजह यह है कि ऑन-प्राइमिस सुरक्षा की सीमाओं की वजह से, प्राइवसी सैंडबॉक्स के लिए आकलन में काफ़ी समय लगेगा. प्राइवेसी सैंडबॉक्स की सुरक्षा से जुड़ी ज़रूरी शर्तों और ऑन-प्राइमिस डिप्लॉयमेंट से जुड़ी चुनौतियों को देखते हुए, हमारा मानना है कि क्लाउड-आधारित डिप्लॉयमेंट (जैसे, AWS के साथ-साथ GCP के साथ काम करना) को बेहतर बनाना और उसका दायरा बढ़ाना, इकोसिस्टम के लिए सबसे ज़्यादा फ़ायदेमंद है. हालांकि, हम इस बारे में ज़्यादा सुझाव, राय या शिकायत का स्वागत करते हैं कि यह ज़रूरी शर्त क्यों है. |
| लागत का स्ट्रक्चर | बिडिंग और नीलामी सेवाओं के प्रस्ताव से, क्लाइंट-साइड मॉडल की तुलना में विज्ञापन टेक्नोलॉजी की लागत और जटिलता बढ़ जाएगी. | फ़िलहाल, हम बिडिंग और नीलामी सर्वर में बिडिंग और नीलामी वर्कफ़्लो को सपोर्ट करने की लागत का अनुमान लगाने के लिए एक गाइड बना रहे हैं. यह गाइड, विज्ञापन टेक्नोलॉजी के इस्तेमाल से जुड़ी होगी. इससे हमारे डिज़ाइन के एक लक्ष्य को पूरा किया जा सकेगा. |
| K-Anon टाइमलाइन | `renderUrl` पर, k-anonymity की योजना से जुड़ी पाबंदियां कब लागू होंगी? | हम नीति उल्लंघन ठीक करने की समयावधि के बारे में जानकारी देने वाले वीडियो पर काम कर रहे हैं. इसे जल्द ही रिलीज़ किया जाएगा. |
| runAdAuction की पाबंदियां | क्या Chrome, runAdAuction को सिर्फ़ टॉप पेज से कॉल करने की अनुमति दे सकता है? |
हमारा डिज़ाइन, runAdAuction को टॉप पेज से कॉल करने की सुविधा पूरी तरह से देता है. हालांकि, हमारा मानना है कि इसे सिर्फ़ टॉप डोमेन से कॉल करने की सुविधा देने से, पब्लिशर को ज़्यादा नुकसान होगा.हमें नेटवर्क से खास तौर पर यह सुझाव मिला है कि प्राइवसी सैंडबॉक्स को पब्लिशर और विज्ञापन देने वालों पर पड़ने वाले बोझ को कम करना चाहिए. यह सुझाव, वेब डेवलपमेंट के सामान्य सिद्धांत के मुताबिक है. इस सिद्धांत के मुताबिक, साइट के मालिक अपनी साइटों को चलाने के लिए, तीसरे पक्ष के टूल का इस्तेमाल कर सकते हैं. Privacy Sandbox का मकसद, पब्लिशर और विज्ञापन टेक्नोलॉजी कंपनियों के काम करने के तरीके को तय किए बिना, एक बेहतर नेटवर्क को बढ़ावा देना है. हम पब्लिशर को यह चुनने की सुविधा देते हैं कि उनकी साइट पर runAdAuction को कैसे और कौन कॉल करेगा. इससे, पब्लिशर अपनी ज़रूरतों के हिसाब से सबसे सही तरीका चुन सकते हैं. |
| लागू करने में मदद | क्या Chrome, एक से ज़्यादा सेलर वाली नीलामी को ओपन-सोर्स के तौर पर लागू कर सकता है या इसमें योगदान दे सकता है? | Privacy Sandbox का मकसद, निजता बनाए रखने वाली ऐसी टेक्नोलॉजी डेवलप करना है जो तीसरे पक्ष की कुकी या क्रॉस-साइट आइडेंटिफ़ायर पर निर्भर न हों. हम विज्ञापन टेक्नोलॉजी के काम करने के तरीके के बारे में बताए बिना, बेहतर ईकोसिस्टम को बढ़ावा देना चाहते हैं. हमने अपने GitHub डेटा स्टोर करने की जगह पर, एपीआई के काम करने के तरीके के बारे में दिशा-निर्देश पब्लिश किए हैं. साथ ही, हम इंडस्ट्री के साथ मिलकर समाधान ढूंढने के लिए तैयार हैं. हम किसी खास तरीके को लागू करने का प्लान नहीं बना रहे हैं. हमारा मुख्य मकसद, प्लैटफ़ॉर्म टेक्नोलॉजी बनाना है, न कि उन टेक्नोलॉजी का इस्तेमाल करने की रणनीतियां तय करना. हमारी टेक्नोलॉजी की मदद से, विज्ञापन टेक्नोलॉजी कंपनियां अपने ग्राहकों को बेहतर सेवा दे पाएंगी. साथ ही, वे उपभोक्ताओं की निजता को सुरक्षित रखने के लिए सही गार्डराइल भी उपलब्ध करा पाएंगी. |
| एक से ज़्यादा सेलर वाली नीलामियां | क्या Chrome, कॉम्पोनेंट नीलामियों के साथ "संदर्भ के हिसाब से" विजेता को शेयर करने के लिए मजबूर करेगा? | Protected Audience API को इस तरह से डिज़ाइन किया गया है कि एक से ज़्यादा सेलर की नीलामी शुरू करने वाले पक्ष, कॉम्पोनेंट नीलामी को जानकारी दे सकें. ध्यान दें: ऐसा सिर्फ़ नीलामी शुरू करने से पहले किया जा सकता है. हालांकि, हमें लगता है कि ब्राउज़र यह नहीं बता सकता कि कोई जानकारी, संदर्भ के हिसाब से सही है या नहीं. इसलिए, हम कुछ जानकारी को ब्लॉक नहीं कर सकते या उसके लिए ज़रूरी शर्तें नहीं तय कर सकते. |
| सहमति ट्रैकिंग के लिए उपयोगकर्ता की प्राथमिकता | Adtech, PA से पूछ रहा है कि उपयोगकर्ता की सहमति ट्रैकिंग को सही तरीके से कैसे लागू किया जाए | हमारे जवाब में, हमने पहले सवाल में जो कहा था वह शामिल है: "विज्ञापन टेक्नोलॉजी से जुड़ी कंपनी, खास विज्ञापनों के लिए यह कंट्रोल करने की सबसे सही स्थिति में होती है कि कौनसे क्रिएटिव दिखाए जाएं या उन्हें कैसे चुना जाए." हमने मई में हुई WICG की सुरक्षित ऑडियंस मीटिंग के दौरान, इस समस्या से जुड़ी कई स्थितियों के बारे में बातचीत की थी. साथ ही, हम इस समस्या के बारे में ज़्यादा सुझाव, राय, और शिकायतें पाने के लिए तैयार हैं. |
| कस्टम ऑडियंस | क्या एसएसपी, कस्टम ऑडियंस बनाने से जुड़े इस्तेमाल के उदाहरणों के लिए, Protected Audience API का इस्तेमाल कर सकता है? | Protected Audience API की मदद से, एसएसपी और विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली अन्य कंपनियां, कस्टम ऑडियंस का मालिकाना हक हासिल कर सकती हैं और उन्हें मैनेज कर सकती हैं. एसएसपी को PA API के साथ इंटिग्रेट करने के तरीके के बारे में ज़्यादा दिशा-निर्देश तैयार किए जा रहे हैं. इन्हें एसएसपी और विज्ञापन टेक्नोलॉजी की सेवा देने वाली अन्य कंपनियों के लिए उपलब्ध कराया जाएगा, ताकि वे इंटिग्रेशन की प्रोसेस को आसानी से पूरा कर सकें. |
| फ़ॉर्मैट | क्या Protected Audience API, वीडियो के साथ काम करता है? | वीडियो विज्ञापनों को दो में से किसी एक तरीके से डिलीवर किया जाता है: वीएएसटी एक्सएमएल या एचटीएमएल (एक आउटस्ट्रीम विज्ञापन, जो आखिर में वीडियो प्लेयर में भी वीएएसटी एक्सएमएल लोड कर सकता है). खरीदार, renderURL की मदद से, इनमें से किसी भी फ़ॉर्मैट में डेटा दिखा सकते हैं. Attribution Reporting API के साथ काम करने के लिए, VAST स्पेसिफ़िकेशन को हाल ही में अपडेट किया गया है. वीडियो विज्ञापन दिखाने वाली साइटों को, Protected Audience API की मदद से विज्ञापन दिखाने के तरीके के लिए तैयारी करनी होगी. इसका मतलब है कि यह पक्का करना कि प्लेसमेंट टैग, Protected Audience iframe से वीडियो प्लेयर पर यूआरएल भेज सकें. फ़ेंस किए गए फ़्रेम की सुविधा का इस्तेमाल करने की ज़रूरी शर्तें 2026 से पहले लागू नहीं होंगी. हम इस सुविधा के इस्तेमाल से पहले, वीडियो से जुड़ी ज़रूरतों को पूरा करने के लिए काम करेंगे. |
| वीडियो की स्पीड | Protected Audience API के साथ, पेसिंग का इस्तेमाल कैसे किया जाता है? | हम सुझाव की सराहना करते हैं. हमें इस अनुरोध के ज़्यादा उदाहरण देखने हैं. साथ ही, हमें एसएसपी पार्टनर से ज़्यादा जानकारी भी चाहिए, क्योंकि अब तक यह ज़्यादातर डीएसपी की समस्या रही है. |
| अपडेट आवृत्ति | dailyUpdate से आने वाले कॉल की फ़्रीक्वेंसी (हर इंटरेस्ट ग्रुप के लिए, हर दिन एक कॉल तक) कुछ खास इस्तेमाल के उदाहरणों के लिए काफ़ी नहीं हो सकती. जैसे, प्रॉडक्ट की जानकारी अपडेट करना. |
हम सुझाव की सराहना करते हैं. AdTech कंपनियों को अलग-अलग कैडेंस में रीफ़्रेश होने वाले सिग्नल का इस्तेमाल करने की अनुमति देने के लिए, अन्य समाधान भी उपलब्ध हैं. जैसे, K/V लुकअप. |
| विज्ञापन की क्वालिटी कंट्रोल करना | पब्लिशर, विज्ञापन की क्वालिटी कंट्रोल की सुविधा को कैसे लागू करते हैं? | फ़िलहाल, Protected Audience API की मदद से पब्लिशर, अपने एसएसपी को कुछ कंट्रोल के बारे में बता सकते हैं. ये कंट्रोल, नीलामी कॉन्फ़िगरेशन और बिडिंग से पहले की जाने वाली कार्रवाई (जैसे, विज्ञापनों से जुड़े लेबल के आधार पर बनी ब्लैकलिस्ट) के हिस्से के तौर पर सेट किए जा सकते हैं. अगर आपको लगता है कि इस नेटवर्क में कोई और सुविधा जोड़ी जा सकती है, तो हमें बताएं. |
| डीबग करना | forDebuggingOnly की सुविधा कब हटाई जाएगी? |
तीसरे पक्ष की कुकी का इस्तेमाल बंद होने की वजह से, हम लॉस इवेंट के लिए forDebuggingOnly को बंद करने जा रहे हैं. हमारा प्लान है कि हम साल 2026 में, जीतने वाले इवेंट के लिए forDebuggingOnly को बंद कर दें. |
| क्रॉस-डिवाइस के हिसाब से एक जैसी दिलचस्पी वाले ग्रुप | पुष्टि किए गए उपयोगकर्ता एजेंट के लिए, अलग-अलग डिवाइसों पर एक जैसी दिलचस्पी वाले ग्रुप की सुविधा चालू करने का प्रस्ताव | हम इस प्रस्ताव का आकलन कर रहे हैं. हालांकि, अलग-अलग डिवाइसों पर टारगेटिंग करने की सुविधा की वजह से निजता से जुड़ी गंभीर समस्याएं आ सकती हैं. इस बारे में इस GitHub समस्या में बताया गया है. |
| (पहली तिमाही में भी रिपोर्ट की गई) डाइनैमिक रीमार्केटिंग | क्या तीसरे पक्ष की कुकी के बंद होने के बाद भी, Protected Audience API की मदद से डाइनैमिक रीमार्केटिंग की जा सकेगी? | हमारा मानना है कि जैसा कि यहां बताया गया है, सुरक्षित ऑडियंस का इस्तेमाल करके, इस उदाहरण का इस्तेमाल किया जा सकता है. |
| मिलते-जुलते डेटा पर क्लिक करें | browserSignals. में क्लिक से जुड़ा डेटा जोड़ना |
फ़िलहाल, हम शुरुआती रैंक देने के लिए, क्लिक होने के समय के बारे में जानकारी मांग रहे हैं. |
| (इसकी शिकायत साल 2022 की चौथी तिमाही में भी की गई थी) सुरक्षित ऑडियंस में उपयोगकर्ता के तय किए गए फ़ंक्शन | Protected Audience API में, उपयोगकर्ता के तय किए गए फ़ंक्शन (यूडीएफ़) कैसे काम करेंगे? ये ऐसे फ़ंक्शन हैं जिन्हें एंड यूज़र प्रोग्राम कर सकते हैं, ताकि एपीआई की सुविधाओं को बेहतर बनाया जा सके. | इस समस्या को उठाने वाले विज्ञापन टेक्नोलॉजी ने यह भी बताया कि वे अब भी इस बात का आकलन कर रहे हैं कि यूडीएफ़ का इस्तेमाल कैसे किया जा सकता है. इसलिए, कम से कम सामान्य रूप से उपलब्ध होने तक, इस पर कोई कार्रवाई नहीं की जा सकती. |
| मुद्रा | मुद्रा की रकम को फ़्लोटिंग पॉइंट का इस्तेमाल करके नहीं दिखाया जाना चाहिए. | हमने इस समस्या के बारे में यहां ज़्यादा जानकारी दी है. |
| डीएसपी के अलावा, विज्ञापन चुनने की अन्य सुविधाएं | Protected Audience API की नीलामियों में, विज्ञापन सर्वर की क्या भूमिका होती है? | हम विज्ञापन सर्वर के लिए, बिड के बाद विज्ञापन चुनने / डाइनैमिक क्रिएटिव ऑप्टिमाइज़ेशन सेवाएं देने के अनुरोधों के बारे में जानते हैं. फ़िलहाल, हम Protected Audience API के मौजूदा वर्शन और इन अनुरोधों के बीच मौजूद अंतर का आकलन कर रहे हैं. |
| GenerateBid | generateBid से, हर विज्ञापन की दिलचस्पी के ग्रुप के लिए एक से ज़्यादा विज्ञापन दिखाने के Google Ads के प्रस्ताव के लिए सहायता. साथ ही, उन विज्ञापनों को `scoreAd` में स्कोर किया गया है. |
फ़िलहाल, इसकी समीक्षा की जा रही है. अन्य सुझाव/राय/शिकायत यहां भेजें. |
| नीलामी का ऑर्डर | क्या Protected Audience API की नीलामियां आखिर में होनी चाहिए, ताकि वह अन्य सभी नीलामियों के नतीजों से इनपुट ले सके? | Protected Audience API को आखिर में चलाने के लिए, कोई तकनीकी शर्त नहीं है. |
| उपयोगकर्ता की ओर से शुरू नहीं किया गया नेविगेशन | उपयोगकर्ता की ओर से शुरू नहीं किया गया नेविगेशन एक्सपोज़ करना | हम इस अनुरोध की समीक्षा कर रहे हैं और इस पर यहां चर्चा कर रहे हैं . साथ ही, हम आपके सुझाव, राय या शिकायतों का स्वागत करते हैं. |
| कैश मेमोरी में सेव करना | अगर उपयोगकर्ता की स्थिति बदलती है, तो एसएसपी को किसी कैश मेमोरी से किसी डीएसपी के perBuyerSignals को नहीं बनाना चाहिए. | हम समझते हैं कि perBuyer सिग्नल के हर इस्तेमाल के उदाहरण के लिए, कैश मेमोरी में सेव करने की सुविधा काम नहीं करती. इसलिए, हम अन्य विकल्पों का आकलन कर रहे हैं. हम इस बात पर, नेटवर्क से जुड़े किसी भी व्यक्ति या कंपनी के सुझाव, राय या शिकायत का स्वागत करते हैं कि कैश मेमोरी का इस्तेमाल उनके इस्तेमाल के उदाहरणों के लिए किया जा सकता है या नहीं. |
| एट्रिब्यूशन रिपोर्टिंग और Protected Audience | Attribution Reporting API और Protected 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() फ़ंक्शन, हर इंटरेस्ट ग्रुप के हिसाब से चलता है. साथ ही, generateBid को लागू करने पर डीएसपी यह जानकारी दिखाता है: return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| बाहरी योगदान | Key/Value Server के GitHub कोड बेस में, बाहरी लोगों के योगदान को शामिल करने का अनुरोध. | हम GitHub कोड में बाहरी योगदान देने की सुविधा देने के लिए, अपनी प्रोसेस को अपडेट कर रहे हैं. |
| इंटरेस्ट ग्रुप का साइज़ | IG में ज़्यादा से ज़्यादा कितनी कुंजियां इस्तेमाल की जा सकती हैं? | फ़िलहाल, एक आईजी के साइज़ की सीमा 50 केबी है. इसमें पासकोड भी शामिल हैं. हम साइज़ की सीमा के बारे में ज़्यादा बातचीत के लिए तैयार हैं. |
| एक साथ कई टास्क करना | K/V सर्वर कॉल की संख्या कैसे कम की जा सकती है? | K/V कॉल की संख्या कम करने के लिए, एचटीटीपी कैश-कंट्रोल हेडर का इस्तेमाल किया जा सकता है. उदाहरण के लिए, इसे सभी कॉम्पोनेंट की नीलामियों में और एक ही पेज पर मौजूद सभी विज्ञापन स्लॉट में कैश मेमोरी में सेव किया जा सकता है. |
| वर्शन कंट्रोल | विज्ञापन टेक्नोलॉजी कोड के कई वर्शन के साथ काम करना | बिडिंग और नीलामी से जुड़ी सेवाएं, विज्ञापन टेक्नोलॉजी कोड के कई वर्शन के साथ काम करेंगी. बिडिंग और ऑक्शन एपीआई में, SelectAd अनुरोध से ऑक्शन अनुरोध (यानी बिडिंग / ऑक्शन और रिपोर्टिंग के लिए) के लिए इस्तेमाल किए गए कोड का वर्शन पता चल सकता है. |
| शेयर किया गया स्टोरेज | बिडिंग और नीलामी की सेवा में, शेयर किए गए स्टोरेज में लिखने की सुविधा. | फ़िलहाल, बिडिंग और नीलामी सेवाएं, शेयर किए गए स्टोरेज के साथ काम नहीं करती हैं. हालांकि, हम इस बारे में और सुझाव/राय/शिकायत देने के लिए आपका स्वागत करते हैं कि इस तरह के इस्तेमाल के उदाहरण, नेटवर्क के लिए क्यों अहम हैं. |
| वेब-टू-ऐप्लिकेशन | एक जैसी पसंद के हिसाब से बनाए गए ग्रुप को वेब से ऐप्लिकेशन में शेयर करने की सुविधा. | फ़िलहाल, Chrome और Android पर Protected Audience API को डिप्लॉय करने के दायरे में, वेब-टू-ऐप्लिकेशन को शामिल नहीं किया गया है. हालांकि, हम इस इस्तेमाल के उदाहरण के महत्व के बारे में, नेटवर्क से जुड़े लोगों की राय जानना चाहते हैं. |
| K-Anonymity | K-Anonymity फ़ॉलबैक को मैनेज करने का तरीका | हम समस्या पर चर्चा कर रहे हैं. साथ ही, हमें इस बारे में और सुझाव, राय या शिकायतें भेजने में खुशी होगी. |
डिजिटल विज्ञापनों की परफ़ॉर्मेंस का आकलन करना
एट्रिब्यूशन रिपोर्टिंग (और अन्य एपीआई)
| सुझाव, शिकायत या राय की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| वैकल्पिक वीटीसी इवेंट लेवल रिपोर्ट कॉन्फ़िगरेशन | वैकल्पिक वीटीसी इवेंट-लेवल रिपोर्ट कॉन्फ़िगरेशन के बारे में सुझाव/राय | हमें कुछ सुझाव मिले हैं कि इवेंट-लेवल के मौजूदा कॉन्फ़िगरेशन सबसे सही नहीं हैं. इसलिए, हम सबसे सही ग्लोबल कॉन्फ़िगरेशन के बारे में सुझाव/राय मांग रहे हैं. हम इस बारे में और सुझाव, राय या शिकायतें सुनने के लिए तैयार हैं. हमें लगता है कि इवेंट लेवल पर, आसानी से समझने लायक जानकारी से भी इस समस्या को हल करने में मदद मिलती है. |
| इवेंट-लेवल के लिए ज़रूरत के मुताबिक कॉन्फ़िगरेशन | इवेंट-लेवल पर कॉन्फ़िगरेशन की सुविधा का स्टेटस क्या है? | हमने इवेंट लेवल पर कॉन्फ़िगरेशन में बदलाव करने के बारे में दस्तावेज़ शेयर किया है. यह सुविधा अब भी प्रस्ताव के चरण में है. हम इस बारे में ज़्यादा सुझाव, राय या शिकायतें चाहते हैं कि यह सुविधा, YouTube के लिए कितनी काम की होगी. |
| इवेंट-लेवल के लिए ज़रूरत के मुताबिक कॉन्फ़िगरेशन | अलग-अलग पक्षों की विरोधी रिपोर्ट को कैसे मिलाया जा सकता है? | ज़्यादातर रिपोर्टिंग स्थितियों को एग्रीगेट रिपोर्ट का इस्तेमाल करके हल किया जाता है. वहीं, इवेंट-लेवल कॉन्फ़िगरेशन का सुझाव, खास तौर पर इवेंट-लेवल रिपोर्ट के लिए ज़्यादा सुविधाओं के लिए है. इवेंट-लेवल रिपोर्ट का इस्तेमाल, ज़्यादातर ऑप्टिमाइज़ेशन के उदाहरणों के लिए किया जाता है. इस स्थिति के बारे में, नेटवर्क से जुड़ी किसी भी टिप्पणी या सुझाव का हम स्वागत करते हैं. |
| सोर्स का रजिस्ट्रेशन | अगर सोर्स रजिस्टर करने के बाद ट्रिगर रजिस्टर किया जाता है, तो क्या होगा? | फ़िलहाल, अगर ट्रिगर रजिस्ट्रेशन के बाद सोर्स रजिस्ट्रेशन होता है, तो सोर्स और ट्रिगर को एक-दूसरे को एट्रिब्यूट नहीं किया जा सकेगा. ऐसा लगता है कि यह कभी-कभी होने वाली स्थिति है. इस समस्या के बारे में हमें कोई भी सुझाव, राय या शिकायत भेजें. अगर यह समस्या कई विज्ञापन टेक्नोलॉजी विशेषज्ञों को आ रही है, तो हम इसे ठीक करने की कोशिश करेंगे. |
| कई विज्ञापन एजेंसियों के साथ काम करना | जब विज्ञापन देने वाला व्यक्ति या कंपनी कई विज्ञापन एजेंसियों के साथ काम कर रही हो, तो डीएसपी, Attribution Reporting API का इस्तेमाल कैसे कर सकते हैं? | एपीआई, रीडायरेक्ट के साथ काम करता है. इसलिए, इसका इस्तेमाल तब भी किया जा सकता है, जब विज्ञापन देने वाला व्यक्ति या कंपनी एक से ज़्यादा विज्ञापन एजेंसियों के साथ काम कर रही हो. इसके अलावा, रीडायरेक्ट करने से जुड़ी कुछ सीमाएं भी हैं. इनसे यह पक्का किया जाता है कि एपीआई, निजता को बेहतर बना रहा है. हमने उस खास स्थिति के लिए, Shared Storage API का इस्तेमाल करके समस्या हल करने का एक संभावित तरीका भी ढूंढ लिया है जिसकी वजह से विज्ञापन टेक्नोलॉजी से जुड़ी समस्या आ रही है. इस स्थिति के बारे में हमें कोई और सुझाव, राय या शिकायत भेजें. हम उस सुझाव, राय या शिकायत के आधार पर सुधार करते रहेंगे. |
| डेस्टिनेशन की सीमाएं | डेस्टिनेशन की सीमाओं की वजह से, अपने-आप रीफ़्रेश होने वाले विज्ञापनों के इस्तेमाल के उदाहरण पर असर पड़ सकता है. | हमने 1 मई को हुई WICG की मीटिंग में इस समस्या के बारे में बात की थी. साथ ही, हम इस बारे में सुझाव, राय या टिप्पणियां चाहते हैं कि इसकी सही सीमा क्या होनी चाहिए. हमने इवेंट-लेवल की रिपोर्ट के साथ एट्रिब्यूशन रिपोर्टिंग की जानकारी में यह जानकारी जोड़ी है कि ब्राउज़र, सोर्स-साइटों से दिखाए गए `डेस्टिनेशन` eTLD+1 की संख्या को सीमित कर सकता है. (पुल का अनुरोध देखें). |
| एट्रिब्यूशन रिपोर्टिंग और Protected Audience | Attribution Reporting API और Protected 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 के स्टैबल 115 वर्शन से, हम Chrome के कुछ उपयोगकर्ताओं के लिए, काम के कॉन्टेंट और मेज़रमेंट एपीआई को डिफ़ॉल्ट रूप से चालू करना शुरू करेंगे. संभावित समस्याओं पर नज़र रखने के दौरान, इस सुविधा को ज़्यादा से ज़्यादा लोगों के लिए उपलब्ध कराया जाएगा. हमारा लक्ष्य है कि 2023 की तीसरी तिमाही तक, यह सुविधा 100% उपलब्ध हो जाए. यह बदलाव, काम के विज्ञापन दिखाने और मेज़रमेंट के लिए ऑरिजिन ट्रायल के खत्म होने के साथ ही होगा. जुलाई से, टेस्टर इन एपीआई को सामान्य तौर पर ऐक्सेस करने के लिए रजिस्टर कर पाएंगे. इससे, ऑरिजिन ट्रायल की उपलब्धता और रजिस्टर करने के बाद सामान्य तौर पर उपलब्ध होने की अवधि में ओवरलैप होगा. आपका ऑरिजिन ट्रायल टोकन 19 सितंबर तक मान्य रहेगा. हालांकि, हमारा सुझाव है कि आप समयसीमा खत्म होने से पहले एपीआई के लिए रजिस्टर कर लें, ताकि किसी भी टेस्ट में रुकावट आए बिना, ऑरिजिन ट्रायल से आसानी से बाहर निकला जा सके. इस सूचना में बताया गया है कि अपडेट के बाद, पुराने वर्शन (M113 और उससे पहले के वर्शन) से रजिस्टर किया गया डेटा माइग्रेट नहीं किया जाएगा. इसलिए, हो सकता है कि डेटा मिट जाए. यह डेटा लॉस, डीबग रिपोर्टिंग में नहीं दिखेगा. साथ ही, हम 114 से 115 के बीच डेटा लॉस से बचने की कोशिश करेंगे. |
| बिलिंग | हर कन्वर्ज़न की लागत के हिसाब से बिलिंग के लिए, एट्रिब्यूशन रिपोर्टिंग का इस्तेमाल करना | इस लेख में बताया गया है कि हो सकता है कि एट्रिब्यूशन रिपोर्टिंग एपीआई, हर कन्वर्ज़न की लागत के हिसाब से बिलिंग की ज़रूरतों के लिए सही न हो. इसकी वजह यह है कि इवेंट-लेवल और खास जानकारी वाली रिपोर्ट में ग़ैर-ज़रूरी डेटा जोड़ा जाता है. हम एकोसिस्टम के प्लेयर को GitHub पर, Attribution Reporting API के अलग-अलग बिलिंग मॉडल पर पड़ने वाले असर के बारे में सुझाव, शिकायत या राय देने के लिए कहते हैं. |
एग्रीगेशन सेवा
| सुझाव, शिकायत या राय की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| एग्रीगेट की जा सकने वाली रिपोर्ट में देरी से जुड़ा बदलाव | एग्रीगेट की जा सकने वाली रिपोर्ट में देरी को [10-60 मिनट] से [0-10 मिनट] में बदलने के प्रस्ताव पर सकारात्मक प्रतिक्रियाएं मिली हैं. यह बदलाव, नेटवर्क से मिले सुझावों के आधार पर किया गया है | हमें यह देखकर खुशी हो रही है कि प्रस्तावित बदलाव पर लोगों की प्रतिक्रिया अच्छी है. साथ ही, हम नेटवर्क के लोगों को हमारे प्रस्तावों के बारे में सुझाव, राय या शिकायत देने के लिए बढ़ावा देते हैं. |
| ऑन-प्राइमिस सलूशन | क्या एग्रीगेशन सेवा को ऑन-प्राइमिस डेटा सेंटर में डिप्लॉय किया जा सकता है? | हम क्लाउड-आधारित समाधानों के अलावा, अन्य संभावित विकल्पों को भी एक्सप्लोर कर रहे हैं. हालांकि, फ़िलहाल ऑन-प्राइमिस टीईई का इस्तेमाल नहीं किया जा सकता. इसकी वजह यह है कि ऑन-प्राइमिस सुरक्षा की सीमाओं की वजह से, प्राइवसी सैंडबॉक्स के लिए आकलन में काफ़ी समय लगेगा. प्राइवेसी सैंडबॉक्स की सुरक्षा से जुड़ी ज़रूरी शर्तों और ऑन-प्राइमिस डिप्लॉयमेंट से जुड़ी चुनौतियों को देखते हुए, हमारा मानना है कि क्लाउड-आधारित डिप्लॉयमेंट (जैसे, AWS के साथ-साथ GCP के साथ काम करना) को बेहतर बनाना और उसका दायरा बढ़ाना, इकोसिस्टम के लिए सबसे ज़्यादा फ़ायदेमंद है. हालांकि, हम इस बारे में ज़्यादा सुझाव, राय या शिकायत का स्वागत करते हैं कि यह ज़रूरी शर्त क्यों है. |
| अलग-अलग समयावधि के लिए रिपोर्ट फिर से प्रोसेस करना | अलग-अलग समयावधि के लिए रिपोर्ट को फिर से प्रोसेस करने की सुविधा | हमें अलग-अलग तारीख की सीमाओं के लिए, बैच को अलग-अलग करने के लिए इसी तरह के अनुरोध मिले हैं. एक प्रस्ताव यह है कि शेयर किए गए आईडी को विज्ञापन टेक्नोलॉजी से तय किए गए लेबल के साथ बढ़ाने की अनुमति दी जाए, ताकि रिपोर्ट को अलग-अलग बैच में बांटा जा सके. हम इस प्रोसेस का आकलन करने की शुरुआती प्रक्रिया में हैं. इस प्रस्ताव के आगे बढ़ने पर, हम इस बारे में आपको अपडेट देते रहेंगे. |
| ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट की निजता से जुड़ी शर्तें | ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट की मदद से निजता को सुरक्षित रखने के बारे में सकारात्मक राय | हमें यह जानकर खुशी हो रही है कि हमारे प्रस्तावों को, नेटवर्क के लोगों ने सकारात्मक प्रतिक्रियाएं दी हैं. हम इस सुविधा को बेहतर बनाने के लिए लगातार काम कर रहे हैं. इसलिए, अगर आपके पास कोई सुझाव, राय या शिकायत है, तो हमें बताएं. |
| सेवा की शर्तें | एग्रीगेशन सेवा की शर्तों को स्वीकार करने की समयसीमा क्या है? | हमने अभी तक नियम और शर्तों को स्वीकार करने की समयसीमा तय नहीं की है. हालांकि, हमारा सुझाव है कि इकोसिस्टम की कंपनियां, नियम और शर्तों को जल्द से जल्द स्वीकार कर लें, ताकि रजिस्टर करने में देरी न हो. अगर कंपनियों को कोई सवाल पूछना है, तो हम उनसे अनुरोध करते हैं कि वे हमसे संपर्क करें. |
| मुख्य डिस्कवरी | मुख्य खोज की सुविधा की मदद से, टेस्टर, संभावित की-कॉम्बिनेशन की सूची के बिना, एग्रीगेट रिपोर्ट क्वेरी कर पाएंगे. इससे, क्रॉस-नेटवर्क एट्रिब्यूशन की खास जानकारी वाली रिपोर्ट को प्रोसेस करके, परफ़ॉर्मेंस को बेहतर और सटीक बनाया जा सकेगा. | फ़िलहाल, हम इस समस्या को हल करने के लिए काम कर रहे हैं. साथ ही, हम इस बारे में अपने पार्टनर से सुझाव, राय या शिकायतें भी स्वीकार करते हैं. |
Private Aggregation API
| सुझाव, शिकायत या राय की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| शिकायत करने का सोर्स | रिपोर्टिंग के ऑरिजिन को कैसे तय किया जाता है? | रिपोर्टिंग का ऑरिजिन हमेशा निजी एग्रीगेशन कॉलर की स्क्रिप्ट का ऑरिजिन होता है. |
| 128 बिट की कुंजी | 128-बिट पासकोड के लिए स्पेस की सीमा के बारे में साफ़ तौर पर जानकारी | हम इस कीस्पेस की सीमा को ज़्यादा साफ़ तौर पर बताएंगे और सभी पेजों पर मौजूद अंतर को ठीक करेंगे. हमारा सुझाव है कि इस कीस्पेस में बने रहने के लिए, हैश करने की रणनीतियों का इस्तेमाल करें. |
| हर रिपोर्ट में ज़्यादा से ज़्यादा योगदान | हर रिपोर्ट में 20 योगदान की मौजूदा सीमा बहुत कम है. | हम योगदान की तय सीमा बढ़ाने के बजाय, रिपोर्ट को अलग-अलग हिस्सों में बांटने पर विचार कर सकते हैं. इस प्रस्ताव के आगे बढ़ने के साथ-साथ, हम नेटवर्क से जुड़े लोगों की मदद लेंगे. |
| पहुंच की रिपोर्टिंग | रीच की क्रॉस-प्लैटफ़ॉर्म/क्रॉस-डिवाइस रिपोर्टिंग के लिए अनुरोध करें. रीच, ब्रैंड विज्ञापन की बुनियादी मेट्रिक है. विज्ञापन देने वाले लोग या कंपनियां, अपने कैंपेन का विश्लेषण करने और खर्च का बंटवारा करने के लिए, रीच और फ़्रीक्वेंसी रिपोर्टिंग के लिए क्रॉस-प्लैटफ़ॉर्म/क्रॉस-डिवाइस के अनुमान पर भरोसा करती हैं. रीच मॉडल, तीसरे पक्ष के एनवायरमेंट में दिखाए जाने वाले विज्ञापनों को मेज़र करने के लिए, तीसरे पक्ष की कुकी का इस्तेमाल सिग्नल के तौर पर करते हैं. इसलिए, तीसरे पक्ष की कुकी के बंद होने के बाद, विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली कंपनियों ने किसी अन्य समाधान का अनुरोध किया है. |
Privacy Sandbox की टीम, तीसरे पक्ष की कुकी के बंद होने के बाद, क्रॉस-डोमेन रीच के तरीकों के साथ काम करने वाली सुविधाओं पर काम कर रही है. हमारे पास इस बारे में और सुझाव, शिकायत या राय भेजने के लिए, हमारे ईमेल पते पर संपर्क करें. |
गुप्त ट्रैकिंग को सीमित करना
यूज़र-एजेंट रिडक्शन/यूज़र-एजेंट क्लाइंट हिंट
| सुझाव, शिकायत या राय की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| (इसके बारे में साल 2023 की पहली तिमाही में भी बताया गया था) डिवाइस के साइज़, डाइमेंशन या कॉन्फ़िगरेशन के हिसाब से अन्य फ़ॉर्म फ़ैक्टर के लिए सलाह | टीवी, वीआर जैसे अन्य डिवाइसों के साइज़, डाइमेंशन या कॉन्फ़िगरेशन के बारे में जानकारी देने के लिए, उपयोगकर्ता एजेंट क्लाइंट हिंट (UA-CH) का अनुरोध करना | हम डिज़ाइन से जुड़े कुछ अहम फ़ैसले लेने पर अब भी काम कर रहे हैं. जैसे, "टीवी" जैसी एक वैल्यू देना या फ़ॉर्म-फ़ैक्टर की सुविधाओं की सूची देना. हालांकि, हम इस आइडिया का प्रोटोटाइप बनाने में दिलचस्पी बनाए रखेंगे. |
| प्राइवसी बजट | निजता बजट की पाबंदियों की वजह से, बहुत ज़्यादा अनुरोध भेजने पर UA-CH अनुरोधों के नतीजे तय नहीं किए जा सकते. | फ़िलहाल, हमारे पास निजता बजट के प्रस्ताव के बारे में कोई नया अपडेट नहीं है. हालांकि, हमने तीसरे पक्ष की कुकी के बंद होने से पहले, UA क्लाइंट के हिंट के अनुरोधों पर पाबंदी नहीं लगाने का वादा किया है. |
| साइट के साथ काम करने की सुविधा | वेबसाइटें UA-CH ब्रैंड का इस्तेमाल करके, कुछ ब्राउज़र को साइटों को ऐक्सेस करने से रोक रही हैं. | ब्रैंड की सूची बनाने के कई मान्य उदाहरण हैं. इनमें से एक उदाहरण, ऐप्लिकेशन के साथ काम करने वाले ब्रैंड की जानकारी देना है. इन समस्याओं को हल करने के लिए, UA के पास कई ब्रैंड का इस्तेमाल करने का विकल्प होता है. |
आईपी प्रोटेक्शन (पहले इसे Gnatcatcher कहा जाता था)
| सुझाव, शिकायत या राय की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| धोखाधड़ी और गलत इस्तेमाल | कंपनियां, आईपी पते की सुरक्षा की सुविधा की मदद से धोखाधड़ी से जुड़े उपाय कैसे सेट अप कर सकती हैं? | हम धोखाधड़ी रोकने के लिए इस्तेमाल किए जाने वाले उदाहरणों की अहमियत और उन पर पड़ने वाले संभावित असर को समझते हैं. हम इस गर्मी के आखिर में, धोखाधड़ी रोकने में मदद करने के बारे में ज़्यादा जानकारी पब्लिश करेंगे. हम इकोसिस्टम से सुझाव, शिकायत या राय मांग रहे हैं, ताकि हम धोखाधड़ी रोकने के लिए इस्तेमाल किए जाने वाले उदाहरणों को बेहतर तरीके से इस्तेमाल कर सकें. |
| GeoIP | जियोआईपी की टेस्टिंग और डिप्लॉयमेंट टाइमलाइन के बारे में ज़्यादा जानकारी | Chrome ने हाल ही में, जियोआईपी के लिए बनाए गए हमारे प्लान के बारे में नई जानकारी पब्लिश की है. हम तीसरी तिमाही में, इसे लागू करने की समयावधि के बारे में ज़्यादा जानकारी पब्लिश करने वाले हैं. हम उम्मीद करते हैं कि शुरुआत में, हम आईपी प्रोटेक्शन को उपयोगकर्ता के ऑप्ट-इन की सुविधा के तौर पर लॉन्च करेंगे. यह सुविधा, ट्रैफ़िक के कुछ प्रतिशत हिस्से पर उपलब्ध होगी. इसकी वजह यह है कि हम समझते हैं कि इस प्रस्ताव में कंपनियों के लिए कुछ अहम बदलाव हो सकते हैं. इसलिए, हम चाहते हैं कि इस सुविधा को बड़े पैमाने पर रोल आउट करने से पहले, नेटवर्क को अडजस्ट होने और सुझाव देने का समय दिया जाए. |
| खाता प्रमाणीकरण | प्रॉक्सी सर्वर की मदद से खाते की पुष्टि कैसे होगी? | हम इस गर्मी के आखिर में, खाते की पुष्टि करने के बारे में ज़्यादा जानकारी पब्लिश करेंगे. हालांकि, हमने पहले ही कुछ शुरुआती बातें शेयर कर दी हैं. |
बाउंस ट्रैकिंग को कम करने की सुविधा
| सुझाव, शिकायत या राय की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| जांच से जुड़े दिशा-निर्देश | बाउंस ट्रैकिंग को कम करने की सुविधा की जांच करने के तरीके के बारे में जानकारी | हमने मई में एक ब्लॉग पोस्ट पब्लिश की थी. इसमें, बाउंस ट्रैकिंग को कम करने की सुविधा की जांच करने के तरीके के बारे में ज़्यादा जानकारी दी गई थी. |
| दस्तावेज़ | बाउंस ट्रैकिंग के प्रस्ताव में साफ़ तौर पर जानकारी दी गई हो | मौजूदा प्रस्ताव पर अब भी काम जारी है. Chrome, इस प्रस्ताव को अपडेट करता रहेगा, ताकि ईकोसिस्टम को साफ़ तौर पर जानकारी दी जा सके. हम इस बारे में ज़्यादा जानकारी देने पर काम कर रहे हैं. अगर आपके पास कोई सुझाव या राय है, तो हमें ज़रूर बताएं. |
| कुकी मिटाना | क्या बाउंस ट्रैकिंग को कम करने की सुविधा, किसी डोमेन में मौजूद सभी कुकी मिटा देगी? | बाउंस ट्रैकिंग को कम करने की सुविधा (बीटीएम), जैसा कि यहां बताया गया है, सभी स्टोरेज और कैश मेमोरी को मिटा देगी. |
| बाउंस ट्रैकिंग की क्षमता को कंट्रोल करने की सुविधा को गच्चा देना | पॉप-अप या नए टैब के ज़रिए रीडायरेक्ट करके, बाउंस ट्रैकर का क्लासिफ़िकेशन बायपास किया जा सकता है. | बाउंस ट्रैकिंग मिटिगेशन की खास जानकारी पर अब भी काम चल रहा है. फ़िलहाल, हमने ज़्यादातर ध्यान एक ही टैब में रीडायरेक्ट करने पर लगाया है. हालांकि, आने वाले समय में हम पॉप-अप फ़्लो पर काम करेंगे. अन्य सुझाव/राय/शिकायत यहां भेजें. |
प्राइवसी बजट
| सुझाव, शिकायत या राय की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| समीपवर्ती लक्ष्यीकरण | निजता बजट से, आस-पास मौजूद लोगों को टारगेट करने के उदाहरणों पर असर पड़ सकता है. | हमें इस समस्या के बारे में सुझाव, राय या शिकायत मिली है. हमें इस बारे में ज़्यादा जानना है कि इस समस्या का नेटवर्क पर क्या असर पड़ सकता है. |
अलग-अलग साइटों पर निजता की सीमाओं को बेहतर बनाना
पहले पक्ष के सेट
| सुझाव, शिकायत या राय की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| (पिछली तिमाहियों में भी रिपोर्ट की गई) डोमेन की सीमा | खाते से जुड़े डोमेन की संख्या बढ़ाने का अनुरोध करना | Chrome, असोसिएट किए गए सबसेट के लिए, संख्या की सही सीमा का आकलन कर रहा है. इससे, पहचाने गए इस्तेमाल के उदाहरणों के लिए निजता और उपयोगिता को संतुलित किया जा सकेगा. शुरुआत से ही, Chrome ने बताया था कि असोसिएट किए गए सबसेट की सटीक संख्या तय नहीं हुई है. |
| एम्बेड किए गए कॉन्टेंट के इस्तेमाल का उदाहरण | एम्बेड किए गए इस्तेमाल के उदाहरणों के लिए सहायता, जिनमें पहले पक्ष के सेट, सीएचआईपी, और शेयर किए गए स्टोरेज की ज़रूरत होती है | Chrome को इस इस्तेमाल के उदाहरण के बारे में सुझाव/राय/शिकायत मिली है. हमारी टीम इसकी जांच कर रही है. साथ ही, ज़्यादा सुझाव/राय/शिकायत का स्वागत करती है. |
| डेटा स्टोर करने की जगह मैनेज करना | GitHub के डेटा स्टोर से फ़र्स्ट-पार्टी सेट हटाने से जुड़ी नीतियों के बारे में जानकारी. ऐसा तब किया जाता है, जब सेट में अंतर या लापरवाही मिलती है | Chrome को इस इस्तेमाल के उदाहरण के बारे में सुझाव मिल गया है. हमारी टीम इसकी जांच कर रही है. साथ ही, अन्य सुझाव, शिकायत या राय देने के लिए हम आपका स्वागत करते हैं. |
| उपयोगकर्ता को जानकारी देना | Chrome को उपयोगकर्ताओं की जागरूकता बढ़ानी चाहिए और पहले पक्ष के सेट के बारे में उनकी समझ को बेहतर बनाना चाहिए, ताकि इस सुविधा को ज़्यादा से ज़्यादा लोग अपना सकें. | Chrome, उपयोगकर्ताओं को फ़र्स्ट-पार्टी सेट के बारे में जानकारी देने के लिए प्रतिबद्ध है. इस बारे में ज़्यादा जानने के लिए, Chrome के यूज़र इंटरफ़ेस से लिंक किया गया सहायता केंद्र का लेख पढ़ें. Chrome, उपयोगकर्ताओं को सही संदर्भ में सबसे अच्छी जानकारी देने के तरीके को लगातार बेहतर बनाने की कोशिश कर रहा है. |
| Post 3PCD | तीसरे पक्ष की कुकी के इस्तेमाल पर रोक लगने के बाद भी, वे पहले पक्ष के सेट में मौजूद रहेंगी. | requestStorageAccess और requestStorageAccessFor, तीसरे पक्ष की कुकी को खास और साफ़ तौर पर बताए गए इस्तेमाल के उदाहरणों के लिए फिर से उपलब्ध कराते हैं. हालांकि, अब उन्हें साइट के ऐक्टिव इनवोकेशन की ज़रूरत होती है. यह Chrome में तीसरे पक्ष की कुकी की मौजूदा स्थिति की तरह, डिफ़ॉल्ट रूप से उपलब्ध नहीं होता.एक ही सेट में इस तरीके से अनुरोध करने के लिए, उपयोगकर्ता की अनुमति की ज़रूरत नहीं होगी. हालांकि, उपयोगकर्ता सेटिंग में जाकर, इस सुविधा से ऑप्ट-आउट कर सकते हैं. ज़्यादा जानकारी के लिए, सहायता केंद्र का लेख पढ़ें. यह लेख, Chrome के यूज़र इंटरफ़ेस से लिंक किया गया है. फ़्रेम रेट को 100% तक बढ़ाने के बाद, हम मौजूदा डेवलपर गाइड को और बेहतर बनाने की योजना बना रहे हैं. |
| पहले पक्ष के सेट सबमिट करना | .json एक्सटेंशन शामिल करने के लिए, ज़रूरी .well-known/first-party-set का नाम बदलें. |
हमने यह बदलाव इसलिए किया है, ताकि यह पक्का किया जा सके कि कुछ वेब होस्टिंग प्लान काम करते हों. |
| आईएएनए रजिस्ट्रेशन | first_party_sets.JSON को आईएएनए के साथ रजिस्टर किया जाना चाहिए |
हम इस प्रस्ताव पर विचार कर रहे हैं. साथ ही, यहां और सुझाव/राय/शिकायत भेजने का स्वागत है. |
Fenced Frames API
| सुझाव, शिकायत या राय की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| विज्ञापन ब्लॉकिंग | फ़ेंस किए गए फ़्रेम की मदद से, विज्ञापन रोकने वाले एक्सटेंशन आसानी से विज्ञापनों को ब्लॉक कर सकते हैं. | एक्सटेंशन, फ़ेंस्ड फ़्रेम के साथ उसी तरह इंटरैक्ट कर सकते हैं जिस तरह वे iframe के साथ इंटरैक्ट करते हैं. फ़ेंस किए गए फ़्रेम को जिस असली यूआरएल पर नेविगेट किया जा रहा है वह एक्सटेंशन को भी दिखेगा. इसलिए, वे यूआरएल से मैच करने वाले नियमों को ब्लॉक करने के लिए लागू कर सकते हैं, जैसे कि वे iframes में करते हैं. बिना किसी शर्त के सभी फ़ेंस किए गए फ़्रेम को ब्लॉक करने से, फ़ेंस किए गए फ़्रेम के ऐसे इस्तेमाल के उदाहरणों पर असर पड़ सकता है जिनमें विज्ञापन नहीं दिखाए जाते. |
Shared Storage API
| सुझाव, शिकायत या राय की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| ज़्यादा से ज़्यादा लोगों का इस्तेमाल | शेयर किया गया स्टोरेज, पूरे इंडस्ट्री में एक स्टैंडर्ड होना चाहिए और सभी ब्राउज़र पर उपलब्ध होना चाहिए. | हमें आपका सुझाव मिला है. Chrome, W3C फ़ोरम में लगातार हिस्सा ले रहा है, ताकि इस प्रस्ताव को बढ़ावा दिया जा सके, सुझाव मांगे जा सकें, और इसे अपनाने के लिए बढ़ावा दिया जा सके. |
| आउटपुट गेट | शेयर किए गए स्टोरेज के आउटपुट गेट बहुत सीमित हैं. | हम इस सुझाव पर विचार कर रहे हैं. साथ ही, हम इस बारे में और सुझाव, राय या शिकायतें भी स्वीकार करते हैं कि आउटपुट गेट बहुत सीमित क्यों हैं. |
| नियामक अनुपालन | शेयर किया गया स्टोरेज, डेटा के रखरखाव की नीतियों जैसे नियमों का पालन कैसे करेगा? | शेयर किए गए स्टोरेज की मदद से, सेव किए गए किसी भी डेटा के लाइफ़टाइम और उसकी समयसीमा को कंट्रोल करने के लिए, लॉजिक को लागू और पसंद के मुताबिक बनाया जा सकता है. विज्ञापन टेक्नोलॉजी विशेषज्ञ, डेटा को लिखने के टाइमस्टैंप के आधार पर, शेयर किए गए स्टोरेज का डेटा अपडेट या मिटा सकते हैं. |
| A/B टेस्टिंग | Shared Storage और Protected Audience API के लिए A/B टेस्टिंग कैसे की जा सकती है? | हम इस मामले के बारे में ज़्यादा दिशा-निर्देश पब्लिश करने पर काम कर रहे हैं. आने वाले समय में, हम इस बारे में ज़्यादा जानकारी शेयर करेंगे. |
| शेयर किए गए स्टोरेज की सीमा | शेयर किए गए स्टोरेज की सीमा पूरी होने पर क्या होगा? | सीमा पूरी होने पर, कोई और इनपुट सेव नहीं किया जाएगा. |
| एक ही पेज लोड पर कई ऐक्सेस | एक ही पेज लोड होने पर, शेयर किए गए स्टोरेज को कई बार ऐक्सेस करने पर क्या होता है? | इस समस्या को हल करने का सबसे अच्छा तरीका, window.sharedStorage.append(key, value) फ़ंक्शन का इस्तेमाल करना है. हर विज्ञापन की वैल्यू अपडेट करने के बजाय, जो कई विज्ञापनों के होने पर गड़बड़ी पैदा कर सकता है. जोड़ने वाला फ़ंक्शन, नई वैल्यू को मौजूदा वैल्यू के आखिर में जोड़ देगा. |
| iframe की सुविधाएं | क्या तीसरे पक्ष की कुकी के बंद होने के बाद, शेयर किए गए स्टोरेज में कुछ iframe फ़ंक्शन काम करेंगे? | तीसरे पक्ष की कुकी के इस्तेमाल पर रोक लगने के बाद, iframes में मौजूद लोकल स्टोरेज को टॉप-लेवल साइट के हिसाब से बांटा जाएगा. हालांकि, iframes को ब्लॉक नहीं किया जाएगा. iframe के लोकल स्टोरेज में मौजूद डेटा को कई टॉप लेवल साइटों पर कॉपी नहीं किया जा सकता. हालांकि, iframe में अब भी लोकल स्टोरेज का इस्तेमाल किया जा सकता है. |
CHIPs
| सुझाव, शिकायत या राय की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| पार्टीशन की सीमा | हर सेगमेंट वाली साइट के लिए 10 कि॰ब॰, अब भी काफ़ी है. हमें इसे कम करना है. | Firefox ने पहले ही CHIPS पर पॉज़िटिव पोज़िशन का एलान कर दिया है. Webkit से जुड़ी सहायता पाने के लिए, हम डेवलपर को सीधे Apple को सुझाव/राय देने का सुझाव देते हैं. इसके लिए, GitHub पर इस समस्या के बारे में बताएं. यह समस्या उन इस्तेमाल के उदाहरणों से जुड़ी है जहां स्टोरेज को अलग-अलग हिस्सों में बांटने के बजाय, कुकी को अलग-अलग हिस्सों में बांटना बेहतर होता है. |
| पुष्टि किए गए एम्बेड | अलग-अलग पार्टिशन की वजह से पुष्टि किए गए एम्बेड पर असर पड़ने की वजह से, सीएचआईपी का मौजूदा एसएसओ साइन-इन फ़्लो पर असर पड़ सकता है. | हम पुष्टि किए गए एम्बेड के इस्तेमाल के उदाहरण के लिए, Storage Access API का फ़ायदा उठाना चाहते हैं. इसके लिए, हमने हाल ही में प्रॉटोटाइप बनाने का अनुरोध भेजा है. |
| लाइफ़टाइम नीतियां | क्या लाइफ़टाइम की संभावित नीतियां, पहले पक्ष की कुकी पर लागू होंगी? | फ़िलहाल, हमारे पास पहले-पक्ष की कुकी के लाइफ़टाइम की सीमाएं लागू करने का कोई प्लान नहीं है. |
FedCM
| सुझाव, शिकायत या राय की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| OAuth अनुमति से जुड़ी सहायता | प्रोफ़ाइल के अलावा अन्य OAuth स्कोप को अनुमति देने के लिए अलाइन करना | हम W3C FedID CG के ज़रिए, वेब आइडेंटिटी कम्यूनिटी से इनपुट ले रहे हैं. इससे हमें तीसरे पक्ष की कुकी के बंद होने के बाद, बुनियादी पुष्टि के अलावा अनुमति देने के सबसे सही तरीकों के बारे में पता चलेगा. |
| एसएएमएल के लिए सहायता | SAML सहायता की ज़रूरी शर्तों के मुताबिक होना | तीसरे पक्ष की कुकी बंद होने के बाद, टीम रिसर्च और शिक्षा कम्यूनिटी से एसएएमएल सहायता की ज़रूरतों के बारे में इनपुट ले रही है. इसमें OpenID-connect सहायता के अलावा, अन्य चीज़ें भी शामिल हैं. |
स्पैम और धोखाधड़ी को रोकना
Private State Token API (और अन्य एपीआई)
| सुझाव, शिकायत या राय की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| नए सिग्नल एक्सप्लोर करना | कई पार्टनर ने डिवाइस के भरोसेमंद होने या उपयोगकर्ता के भरोसे से जुड़े, ब्राउज़र की मदद से मिलने वाले सिग्नल को एक्सप्लोर करने के लिए सकारात्मक भावनाएं दिखाई हैं. आम तौर पर, वे इस बात को लेकर भी सावधान रहते हैं कि धोखाधड़ी का पता लगाने के लिए, खास मकसद से बनाए गए नए सिग्नल काफ़ी हैं या नहीं. | हमें धोखाधड़ी और वेब सुरक्षा समुदाय के साथ मिलकर नए प्रस्तावों को एक्सप्लोर करने में खुशी हो रही है. साथ ही, हम उनकी समस्याओं को समझते हैं और उनसे जुड़ी जानकारी शेयर करते हैं. यही वजह है कि "स्पैम और धोखाधड़ी से लड़ना", Privacy Sandbox की मुख्य स्ट्रीम है. साथ ही, हम उपयोगकर्ता की निजता को बेहतर बनाने के साथ-साथ, वेब की सुरक्षा को बनाए रखने में निवेश को प्राथमिकता देते हैं. |
| पीएसटी के बारे में अच्छा सुझाव या राय | कई पार्टनर ने धोखाधड़ी रोकने या वेब सुरक्षा के अलग-अलग उदाहरणों के लिए, पीएसटी की जांच करने या उनका इस्तेमाल करने में दिलचस्पी दिखाई है. | हमें यह जानकर खुशी हुई कि आपको पीएसटी का इस्तेमाल करने वाले नए समाधानों के बारे में जानने में दिलचस्पी है. Chrome डेवलपर साइट पर, हमारे पास संसाधन और सैंपल कोड उपलब्ध हैं. साथ ही, हम आपके सुझाव, राय या शिकायतों का स्वागत करते हैं. |
| धोखाधड़ी और गलत इस्तेमाल | तीसरे पक्ष की कुकी के बंद होने के बाद, मेज़रमेंट में विज्ञापन धोखाधड़ी को रोकने / उसका पता लगाने के लिए दिशा-निर्देश. ऐसा तब किया जाता है, जब आइडेंटिफ़ायर उपलब्ध न हों. | हमने निजी स्टेटस टोकन जैसे टूल लॉन्च किए हैं. इनकी मदद से, धोखाधड़ी रोकने के लिए तीसरे पक्ष की कुकी की वजह से खोए हुए कुछ सिग्नल को वापस पाया जा सकता है. हालांकि, इसके लिए निजता से जुड़े नए कंट्रोल लागू किए गए हैं. हम धोखाधड़ी और गलत इस्तेमाल को रोकने के लिए, नए प्रस्तावों पर काम कर रहे हैं. इससे, Privacy Sandbox में किए गए अन्य बदलावों के साथ-साथ, इन सुविधाओं को बनाए रखा जा सकेगा. |
| जारी करने वाले बैंक और ऑरिजिन की जानकारी की दर | यूनीक उपयोगकर्ताओं की पहचान करने के लिए, जारी करने वाले बैंक से ऑरिजिन को मिलने वाली जानकारी का रेट ज़रूरत के मुताबिक होना चाहिए. | हमने स्पेसिफ़िकेशन को अपडेट किया है, ताकि यह साफ़ तौर पर बताया जा सके कि निजी स्टेटस टोकन का इस्तेमाल करके, उपयोगकर्ता का कौनसा डेटा शेयर किया जा सकता है. डिज़ाइन के हिसाब से, एक बार में ज़्यादा से ज़्यादा छह सार्वजनिक कुंजियों का इस्तेमाल किया जा सकता है. ये कुंजियां किसी उपयोगकर्ता की "स्थिति" दिखा सकती हैं. कुंजियों के इन सेट को सिर्फ़ हर 60 दिन में अपडेट किया जा सकता है. हालांकि, कुछ मामलों में कुंजियों को तुरंत बदलना ज़रूरी हो सकता है. ऐसे में, कुंजियों को तुरंत बदला जा सकता है. इससे, समय के साथ उपयोगकर्ता के अतिरिक्त डेटा को जोड़ने की संभावना कम हो जाती है. किसी भी नए वेब एपीआई के साथ, उपयोगकर्ता को दी जाने वाली सुविधा और नई जानकारी के बीच संतुलन बना रहता है. हमारा अनुमान है कि पीएसटी, उपयोगकर्ता की निजता को सुरक्षित रखने के साथ-साथ, धोखाधड़ी से जुड़े इस्तेमाल के मुख्य उदाहरणों को चालू करते हैं. इन उदाहरणों पर, तीसरे पक्ष की कुकी के बंद होने का असर पड़ा है. |
| फ़ेच इंटिग्रेशन | fetch इंटिग्रेशन मुश्किल और ज़रूरी नहीं है. |
fetch का इस्तेमाल करने के फ़ायदे और नुकसान हैं. हम वेब नेटवर्क के लिए, स्टैंडर्ड के तौर पर इसे इस्तेमाल करना चाहते हैं. हालांकि, जब तक हमें यह साफ़ तौर पर पता नहीं चल जाता कि स्टैंडर्ड कैसा होगा, तब तक यह बदलाव करना जल्दबाजी होगी. अगर कोई स्टैंडर्ड बनता है, तो हम वेब डेवलपर को उस स्टैंडर्ड के मुताबिक काम करने के लिए भी ज़िम्मेदारी से काम करेंगे. |
| स्टोरेज की जगह | प्राइवेट स्टेट टोकन की कुंजी के कॉन्फ़िगरेशन, PrivacyPass प्रोटोकॉल के साथ एक ही जगह पर सेव होने चाहिए. | ऑरिजिन ट्रायल के दौरान टेस्टिंग करते समय, डेवलपर ने बताया कि वे .well-known डायरेक्ट्री के बजाय, सामान्य यूआरएल पर अपनी कुंजियों को सेव करना पसंद करते हैं. PrivacyPass में कुंजी के लिए किए गए वादे का फ़ॉर्मैट, खास तौर पर उस वर्शन के लिए सही नहीं है जिसमें कुंजी सेट, "सार्वजनिक मेटाडेटा" की वैल्यू को लागू करने के लिए हैं. अगर PrivacyPass का कोई वैरिएंट, सार्वजनिक मेटाडेटा (POPRF, आंशिक आरएसए ब्लाइंडिंग या कीसेट के तौर पर) के साथ स्टैंडर्ड हो जाता है, तो हम उसे इस्तेमाल करने के लिए, आने वाले समय में PST के किसी नए वर्शन पर स्विच कर सकते हैं. |
| एपीआई का हेडर लागू करना | एपीआई के हेडर को लागू करने के बारे में सवाल | एपीआई के स्टैंडर्ड होने और इस एपीआई के इको सिस्टम के इस्तेमाल के बेहतर होने के बाद, हम उम्मीद करते हैं कि हम इस एपीआई के स्टैंडर्ड नॉन-हेडर वर्शन और हेडर वर्शन, दोनों के साथ काम कर पाएंगे. साथ ही, अगर हेडर वर्शन का इस्तेमाल बहुत कम होता है या अन्य डेटा के साथ रिडेंप्शन/इश्यू करने के अनुरोधों को जोड़ने के स्टैंडर्ड तरीकों के लिए डेवलपर टूल/सहायता काफ़ी है, तो हम हेडर वर्शन को बंद कर सकते हैं. हम समस्या के बारे में यहां चर्चा कर रहे हैं. |
| रजिस्ट्रेशन | क्या जारीकर्ताओं को ब्राउज़र वेंडर के साथ रजिस्टर करना व्यावहारिक है? | हमने प्राइवेट स्टेट टोकन जारी करने वाले के रजिस्ट्रेशन की प्रोसेस के बारे में बताने के लिए, स्पेसिफ़िकेशन को अपडेट किया है. यह प्रोसेस, Privacy Sandbox के बाकी कामों के लिए रजिस्टर करने के प्लान से मिलती-जुलती है. इसमें हम जारीकर्ताओं से सार्वजनिक तौर पर यह बताने के लिए कहते हैं कि वे पीएसटी का इस्तेमाल कैसे करना चाहते हैं. साथ ही, उपयोगकर्ता की निजता की सुरक्षा करने वाली तकनीकी पाबंदियों को स्वीकार करने के लिए भी कहते हैं. |