साल 2023 की दूसरी तिमाही की तिमाही रिपोर्ट, जिसमें प्राइवसी सैंडबॉक्स के प्रपोज़ल और Chrome से मिले जवाब के बारे में, नेटवर्क से मिले सुझावों की खास जानकारी दी गई है.
सीएमए को लेकर अपनी जवाबदेही के तहत, Google ने प्राइवसी सैंडबॉक्स के प्रपोज़ल के लिए, हिस्सेदार के जुड़ाव की प्रोसेस की तीन महीने में तीन रिपोर्ट सार्वजनिक तौर पर उपलब्ध कराने की सहमति दी है. कमीमेंट के पैराग्राफ़ 12 और 17(c)(ii) देखें. प्राइवसी सैंडबॉक्स से जुड़ी फ़ीडबैक की खास जानकारी वाली ये रिपोर्ट, अलग-अलग सोर्स से मिले सुझावों को इकट्ठा करके जनरेट की जाती हैं. इन सोर्स की जानकारी फ़ीडबैक खास जानकारी में दी गई है. इसमें इनके अलावा, और भी चीज़ें शामिल हो सकती हैं: GitHub समस्याएं, privacysandbox.com पर उपलब्ध कराए गए सुझाव फ़ॉर्म. Chrome, नेटवर्क से मिले सुझाव, शिकायत या राय का स्वागत करता है. साथ ही, वह डिज़ाइन से जुड़े फ़ैसलों में सीखने के तरीकों को शामिल करने के तरीके खोज रहा है.
सुझाव, शिकायत या राय की थीम, हर एपीआई की संख्या के हिसाब से रैंक की जाती हैं. इसके लिए, Chrome टीम को मिले सुझाव, शिकायत या राय को किसी तय थीम के आधार पर इकट्ठा करके और उन्हें घटते हुए क्रम में व्यवस्थित किया जाता है. फ़ीडबैक से जुड़ी सामान्य थीम की पहचान करने के लिए, हमने सार्वजनिक मीटिंग (W3C, PatCG, IETF), सीधे तौर पर सुझाव/शिकायत/राय, GitHub पर चर्चा के विषयों और Google की इंटरनल टीम और पब्लिक फ़ॉर्म की मदद से अक्सर पूछे जाने वाले सवालों की समीक्षा की.
खास तौर पर, वेब स्टैंडर्ड बॉडी मीटिंग के लिए तय किए गए समय की समीक्षा की गई और सीधे सुझाव के लिए, Google के 1:1 हिस्सेदारों की मीटिंग के रिकॉर्ड, अलग-अलग इंजीनियर को मिले ईमेल, एपीआई ईमेल पाने वाले लोगों की सूची, और लोगों के सुझाव देने वाले फ़ॉर्म पर विचार किया गया. इसके बाद, Google ने टीम के बीच इन अलग-अलग आउटरीच गतिविधियों को शामिल किया, ताकि यह पता लगाया जा सके कि हर एपीआई के बारे में उभर रही थीम की लोकप्रियता कितनी है.
फ़ीडबैक पर Chrome ने क्या जवाब दिए, यह जानने के लिए अक्सर पूछे जाने वाले सवालों, हिस्सेदारों की ओर से उठाए गए मुद्दों पर असल जवाब, और खास तौर पर सार्वजनिक रिपोर्टिंग की प्रोसेस के लिए एक स्थिति तय की गई है. डेवलपमेंट और टेस्ट को ध्यान में रखते हुए, हमें खास तौर पर Topics, Protected Audience, और Attribution Reporting API के बारे में सवाल और सुझाव मिले.
हो सकता है कि मौजूदा रिपोर्टिंग अवधि के खत्म होने के बाद मिलने वाले फ़ीडबैक को अभी तक Chrome के जवाब के तौर पर न माना जाए.
संक्षिप्त नाम की शब्दावली
- सीएचआईपीएस
- कुकी, इंडिपेंडेंट पार्टिशन्ड स्टेट है
- डीएसपी
- डिमांड-साइड प्लैटफ़ॉर्म
- FedCM
- फ़ेडरेटेड क्रेडेंशियल मैनेजमेंट
- FPS (फ़्रेम प्रति सेकंड)
- पहले पक्ष के सेट
- IAB
- इंटरैक्टिव विज्ञापन ब्यूरो
- आईडीपी
- पहचान देने वाली कंपनी
- आईईटीएफ़
- इंटरनेट इंजीनियरिंग टास्क फ़ोर्स
- IP
- इंटरनेट प्रोटोकॉल पता
- openRTB
- रीयल-टाइम बिडिंग
- OT
- ऑरिजिन ट्रायल
- PatCG
- प्राइवेट ऐडवर्टाइज़िंग टेक्नोलॉजी कम्यूनिटी ग्रुप
- RP
- भरोसेमंद पार्टी
- एसएसपी
- सप्लाई-साइड प्लैटफ़ॉर्म
- TEE
- भरोसेमंद तरीके से एक्ज़ीक्यूशन एनवायरमेंट
- UA
- उपयोगकर्ता एजेंट स्ट्रिंग
- UA-CH
- उपयोगकर्ता-एजेंट क्लाइंट हिंट
- W3C
- वर्ल्ड वाइड वेब कंसोर्टियम
- डब्ल्यूआईपीबी
- विलफ़ुल आईपी ब्लाइंडनेस
सामान्य सुझाव, किसी खास एपीआई/टेक्नोलॉजी के आधार पर नहीं
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| डेटा गवर्नेंस और नियमों का पालन | प्राइवसी सैंडबॉक्स के इस्तेमाल के लिए, ज़रूरी नियमों का पालन करने के लिए ईकोसिस्टम से जुड़े दिशा-निर्देश. | किसी भी नई टेक्नोलॉजी की तरह, हर कंपनी यह पक्का करने के लिए ज़िम्मेदार होती है कि प्राइवसी सैंडबॉक्स का इस्तेमाल कानून के मुताबिक हो. Google दूसरों को कानूनी सलाह नहीं दे सकता. हालांकि, हम जानते हैं कि यह नेटवर्क के लिए, दिलचस्पी वाला एक अहम विषय है. हर एपीआई के लिए, हमने बहुत सारे तकनीकी दस्तावेज़ पब्लिश किए हैं. इन दस्तावेज़ों से, आपको ज़रूरी कानूनी आकलन करने का मौका मिलेगा. साथ ही, हम कानूनी ज़रूरतों का पालन करने वाली कंपनियों की कोशिशों के लिए, अतिरिक्त कॉन्टेंट उपलब्ध कराने पर काम कर रहे हैं. |
| सीएमए क्वांटिटेटिव टेस्टिंग प्रस्ताव | सीएमए क्वांटिटेटिव टेस्टिंग प्रपोज़ल के बारे में ज़्यादा जानकारी | हम सीएमए के साथ मिलकर ऐसे एक्सपेरिमेंट डिज़ाइन कर रहे हैं जिनसे तीसरे पक्ष की कुकी के बंद होने और नेटवर्क पर प्राइवसी सैंडबॉक्स के प्रपोज़ल के लॉन्च होने की जानकारी मिलेगी. अप्रैल में, सीएमए ने इस बारे में ज़्यादा जानकारी पब्लिश की थी कि टेस्टिंग और ट्रायल के दौरान क्या उम्मीद की जा सकती है. इसके बाद, जून में ज़्यादा जानकारी के साथ दिशा-निर्देश पब्लिश किए गए. हम सीएमए के क्वांटिटेटिव टेस्टिंग प्रपोज़ल से जुड़े सवालों या सुझाव को सीधे सीएमए के साथ शेयर करने का सुझाव देते हैं. |
| Chrome की सुविधा वाले टेस्टिंग मोड | टेस्टिंग शेड्यूल के बारे में ज़्यादा जानकारी और साफ़ तौर पर जानकारी | हमने 18 मई को एक ब्लॉग पोस्ट पब्लिश की थी. इसमें, Chrome की सुविधा वाले टेस्टिंग के दो मोड के बारे में ज़्यादा जानकारी दी गई थी. यह पूरी जानकारी नहीं है. जैसे-जैसे हम 2023 की तीसरी तिमाही में इस सुविधा को लागू करेंगे, हम इस बारे में और दिशा-निर्देश पब्लिश करेंगे. |
| बांटा गया स्टोरेज | क्या Chrome की सुविधा वाले टेस्ट के दौरान, पार्टिशन किए गए स्टोरेज का इस्तेमाल किया जाएगा? | तीसरे पक्ष की कुकी के इस्तेमाल को रोकने के प्रयोग से पहले, स्टोरेज के पार्टीशन सभी उपयोगकर्ताओं को भेज दिए जाएंगे. इसलिए, यह प्रयोग के सभी ग्रुप के लिए चालू हो जाएगा. इस समयावधि के दौरान, इस्तेमाल न किए गए स्टोरेज को वापस पाने के लिए, साइटों के पास सुविधा को बंद करने का ट्रायल चालू करने का विकल्प होगा. |
| प्रोडक्शन में मदद | प्राइवसी सैंडबॉक्स से जुड़ी तकनीकी समस्याओं और नेटवर्क पर असर डालने वाली सूचना देने के लिए, Chrome क्या प्रोसेस करता है? | विज्ञापन टेक्नोलॉजी से जुड़ी कंपनियों को समस्याओं की शिकायत करने और उन्हें किसी भी तरह की सूचना देने के लिए, Google कई चैनल उपलब्ध कराता है. सार्वजनिक और निजी फ़ोरम पर ज़्यादा जानकारी पाने के लिए, कृपया हमारी डेवलपर पोस्ट देखें. इससे आपको सुझाव, शिकायत या राय मिलती रहेगी और हम समस्या को हल कर देंगे. |
| रजिस्ट्रेशन की टाइमलाइन | रजिस्ट्रेशन के लिए फ़िलहाल जो समयसीमा दी गई है वह बहुत कम है | हम अब भी नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) की समयसीमा तय कर रहे हैं. साथ ही, हम नेटवर्क से जानना चाहते हैं कि कौनसी समयावधि सबसे सही होगी. |
| डीयूएनएस नंबर | रजिस्ट्रेशन और प्रमाणित करने के लिए, D-U-N-S नंबर से जुड़ी ज़रूरी शर्तों के बारे में ज़्यादा जानकारी | डीयूएनएस नंबर पाने की ज़रूरी शर्तें, डेवलपर Dun & Bradstreet की वेबसाइट पर देख सकते हैं. शर्तें, बाज़ार के हिसाब से अलग-अलग होती हैं. इसलिए, हिस्सा लेने वाले लोगों को किसी खास बाज़ार में अपनी दिलचस्पी के बारे में जानने के लिए वेबसाइट देखना न भूलें. हालांकि, आम तौर पर, इस प्रोग्राम में हिस्सा लेने वाले लोगों को अपने कारोबार के बारे में बुनियादी जानकारी देनी होगी. जैसे, कारोबार का नाम, पता, और कारोबार के मालिक या मैनेजर की संपर्क जानकारी. हिस्सा लेने वाले लोगों से, कारोबार की सालाना आय जैसी वित्तीय जानकारी भी मांगी जा सकती है. आवेदन पूरा होने के बाद, D&B इसकी समीक्षा करेगा और अगर आवेदन स्वीकार हो जाता है, तो आपको डीयूएनएस नंबर जारी करेगा. |
| ऑरिजिन ट्रायल से सामान्य वर्शन पर अपग्रेड करना | क्या ऑरिजिन ट्रायल से सामान्य उपलब्धता पर ट्रांज़िशन का असर, मौजूदा ऑरिजिन ट्रायल के टेस्टर पर पड़ेगा? | जुलाई से, टेस्टर के पास काम का और मेज़रमेंट एपीआई ऐक्सेस करने का विकल्प होगा. हालांकि, यह ऐक्सेस सिर्फ़ उन एपीआई के इस्तेमाल के लिए उपलब्ध होगा जो सामान्य तौर पर उपलब्ध हैं. इससे ऑरिजिन ट्रायल की उपलब्धता और सामान्य उपलब्धता के बीच ओवरलैप होगा. |
| Ad Exchanger स्टडी | सर्वे के काम करने के तरीके के बारे में ज़्यादा जानकारी | सर्वे में जवाब देने वालों से उनके कारोबारों के लिए सिंक दरों और आय का अनुमान लगाने के लिए कहा गया. जवाब देने वाले लोगों ने अपने अलग-अलग सवालों के जवाब देने का तरीका खुद तय किया. |
| पैरामीटर के मान | गै़र-ज़रूरी डेटा का लेवल, पहचान छिपाने के थ्रेशोल्ड, और निजता बजट जैसी पैरामीटर वैल्यू को कैसे तय किया जाता है? | GitHub की इस जानकारी में, प्राइवसी सैंडबॉक्स एपीआई के सामान्य नियमों के बारे में बताया गया है. कई वैल्यू को अब भी फ़ाइनल किया जा रहा है. हम इस विषय पर आपके सुझाव, शिकायत या राय का स्वागत करते हैं. |
काम का कॉन्टेंट और विज्ञापन दिखाएं
विषय
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| निजता संरक्षण | निजता की सुरक्षा पर Topics API का आकलन करने से जुड़ा रिसर्च | हम रिसर्च कम्यूनिटी के साथ मिलकर काम करते हैं और Topics API के निजता से जुड़े विषयों पर रिसर्च को पेपर, रिपोर्ट, और वर्कशॉप प्रज़ेंटेशन में पेश करते हैं. हमें खुशी है कि रिसर्च कम्यूनिटी के ज़्यादा से ज़्यादा बाहरी सदस्य, इस क्षेत्र में हमारी मदद कर रहे हैं. Topics API, उपयोगकर्ताओं को वेब पर सामान्य ट्रैकिंग से बचाता है. ऐसा करने से, बड़े पैमाने पर उपयोगकर्ताओं को ट्रैक करना बहुत मुश्किल हो जाता है. इन पेपर से पता चलता है कि हम Topics API का इस्तेमाल करके ऐसा कर रहे हैं. यह तीसरे पक्ष की कुकी की तुलना में ज़्यादा निजी होती है. यह उपयोगकर्ताओं की पसंदीदा साइटों पर जाने में उनकी मदद करती है और उनकी सुरक्षा भी करती है. |
| विषयों की अलग-अलग कैटगरी, ज़रूरत के मुताबिक नहीं हैं | खास विषयों की कैटगरी में, ज़्यादा जानकारी देने वाले विषय शामिल नहीं होते. इनमें खास विषय भी शामिल हैं. | नेटवर्क से मिले पिछले सुझावों के जवाब में, हमने 15 जून को एक ब्लॉग पोस्ट पब्लिश की थी. इस पोस्ट में, अपडेट की गई नई कैटगरी के बारे में जानकारी दी गई थी. इसमें, नेटवर्क से मिले सुझावों के आधार पर, कई सुधारों को शामिल किया गया था. संशोधित टेक्सॉनमी पर अपने काम के हिस्से के रूप में, हमने Raptive (पहले CafeMedia) और Criteo जैसी कई कंपनियों के साथ काम किया है. संभावित रूप से संवेदनशील विषयों को बाहर रखने के अपने वादे को कायम रखने के साथ-साथ, अपडेट की गई टेक्सॉनमी उन कैटगरी को हटा देगी जिनके बारे में हमें लगता है कि वे कम काम की हैं. ऐसा इसलिए, क्योंकि हमने विज्ञापन देने वालों की रुचियों से बेहतर तरीके से मेल खाने वाली कैटगरी को ध्यान में रखा है. हमारा सुझाव है कि नेटवर्क की सबसे नई कैटगरी की समीक्षा करें और बदलावों के बारे में सुझाव, शिकायत या राय दें. |
| कैटगरी और कैटगरी अपडेट करने की प्रोसेस | विषयों की अलग-अलग कैटगरी और रिलीज़ की फ़्रीक्वेंसी के बारे में ज़्यादा जानकारी. साथ ही, यह भी जानें कि कंपनियां ऐसे अपडेट के लिए कैसे तैयारी कर सकती हैं. | जैसा कि हाल ही में ब्लॉग पोस्ट में शेयर किया गया था, हम उम्मीद करते हैं कि समय के साथ इस कैटगरी में बदलाव होगा. साथ ही, इस कैटगरी को मैनेज करने के लिए, किसी बाहरी पार्टी को चुना जाएगा, जो पूरी इंडस्ट्री के हिस्सेदारों का प्रतिनिधित्व करेगा. हमने topics-announce ग्रुप में रैंप-अप प्लान भी शेयर किया है. |
| पहले पक्ष के सिग्नल पर असर | हाल ही में हुई टेक्सॉनमी से जुड़े अपडेट में, विषयों की संख्या में हुई बढ़ोतरी बहुत अहम हो सकती है. इस वजह से, पहले पक्ष की दिलचस्पी के हिसाब से मिलने वाले अन्य सिग्नल में कमी हो सकती है. | साल 2023 की पहली तिमाही की रिपोर्ट में, सीएमए ने टिप्पणी की, "हम समझते हैं कि Google, विज्ञापन टेक्नोलॉजी की सप्लाई चेन से जुड़े कई बाज़ार में हिस्सा लेने वाले लोगों के साथ, अपने प्रस्तावित नई कैटगरी पर चर्चा कर रहा है. कुछ बड़े पब्लिशरों का कहना है कि विषयों का ज़्यादा इस्तेमाल करने से, पहले पक्ष (ग्राहक) के डेटा आधारित समाधानों पर प्रतिस्पर्धी दबाव बढ़ सकता है. हमारा शुरुआती मानना है कि कुल मिलाकर प्रतिस्पर्धा के लिए ज़्यादा फ़ायदा होना बेहतर है. खास तौर पर, तीसरे पक्ष की कुकी को बंद करने के बाद, छोटे पब्लिशर अपनी इन्वेंट्री से कमाई करना जारी रखें". हमारा मानना है कि CMA की इस टिप्पणी से मेल खाता है. |
| अलग-अलग तरह के हिस्सेदारों के लिए उपयोगिता | SSP और DSP के तौर पर काम करने वाली विज्ञापन टेक्नोलॉजी, नेटवर्क चलाने वाली दूसरी कंपनियों के मुकाबले ज़्यादा फ़ायदेमंद हो सकती हैं. | पिछली तिमाही के मुकाबले, हमारे जवाब में कोई बदलाव नहीं किया गया है: "Google ने प्राइवसी सैंडबॉक्स के प्रपोज़ल को इस तरह डिज़ाइन और लागू करने के लिए प्रतिबद्ध है कि खुद के कारोबार को प्राथमिकता देकर, प्रतिस्पर्धा को गलत न बताए. साथ ही, डिजिटल विज्ञापन और पब्लिशर और विज्ञापन देने वालों पर पड़ने वाले असर को भी ध्यान में रखा जाए, भले ही उनका साइज़ कुछ भी हो. हम यह पक्का करने के लिए सीएमए के साथ मिलकर काम करते रहते हैं कि हमारा काम इन प्रतिबद्धताओं का पालन करे. प्राइवसी सैंडबॉक्स की टेस्टिंग के दौरान, हम इस अहम सवाल का आकलन करेंगे कि अलग-अलग तरह के हिस्सेदारों के लिए नई टेक्नोलॉजी कैसा परफ़ॉर्म कर रही है. इस मामले में सुझाव बहुत ज़रूरी है. खास तौर पर ऐसा खास और कार्रवाई करने लायक सुझाव, शिकायत या राय हमारे तकनीकी डिज़ाइन को और बेहतर बनाने में हमारी मदद कर सकती है. हमने मात्रात्मक परीक्षण के लिए अपना तरीका विकसित करने के लिए CMA के साथ काम किया है. हम बाज़ार में हिस्सा लेने वालों को ज़्यादा जानकारी देने और सुझाए गए तरीकों पर टिप्पणी करने का अवसर देने के लिए प्रयोग के डिज़ाइन पर नोट प्रकाशित करने के लिए CMA के साथ काम करते हैं." |
| डिसेंडेंट विषय | विषय चुनने का मानदंड ब्राउज़र विज़िट की फ़्रीक्वेंसी है, इसलिए क्या सेगमेंट फ़्रैगमेंट करने से डिसेंडेंट विषय कभी सबसे ऊपर नहीं जाएंगे? | Chrome, फ़िलहाल रैंकिंग के दूसरे तरीकों का आकलन कर रहा है. साथ ही, ऐसे अन्य सिग्नल एक्सप्लोर कर रहा है जिनसे रैंकिंग बेहतर हो सकती है. हम तय समय में नेटवर्क में अपने अपडेट किए गए प्लान की जानकारी देंगे. |
| संवेदनशीलता | Topics API का लक्ष्य यह पक्का करना होना चाहिए कि Topics API से मिली या उससे मिली उपयोगकर्ता जानकारी, आज के ट्रैकिंग के तरीकों का इस्तेमाल करके हासिल की जा सकने वाली जानकारी की तुलना में कम संवेदनशील हो. | हमारा मानना है कि मौजूदा टेक्नोलॉजी की तुलना में Topics API काफ़ी निजी है. यह उपयोगकर्ताओं की पहचान से जुड़ी जानकारी को काफ़ी हद तक सीमित करता है. साथ ही, इसे संवेदनशील विषयों को बाहर रखने के लिए डिज़ाइन किया गया है. हम स्वीकार करते हैं कि संवेदनशील कैटगरी बनाने के लिए, पहले पक्ष (ग्राहक) के डेटा के साथ विषय जोड़े जा सकते हैं या उन्हें जोड़ा जा सकता है. हालांकि, हमारा मानना है कि Topics API, उपयोगकर्ता की निजता बनाए रखने की दिशा में एक कदम है. हम इस एपीआई को बेहतर बनाने के लिए प्रतिबद्ध हैं. |
| टेक्सॉनमी स्ट्रक्चर | टॉपिक कैटगरी में आईडी, वर्शन, और अन्य मेटाडेटा स्ट्रक्चर जोड़ें | फ़िलहाल, एपीआई के रिस्पॉन्स में हम टेक्सॉनमी आईडी शामिल कर रहे हैं. लंबे समय तक काम करने वाले मैनेज करने की दिशा में आगे बढ़ने पर, टॉपिक ऑब्जेक्ट की समीक्षा करना और ज़रूरत पड़ने पर वर्शन पर अतिरिक्त मेटाडेटा शामिल करना सही रहेगा. |
| पब्लिशर कंट्रोल | पब्लिशर को यह बताना चाहिए कि उनकी साइटों को किन विषयों में रखा जाना चाहिए. | साइटों को गलत कैटगरी में बांटने से, Topics सिग्नल को सिग्नल के तौर पर थोड़ा कम काम का माना जा सकता है. हालांकि, जिन साइटों को गलत कैटगरी में रखा गया है उन पर किसी अन्य साइट की तुलना में ज़्यादा नुकसान नहीं होगा. इसकी वजह यह है कि किसी साइट की विषय से जुड़ी जानकारी, उसकी साइट पर होने वाली नीलामियों के लिए हमेशा उपलब्ध रहेगी. इससे, गलत वर्गीकरण होने पर भी सही विषय से तुलना करने वाली जानकारी मिल सकेगी. इस विषय पर सुझाव, शिकायत या राय यहां पाएं. पब्लिशर को कॉन्टेंट की कैटगरी तय करने की अनुमति देने में जोखिम हो सकता है. साइटें अपनी साइटों को जान-बूझकर गलत कैटगरी में डाल सकती हैं. इस वजह से, वे सभी के लिए काम को कम कर सकती हैं या कम सामान्य विषयों में संवेदनशील मतलब की नकल करके, उपयोगकर्ता की निजता को नुकसान पहुंचा सकती हैं. |
| Chrome एक्सटेंशन | Chrome एक्सटेंशन को मौजूदा कुकी मैनेजमेंट एक्सटेंशन से मिलते-जुलते विषय मैनेज और फ़िल्टर करने की अनुमति दें | जैसा कि GitHub पर चर्चा की गई है, यह पहले से ही मुमकिन है, लेकिन हम नेटवर्क से आपके सुझाव, शिकायत या राय का स्वागत करते हैं. |
| सामान्य रूप से उपलब्ध होने पर ट्रांज़िशन | क्या ऑरिजिन ट्रायल से सामान्य उपलब्धता पर ट्रांज़िशन करने से, Topics API पर कोई असर पड़ेगा? | ऑरिजिन ट्रायल से सामान्य उपलब्धता पर स्विच करने वाले उपयोगकर्ताओं का डेटा नहीं मिटेगा. |
| निजता | होस्ट के नामों में निजी जानकारी हो सकती है, जिसे Topics API की मदद से ऐक्सेस किया जा सकता है | निजता की सुरक्षा के लिए, हमने कई पाबंदियां लगाई हैं. जैसा कि यहां बताया गया है. |
| धोखाधड़ी और गलत इस्तेमाल | धोखाधड़ी वाली विज़िट से, विषयों में हेर-फेर किए जाने से कैसे बचें | जोखिम की आशंकाओं के बारे में यहां बताया गया है. |
| टॉपिक क्लासिफ़ायर | क्या वेबसाइटें, अपने टॉपिक क्लासिफ़िकेशन में बदलाव करने का अनुरोध कर सकती हैं? | हम इस विषय पर हमारे नेटवर्क से राय लेना चाहते हैं और हम आपका स्वागत करते हैं. |
| विषय मुहैया कराने वाली साइटें | ऐसी वेबसाइटें तय करें जो कई विषयों के लिए कॉन्टेंट होस्ट करती हैं. इन्हें "खास विषयों की जानकारी देने वाली साइटों" के तौर पर तय करें. साथ ही, वेब पेजों पर मौजूद टैग के आधार पर, कैटगरी तय करने वाली कंपनियों को ट्रेनिंग दें. | हम यहां इस प्रस्ताव पर चर्चा कर रहे हैं. साथ ही, अन्य सुझावों का स्वागत है. |
Protected Audience API (पहले इसे FLEDGE कहा जाता था)
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| ट्रैफ़िक को आकार देना | क्वेरी-प्रति-सेकंड (क्यूपीएस) लोड को ऑप्टिमाइज़ करने के लिए, एसएसपी से मिले फ़िल्टर की परफ़ॉर्मेंस पर असर | हमने ट्रैफ़िक को आकार देने के बारे में सोचने में काफ़ी समय बिताया है और सुझाव है कि एसएसपी को कैश मेमोरी का फ़ायदा लेने का सुझाव दिया जाता है. |
| टेस्ट की संख्या | Protected Audience को आज़माना मुश्किल काम है, क्योंकि SSP और DSP को ज़्यादा ट्रैफ़िक पाने में परेशानी हो रही है. | हम सुरक्षित ऑडियंस को अपनाने और उनकी जांच करने के लिए, SSP और DSP पार्टनर से लगातार संपर्क कर रहे हैं. सामान्य रूप से उपलब्ध होने की शुरुआत हो गई है. हमें भरोसा है कि पीए की सुविधा चालू होने पर, पार्टनर के ट्रैफ़िक के हिसाब से टेस्ट करना ज़्यादा आसान हो जाएगा. |
| जटिलता | Protected Audience की सुविधाएं लागू करने के लिए, काफ़ी मेहनत और लागत की ज़रूरत होती है. | हम समझते हैं कि प्राइवसी सैंडबॉक्स के साथ-साथ, नई टेक्नोलॉजी को इस्तेमाल करना मुश्किल है. प्राइवसी सैंडबॉक्स की टीम, अलग-अलग हिस्सेदारों के साथ मिलकर काम कर रही है, ताकि उन्हें टेक्नोलॉजी के बारे में जानकारी दी जा सके और उनकी मदद की जा सके. साथ ही, यह टीम नेटवर्क को अपनाने में मदद करने के लिए, काम करने वाली अन्य कंपनियों का लगातार आकलन कर रही है. |
| एक्ज़ीक्यूशन के लिए भरोसेमंद एनवायरमेंट | गैर-सार्वजनिक क्लाउड एनवायरमेंट में ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) के लिए सहायता | हम क्लाउड-आधारित सलूशन के अलावा अन्य विकल्पों पर काम कर रहे हैं. हालांकि, फ़िलहाल हम कंपनी की इमारत में मौजूद टीईई को इस टेक्नोलॉजी के साथ इस्तेमाल नहीं कर सकते, क्योंकि उन्हें प्राइवसी सैंडबॉक्स के लिए जांच करने में काफ़ी समय लगता है. प्राइवसी सैंडबॉक्स की सुरक्षा से जुड़ी ज़रूरी शर्तों और कंपनी की इमारत में डिप्लॉयमेंट की चुनौतियों को देखते हुए, हमारा मानना है कि क्लाउड-आधारित डिप्लॉयमेंट को बढ़ाने और उनमें सुधार करने के लिए, AWS के साथ-साथ GCP के साथ काम करना भी काफ़ी फ़ायदेमंद साबित हो सकता है. हालांकि, इस तरह की शर्त को पूरा करना ज़रूरी क्यों है, इस बारे में हम अतिरिक्त सुझाव, शिकायत या राय का स्वागत करते हैं. |
| लागत का स्ट्रक्चर | बिडिंग और नीलामी की सेवाओं के प्रस्ताव से, क्लाइंट-साइड मॉडल की तुलना में, विज्ञापन टेक्नोलॉजी की लागत और जटिलता बढ़ जाएगी. | फ़िलहाल, हम बिडिंग और नीलामी सर्वर में, सहायक बिडिंग और नीलामी के वर्कफ़्लो की लागत का अनुमान लगाने के लिए एक गाइड तैयार कर रहे हैं. इसे विज्ञापन-टेक्नोलॉजी के इस्तेमाल के साथ जोड़ा जाएगा और हमारे डिज़ाइन के लक्ष्यों में से एक को पूरा किया जाएगा. |
| के-एनन टाइमलाइन | `renderUrl` पर, प्लान के मुताबिक बनाई गई के-ऐनिमिटी की पाबंदियां कब लागू की जाएंगी? | हम नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) की टाइमलाइन के बारे में जानकारी देने वाले वीडियो पर काम कर रहे हैं. यह टाइमलाइन जल्द ही रिलीज़ की जाएगी. |
| RunAdनीलामी से जुड़ी पाबंदियां | क्या Chrome, runAdAuction को सिर्फ़ टॉप पेज से कॉल करने की अनुमति दे सकता है? |
हमारा डिज़ाइन, runAdAuction को टॉप पेज से कॉल किए जा सकने के लायक बनाने में पूरी तरह से मदद करता है. हालांकि, हमारा मानना है कि पब्लिशर के लिए, इसे सिर्फ़ टॉप डोमेन से कॉल करने लायक सीमित करना ज़्यादा नुकसानदेह होगा.हमें नेटवर्क से खास तौर पर पता चला है कि प्राइवसी सैंडबॉक्स, पब्लिशर और विज्ञापन देने वाले लोगों या कंपनियों पर बोझ को कम करने के लिए ज़रूरी है. यह सुझाव, वेब डेवलपमेंट के सामान्य सिद्धांत से मेल खाता है. इसमें बताया जाता है कि साइट के मालिक, अपनी साइटों को चलाने के लिए तीसरे पक्ष के टूल का इस्तेमाल कर सकते हैं. प्राइवसी सैंडबॉक्स का लक्ष्य, नेटवर्क को बेहतर बनाना है. इसके लिए, यह तय करने की ज़रूरत नहीं है कि पब्लिशर और विज्ञापन टेक्नोलॉजी कैसे काम करती हैं. हमारा मानना है कि पब्लिशर को उनकी साइट पर runAdAuction को कॉल करने का तरीका और उन्हें कॉल करने का विकल्प देने की अनुमति देने से, हम पब्लिशर को उनकी ज़रूरत के हिसाब से सबसे सही तरीका चुनने में मदद करते हैं. |
| लागू करने में मदद | क्या Chrome, मल्टी-सेलर नीलामी को ओपन-सोर्स लागू करने में, कोई योगदान दे सकता है? | प्राइवसी सैंडबॉक्स का मकसद, निजता बनाए रखने वाली ऐसी टेक्नोलॉजी डेवलप करना है जो तीसरे पक्ष की कुकी या अन्य क्रॉस-साइट आइडेंटिफ़ायर पर भरोसा नहीं करती. हम एक बेहतर नेटवर्क को बढ़ावा देना चाहते हैं. इसके लिए, हम यह तय करने की ज़रूरत नहीं है कि विज्ञापन टेक्नोलॉजी को कैसे काम करना चाहिए. हमने GitHub के डेटा स्टोर करने की जगह पर एपीआई के काम करने के तरीके के बारे में दिशा-निर्देश पब्लिश किए हैं. हम इंडस्ट्री के साथ समाधान एक्सप्लोर करने के लिए तैयार हैं. हम किसी खास तरीके से इसे लागू नहीं करना चाहते हैं, क्योंकि हमारा मुख्य सुझाव प्लैटफ़ॉर्म टेक्नोलॉजी को बनाना है. हम उन टेक्नोलॉजी को इस्तेमाल करने की रणनीतियां तय नहीं करेंगे. हमारी टेक्नोलॉजी, विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली कंपनियों को उपभोक्ताओं के लिए निजता की सुरक्षा का बेहतर दायरा उपलब्ध कराने में मदद करेगी. |
| एक से ज़्यादा सेलर के लिए नीलामी | क्या Chrome, कॉम्पोनेंट नीलामियों के साथ "संदर्भ के हिसाब से" विजेता शेयर करेगा? | Protected Audience API, मल्टी-सेलर नीलामी की शुरुआत करने वाले पक्षों को कॉम्पोनेंट नीलामी में जानकारी भेजने की सुविधा देता है (ध्यान दें: सिर्फ़ नीलामी शुरू करने से पहले). इसके बावजूद, हमें ब्राउज़र के लिए ऐसा कोई तरीका नहीं दिखता जिससे वह यह पता लगा सके कि कोई जानकारी, कॉन्टेक्स्ट के हिसाब से विजेता है या नहीं. इसलिए, हम उसे ब्लॉक नहीं कर सके या किसी खास जानकारी की ज़रूरत को लागू नहीं कर सके. |
| सहमति ट्रैकिंग के लिए उपयोगकर्ता की पसंद | विज्ञापन टेक्नोलॉजी, पीए से उपयोगकर्ता की सहमति ट्रैकिंग को सही तरीके से लागू करने का तरीका पूछ रही है | हमने अपने जवाब में पहली तिमाही में कही गई बात शामिल है: "खास विज्ञापनों के लिए, विज्ञापन टेक्नोलॉजी सबसे बेहतर विकल्प है. इससे यह तय किया जा सकता है कि कौनसे क्रिएटिव दिखाए जाएं या उन्हें कैसे चुना जाए." हमने मई डब्ल्यूआईसीजी की सुरक्षित ऑडियंस मीटिंग के दौरान, इस समस्या से जुड़ी कई स्थितियों पर चर्चा की. साथ ही, हम आपके सुझाव, शिकायत या राय और इस समस्या पर चर्चा का स्वागत करते हैं. |
| कस्टम ऑडियंस | क्या कस्टम ऑडियंस बनाने से जुड़े एसएसपी के इस्तेमाल के उदाहरण, Protected Audience API की मदद से काम करेंगे? | Protected Audience API, एसएसपी और विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली अन्य कंपनियों को कस्टम ऑडियंस का मालिक बनने और उन्हें मैनेज करने की अनुमति देता है. SSP को PA API के साथ इंटिग्रेट करने के तरीके को लेकर आगे के दिशा-निर्देश तैयार किए जा रहे हैं. इसे SSP और विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली दूसरी कंपनियों को दिया जाएगा, ताकि वे इंटिग्रेशन की कोशिशों में अपना योगदान दे सकें. |
| फ़ॉर्मैट | क्या यह वीडियो, Protected Audience API के साथ काम करता है? | वीडियो विज्ञापन दो में से एक तरीके से डिलीवर किए जाते हैं: VAST एक्सएमएल या एचटीएमएल (एक ऐसा आउटस्ट्रीम विज्ञापन जो VAST एक्सएमएल को किसी वीडियो प्लेयर में भी लोड कर सकता है). खरीदार, रेंडरिंग यूआरएल के ज़रिए इनमें से किसी भी फ़ॉर्मैट में लौटा सकते हैं. Attribution Reporting API के साथ काम करने के लिए, VAST (वीडियो विज्ञापन देने के लिए टेम्प्लेट) स्पेसिफ़िकेशन को हाल ही में अपडेट किया गया था. वीडियो विज्ञापन दिखाने वाली साइटों को, Protected Audience API की मदद से विज्ञापन दिखाने के तरीके के हिसाब से तैयारी करनी होगी. इसका मतलब है कि यह पक्का करना कि प्लेसमेंट टैग, Protected Audience iframe से वीडियो प्लेयर में यूआरएल भेज सकते हैं. फ़ेंस्ड फ़्रेम के लिए, हम फ़ेंस किए गए फ़्रेम का इस्तेमाल करने से जुड़ी ज़रूरी शर्तों को पूरा करने के लिए काम करेंगे. साल 2026 से पहले हम फ़ेंस किए गए फ़्रेम का इस्तेमाल नहीं करेंगे. |
| पेसिंग | Protected Audience API के साथ, पेसिंग के इस्तेमाल का उदाहरण कैसे काम करता है? | हम सुझाव की सराहना करते हैं. हम चाहते हैं कि इस अनुरोध के और मामले देखने के साथ-साथ ज़्यादा जानकारी के लिए, SSP पार्टनर से भी ज़्यादा जानकारी मिले, क्योंकि अब तक DSP के मामले में यह चिंता ज़्यादा रही है. |
| अपडेट का अंतराल | प्रॉडक्ट की जानकारी अपडेट करने जैसे कुछ मामलों में, dailyUpdate से हर दिन एक इंटरेस्ट ग्रुप के लिए कॉल की फ़्रीक्वेंसी काफ़ी नहीं होती. |
हम सुझाव की सराहना करते हैं. विज्ञापन टेक्नोलॉजी को के/वी लुकअप जैसे अलग-अलग फ़्रीक्वेंसी में रीफ़्रेश किए जाने वाले सिग्नल का इस्तेमाल करने की अनुमति देने के लिए, दूसरे तरीके भी उपलब्ध हैं. |
| विज्ञापन क्वालिटी कंट्रोल | पब्लिशर, विज्ञापन क्वालिटी कंट्रोल को कैसे लागू करते हैं? | Protected Audience API, फ़िलहाल पब्लिशर को यह सुविधा देता है कि वे अपने SSP को कुछ खास कंट्रोल के बारे में जानकारी दे सकें.ये कंट्रोल, नीलामी से पहले के कॉन्फ़िगरेशन के तहत बनाए जा सकते हैं. जैसे, विज्ञापनों से जुड़े लेबल के आधार पर अस्वीकार की गई सूचियां. नेटवर्क की किसी भी अतिरिक्त सुविधा के लिए, हमें सुझाव, शिकायत या राय देनी होंगी. |
| डीबग करना | forDebuggingOnly की सुविधा कब हटाई जाएगी? |
तीसरे पक्ष की कुकी का इस्तेमाल रोकने की वजह से होने वाले नुकसान की वजह से, हम forDebuggingOnly को बंद करने जा रहे हैं. हम साल 2026 में जीतने वाले इवेंट के लिए, forDebuggingOnly को जल्द से जल्द बंद करने वाले हैं. |
| क्रॉस-डिवाइस इंटरेस्ट ग्रुप | पुष्टि किए गए उपयोगकर्ता एजेंट के लिए, क्रॉस-डिवाइस इंटरेस्ट ग्रुप चालू करने का प्रस्ताव | हम इस प्रस्ताव की समीक्षा कर रहे हैं, लेकिन क्रॉस-डिवाइस टारगेटिंग की ज़्यादा सटीक जानकारी, निजता से जुड़ी गंभीर समस्याओं को हल कर सकती है. इसकी चर्चा GitHub से जुड़ी इस समस्या में की गई है. |
| (Q1 में भी रिपोर्ट किया गया) डायनामिक रीमार्केटिंग | तीसरे पक्ष की कुकी के बंद होने के बाद भी, क्या Protected Audience API की मदद से डाइनैमिक रीमार्केटिंग की सुविधा काम करेगी? | हमारा मानना है कि प्रोटेक्टेड ऑडियंस की मदद से, इस्तेमाल का यह उदाहरण लिया जा सकता है. इसके बारे में यहां बताया गया है. |
| क्लिक से जुड़ा डेटा | browserSignals. में क्लिक से जुड़ा डेटा जोड़ें |
फ़िलहाल, हम इस बारे में जानकारी मांग रहे हैं कि इस क्लिक को शुरुआती स्थिति मिली. |
| (यह डेटा, 2022 की चौथी तिमाही में भी रिपोर्ट किया गया है) सुरक्षित ऑडियंस में, उपयोगकर्ता के तय किए गए फ़ंक्शन | Protected Audience API में, उपयोगकर्ता के तय किए गए फ़ंक्शन (यूडीएफ़) किस तरह काम करेंगे? इन फ़ंक्शन को असली उपयोगकर्ता प्रोग्राम कर सकते हैं, ताकि वे एपीआई के फ़ंक्शन को बेहतर बना सकें. | इस समस्या को बताने वाली विज्ञापन टेक्नोलॉजी ने यह भी बताया कि वे यूडीएफ़ की मदद से क्या कर सकते हैं, इसका आकलन किया जा रहा है. इसलिए, अभी तक कोई कार्रवाई करने लायक सुझाव नहीं मिला है. |
| मुद्रा | फ़्लोटिंग पॉइंट का इस्तेमाल करके, मुद्रा की रकम नहीं दिखाई जानी चाहिए. | हमने यहां इस समस्या के बारे में ज़्यादा जानकारी दी है. |
| गैर-DSP विज्ञापन चुनने की क्षमताएं | Protect Audience API से जुड़ी नीलामियों में Ad Servers की क्या भूमिका होती है? | हम विज्ञापन सर्वर के अनुरोधों से जानते हैं कि वे बोली के बाद विज्ञापन चुनने / डाइनैमिक क्रिएटिव ऑप्टिमाइज़ेशन सेवाएं जारी रखें. फ़िलहाल, हम मौजूदा Protected Audience API और इन अनुरोधों के बीच के गैप के विश्लेषण का आकलन कर रहे हैं. |
| GenerateBid | हर विज्ञापन इंटरेस्ट ग्रुप के लिए, generateBid से एक से ज़्यादा कैंडिडेट विज्ञापन को दिखाने के Google Ads प्रस्ताव के लिए सहायता. साथ ही, उन उम्मीदवारों को `scoreAd` में स्कोर किया जा सकता है. |
फ़िलहाल, इसका आकलन किया जा रहा है. हम अन्य सुझाव, शिकायत या राय का स्वागत करते हैं. |
| नीलामी आदेश | क्या Protected Audience API से जुड़ी नीलामियां, सबसे आखिर में चलाए जाने के लिए ज़रूरी हैं, ताकि इसे अन्य सभी नीलामियों के नतीजों से जानकारी मिल सके? | Protected Audience API को पिछली बार इस्तेमाल करने के लिए, कोई तकनीकी ज़रूरी नहीं है. |
| गैर-उपयोगकर्ता द्वारा शुरू किया गया नेविगेशन | गैर-उपयोगकर्ता द्वारा आरंभ किए गए नेविगेशन को उजागर करें | हम इस अनुरोध की समीक्षा कर रहे हैं और इस पर यहां चर्चा कर रहे हैं. साथ ही, हम आपको कुछ और सुझाव भी दे रहे हैं. |
| कैश मेमोरी में सेव करना | अगर उपयोगकर्ता की स्थिति बदलती है, तो SSP को कैश मेमोरी से दिए गए DSP के perBuyerSignals नहीं बनाने चाहिए. | हम समझते हैं कि PerBuyer सिग्नल के लिए, इस्तेमाल के हर उदाहरण के लिए कैश मेमोरी की सुविधा काम नहीं करती है. हम आगे के विकल्पों का आकलन कर रहे हैं. हम नेटवर्क से मिलने वाले अन्य सुझाव, शिकायत या राय का स्वागत करते हैं. इसमें हमें बताया गया है कि कैश मेमोरी में सेव करने की सुविधा, उनके इस्तेमाल के उदाहरण में काम करेगी या नहीं. |
| एट्रिब्यूशन रिपोर्टिंग और सुरक्षित ऑडियंस | 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() फ़ंक्शन, हर इंटरेस्ट ग्रुप के हिसाब से चलता है और जनरेट बिड लागू करते समय, डीएसपी यह जानकारी दिखाता है:
return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| बाहरी योगदान | कुंजी/वैल्यू सर्वर के GitHub कोड बेस पर, बाहरी योगदान के लिए अनुरोध करें. | हम अपने काम की प्रोसेस को अपडेट करना चाहते हैं, ताकि GitHub कोड में बाहरी लोग योगदान दे सकें. |
| इंटरेस्ट ग्रुप का साइज़ | IG, ज़्यादा से ज़्यादा कितनी कुंजियों का इस्तेमाल कर सकता है? | फ़िलहाल, एक IG के साइज़ की सीमा 50 केबी है और इसके हिस्से के तौर पर कुंजियों को गिना जाता है. ऐप्लिकेशन के साइज़ की सीमा पर होने वाली बातचीत का हम स्वागत करते हैं. |
| बैच बनाने की सुविधा | K/V सर्वर कॉल की संख्या कैसे कम की जा सकती है? | K/V कॉल की संख्या कम करने के लिए, एचटीटीपी कैश-कंट्रोल हेडर का इस्तेमाल किया जा सकता है. उदाहरण के लिए, इसे कॉम्पोनेंट नीलामियों और किसी एक पेज के विज्ञापन स्लॉट में भी कैश मेमोरी में सेव किया जा सकता है. |
| वर्शन कंट्रोल | विज्ञापन टेक्नोलॉजी से जुड़े कोड के कई वर्शन के साथ काम करता है | बिडिंग और नीलामी से जुड़ी सेवाओं में, विज्ञापन टेक्नोलॉजी से जुड़े कोड के कई वर्शन काम करेंगे. बिडिंग और नीलामी एपीआई में, SelectAd अनुरोध, नीलामी के अनुरोध के लिए इस्तेमाल किए गए कोड के वर्शन के बारे में बता सकता है. जैसे, बिडिंग / नीलामी और रिपोर्टिंग के लिए. |
| शेयर किया गया स्टोरेज | बिडिंग और नीलामी सेवा में, शेयर किए गए स्टोरेज के लिए लिखने की सुविधा मिलती है. | फ़िलहाल, बिडिंग और नीलामी से जुड़ी सेवाएं, शेयर किए गए स्टोरेज के साथ काम नहीं करती हैं. हालांकि, हम यह जानने के लिए आपको और सुझाव दे सकते हैं कि इस्तेमाल के ऐसे उदाहरण नेटवर्क के लिए क्यों अहम हैं. |
| वेब-से-ऐप्लिकेशन | एक जैसी दिलचस्पी वाले ग्रुप के साथ, वेब से ऐप्लिकेशन शेयर करने की सुविधा का इस्तेमाल करें. | फ़िलहाल, Chrome और Android पर Protected Audience API के डिप्लॉयमेंट में वेब-टू-ऐप्लिकेशन का दायरा नहीं है. हालांकि, हम नेटवर्क से यह जानना चाहते हैं कि इस्तेमाल के इस उदाहरण की क्या अहमियत है. |
| के-ऐनिमिटी | के-ऐनिमिटी फ़ॉलबैक को मैनेज करने का तरीका | हम इस समस्या पर चर्चा कर रहे हैं. साथ ही, अन्य सुझावों का स्वागत है. |
डिजिटल विज्ञापनों का आकलन करना
एट्रिब्यूशन रिपोर्टिंग (और दूसरे एपीआई)
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| वैकल्पिक वीटीसी इवेंट लेवल रिपोर्ट के कॉन्फ़िगरेशन | वैकल्पिक VTC इवेंट-लेवल रिपोर्ट के कॉन्फ़िगरेशन के बारे में सुझाव, शिकायत या राय | हमें कुछ सुझाव मिले हैं कि मौजूदा इवेंट-लेवल कॉन्फ़िगरेशन सबसे बेहतर नहीं हैं. इसलिए, हम सबसे बेहतर ग्लोबल कॉन्फ़िगरेशन पर सुझाव मांग रहे हैं. हम इस बारे में और सुझाव, शिकायत या राय जानना चाहते हैं. हमें लगता है कि इवेंट लेवल के बारे में ज़्यादा जानकारी देने वाले हमारे टूल से, हमें इस समस्या को हल करने में मदद मिलेगी. |
| सुविधाजनक इवेंट-लेवल कॉन्फ़िगरेशन | सुविधाजनक इवेंट-लेवल कॉन्फ़िगरेशन की सुविधा का क्या स्टेटस है? | हमने फ़्लेक्सिबल इवेंट-लेवल कॉन्फ़िगरेशन से जुड़ा दस्तावेज़ शेयर किया है. इस सुविधा पर अभी काम चल रहा है. हमें इस बारे में और फ़ीडबैक चाहिए कि नेटवर्क के लिए यह सुविधा काम करेगी या नहीं. |
| सुविधाजनक इवेंट-लेवल कॉन्फ़िगरेशन | अलग-अलग पक्षों की विरोधी रिपोर्ट का समाधान कैसे किया जा सकता है? | ज़्यादातर रिपोर्टिंग स्थितियों को एग्रीगेट रिपोर्ट के ज़रिए बताया जाता है, जबकि सुविधाजनक इवेंट-लेवल कॉन्फ़िगरेशन प्रस्ताव खास तौर पर इवेंट-लेवल रिपोर्ट के लिए अतिरिक्त लचीलेपन के लिए है, जिन्हें अक्सर ऑप्टिमाइज़ेशन के इस्तेमाल के उदाहरणों के लिए इस्तेमाल किया जाता है. इस मामले में, नेटवर्क से जुड़ी किसी भी टिप्पणी/सुझाव, शिकायत या राय का हम स्वागत करते हैं. |
| सोर्स रजिस्ट्रेशन | अगर ट्रिगर के रजिस्ट्रेशन के बाद सोर्स का रजिस्ट्रेशन होता है, तो क्या होगा? | फ़िलहाल, अगर ट्रिगर के रजिस्ट्रेशन के बाद सोर्स का रजिस्ट्रेशन होता है, तो सोर्स और ट्रिगर को एक-दूसरे के साथ एट्रिब्यूट नहीं किया जा सकेगा. यह एक ऐसा मामला लगता है जो शायद किसी बड़े मामले में लागू न हो. हम इस समस्या के बारे में किसी भी अन्य सुझाव, शिकायत या राय का स्वागत करते हैं. अगर विज्ञापन टेक्नोलॉजी का इस्तेमाल कई बार ऐसा होता है, तो हम उसे ठीक करने की कोशिश करेंगे. |
| कई विज्ञापन एजेंसियों के साथ काम करना | जब कोई विज्ञापन देने वाला, कई विज्ञापन एजेंसियों के साथ काम करता है, तब डीएसपी, Attribution Reporting API का इस्तेमाल कैसे कर सकते हैं? | यह एपीआई, रीडायरेक्ट के साथ काम करता है. इसलिए, इसका इस्तेमाल तब भी किया जा सकता है, जब विज्ञापन देने वाला, कई विज्ञापन एजेंसियों के साथ काम कर रहा हो. इसके अलावा, रीडायरेक्ट से जुड़ी कुछ सीमाएं हैं, ताकि यह पक्का किया जा सके कि एपीआई, निजता को बेहतर बना रहा है. हमने विज्ञापन टेक्नोलॉजी से जुड़ी समस्या के लिए, Shared Storage API का इस्तेमाल करने का तरीका भी ढूंढा है. हम इस स्थिति के बारे में किसी भी अन्य सुझाव, शिकायत या राय का स्वागत करते हैं और उस सुझाव के आधार पर, हम इसे फिर से लागू करते रहेंगे. |
| गंतव्य सीमाएं | अपने-आप रीफ़्रेश होने वाले विज्ञापनों के इस्तेमाल के उदाहरण पर, डेस्टिनेशन की सीमाओं का असर पड़ सकता है. | हमने 1 मई को हुई डब्ल्यूआईसीजी मीटिंग में इस समस्या पर चर्चा की थी. हम इस बारे में सुझाव चाहते हैं कि उचित सीमा क्या होगी. हमने इवेंट-लेवल की रिपोर्ट के साथ एट्रिब्यूशन रिपोर्टिंग में बताया है कि ब्राउज़र, सोर्स साइटों से दिखाए जाने वाले `डेस्टिनेशन` eTLD+1 की संख्या को सीमित कर सकता है. (पुल अनुरोध देखें). |
| एट्रिब्यूशन रिपोर्टिंग और सुरक्षित ऑडियंस | 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 और उससे पहले के वर्शन (M113) और उससे पहले के वर्शन में रजिस्टर किया गया डेटा माइग्रेट नहीं किया जाएगा. इसलिए, डेटा मिट सकता है. डेटा लीक होने की यह जानकारी डीबग रिपोर्टिंग में नहीं दिखेगी. साथ ही, हम 114 से 115 तक के डेटा को नुकसान से बचाने की कोशिश करेंगे. |
| बिलिंग | हर कन्वर्ज़न की लागत के लिए बिलिंग के लिए एट्रिब्यूशन रिपोर्टिंग का इस्तेमाल करना | जैसा कि इस लेख में बताया गया है, हो सकता है कि Attribution Reporting API, हर कन्वर्ज़न की लागत की बिलिंग की ज़रूरतों के लिए सही न हो. ऐसा इवेंट-लेवल और खास जानकारी वाली रिपोर्ट में मौजूद गै़र-ज़रूरी डेटा की वजह से होता है. हम नेटवर्क चलाने वालों को सलाह देते हैं कि वे GitHub पर Attribution Reporting API की मदद से, अलग-अलग बिलिंग मॉडल पर पड़ने वाले असर के बारे में सुझाव दें. |
एग्रीगेशन सेवा
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| एग्रीगेट की जा सकने वाली रिपोर्ट में देरी | नेटवर्क से मिले सुझाव के आधार पर इस प्रस्ताव पर सकारात्मक प्रतिक्रियाएं दी गई हैं कि इकट्ठा की जा सकने वाली रिपोर्ट में देरी को बदलकर [10 से 60 मिनट] से [0 से 10 मिनट] किया जाएगा. | हमें इस बदलाव पर सकारात्मक प्रतिक्रिया मिलने की खुशी है. साथ ही, हम नेटवर्क को बढ़ावा देते हैं कि वह हमारे प्रस्तावों पर सुझाव देते रहें. |
| कंपनी की इमारत में उपलब्ध समाधान | क्या एग्रीगेशन सेवा को कंपनी की इमारत में मौजूद डेटा सेंटर में डिप्लॉय किया जा सकता है? | हम क्लाउड-आधारित सलूशन के अलावा अन्य विकल्पों पर काम कर रहे हैं. हालांकि, फ़िलहाल हम कंपनी की इमारत में मौजूद टीईई को इस टेक्नोलॉजी के साथ इस्तेमाल नहीं कर सकते, क्योंकि उन्हें प्राइवसी सैंडबॉक्स के लिए जांच करने में काफ़ी समय लगता है. प्राइवसी सैंडबॉक्स की सुरक्षा से जुड़ी ज़रूरी शर्तों और कंपनी की इमारत में डिप्लॉयमेंट की चुनौतियों को देखते हुए, हमारा मानना है कि क्लाउड-आधारित डिप्लॉयमेंट को बढ़ाने और उनमें सुधार करने के लिए, AWS के साथ-साथ GCP के साथ काम करना भी काफ़ी फ़ायदेमंद साबित हो सकता है. हालांकि, इस तरह की शर्त को पूरा करना ज़रूरी क्यों है, इस बारे में हम अतिरिक्त सुझाव, शिकायत या राय का स्वागत करते हैं. |
| अलग-अलग समयावधि के लिए रिपोर्ट को फिर से प्रोसेस करना | अलग-अलग समयावधि के लिए रिपोर्ट को फिर से प्रोसेस करने की सुविधा | हमें अलग-अलग तारीख की सीमाओं के लिए, बैच को बांटने के इसी तरह के अनुरोध मिले हैं. एक प्रस्ताव यह है कि शेयर किए गए आईडी को विज्ञापन तकनीक से तय किए गए लेबल के साथ बढ़ाया जा सके, ताकि रिपोर्ट को अलग-अलग बैच में बांटा जा सके. हम इस प्रोसेस का आकलन करने की प्रक्रिया में हैं. साथ ही, जैसे-जैसे इस प्रस्ताव में बदलाव होंगे, हम इस नेटवर्क को अपडेट करते रहेंगे. |
| ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट की निजता से जुड़े असर | ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट के निजता से जुड़े असर के बारे में सकारात्मक राय | हमें अपने प्रस्तावों के बारे में नेटवर्क से अच्छी प्रतिक्रिया मिली है. हम इन्हें बेहतर बनाने के लिए लगातार सुझाव दे रहे हैं. |
| सेवा की शर्तें | एग्रीगेशन सेवा की सेवा की शर्तें स्वीकार करने की समयसीमा क्या है? | हमने अभी तक नियम और शर्तें स्वीकार करने के लिए कोई समयसीमा तय नहीं की है. हालांकि, हमारी सलाह है कि नेटवर्क कंपनियों को जल्द से जल्द नियम और शर्तें स्वीकार करनी चाहिए, ताकि रजिस्ट्रेशन में देरी न हो. हम कंपनियों को सलाह देते हैं कि अगर उनके पास कोई सवाल है, तो वे हमसे संपर्क करें. |
| कुंजी की खोज | खोज की मुख्य सुविधा की मदद से टेस्टर, एग्रीगेट रिपोर्ट के लिए क्वेरी कर पाएंगे. इसके लिए, उन्हें संभावित कुंजी के कॉम्बिनेशन की साफ़ तौर पर सूची की ज़रूरत नहीं होगी. इससे, बेहतर परफ़ॉर्मेंस और सटीक होने के लिए, क्रॉस-नेटवर्क एट्रिब्यूशन के लिए खास जानकारी वाली रिपोर्ट को प्रोसेस किया जा सकेगा. | फ़िलहाल, हम समाधान और समाधान ढूंढ रहे हैं. साथ ही, नेटवर्क से आपको मिलने वाले अन्य सुझाव, शिकायत या राय का हम स्वागत कर रहे हैं. |
निजी एग्रीगेशन एपीआई
| फ़ीडबैक थीम | खास जानकारी | 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 के यूज़र इंटरफ़ेस (यूआई) से लिंक किया जाता है. Chrome की यह भी कोशिश रहती है कि वह उपयोगकर्ताओं को सही कॉन्टेक्स्ट के हिसाब से, सबसे सही जानकारी देने के तरीके सीखता रहे. |
| 3PCD पोस्ट करें | तीसरे पक्ष की कुकी के बंद होने के बाद भी, पहले पक्ष के सेट में तीसरे पक्ष की कुकी मौजूद रहेंगी. | हालांकि, requestStorageAccess और requestStorageAccessFor वाकई में किसी खास और साफ़ तौर पर बताए गए इस्तेमाल के मामलों के लिए, तीसरे पक्ष की कुकी को फिर से उपलब्ध कराते हैं. हालांकि, अब उन्हें डिफ़ॉल्ट रूप से उपलब्ध होने के बजाय, साइट के ज़रिए उन कुकी को चालू करने की ज़रूरत होती है जो तीसरे पक्ष की कुकी (Chrome में) की मौजूदा स्थिति के साथ उपलब्ध होती हैं.हालांकि, सिर्फ़ एक सेट में इस सुविधा को शुरू करने के लिए उपयोगकर्ता की अनुमति की ज़रूरत नहीं होगी. हालांकि, उपयोगकर्ता 'सेटिंग' में जाकर, इस व्यवहार से ऑप्ट-आउट करके इसे रोक सकते हैं. Chrome के यूज़र इंटरफ़ेस (यूआई) से लिंक किया गया सहायता केंद्र का लेख, उपयोगकर्ताओं के लिए ज़्यादा जानकारी उपलब्ध है. हम मौजूदा डेवलपर गाइड में इसे 100% तक बढ़ाने के बारे में सोच रहे हैं. |
| पहले पक्ष के सेट का सबमिशन | .json एक्सटेंशन शामिल करने के लिए, ज़रूरी .well-known/first-party-set का नाम बदलें. |
हमने यह बदलाव इसलिए किया है, ताकि यह पक्का किया जा सके कि कुछ वेब होस्टिंग प्लान काम करते हैं. |
| IANA रजिस्ट्रेशन | first_party_sets.JSON, IANA के साथ रजिस्टर होना चाहिए |
हम इस प्रस्ताव पर विचार कर रहे हैं और अन्य सुझाव, शिकायत या राय यहां का स्वागत है. |
फ़ेंस किए गए फ़्रेम का एपीआई
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| विज्ञापन ब्लॉकिंग | फ़ेंस किए गए फ़्रेम की मदद से, विज्ञापन रोकने वाले लोग आसानी से विज्ञापनों को ब्लॉक कर सकते हैं. | एक्सटेंशन, फ़ेंस किए गए फ़्रेम के साथ उसी तरह इंटरैक्ट कर सकते हैं जिस तरह वे iframe के साथ इंटरैक्ट करते हैं. फ़ेंस किए गए फ़्रेम को जिस असल यूआरएल पर ले जाना है वह एक्सटेंशन को भी दिखेगा. इसलिए, वे ब्लॉक करने के लिए यूआरएल के मिलान वाले किसी भी नियम को लागू कर सकते हैं, जैसा कि वे iframes में करते हैं. अगर फ़ेंस किए गए फ़्रेम के इस्तेमाल पर कोई शर्त नहीं है, तो ऐसा हो सकता है कि फ़ेंस किए गए फ़्रेम के इस्तेमाल के मामले में विज्ञापन न दिखें. |
शेयर किया गया स्टोरेज एपीआई
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| ज़्यादा से ज़्यादा लोगों का इस्तेमाल | शेयर किया गया स्टोरेज, सभी ब्राउज़र पर उपलब्ध होने वाला स्टैंडर्ड होना चाहिए. | हम इस सुझाव, शिकायत या राय का स्वागत करते हैं और इसकी पुष्टि करते हैं. इस प्रस्ताव को बढ़ावा देने, सुझाव पाने, और इसे अपनाने के लिए Chrome, W3C फ़ोरम में लगातार हिस्सा ले रहा है. |
| आउटपुट गेट | शेयर किए गए स्टोरेज के आउटपुट गेट बहुत सीमित हैं. | हम इस सुझाव पर विचार कर रहे हैं. साथ ही, आउटपुट गेट बहुत सीमित क्यों हैं, इस बारे में हम नेटवर्क से मिले अतिरिक्त सुझाव का स्वागत करते हैं. |
| नियामक अनुपालन | शेयर किए गए स्टोरेज की सुविधा, डेटा के रखरखाव की नीतियों जैसे नियमों के पालन को कैसे मैनेज करेगी? | शेयर किए गए स्टोरेज की सुविधा से, किसी भी सेव किए गए डेटा के लाइफ़टाइम और उसकी समयसीमा को कंट्रोल करने के लिए, लॉजिक को लागू किया जा सकता है. साथ ही, उसे अपने हिसाब से बदला जा सकता है. विज्ञापन टेक्नोलॉजी, टाइमस्टैंप के हिसाब से शेयर किए गए स्टोरेज के डेटा को अपडेट या मिटा सकती हैं. |
| A/B परीक्षण | शेयर किए गए स्टोरेज और 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-कनेक्ट सहायता के अलावा) पर रिसर्च और शिक्षा से जुड़े समुदायों से लगातार मदद मांग रही है. |
स्पैम और धोखाधड़ी को रोकना
Private State Token API (और अन्य एपीआई)
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| नए सिग्नल एक्सप्लोर करना | कई पार्टनर ने ब्राउज़र की मदद से, डिवाइस को पूरी सुरक्षा देने या उपयोगकर्ता पर भरोसा जताने के सिग्नल को एक्सप्लोर करने के बारे में सकारात्मक राय दी है. आम तौर पर, वे नए मकसद के लिए बनाए गए सिग्नल को लेकर भी सावधान रहते हैं, क्योंकि इनसे धोखाधड़ी का पता लगाने के मौजूदा लेवल को बनाए रखने में मदद मिलती है. | हम धोखाधड़ी और वेब सुरक्षा समुदाय के साथ मिलकर नए ऑफ़र एक्सप्लोर करने के लिए उत्साहित हैं. साथ ही, हम उनकी समस्याओं को स्वीकार करते हैं और उनके बारे में बताते हैं. यही वजह है कि प्राइवसी सैंडबॉक्स का मुख्य वर्कस्ट्रीम "स्पैम और धोखाधड़ी से लड़ना" रहा है. इसलिए, हम उपयोगकर्ताओं की निजता को बेहतर बनाने के साथ-साथ वेब सुरक्षा को बनाए रखने के लिए लगातार काम कर रहे हैं. |
| पीएसटी के बारे में अच्छा फ़ीडबैक | कई पार्टनर ने धोखाधड़ी रोकने या वेब सुरक्षा से जुड़े अलग-अलग मामलों के लिए, पीएसटी की जांच करने या उसका इस्तेमाल करने में दिलचस्पी दिखाई है. | हमें यह जानकर खुशी हो रही है कि हम पीएसटी का इस्तेमाल करने वाले नए समाधानों की खोज करने में हमारी मदद कर रहे हैं. हमारे पास Chrome डेवलपर साइट पर संसाधन और सैंपल कोड उपलब्ध हैं. साथ ही, अगर आपको कोई और सुझाव/राय देनी है या शिकायत करनी है, तो हमें बताएं. |
| धोखाधड़ी और गलत इस्तेमाल | आइडेंटिफ़ायर उपलब्ध न होने पर, तीसरे पक्ष की कुकी के बंद होने के बाद, विज्ञापन से होने वाली धोखाधड़ी से बचाव / मेज़रमेंट में जांच के बारे में दिशा-निर्देश. | हमने प्राइवेट स्टेट टोकन जैसे टूल लॉन्च किए हैं. इनसे तीसरे पक्ष की कुकी के खोए हुए सिग्नल को वापस पाने में मदद मिलेगी. यह धोखाधड़ी रोकने के मकसद से किया जाता है. हालांकि, इसके लिए नई निजता सेटिंग लागू की गई हैं. हम धोखाधड़ी और डेटा के गलत इस्तेमाल को रोकने के नए प्रस्ताव बनाने पर लगातार काम कर रहे हैं, ताकि प्राइवसी सैंडबॉक्स में किए गए अन्य बदलावों की मदद से उनकी क्षमताओं को बनाए रखा जा सके. |
| जारी करने वाले से शुरुआत की जगह की जानकारी की दर | जारी करने वाले से ऑरिजिन के बीच जानकारी की दर, यूनीक उपयोगकर्ताओं की पहचान करने के लिए काफ़ी है. | हमने खास जानकारी को अपडेट किया है, ताकि यह साफ़ तौर पर पता चल सके कि प्राइवेट स्टेट टोकन का इस्तेमाल करके, उपयोगकर्ता का कौनसा डेटा शेयर किया जा सकता है. इस तरह डिज़ाइन के मुताबिक, एक बार में छह सार्वजनिक कुंजियों का इस्तेमाल किया जा सकता है. ये कुंजियां किसी खास उपयोगकर्ता को "राज्य" के तौर पर दिखा सकती हैं. कुंजियों के ये सेट सिर्फ़ 60 दिनों में अपडेट किए जा सकते हैं (कुछ खास मामलों को छोड़कर, जहां आपातकालीन स्थिति में कुंजी बदलने की ज़रूरत हो). इससे, समय के साथ उपयोगकर्ता के अन्य डेटा को जोड़ने की संभावना कम हो जाती है. किसी भी नए वेब API के साथ, दी जाने वाली उपयोगिता और इससे मिलने वाली पूरी नई उपयोगकर्ता जानकारी में संतुलन होता है. हमारा अनुमान है कि पीएसटी के ज़रिए उपयोगकर्ता की निजता की सुरक्षा करने के लिए ज़रूरी कदम उठाए जाते हैं. साथ ही, तीसरे पक्ष की कुकी के इस्तेमाल को रोकने से, धोखाधड़ी रोकने के मामलों में भी मदद मिलती है. |
| डेटा फ़ेच करें | fetch को इंटिग्रेट करना मुश्किल और ज़रूरी नहीं है. |
fetch के इस्तेमाल के अपने फ़ायदे और नुकसान हैं. साथ ही, हम वेब नेटवर्क में और स्टैंडर्ड तय करना चाहते हैं. हालांकि, हमारा मानना है कि अभी यह बदलाव करना अभी बाकी है. ऐसा तब तक होगा, जब तक हम यह बेहतर तरीके से न समझ लें कि स्टैंडर्ड कैसा दिखेगा. अगर कोई मानक सामने आता है, तो हम वेब डेवलपर को भी उस मानक पर ले जाने की पूरी ज़िम्मेदारी लेते हैं. |
| सेव करने की जगह | प्राइवेट स्टेट टोकन कुंजी के कॉन्फ़िगरेशन को उसी जगह पर सेव किया जाना चाहिए जहां PrivacyPass प्रोटोकॉल मौजूद है. | ऑरिजिन ट्रायल के दौरान, डेवलपर ने बताया कि उन्होंने अपनी कुंजियों को .well-known डायरेक्ट्री के बजाय सामान्य यूआरएल पर सेव करने को प्राथमिकता दी है. PrivacyPass में तय की गई कुंजी का फ़ॉर्मैट, खास तौर पर ऐसे वर्शन के लिए सही नहीं है जिसमें कीसेट का इस्तेमाल करके, इंप्लिसिट "सार्वजनिक मेटाडेटा" की वैल्यू दी गई हो. अगर PrivacyPass का कोई वैरिएंट, सार्वजनिक मेटाडेटा (पीओपीआरएफ़, पार्शियल आरएसए ब्लाइंडिंग या कीसेट) के साथ स्टैंडर्ड के मुताबिक बन जाता है, तो हम यह सुविधा देने के लिए, पीएसटी के आने वाले वर्शन पर स्विच कर सकते हैं. |
| एपीआई को लागू करने का हेडर | एपीआई के हेडर लागू करने से जुड़े सवाल | जैसे-जैसे API स्टैंडर्ड बन जाता है और इस एपीआई का नेटवर्क इस्तेमाल करने लगता है, हम या तो इस एपीआई के बिना हेडर वाले स्टैंडर्ड वर्शन, दोनों पर काम करेंगे और अगर बहुत कम इस्तेमाल होने पर हेडर वर्शन का इस्तेमाल बंद कर दिया जाएगा या अन्य डेटा से जारी करने/रिडीम करने के अनुरोधों को जोड़ने के लिए डेवलपर टूलिंग/सहायता मौजूद होगी, तो हो सकता है. हम इस समस्या के बारे में यहां चर्चा कर रहे हैं. |
| रजिस्ट्रेशन | क्या जारी करने वालों को ब्राउज़र वेंडर के साथ रजिस्टर करना सही है? | हमने प्राइवेट स्टेट टोकन जारी करने वाले रजिस्ट्रेशन की प्रोसेस के बारे में जानकारी अपडेट की है. हालांकि, यह अपनी प्रोसेस का इस्तेमाल करता है, लेकिन यह प्राइवसी सैंडबॉक्स के अन्य वर्शन के रजिस्ट्रेशन प्लान की तरह ही है. इसमें, हम पीएसटी को इस्तेमाल करने के अपने मकसद के बारे में, सार्वजनिक तौर पर जानकारी देने वाले बैंक या कंपनी को मांगते हैं. साथ ही, उन तकनीकी पाबंदियों को स्वीकार करने के लिए भी कहते हैं जो उपयोगकर्ता की निजता को सुरक्षित रखती हैं. |