साल 2023 की पहली तिमाही की तिमाही रिपोर्ट में, प्राइवसी सैंडबॉक्स के प्रपोज़ल और Chrome से मिले जवाब के बारे में, नेटवर्क से मिले सुझावों की खास जानकारी दी गई है.
सीएमए को लेकर अपनी जवाबदेही के तहत, Google ने प्राइवसी सैंडबॉक्स के प्रपोज़ल के लिए, हिस्सेदार के जुड़ाव की प्रोसेस की तीन महीने में तीन रिपोर्ट सार्वजनिक तौर पर उपलब्ध कराने की सहमति दी है. कमीमेंट के पैराग्राफ़ 12 और 17(c)(ii) देखें. प्राइवसी सैंडबॉक्स से जुड़ी फ़ीडबैक की खास जानकारी वाली ये रिपोर्ट, अलग-अलग सोर्स से मिले सुझावों को इकट्ठा करके जनरेट की जाती हैं. इन सोर्स की जानकारी फ़ीडबैक खास जानकारी में दी गई है. इसमें इनके अलावा, और भी चीज़ें शामिल हो सकती हैं: GitHub समस्याएं, privacysandbox.com पर उपलब्ध कराए गए सुझाव फ़ॉर्म. Chrome, नेटवर्क से मिले सुझाव, शिकायत या राय का स्वागत करता है. साथ ही, वह डिज़ाइन से जुड़े फ़ैसलों में सीखने के तरीकों को शामिल करने के तरीके खोज रहा है.
सुझाव, शिकायत या राय की थीम, हर एपीआई की संख्या के हिसाब से रैंक की जाती हैं. इसके लिए, Chrome टीम को मिले सुझाव, शिकायत या राय को किसी तय थीम के आधार पर इकट्ठा करके और उन्हें घटते हुए क्रम में व्यवस्थित किया जाता है. फ़ीडबैक से जुड़ी सामान्य थीम की पहचान करने के लिए, हमने सार्वजनिक मीटिंग (W3C, PatCG, IETF), सीधे तौर पर सुझाव/शिकायत/राय, GitHub पर चर्चा के विषयों और Google की इंटरनल टीम और पब्लिक फ़ॉर्म की मदद से अक्सर पूछे जाने वाले सवालों की समीक्षा की.
खास तौर पर, वेब स्टैंडर्ड बॉडी मीटिंग के लिए तय किए गए समय की समीक्षा की गई और सीधे सुझाव के लिए, Google के 1:1 हिस्सेदारों की मीटिंग के रिकॉर्ड, अलग-अलग इंजीनियर को मिले ईमेल, एपीआई ईमेल पाने वाले लोगों की सूची, और लोगों के सुझाव देने वाले फ़ॉर्म पर विचार किया गया. इसके बाद, Google ने टीम के बीच इन अलग-अलग आउटरीच गतिविधियों को शामिल किया, ताकि यह पता लगाया जा सके कि हर एपीआई के बारे में उभर रही थीम की लोकप्रियता कितनी है.
फ़ीडबैक पर Chrome ने क्या जवाब दिए, यह जानने के लिए अक्सर पूछे जाने वाले सवालों, हिस्सेदारों की ओर से उठाए गए मुद्दों पर असल जवाब, और खास तौर पर सार्वजनिक रिपोर्टिंग की प्रोसेस के लिए एक स्थिति तय की गई है. डेवलपमेंट और टेस्टिंग के मौजूदा फ़ोकस को दिखाते हुए, हमें खास तौर पर Topics, FLEDGE, और Attribution Reporting API के बारे में सवाल और सुझाव मिले.
हो सकता है कि मौजूदा रिपोर्टिंग अवधि के खत्म होने के बाद मिलने वाले फ़ीडबैक को अभी तक Chrome के जवाब के तौर पर न माना जाए.
संक्षिप्त नाम की शब्दावली
- सीएचआईपीएस
- कुकी, इंडिपेंडेंट पार्टिशन्ड स्टेट है
- डीएसपी
- डिमांड-साइड प्लैटफ़ॉर्म
- FedCM
- फ़ेडरेटेड क्रेडेंशियल मैनेजमेंट
- FPS (फ़्रेम प्रति सेकंड)
- पहले पक्ष के सेट
- IAB
- इंटरैक्टिव विज्ञापन ब्यूरो
- आईडीपी
- पहचान देने वाली कंपनी
- आईईटीएफ़
- इंटरनेट इंजीनियरिंग टास्क फ़ोर्स
- IP
- इंटरनेट प्रोटोकॉल पता
- openRTB
- रीयल-टाइम बिडिंग
- OT
- ऑरिजिन ट्रायल
- PatCG
- प्राइवेट ऐडवर्टाइज़िंग टेक्नोलॉजी कम्यूनिटी ग्रुप
- RP
- भरोसेमंद पार्टी
- एसएसपी
- सप्लाई-साइड प्लैटफ़ॉर्म
- TEE
- भरोसेमंद तरीके से एक्ज़ीक्यूशन एनवायरमेंट
- UA
- उपयोगकर्ता एजेंट स्ट्रिंग
- UA-CH
- उपयोगकर्ता-एजेंट क्लाइंट हिंट
- W3C
- वर्ल्ड वाइड वेब कंसोर्टियम
- डब्ल्यूआईपीबी
- विलफ़ुल आईपी ब्लाइंडनेस
सामान्य सुझाव, किसी खास एपीआई/टेक्नोलॉजी के आधार पर नहीं
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| परीक्षण और परीक्षण | अगर प्राइवसी सैंडबॉक्स एपीआई टेस्ट के शुरू होने से पहले पूरा नहीं होता है, तो सीएमए के आकलन को के बारे में बताने के लिए टेस्टिंग कितने काम की है | Privacy Sandbox APIs का डेवलपमेंट तेज़ी से हो रहा है.
ये टेस्ट के लिए ऑरिजिन ट्रायल में पहले से ही उपलब्ध हैं और आम तौर पर, गर्मी के इस मौसम में 100% ट्रैफ़िक के लिए आम तौर पर उपलब्ध रहेंगे. इसके अलावा, हमने कुछ खास सुविधाओं (जैसे कि FLEDGE इवेंट-लेवल रिपोर्टिंग, iframes के साथ FLEDGE रेंडरिंग) के लिए टाइमलाइन के बारे में साफ़ तौर पर बताया है जिन पर साल 2026 से पहले कोई असर नहीं पड़ेगा. हम नेटवर्क को एपीआई की जांच करने और सीएमए को सुझाव देने का सुझाव देते हैं. यह सुझाव इस आधार पर दिया जाता है कि तीसरे पक्ष की कुकी के बंद होने के बाद, टेस्टर किन चीज़ों पर भरोसा करने की उम्मीद करते हैं. इससे तीसरे पक्ष की कुकी के इस्तेमाल को रोकने से होने वाले असर का आकलन करने में मदद मिल सकती है. |
| उपयोगकर्ता नियंत्रण | प्राइवसी सैंडबॉक्स एपीआई के यूज़र कंट्रोल के असर से जुड़े नेटवर्क के बारे में साफ़ दिशा-निर्देश | हम इस बारे में कानूनी सलाह नहीं दे सकते कि नेटवर्क, उपयोगकर्ता के किन कंट्रोल का इस्तेमाल कर सकता है. इसके साथ ही, Chrome कुछ प्रतिशत उपयोगकर्ताओं को अपडेट किए गए प्राइवसी सैंडबॉक्स ("बेहतर विज्ञापन निजता") के कंट्रोल दिखा रहा है. ऐसा प्राइवसी सैंडबॉक्स टेक्नोलॉजी को बेहतर बनाने की हमारी कोशिश के तहत किया जा रहा है. इन अपडेट में, पहले से ज़्यादा आसान, काम की भाषा, और लेआउट शामिल हैं. जब Chrome ने इन रिफ़ाइन सिस्टम का आकलन कर लिया और यह तय कर लिया कि उन्हें बड़ी आबादी तक बढ़ाना है या नहीं, तो वे नेटवर्क के साथ ज़्यादा जानकारी शेयर कर सकते हैं. |
| डेटा लीक होना | ब्राउज़र के साथ छेड़छाड़ किए जाने पर, Google और अन्य पक्षों के बीच पहले पक्ष का डेटा लीक होने का जोखिम | FLEDGE का
जानकारी देने वाला यह साफ़ तौर पर बताता है कि एक विज्ञापन टेक्नोलॉजी का डेटा
सिर्फ़ उसी विज्ञापन टेक्नोलॉजी के साथ शेयर किया जाता है (उनके वर्कलेट या उनके भरोसेमंद सर्वर के साथ) या जब उस विज्ञापन तकनीक से साफ़ तौर पर
शेयर किया जाता है (जैसे कि खरीदार को वह विज्ञापन यूआरएल दिखाता है जिसे वह दिखाना चाहता है). इनमें एक अपवाद यह है कि के-अनामता की जांच, ग्लोबल सेंट्रलाइज़्ड सर्वर के ज़रिए ही की जानी चाहिए. निजता के बारे में हम क्या सोच रहे हैं, इस बारे में विस्तार से जानने के लिए के-अनामता का एक्सप्लेनर वीडियो देखें. इसके अलावा, हम आपको इस बारे में ज़्यादा जानकारी देना चाहते हैं कि के-ऐनिमिटी सर्वर के डिज़ाइन में, विज्ञापन टेक्नोलॉजी से जुड़ी सुरक्षा देने वाली सुविधाओं का इस्तेमाल कैसे किया जाता है. |
| चर्चा के लिए अतिरिक्त फ़ोरम | फ़ीडबैक शेयर करने के लिए गैर-तकनीकी इकोसिस्टम प्लेयर, W3C के लिए एक अतिरिक्त फ़ोरम का अनुरोध करें | प्राइवसी सैंडबॉक्स से जुड़ा सुझाव फ़ॉर्म, सामान्य और खास टिप्पणियों, तकनीकी और गैर-तकनीकी
के लिए सही है. वेब विज्ञापन कारोबार को बेहतर बनाने वाला ग्रुप एक ऐसा फ़ोरम है जहां हर हफ़्ते कॉल करके GitHub के डेटा स्टोर पर चर्चा की जाती है. developer.chrome.com पर मौजूद प्राइवसी सैंडबॉक्स के फ़ीडबैक पेज पर, सुझाव/राय देने या शिकायत करने और बातचीत में शामिल होने के अन्य तरीकों के बारे में बताया गया है. Chrome में सवालों और कॉन्टेंट शेयर करने की सुविधा देने के लिए, ऑफ़िस में कामकाज के घंटे के दौरान सार्वजनिक घंटे जैसे इवेंट भी जारी रहेंगे. इसके अलावा, Chrome ने पिछली तिमाही में एक दर्जन से ज़्यादा इंडस्ट्री इवेंट होस्ट किए या उनमें शामिल हुए. |
| टाइमलाइन के बारे में जानकारी | 2023 की तीसरी तिमाही में, सामान्य रूप से उपलब्ध होने की सटीक तारीख की जानकारी | PrivacySandbox.com पर पब्लिश की गई टाइमलाइन के मुताबिक, Chrome के वर्शन 115 की रिलीज़ के साथ 'सामान्य उपलब्धता' को लॉन्च करने की शुरुआत की गई है. |
| reCAPTCHA | reCATPCHA के स्पैम का पता लगाने के इस्तेमाल के उदाहरण के लिए Sandbox API का असर | हमें reCAPTCHA से समय-समय पर सुझाव मिलते हैं, ताकि यह पक्का किया जा सके कि प्राइवसी सैंडबॉक्स के प्रस्तावों से, वेब सुरक्षा या धोखाधड़ी पर कोई असर न पड़े. वे तीसरे पक्ष की कुकी को रोकने और उसके हिसाब से काम करने के लिए अपना प्लान बना रहे हैं. इसलिए, उन्होंने इस सवाल को सबसे सही जवाब दिया है. |
| Chrome एक्सटेंशन | क्या प्राइवसी सैंडबॉक्स से जुड़ी टेक्नोलॉजी के इस्तेमाल, जैसे कि एंटी कवरट ट्रैकिंग (ACT) के मेज़रमेंट Chrome एक्सटेंशन पर लागू होंगे? | हमने इस बारे में कोई सूचना नहीं दी है कि ACT Chrome एक्सटेंशन पर लागू हो सकता है या नहीं. हालांकि, अगर कोई टेक्नोलॉजी अनजाने में किसी उपयोगकर्ता की जानकारी इकट्ठा करती है, तो यह हमारे निजता के सिद्धांतों के मुताबिक नहीं होगी. |
काम का कॉन्टेंट और विज्ञापन दिखाएं
विषय
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| TAG के डिज़ाइन की समीक्षा | TAG ने विषयों की शुरुआती डिज़ाइन समीक्षा रिलीज़ की है. | हम Topics का इस्तेमाल करना जारी रखेंगे. साथ ही, हमने नए अपडेट पेज पर और इस समस्या में, Topics को इस्तेमाल करने के अपने वादे के बारे में अपडेट शेयर किया है. हमने TAG समीक्षा के लिए अलग-अलग जवाब दिया और हमने बेहतर तरीके से काम करने के अपने विज़न के बारे में बताया. विषयों का एपीआई, उन एपीआई के कलेक्शन का हिस्सा रहेगा जिनकी विज्ञापन नेटवर्क को 2023 के दौरान जांच करनी चाहिए. हमें उम्मीद है कि टेस्टिंग से मिले सुझाव और उसे लागू करने से जुड़ा अनुभव, इस क्षेत्र में क्रॉस-ब्राउज़र स्टैंडर्ड के काम करने की दिशा में की जाने वाली कोशिशों में अहम योगदान देगा. हम बदलाव को आसान बनाने के लिए नेटवर्क के साथ काम करते रहना चाहते हैं. यहां Topics API को क्रॉस-ब्राउज़र के साथ काम करने के साथ-साथ एक मानक माना जा सकता है. |
| विषयों के बारे में नज़रिया | Chrome को ओपन अप्रोच के लिए Topics API डेवलप करना होगा, | इस भावना की सराहना करते हैं और हम इंडस्ट्री ग्रुप के साथ काम करते रहने की कोशिश करते रहेंगे, ताकि हम ऐसा Topics API डेवलप कर सकें जिससे पूरे नेटवर्क को फ़ायदा मिले. |
| (साल 2022 की तीसरी तिमाही में भी इसकी जानकारी दी गई है) विषयों की अलग-अलग कैटगरी इतनी ज़्यादा नहीं है |
बड़े विषयों की कैटगरी में, ज़्यादा जानकारी देने वाले विषय शामिल नहीं हैं. इसमें खास तौर पर क्षेत्र के हिसाब से तय किए गए विषय भी शामिल नहीं हैं. | पहली तिमाही के लिए अपडेट: कैटगरी में सुधार पर काम जारी है. दूसरी तिमाही में, हम Topics API के लिए अपडेट की गई अलग-अलग कैटगरी का एलान करेंगे. यह नई कैटगरी बनाने के लिए, हमने नेटवर्क की अलग-अलग कंपनियों के साथ मिलकर काम किया. हम प्रॉडक्ट की उस कैटगरी पर सुझाव चाहते हैं जो नेटवर्क के लिए सबसे ज़्यादा काम की हो. विषयों की संख्या बढ़ाने या ज़्यादा जानकारी देने वाले विषयों को शामिल करने का आकलन करते समय, कुछ बातों का ध्यान रखा जाता है. जैसे, 1) निजता से जुड़ी समस्याओं (ज़्यादा विषयों पर फ़िंगरप्रिंट का जोखिम हो सकता है) और 2) पहले देखे जा चुके विषयों को फिर से पाने की क्षमता (जैसे कि ज़्यादा विषयों में, विज्ञापन टेक्नोलॉजी से चुने गए विषय को पहले देखा हो) की संभावना कम है. |
| (2022 की चौथी तिमाही में भी रिपोर्ट की गई) पहले पक्ष के सिग्नल पर असर |
टॉपिक के सिग्नल ज़्यादा अहम हो सकते हैं. इसकी वजह से, पहले पक्ष के दिलचस्पी के हिसाब से मिलने वाले अन्य सिग्नल की वैल्यू कम हो जाती है. | हमारा मानना है कि रुचि के हिसाब से विज्ञापन दिखाना, वेब के लिए इस्तेमाल का एक ज़रूरी उदाहरण है. साथ ही, Topics को ऐसे इस्तेमाल के उदाहरण के लिए डिज़ाइन किया गया है. हम समझते हैं कि कुछ बड़े पब्लिशर इस बात को लेकर चिंतित हैं कि Topics की मदद से, उनके पहले पक्ष (ग्राहक) के डेटा की रणनीतियों पर बुरा असर पड़ सकता है. हमें इकोसिस्टम की टेस्टिंग होनी है. इसमें इस बात की अहम जानकारी मिलेगी कि पब्लिशर पर Topics का कितना असर पड़ रहा है. |
| विज्ञापनों के अलावा अन्य विषयों के इस्तेमाल के उदाहरण | रुचि के हिसाब से विज्ञापन दिखाने के अलावा दूसरे कामों के लिए विषयों का इस्तेमाल | विषयों को रुचि के हिसाब से विज्ञापन के इस्तेमाल के उदाहरण को ध्यान में रखकर बनाया गया है. हमारा मानना है कि मुफ़्त और ओपन वेब के लिए यह एक ज़रूरी उदाहरण है. फ़िलहाल, हम इस्तेमाल के दूसरे उदाहरणों पर सुझाव मांग रहे हैं और समीक्षा कर रहे हैं. |
| डिफ़ॉल्ट ऑप्ट-इन स्थिति | विषयों की सहमति के लिए डिफ़ॉल्ट रूप से लागू होने वाले क्षेत्रीय कानून पर असर | हम कानूनी राय पर टिप्पणी नहीं कर सकते. |
| (साल 2022 की तीसरी तिमाही में भी इसकी रिपोर्ट दी गई) गलत कैटगरी में रखी गई साइटें |
किसी साइट के लिए विषयों की गलत कैटगरी तय करने पर, विज्ञापन टारगेटिंग (विज्ञापन के लिए सही दर्शक चुनना) | पहली तिमाही के लिए अपडेट: दूसरी तिमाही में, हम Topics API के लिए, कैटगरी तय करने वाले अपडेट किए गए एल्गोरिदम का एलान करेंगे. साथ ही, हम इसके नेटवर्क के साथ काम करने के लिए तैयार हैं. मौजूदा सुझाव के आधार पर, साइटों को बदलने के लिए चुनी गई सूची के कॉम्बिनेशन के हिसाब से कैटगरी तय की जाती हैं. इनमें, सबसे लोकप्रिय साइटें और उपयोगकर्ता के डिवाइस पर मौजूद मशीन लर्निंग मॉडल शामिल होते हैं. Chrome, विषयों की कैटगरी तय करने में योगदान देने वाली साइटों के विकल्पों का आकलन करता रहता है. बिजली, पानी जैसी सुविधाओं में किए गए किसी भी तरह के सुधार, निजता और इसके गलत इस्तेमाल को ध्यान में रखकर किए जाने चाहिए. उदाहरण के लिए, कुछ जोखिमों में ये शामिल हैं: अलग-अलग (और संभावित रूप से संवेदनशील) मतलबों को विषय में शामिल करने के लिए खुद के लेबल का इस्तेमाल करने वाली साइटें; पैसे कमाने के लिए अपने विषयों को गलत तरीके से पेश करने वाली साइटें; कमाई करने के मकसद से विषयों को गलत तरीके से पेश करने वाली साइटें; उदाहरण के लिए, बेमतलब के शोर के साथ उपयोगकर्ताओं के विषयों को स्पैम करना. लोग chrome://topics-internals या इस कोलैब के ज़रिए उपलब्ध टूल की मदद से, इन कॉम्पोनेंट की जांच कर सकते हैं. टेस्टिंग के ज़रिए, हम समय के साथ वर्गीकरण में सुधार होने की उम्मीद करते हैं. साथ ही, हम गलत कैटगरी वाली साइटों के उदाहरणों के सुझाव का स्वागत करते हैं. |
| विषयों की कैटगरी तय करने वाला टूल | डीबग करने के मकसद से, कॉलर को "कोई विषय नहीं" दिखाए जाने की वजहों के बारे में ज़्यादा जानकारी देने का अनुरोध | हम समझते हैं और इस बात की सराहना करते हैं कि डीबग करने वाले टूल डेवलपर के लिए काम के हैं, क्योंकि वे Topics API को अपने सिस्टम में इंटिग्रेट करने के लिए काम करते हैं. हालांकि, अतिरिक्त जानकारी (जैसे कि 'कोई विषय क्यों नहीं लौटाया गया' क्यों नहीं) के बारे में बताकर, हम अनजाने में ऐसी जानकारी शेयर कर सकते हैं जिससे पक्षों को अतिरिक्त जानकारी ज़ाहिर करने में मदद मिलती है. उदाहरण के लिए, अगर किसी उपयोगकर्ता ने गुप्त मोड में है, एपीआई को बंद किया है, वगैरह, तो उपयोगकर्ता की निजता को नुकसान पहुंचाना. हालांकि, इस समय हम और डीबगिंग टूल उपलब्ध कराने की योजना नहीं बना रहे हैं, फिर भी हम इस बारे में फ़ीडबैक पाने के लिए तैयार हैं कि कौनसे टूल काम के होंगे. |
| निजी जानकारी वापस पाने (पीआईआर) | निजी जानकारी वापस पाने की सुविधा लागू करने के लिए, Topics API का अनुरोध | हमने पहले पीआईआर का इस्तेमाल करके जांच की थी और समझौते की जानकारी यहां शेयर की है. |
| बिड स्ट्रीम | क्या बिड स्ट्रीम में विषय को विक्रेता से तय की गई ऑडियंस से अलग तरीके से दिखाया जाएगा? | Topics API, प्राइवसी सैंडबॉक्स का एक प्रस्ताव है, जिसे Chrome ने बनाया है. यह IAB Tech Lab के विक्रेता की ओर से तय की गई ऑडियंस के प्रस्ताव से अलग है. हमें उम्मीद है कि बिडिंग में दोनों को अलग-अलग दिखाया जाएगा. जानें कि OpenRTB बिड रिक्वेस्ट में विषय कैसे दिखाए जाएंगे. |
Protected Audience API (पहले इसे FLEDGE कहा जाता था)
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| FLEDGE की सुविधा उपलब्ध है या नहीं | फ़ेंस किए गए फ़्रेम को लागू करने, के-ऐनिमिटी वगैरह जैसी FLEDGE की सुविधाओं की टेस्टिंग और उन्हें लागू करने की समयावधि के बारे में साफ़ तौर पर बताना. | हमने अलग-अलग स्कोप वाली FLEDGE की सुविधाओं के बारे में एक ब्लॉग पोस्ट शेयर किया है. साथ ही, यह भी बताया है कि ये सुविधाएं कब काम करेंगी. हम FLEDGE को लगातार डेवलप कर रहे हैं. इसलिए, अगर हम एलान के बारे में सुझाव देना चाहते हैं, तो हमें बताएं. |
| प्रॉडक्ट रेंडरिंग से जुड़ी पाबंदियां | FLEDGE की बाड़ वाले फ़्रेम के लिए, एक से ज़्यादा पीस वाले विज्ञापनों की पाबंदियों को ढीला करने का अनुरोध | जैसा कि हमने फ़रवरी में बताया था, फ़ेंस किए गए फ़्रेम का इस्तेमाल कम से कम 2026 तक ज़रूरी नहीं होगा. साथ ही, iframes का इस्तेमाल urn-iframe में किया जा सकेगा. हम इस विषय पर आगे की चर्चा का स्वागत करते हैं. |
| बढ़ाए जा सकने से जुड़ी समस्याएं | इस्तेमाल के पैमाने के हिसाब से FLEDGE की परफ़ॉर्मेंस | हम आपके सुझाव, शिकायत या राय पर लगातार नज़र रख रहे हैं और ज़्यादा संदर्भ को समझ रहे हैं, ताकि हम कार्रवाई करने लायक समाधान के सुझाव दे सकें. सबसे पहले, सुझाव को दो कैटगरी में बांटा गया:
|
| (साल 2022 की तीसरी तिमाही में भी इसकी रिपोर्ट दी गई है) बिडिंग लॉजिक का दिखना |
चिंता करें कि DSP बिडिंग लॉजिक को JavaScript में दिखाया जाएगा | पहली तिमाही में अपडेट: हमने एक प्रस्ताव शेयर किया है. इस सुविधा से, दुश्मनों को सर्वर से डेटा का अनुरोध करने की सुविधा सीमित तौर पर मिलेगी. जैसे, एक्सप्लोरेट्री (ज़बरदस्ती ब्राउज़िंग) के ज़रिए डेटा का अनुरोध करना. इसलिए, नेटवर्क चलाने वाले लोगों का स्वागत है, ताकि वे प्रस्ताव के लिए अपने सुझाव या सहायता शेयर कर सकें. |
| परीक्षण समस्याएं | छोटे डीएसपी को FLEDGE की सही तरीके से जांच करने की सुविधा मिलती है. साथ ही, उस जोखिम को कम किया जा सकता है जिसकी वजह से, विज्ञापन देने वाले लोग या कंपनियां, सिर्फ़ बड़े DSP के साथ टेस्ट करने में दिलचस्पी रखती हैं | हम छोटे डीएसपी के साथ काम करने के लिए प्रतिबद्ध हैं. साथ ही, FLEDGE किस तरह से सामान्य रूप से उपलब्ध होगा, इस बारे में जानने के लिए, हम सभी तरह के डीएसपी और विज्ञापन देने वालों के बीच टेस्टिंग को बढ़ावा देते हैं. हम जानना चाहेंगे कि नेटवर्क में दूसरे लोगों के साथ FLEDGE की टेस्टिंग करने में, हम किस तरह उनकी मदद कर सकते हैं. साथ ही, हम विज्ञापन देने वाली कंपनियों को छोटे डीएसपी से टेस्ट करने के लिए प्रेरित करने के आइडिया और इंडस्ट्री की कोशिशों का स्वागत करेंगे. |
| डायनैमिक रीमार्केटिंग | क्या तीसरे पक्ष की कुकी के बंद होने के बाद भी FLEDGE की मदद से डाइनैमिक रीमार्केटिंग की जा सकती है? | हम इस सवाल का जवाब देने पर विचार कर रहे हैं. साथ ही, हम नेटवर्क में काम करने वाले खिलाड़ियों का स्वागत करते हैं, ताकि वे डाइनैमिक रीमार्केटिंग इस्तेमाल करने के तरीके के बारे में ज़्यादा जानकारी पा सकें. |
| धोखाधड़ी/गलत इस्तेमाल | नेटवर्क, जोखिम को कैसे कम कर सकता है और बुरे मकसद से काम करने वाले लोगों या खरीदारों को पसंदीदा ऑडियंस के तौर पर दिखाने से कैसे रोक सकता है? | हम धोखाधड़ी और गलत इस्तेमाल के ख़िलाफ़ नेटवर्क चलाने वाली कंपनियों के साथ काम करने की उम्मीद करते हैं. साथ ही, हम इस बारे में आपके सुझाव, शिकायत या राय का स्वागत करते हैं. |
| उपयोगकर्ता प्राथमिकताएं | उपयोगकर्ता की प्राथमिकताओं को सेव करने और विज्ञापन चुनने में इस्तेमाल करने की प्रोसेस | खास विज्ञापनों के लिए, काम की विज्ञापन टेक्नोलॉजी सबसे बेहतर विकल्प होती है. इससे यह कंट्रोल किया जा सकता है कि कौनसे क्रिएटिव दिखाए जाएं या उन्हें कैसे चुना जाए. |
| क्वांटिटेटिव टेस्टिंग प्रपोज़ल | क्वान्टिटेटिव टेस्टिंग को सही साबित करने के लिए, क्या यह टेस्ट तीसरे पक्ष की कुकी के बिना किए जाने वाले ट्रैफ़िक पर किया जाना चाहिए या सिर्फ़ FLEDGE का इस्तेमाल करने वाले SSP के साथ किया जाना चाहिए? तीसरे पक्ष की कुकी के सिग्नल को मिक्स होने से कैसे रोका जा सकता है? | हम इस सुझाव की सराहना करते हैं. हम सीएमए के साथ मिलकर ऐसे प्रयोग तैयार कर रहे हैं जिनसे तीसरे पक्ष की कुकी के बंद होने और नेटवर्क पर प्राइवसी सैंडबॉक्स के प्रपोज़ल के लॉन्च होने की सटीक जानकारी मिलेगी. हम चाहते हैं कि सीएमए के क्वांटिटेटिव टेस्टिंग प्रपोज़ल पर अतिरिक्त सुझाव, शिकायत या राय को सीधे सीएमए के साथ शेयर किया जाए. |
| ज़्यादा साफ़ तौर पर जानकारी देने वाला दस्तावेज़ | नीलामी के कॉन्फ़िगरेशन के बारे में साफ़ तौर पर जानकारी देने वाले दस्तावेज़ के लिए अनुरोध | आने वाले हफ़्तों में, हम FLEDGE की नीलामी की रिपोर्टिंग के बारे में ज़्यादा जानकारी के साथ एक ब्लॉग पोस्ट शेयर करेंगे. |
| साथ-साथ जोड़ना | क्या बिडिंग और नीलामी (B&A) सेवा, एक-दूसरे के साथ काम करेगी? | बिडिंग / नीलामी सर्वर का इस्तेमाल करने वाली विज्ञापन टेक्नोलॉजी, ऐसे कई सर्वर शुरू कर सकती है जो साथ-साथ नतीजे दे सकते हैं. |
| गलत इस्तेमाल को कम करना | क्या प्राइवेट स्टेट टोकन का इस्तेमाल करने वाले FLEDGE के-ऐनिमिटी सर्वर को, उपयोगकर्ता की निजता को बनाए रखने के लिए काफ़ी होगा? | के-ऐनॉनिमिटी को बढ़ाने का मकसद, माइक्रोटारगेटिंग पर कम और उस समय के दौरान कुछ बैकस्टॉप पर फ़ोकस करना है जहां FLEDGE इवेंट-लेवल रिपोर्टिंग की अनुमति देता है. हमने इस बारे में आपके साथ और राय शेयर की है. साथ ही, आपके पास सुझाव, राय या शिकायतका स्वागत है. |
| ईएस मॉड्यूल में गड़बड़ी | generateBid को ग्लोबल फ़ंक्शन के तौर पर छोड़ने का अनुरोध करें, क्योंकि यह ES मॉड्यूल से मेल नहीं खाता |
हम इस अनुरोध पर चर्चा कर रहे हैं और अन्य सुझावों का स्वागत करते हैं. |
| कॉम्पोनेंट नीलामी | नीलामी के डिज़ाइन पर पब्लिशर को ज़्यादा कंट्रोल देने का अनुरोध | डिवाइस पर Chrome की तरह ही कॉम्पोनेंट की नीलामी का भी इस्तेमाल करने के लिए बिडिंग और नीलामी की योजना. |
| B&A की टाइमलाइन | B&A सर्वर की जांच में दिलचस्पी रखने वाली विज्ञापन टेक्नोलॉजी से जुड़ी टाइमलाइन की समयावधि | हमने हाल ही में B&A का एक्सप्लेनर अपडेट किया है. साथ ही, हमने टाइमलाइन सेक्शन को अपडेट किया है, ताकि सीएमए के साथ अलाइन करने के बाद, Chrome-B&A टेस्टिंग के अलग-अलग चरणों के लिए, टाइमलाइन की साफ़ तौर पर जानकारी दी गई हो. |
| टाइम आउट कंट्रोल स्कीम | FLEDGE के लिए उपलब्ध टाइम आउट कंट्रोल स्कीम को बेहतर बनाना | यह एक दिलचस्प प्रस्ताव है. हम इसे अध्ययन और अपने विकास पर रिपोर्ट करने के लिए प्रस्तावों की सूची में जोड़ देंगे. |
| क्रिएटिव बिडस्ट्रीम | क्रिएटिव के आधार पर, सफल बिड की समीक्षा करने और उसे फ़िल्टर करने की सुविधा | यह एक दिलचस्प प्रस्ताव है. हम इसे अध्ययन और अपने विकास पर रिपोर्ट करने के लिए प्रस्तावों की सूची में जोड़ देंगे. |
reportWin |
reportWin फ़ंक्शन के विजेता के अलावा किसी अन्य इंटरेस्ट ग्रुप के मालिक की सबसे ज़्यादा स्कोर वाली बिड के बारे में
ज़्यादा जानकारी देने का प्रस्ताव |
यह एक दिलचस्प प्रस्ताव है. हम एग्रीगेट रिपोर्टिंग में, अतिरिक्त सिग्नल जोड़ने पर विचार करेंगे. साथ ही, आपको यहां अपने सुझाव या राय दें. |
| इवेंट किस तरह के हैं | FLEDGE के साथ इंटिग्रेट किए जाने पर, मेज़रमेंट एपीआई में इवेंट के टाइप का स्टैंडर्ड तय करना | यह एक दिलचस्प प्रस्ताव है. हम इसे अध्ययन और अपने विकास पर रिपोर्ट करने के लिए प्रस्तावों की सूची में जोड़ देंगे. इस क्षेत्र में हमारी कोशिशों के साथ मिलकर काम करने की ज़रूरत होगी. इससे FLEDGE के अलावा, अन्य प्राइवसी सैंडबॉक्स एपीआई पर भी असर पड़ेगा. हमारे आपके और सुझाव, राय या शिकायत यहां दिए जा सकते हैं. |
| इवेंट-लेवल रिपोर्टिंग के लिए लंबे समय तक चलने वाले समाधान | तीसरे पक्ष की कुकी का इस्तेमाल बंद करने के बाद भी, highestScoringOtherBid जैसे कुछ डेटा को बनाए रखने में दिलचस्पी है |
जैसा कि हमने फ़रवरी ब्लॉग पोस्ट में बताया था कि इवेंट-लेवल पर नीलामी जीतने की रिपोर्टिंग, "कम से कम 2026" तक उपलब्ध रहेगी. हमारे पास इस समय शेयर करने के लिए और जानकारी नहीं है. हालांकि, हम इस बारे में अतिरिक्त सुझाव, शिकायत या राय का स्वागत करते हैं कि तीसरे पक्ष की कुकी के बंद होने के बाद, कुछ डेटा को उपलब्ध कराना क्यों ज़रूरी है. |
| एक जैसी दिलचस्पी वाले ग्रुप की सीमा | कोई ऑरिजिन किसी एक ब्राउज़र में, ज़्यादा से ज़्यादा कितने इंटरेस्ट ग्रुप जोड़ सकता है? | Chrome में हर मालिक के लिए, ज़्यादा से ज़्यादा 1,000 इंटरेस्ट ग्रुप और 1,000 इंटरेस्ट ग्रुप के मालिक जोड़े जा सकते हैं. इनका मकसद सीमा तय करना है, न कि नियमित तौर पर काम करना. |
| इवेंट-लेवल के सिग्नल | generateBid और reportWin के लिए, इवेंट-लेवल के सिग्नल शामिल करने के प्रस्ताव के लिए सहायता,
जिसे मशीन लर्निंग ट्रेनिंग में इस्तेमाल किया जा सकता है |
हमने ब्राउज़र के डिज़ाइन किए गए सिग्नल और विज्ञापन टेक्नोलॉजी से तय किए गए सिग्नल के लिए, अपना फ़ैसला शेयर किया है. साथ ही, आपके पास अपने सुझाव, शिकायत या राय का भी स्वागत है. |
| बोली-प्रक्रिया स्क्रिप्ट | बिडिंग स्क्रिप्ट के यूआरएल में, यूज़र आईडी शामिल करें. | ऐसा नहीं किया जा सकता. ऐसा इसलिए, क्योंकि FLEDGE में अतिरिक्त शर्त है कि इंटरेस्ट ग्रुप के मालिक के टपल, बिडिंग स्क्रिप्ट यूआरएल, और रेंडर किए गए क्रिएटिव को दिखाने के लिए, के-अनाम होने चाहिए. |
| K-anon एनफ़ोर्समेंट | क्या (कॉम्पोनेंट विज्ञापन, साइज़) पेयर पर के-अनामता को लागू किया गया है? | हां. टर्टलडोव/issues/312 देखें. |
| बिडिंग और नीलामी सेवाओं से जुड़ी ज़रूरी शर्तें | B&A सेवाएं, डिवाइस पर मौजूद FLEDGE और अन्य B&A सेवाओं से इंटिग्रेट करने में लोगों की मदद कैसे करती हैं? | हम अब भी डिज़ाइन को तैयार कर रहे हैं और आपके सुझाव, राय या शिकायत का स्वागत है. |
| व्यू के बाद एट्रिब्यूशन | क्या पोस्ट-व्यू एट्रिब्यूशन काम करेगा? | फ़िलहाल, हमारे पास विज्ञापन दिखने से जुड़े आंकड़ों की कोई स्टैंडर्ड डेफ़िनिशन नहीं है. इसलिए, किसी व्यू इवेंट को मार्क करने के लिए क्रिएटिव पर ही निर्भर रहने की ज़रूरत होती है. टर्टलडोव/issues/452 देखें. |
| एक जैसी टारगेटिंग | क्या प्राइवसी सैंडबॉक्स, "एक जैसी टारगेटिंग" की सुविधा देता है? | हम यहां इस्तेमाल के उदाहरण पर चर्चा कर रहे हैं. साथ ही, कुछ और इनपुट दें. |
| रीयल-टाइम मॉनिटरिंग एपीआई | रीयल-टाइम में FLEDGE की निगरानी के तरीके का प्रस्ताव | हम प्रस्ताव पर चर्चा कर रहे हैं और यहां दूसरे इनपुट का स्वागत करते हैं. |
| FLEDGE रिपोर्टिंग | reportWin और reportResult को किसी भी क्रम में बनाया जाना चाहिए, ताकि रिपोर्टिंग या
कम रिपोर्टिंग से बचा जा सके. |
reportResult() को खरीदार से पहले
reportWin() लागू करना ज़रूरी है, ताकि reportResult()
के सेलर सिग्नल को reportWin() में शामिल किया जा सके. ज़्यादा जानकारी के लिए, एक्सप्लेनर देखें. |
| कस्टम कुंजी मान (K/V) सर्वर | क्या आने वाले समय में कस्टम K/V सर्वर काम करेंगे? | हम यहां इस सवाल पर चर्चा कर रहे हैं और अगर कोई और इनपुट दें, तो आपका स्वागत है. |
| टॉप लेवल की नीलामी | क्या टॉप-लेवल की नीलामी करने के लिए, कोई विज्ञापन सर्वर होना ज़रूरी है? | FLEDGE API यह नहीं बताता कि किस पक्ष को इसे कॉल करना चाहिए; FLEDGE के डिज़ाइन में इस तरह की कोई शर्त नहीं है. FLEDGE नीलामी कोई भी चला सकता है. इसमें एक से ज़्यादा सेलर वाली नीलामियां भी शामिल हैं. जैसा कि 2022 की चौथी तिमाही की रिपोर्ट में बताया गया है, FLEDGE की मदद से हर पब्लिशर नीलामी की बनावट चुन सकता है. इसमें टॉप लेवल और कॉम्पोनेंट सेलर का विकल्प भी शामिल है. |
| API का दायरा | क्या FLEDGE, पहले पक्ष (ग्राहक) के डेटा के साथ काम करेगा? | हम 2023 की दूसरी तिमाही में कॉन्टेंट पब्लिश करेंगे. इसमें साफ़ तौर पर बताया जाएगा कि पहले पक्ष (ग्राहक) का डेटा FLEDGE की मदद से इस्तेमाल किया जा सकता है. दोनों के लिए, 1) इंटरेस्ट ग्रुप की सदस्यता तय करने के लिए उस डेटा को लॉजिक के तौर पर इस्तेमाल किया जा सकता है. दूसरा, बिडिंग लॉजिक जनरेट करने के लिए, उसे यूज़र बिडिंग सिग्नल के तौर पर फ़ीड किया जा सकता है. |
| क्रॉस-डोमेन इंटरेस्ट ग्रुप | क्रॉस-डोमेन इंटरेस्ट ग्रुप बनाने की संभावना | किसी इंटरेस्ट ग्रुप में ब्राउज़र जोड़ते समय उपलब्ध किसी भी जानकारी का इस्तेमाल, उस ऑडियंस को बताने के लिए किया जा सकता है. तीसरे पक्ष की कुकी के इस्तेमाल को बंद करने के बाद, इंटर-साइट डेटा की उपलब्धता सीमित हो जाएगी. |
| क्लाइंट-साइड बिडिंग का लॉजिक | मौजूदा सर्वर-साइड बिडिंग लॉजिक को क्लाइंट साइड पर पोर्ट करना | हम इस बारे में ज़्यादा जानना चाहते हैं कि कौनसे क्षेत्र चुनौती भरे हैं या फ़िलहाल पोर्ट करने की प्रक्रिया में कमियां हैं. साथ ही, हम आपके किसी भी अन्य सुझाव या अहम जानकारी का स्वागत करते हैं. |
| K/V सर्वर मान | क्या K/V सर्वर मान किसी प्रकार की स्ट्रिंग होने चाहिए? | वैल्यू कोई स्ट्रिंग होनी चाहिए. हालांकि, वे ऑब्जेक्ट को JSON या प्रोटोकॉल बफ़र में स्टोर कर सकते हैं और उन्हें स्ट्रिंग में बदल सकते हैं. |
| विज्ञापन देने वाले की ब्लॉकलिस्ट | विज्ञापन देने वाले की ब्लॉकलिस्ट में, खरीदार को किस तरह का सिग्नल देना सही होगा? | सही जगह या तो auctionSignals में है या
perBuyerSignals में है. |
| बिडिंग यूनिट | सीपीआई और सीपीएम जैसी अलग-अलग बिडिंग यूनिट के लिए सहायता | हम इस बारे में ज़्यादा जानना चाहते हैं कि मौजूदा डिज़ाइन को देखते हुए इसकी ज़रूरत क्यों है. साथ ही, हम इसके अतिरिक्त सुझाव जानना चाहेंगे. |
| नीलामी का लॉजिक | क्या नीलामी का विजेता ब्राउज़र या विज्ञापन सर्वर तय करता है? | सभी विजेता सैंडबॉक्स के अंदर चुने जाते हैं और सभी फ़ैसले विक्रेता का कोड तय करते हैं. ब्राउज़र बस एक सीमित, निजी माहौल उपलब्ध कराता है, जिसमें खरीदार और विक्रेता कोड चलते हैं. |
| अनुमतियों से जुड़ी नीति | क्या ऑरिजिन ट्रायल खत्म होने के बाद भी, मौजूदा FLEDGE की अनुमतियों से जुड़ी नीति लागू रहेगी? | ऑरिजिन ट्रायल के लिए, दोनों सुविधाओं की डिफ़ॉल्ट तौर पर अनुमति वाली सूची में कुछ समय के लिए बदलाव होंगे. इन्हें बदल दिया जाएगा. हम जानना चाहते हैं कि इस बदलाव को लागू करने से पहले विज्ञापन टेक्नोलॉजी को कितने समय के लिए तैयार करना होगा. |
| सिग्नल साइज़ का कंस्ट्रेंट | 'भरोसेमंद बिडिंग सिग्नल' के अनुरोध, एक ही trustedBiddingSignalsUrl वाले कई इंटरेस्ट ग्रुप में इकट्ठा किए जाते हैं. हालांकि, 2 एमबी के साइज़ की सीमा सीमित होती है. |
कंस्ट्रेंट की सुविधा ऑन-डिवाइस कॉलर के लिए मौजूद है, ताकि डिवाइस पर ज़्यादा रिसॉर्स को ऐक्सेस किया जा सके. B&A सर्वर के कॉल करने वालों को एक ज़्यादा आराम सीमा मिलेगी. |
| रिपोर्टिंग सिग्नल | एक और सिग्नल यानी स्क्रिप्ट की गड़बड़ियां जोड़ें, ताकि हर इंटरेस्ट ग्रुप के मालिक और हर computeBid या reportWin / reportResult के लिए क्लाइंट-साइड की गड़बड़ियों की संख्या फिर से हासिल की जा सके. |
हम इस प्रस्ताव में निजता से जुड़ी संभावित समस्याओं पर विचार कर रहे हैं. साथ ही, नेटवर्क बनाने वाली कंपनियों का स्वागत करते हैं, ताकि वे इस बारे में अहम जानकारी शेयर कर सकें कि ऐसा क्यों करना ज़रूरी है. |
| K-Anon विंडो का साइज़ | K-Anon विंडो का साइज़ सात दिनों की मौजूदा सीमा से बढ़ाएं. | इस पर विचार किया जा रहा है. फ़िलहाल, हमें नेटवर्क से अतिरिक्त इनपुट का इंतज़ार है. |
| डिवाइस के हिसाब से परफ़ॉर्मेंस | अगर उपयोगकर्ता बड़ी संख्या में इंटरेस्ट ग्रुप में है, तो FLEDGE, डिवाइस की परफ़ॉर्मेंस को कैसे मैनेज करता है? | FLEDGE, SSP और DSP के लिए टाइम आउट, प्राथमिकता, और सीमा के कई विकल्प देता है. ये विकल्प ऐसी स्थितियों में विज्ञापन टेक्नोलॉजी को बेहतर कंट्रोल देते हैं जहां डिवाइस की परफ़ॉर्मेंस, नीलामी में हिस्सा लेने की सुविधा को सीमित करने की वजह हो सकती है. |
| बीऐंडए सेवाओं की टेस्टिंग | नेटवर्क प्लेयर से अनुरोध करें कि वे टेस्टिंग के दौरान अपने सर्वर का इस्तेमाल करें, ताकि डीबग करने के लिए ज़्यादा लॉग उपलब्ध हो सकें | B&A से उपयोगकर्ता, अनुमति पा चुके क्लाउड प्रोवाइडर से सर्वर लॉन्च और स्केल कर पाते हैं. उपयोगकर्ता की निजता बनाए रखने के लिए, हम एक्ज़ीक्यूशन लागू करते हैं. इसके लिए, हम भरोसेमंद एक्ज़ीक्यूशन एनवायरमेंट (टीईई) का इस्तेमाल करते हैं. हम जल्द ही B&A TEE को डीबग करने की जानकारी देने वाला वीडियो रिलीज़ करेंगे. साथ ही, इसमें सहायता के लिए सुविधाएं डेवलप की जा रही हैं. हम इस विषय पर और सुझाव चाहिए. |
| नियमों के पालन की ज़रूरी शर्तें | क्या FLEDGE, स्थानीय कानून की ज़रूरी शर्तों का पालन करने के लिए अलग-अलग देशों में क्लाउड सेवा देने वाली कंपनियों के साथ काम करेगा? | हम अन्य क्लाउड सेवा देने वाली कंपनियों के सुझावों के लिए हमेशा तैयार रहते हैं. हालांकि, तीसरे पक्ष की कुकी का इस्तेमाल रोकने की सुविधा लागू होने पर, हम कम से कम GCP और AWS के साथ काम करने की योजना बना रहे हैं. ज़्यादा जानकारी के लिए, यह जानकारी देखें. |
डिजिटल विज्ञापनों का आकलन करना
एट्रिब्यूशन रिपोर्टिंग (और दूसरे एपीआई)
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| शोर के असर से जुड़े डेटा का विश्लेषण | शोर के असर का डेटा विश्लेषण करने के तरीके के बारे में दिशा-निर्देश | हमने शोर और डिज़ाइन से जुड़े फ़ैसलों से जुड़े अतिरिक्त दस्तावेज़ शेयर किए हैं. इनका इस्तेमाल, विज्ञापन टेक्नोलॉजी से जुड़े डेटा पर, ग़ैर-ज़रूरी आवाज़ों के असर को बदलने के लिए किया जा सकता है. ज़्यादा जानकारी वाली गाइड भी उपलब्ध है. |
| शून्य रिपोर्टिंग | शून्य रिपोर्ट लागू करने के बारे में साफ़-साफ़ जानकारी | फ़िलहाल, हम शून्य रिपोर्ट को लागू करने के प्रस्ताव पर काम कर रहे हैं. इसके बारे में, हम जल्द ही ज़्यादा जानकारी शेयर करेंगे. शून्य रिपोर्ट लागू करने से, हमें निजता से समझौता किए बिना, रिपोर्ट में होने वाली देरी को कम करने में मदद मिलेगी. |
| शोर का स्तर | एट्रिब्यूशन विंडो की लंबाई के आधार पर, गै़र-ज़रूरी डेटा के लेवल में बदलाव करना | हम इस प्रस्ताव का स्वागत करते हैं और हम इसे जानकारी में शामिल करने पर काम कर रहे हैं. हम अन्य सुझाव, शिकायत या राय का स्वागत करते हैं. |
| ट्रिगर डेटा का साइज़ | ट्रिगर डेटा का साइज़ तीन बिट तक सीमित क्यों है? | इसका साइज़ तीन बिट और आठ अलग-अलग वैल्यू तक सीमित है. इससे यह पक्का होता है कि किसी उपयोगकर्ता के बारे में क्रॉस-साइट/कॉन्टेक्स्ट की जानकारी सीमित है. हम नेटवर्क के खिलाड़ियों का सुझाव, शिकायत या राय सबमिट करने के लिए स्वागत करते हैं. इससे वे यह तय कर सकते हैं कि इवेंट-लेवल रिपोर्टिंग के लिए, मौजूदा पैरामीटर का इस्तेमाल करना सही है या नहीं. |
| इवेंट-लेवल रिपोर्टिंग ट्रिगर | डुप्लीकेट कॉपी हटाने की तकनीक वाली कुंजी में प्राथमिकता की अनुमति देना | हम इस समस्या के समाधान की कोशिश कर रहे हैं और हमें अपने सुझाव और राय दें. |
| डीबग करने की सुविधा | तीसरे पक्ष की कुकी के बंद होने के बाद, डीबग करने से जुड़ी जानकारी | हम तीसरे पक्ष की कुकी के बंद होने के बाद, डीबग करने का समर्थन करना चाहते हैं और विकल्पों के बारे में सोच रहे हैं. हम ज़्यादा सुझाव और राय ले रहे हैं. |
| क्लिक थ्रू कन्वर्ज़न (दर्शक का ग्राहक बनना) के अन्य विकल्प | क्लिक-थ्रू कन्वर्ज़न (दर्शक का ग्राहक बनना) के विकल्पों के बारे में ज़्यादा जानकारी पाने का अनुरोध | हम लागू होने वाले कन्वर्ज़न मेज़रमेंट के इस्तेमाल के उदाहरणों के लिए, नेटवर्क को Attribution Reporting API का इस्तेमाल एक मज़बूत निजी मेज़रमेंट सिस्टम के तौर पर करने के लिए बढ़ावा देते हैं. दूसरे विकल्प मौजूद हैं और विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली कंपनियों को अपनी ज़रूरत के हिसाब से सही समाधान तय करना होगा. |
| बिलिंग के इस्तेमाल के उदाहरण | इस बात की साफ़ तौर पर जानकारी कि एट्रिब्यूशन रिपोर्टिंग से, कन्वर्ज़न-आधारित बिलिंग के इस्तेमाल के मामलों में, किस हद तक मदद मिलेगी | हम बिलिंग के लिए Attribution Reporting API के
दायरे को समझाने के लिए, सार्वजनिक तौर पर पोस्ट करने पर काम कर रहे हैं. Attribution Reporting API की शुरुआत
इस तरह से नहीं की गई थी कि सीधे तौर पर सीपीए बिलिंग की सुविधा मिलती हो. इसमें, सीपीसी और सीपीएम बिलिंग का भी इस्तेमाल किया जा सकता है. इस बिलिंग स्ट्रक्चर का इस्तेमाल,
विज्ञापन टेक्नोलॉजी से जुड़ी ज़्यादातर कंपनियां करती हैं. अगर आने वाले समय में हमें नेटवर्क के बारे में कोई और सुझाव/राय देनी है या शिकायत करनी है, तो इस सुविधा में हमारी मदद की जा सकती है. |
| केस सपोर्ट का इस्तेमाल करें | मेज़रमेंट एपीआई के लिए, केस दस्तावेज़ का इस्तेमाल करें | हम प्राइवसी सैंडबॉक्स के सभी रिपोर्टिंग प्लैटफ़ॉर्म से जुड़े दस्तावेज़ को बेहतर बनाने के लिए काम कर रहे हैं. |
| क्लिक गुणवत्ता | विज्ञापन पर जान-बूझकर और अनजाने में किए गए क्लिक के बीच अंतर करने के लिए, सिग्नल जोड़ने का अनुरोध करें | हम अनुरोध पर चर्चा कर रहे हैं और आपको कई और इनपुट दे रहे हैं. |
| परफ़ॉर्मेंस मापने का तरीका | एक से ज़्यादा डीएसपी में मेज़रमेंट के समाधान के लिए सहायता | Attribution Reporting API का इस्तेमाल, मेज़रमेंट सेवा देने वाली कंपनियां
एक से ज़्यादा डीएसपी के बीच डुप्लीकेट डेटा बनाने के लिए कर सकती हैं. इसके अलावा, हम attributionsrc में यूआरएल की सूची के लिए सहायता का सुझाव दे रहे हैं. इससे डीएसपी को मेज़रमेंट प्रोवाइडर एट्रिब्यूशन रिपोर्टिंग एपीआई अनुरोधों में मदद करना आसान हो जाएगा. हम ऊपर दिए गए प्रस्ताव पर
किसी भी अतिरिक्त सुझाव का स्वागत करते हैं. |
| इवेंट के लेवल पर रिपोर्टिंग | रिपोर्ट सीधे भेजे जाने से पहले दिनों की संख्या बताने का अनुरोध करें | विज्ञापन टेक्नोलॉजी से जुड़ी टेक्नोलॉजी इस अनुरोध का हिसाब पहले से ही, मौजूदा जानकारी का इस्तेमाल करके लगा सकती हैं. हमने इस अनुरोध से जुड़ा कोई और नेटवर्क फ़ीडबैक नहीं सुना है. हालांकि, हम इस बारे में सुझाव देने के लिए तैयार हैं. |
source_registration_time |
इवेंट-लेवल की एट्रिब्यूशन रिपोर्टिंग में source_registration_time जोड़ें. |
हम इस अनुरोध पर विचार कर रहे हैं. साथ ही, हम इस बारे में अन्य सुझाव, शिकायत या राय का स्वागत कर रहे हैं कि क्या नेटवर्क इस्तेमाल करने वालों के लिए यह सुविधा काम की है. |
| गुप्त मोड | क्या उपयोगकर्ता के गुप्त मोड में होने पर, मेज़रमेंट के तरीके उपलब्ध होंगे? | नहीं, उपयोगकर्ता के गुप्त मोड में होने पर, मेज़रमेंट के तरीके उपलब्ध नहीं होंगे. गुप्त मोड में तीसरे पक्ष की कुकी डिफ़ॉल्ट रूप से बंद होती हैं. |
| डेटा हटाने की सुविधा वाले कमरे | क्या मेज़रमेंट एपीआई को साफ़ कमरों के साथ इस्तेमाल किया जा सकता है? | सामान्य डेटा के लिए क्लीन रूम एक ऐसा माहौल होता है जिसमें अलग-अलग सोर्स से मिले आइडेंटिफ़ायर के डेटा को डेटाबेस में अपलोड किया जाता है, ताकि उस डेटा को मर्ज करके उसका विश्लेषण किया जा सके. प्राइवसी सैंडबॉक्स एपीआई के लिए, इवेंट-लेवल की रिपोर्ट और खास जानकारी वाली रिपोर्ट दो मेज़रमेंट फ़्रेमवर्क हैं. इवेंट-लेवल की रिपोर्ट में विज्ञापन टेक्नोलॉजी से उपलब्ध कराया गया इवेंट-आईडी होता है, जिसका इस्तेमाल डेटा क्लीनअप में किया जा सकता है. हालांकि, इससे जुड़ी कन्वर्ज़न-साइड की जानकारी सीमित होगी और उसमें बहुत ज़्यादा शोर नहीं होगा. एन्क्रिप्ट की गई एग्रीगेटेड रिपोर्ट का इस्तेमाल सीधे किसी साफ़-सुथरे रूम में नहीं किया जा सकता. हालांकि, एग्रीगेशन सेवा से मिले खास जानकारी वाले नतीजों का इस्तेमाल, आपके परफ़ॉर्म किए जा रहे विश्लेषण या पूरक जानकारी के तौर पर इनपुट के तौर पर किया जा सकता है. |
एग्रीगेशन सेवा
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| (साल 2022 की चौथी तिमाही में भी रिपोर्ट की गई) रिपोर्ट में देरी |
रिपोर्टिंग में कितनी देरी हो सकती है? | साल 2023 की पहली तिमाही में हुआ अपडेट: पार्टनर से मिले सुझाव के आधार पर, हमने देरी को कम करने और देरी के असर को कम करने के लिए प्रस्ताव शेयर किए हैं. डब्ल्यूआईसीजी कॉल के दौरान विज्ञापन टेक्नोलॉजी, दोनों प्रस्तावों के साथ काम करती हैं. |
| कोई डुप्लीकेट नियम नहीं है | अगर एक ही 'शेयर किए गए आईडी' वाली एग्रीगेट रिपोर्ट पहले से ही प्रोसेस हो चुकी हैं, तो "देर से इकट्ठा की गई रिपोर्ट" को कैसे मैनेज किया जा सकता है? | हमने एग्रीगेट एपीआई में होने वाली देरी के असर को कुछ हद तक हल करने के लिए, एक प्रस्ताव शेयर किया है. इसमें बताया गया है कि एग्रीगेट की जा सकने वाली रिपोर्ट की शेयर की गई जानकारी में, रिपोर्ट में देरी और एग्रीगेशन सेवा के लिए शेयर किए गए आईडी की परिभाषा को कैसे जोड़ा जा सकता है. प्रस्ताव पर किसी भी तरह के सुझाव, राय या शिकायत का हम स्वागत करते हैं. |
| डेटा प्रोसेसिंग | निजता बजट का इस्तेमाल करके डिफ़रेंशियल प्राइवसी को ध्यान में रखते हुए, डेटा के एक से ज़्यादा पास को इस्तेमाल करने की सुविधा चालू करने का अनुरोध करें | हम इस इस्तेमाल के उदाहरण को चालू करने के लिए, निजता बजट के ज़्यादा सुविधाजनक तरीके इस्तेमाल करने की संभावना पर चर्चा कर रहे हैं. साथ ही, हम अतिरिक्त सुझावों का स्वागत करते हैं. |
| (2022 की दूसरी तिमाही में भी रिपोर्ट की गई) क्वेरी अर्गोनॉमिक्स | कुंजियों के एग्रीगेट के आधार पर क्वेरी करने की सुविधा चालू करता है. | साल 2023 की पहली तिमाही का अपडेट: इस सुविधा के अनुरोध पर अब भी विचार किया जा रहा है. हालांकि, फ़िलहाल हमारे पास शेयर करने का कोई प्रस्ताव नहीं है. |
| ऑरिजिन ट्रायल की सीमाएं | एग्रीगेशन सेवा के दायरे के बारे में साफ़ तौर पर बताएं, जैसे कि "कोई डुप्लीकेट नियम नहीं", जिसे फ़िलहाल ऑरिजिन ट्रायल पर लागू नहीं किया जाता. | हम अपने दस्तावेज़ को अपडेट कर रहे हैं, ताकि यह साफ़ किया जा सके कि ऑरिजिन ट्रायल में और GA में क्या उपलब्ध होगा. |
निजी एग्रीगेशन एपीआई
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| निजी एग्रीगेशन योगदान का बजट | L1 के योगदान के लिए तय किया गया बजट बहुत सीमित है. | Private एग्रीगेशन API को किए जाने वाले हर कॉल को योगदान कहा जाता है. उपयोगकर्ता की निजता की सुरक्षा के लिए, किसी व्यक्ति से इकट्ठा किए जा सकने वाले योगदान की संख्या सीमित होती है. जब सभी एग्रीगेशन कुंजियों की एग्रीगेट की जा सकने वाली सभी वैल्यू को जोड़ा जाता है, तब कुल योग, योगदान के बजट से कम होना चाहिए. मौजूदा डिज़ाइन में, हम पिछले 24 घंटों में किसी खास रिपोर्टिंग ऑरिजिन के लिए, योगदान की सीमा तय करते हैं. इस सीमा को रोलिंग विंडो के तौर पर इस्तेमाल किया जाता है. यह L1 योगदान का बजट है, जिसके बारे में सुझाव में बताया गया है. हमारा सुझाव है कि डेवलपर, योगदान की वैल्यू को अनुमानित वॉल्यूम के हिसाब से बढ़ाएं. जैसे, सिर्फ़ 1 वैल्यू का इस्तेमाल न करें. इसलिए, ज़्यादा सामान्य इवेंट के लिए कम वैल्यू का इस्तेमाल करना सही रहेगा, ताकि बजट खत्म होने से बचा जा सके. फ़िलहाल, हम प्राइवेट एग्रीगेशन एपीआई के योगदान बजट को लेकर, न्यूमेरिक बाउंड और स्कोप, दोनों के लिए सुझाव, शिकायत या राय मांग रहे हैं. हम हर ऑरिजिन से हर साइट के लिए स्कोप को ले जाने पर विचार कर रहे हैं. साथ ही, मौजूदा बाउंड्री को 10 मिनट की विंडो पर ले जाने पर विचार कर रहे हैं. इसमें रोज़ाना की ज़्यादा सीमा भी शामिल होगी. |
कवर ट्रैकिंग को सीमित करें
उपयोगकर्ता-एजेंट को कम करना/उपयोगकर्ता-एजेंट क्लाइंट-हिंट
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| UA-R का इस्तेमाल | यूके की टॉप 10,000 साइटों में से, प्रोग्रामैटिक विज्ञापन का इस्तेमाल करने वाली सिर्फ़ 1% साइटें ही एचटीटीपी क्लाइंट हिंट भेज रही हैं. जो डीएसपी माइग्रेट नहीं हुए हैं वे धोखाधड़ी रोकने वाली सुविधाओं पर असर डाल सकते हैं. | एक ही डेटा सेट का विश्लेषण करने के बाद हमें पता चला है कि अगर एचटीएमएल <meta> टैग और JavaScript API के ज़रिए UA-CH के इस्तेमाल को ध्यान में रखा जाता है, तो UA-CH का इस्तेमाल करने वाली साइटों की संख्या, सुझाव में दिए गए 1% आंकड़ों से काफ़ी ज़्यादा है. इसके और नेटवर्क से मिले सुझाव जैसे दूसरे तथ्यों के आधार पर, हम उम्मीद करते हैं कि पब्लिश की गई टाइमलाइन के मुताबिक, UA रिडक्शन के छठे चरण को धीरे-धीरे लॉन्च किया जाएगा. साथ ही, सीएमए को इसकी जानकारी दी जाएगी. हमने देखा है कि साइटों को ट्रांज़िशन के लिए तैयार होने में करीब दो साल का समय लगा है. जिन साइटों को लगता है कि वे अपने लिए तैयार नहीं हैं, उनके लिए अब भी एक सुविधा बंद करने का ट्रायल उपलब्ध है. |
| डिवाइस के अन्य नाप या आकार के लिए संकेत | UA-CH का अनुरोध करें कि वह टीवी, वीआर जैसे अन्य डिवाइसों के नाप या आकार की जानकारी दे | हम इस प्रस्ताव का स्वागत कर रहे हैं और हम इसे डिज़ाइन में शामिल करने की कोशिश कर रहे हैं. हम आपके अतिरिक्त सुझाव का स्वागत करते हैं. |
| ऑटोमेटेड टेस्टिंग | UAR चरण 6 के शिप होने से पहले, हेडलेस Chrome में UA-CH बग को ठीक करने का अनुरोध करें | जिस गड़बड़ी की शिकायत की गई थी उसे ठीक कर दिया गया है. |
| iOS पर UA-CH सहायता | अगर किसी साइट में विज्ञापन दिखाने के लिए, UA की पूरी जानकारी का इस्तेमाल किया जाता है, तो ध्यान दें कि iOS पर Chrome काम नहीं करता. | Safari के अलावा दूसरे iOS ब्राउज़र (इनमें iOS पर Chrome भी शामिल है) के लिए, WebKit प्रोजेक्ट को चालू करने से पहले UA-CH के लिए सहायता जोड़ना ज़रूरी होगा (क्योंकि वे नेटवर्क स्टैक को कंट्रोल करते हैं). |
आईपी सुरक्षा (पहले इसे Gnatcatcher कहा जाता था)
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| (चौथी तिमाही में भी रिपोर्ट किए गए) जियोलोकेशन के इस्तेमाल के उदाहरण | आईपी सुरक्षा की वजह से, सही भौगोलिक जगह के इस्तेमाल के मामलों को आने वाले समय में काम करने से रोका जा सकता है. उदाहरण के लिए, जगह की जानकारी के हिसाब से कॉन्टेंट को उपयोगकर्ता के मनमुताबिक बनाने की सुविधा. | साल 2022 की चौथी तिमाही से, इस जवाब में कोई बदलाव नहीं किया गया है: "हम पार्टनर के साथ मिलकर काम कर रहे हैं, ताकि यह पक्का कर सकें कि Chrome, आईपी पतों के इस्तेमाल के उचित मामलों में मदद करता रहे. हम आईपी जियोलोकेशन की जानकारी के स्तर के बारे में, नेटवर्क से जुड़े सुझाव मांग रहे हैं." |
| नियामक अनुपालन | अगर किसी इलाके की जनसंख्या 10 लाख से कम है, तो आईपी सुरक्षा के लिए 10 लाख का मौजूदा थ्रेशोल्ड, वेबसाइटों को कानून का पालन करने के लिए, आईपी पतों का इस्तेमाल करने से रोकेगा. | हम यह पक्का करने के लिए हिस्सेदारों के साथ काम कर रहे हैं कि Chrome, आईपी पतों के इस्तेमाल के उचित मामलों में लगातार मदद करे. हम आईपी सुरक्षा के कानून के पालन को लेकर, नेटवर्क से जुड़े सुझावों या राय जानना चाहते हैं. |
| गलत इस्तेमाल को कम करना | पक्ष, दूसरे लोगों के साथ बिना छिपाए गए आईपी पते शेयर करके, आईपी सुरक्षा को गच्चा दे सकते हैं. | हम इस जोखिम को समझते हैं कि मौजूदा आईपी सुरक्षा प्रस्ताव
की वजह से शायद पक्षों को दूसरे लोगों के साथ बिना मास्क किए आईपी
पते शेयर करने से तकनीकी रूप से रोका न जाए. हम खतरों को कम करने के लिए काम कर रहे हैं, ताकि
इस तरह के गलत इस्तेमाल के जोखिम से बचा जा सके. हम इस प्रपोज़ल पर फिर से काम करते हैं. इसलिए, हम चाहते हैं कि ज़्यादा से ज़्यादा सुझाव शिकायत/राय दें और चर्चा करें. खास तौर पर, हम इस्तेमाल के ऐसे किसी मामले के बारे में जानना चाहते हैं जहां पार्टियों को यह भरोसा हो कि उन्हें, बिना छिपाए गए आईपी पते को दूसरे पक्षों के साथ शेयर करना होगा. |
| नेटवर्क ब्लॉक करना | पक्ष, आईपी सुरक्षा प्रॉक्सी का इस्तेमाल करके, नेटवर्क ब्लॉक करने की प्रोसेस से बच सकते हैं. | इस स्थिति में, ब्लॉक करने वाली इकाई को आईपी सुरक्षा को बंद करना होगा. हमने समस्या का जवाब दे दिया है और हमें कुछ और सुझाव, शिकायत या राय दें. |
| आईपी पते की ब्लॉक सूचियां जिन पर आईपी सुरक्षा के प्रस्ताव का असर हुआ है | विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली कई कंपनियां, आईपी पतों की बुनियादी ब्लॉक सूची का इस्तेमाल करती हैं, जैसे कि TAG डेटासेंटर की आईपी सूची. ऐसा उन विज्ञापन इन्वेंट्री पर बिडिंग को रोकने के लिए किया जाता है जिनमें धोखाधड़ी या कम से कम कमाई नहीं की जा सकती. अगर विज्ञापन टेक्नोलॉजी भी एक ट्रैकर है और आईपी सुरक्षा के प्रस्ताव के मुताबिक हो सकता है, तो हो सकता है कि वह कंपनी विज्ञापन इन्वेंट्री खरीदने से पहले विज्ञापनों की बुनियादी जांच न कर पाए. | हम संभावित समस्याओं और समाधानों के बारे में, आईपी की सुरक्षा से जुड़े प्रस्ताव पर ज़्यादा सुझाव और चर्चा करने का सुझाव देते हैं. एक विकल्प यह है कि आईपी सुरक्षा पर मिलती-जुलती सूचियां लागू करें. इससे हम पहले फ़्लैग किए गए आईपी पतों से शुरू होने वाले क्लाइंट को प्रॉक्सी नहीं कर रहे हैं. |
क्रॉस-साइट निजता की सीमाओं को मज़बूत बनाएं
पहले पक्ष के सेट
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| (Q4 में भी रिपोर्ट की गई) डोमेन सीमा | इससे जुड़े डोमेन की संख्या बढ़ाने का अनुरोध करें | साल 2022 की चौथी तिमाही से, हमारे जवाब में कोई बदलाव नहीं किया गया है: "हमने डब्ल्यूआईसीजी कॉल में साफ़ तौर पर बताया है कि Chrome एक ऐसा समाधान देने के लिए प्रतिबद्ध है जो उपयोगकर्ताओं की निजता से जुड़े हितों को भी ध्यान में रखेगा. इसे ध्यान में रखते हुए, हम इस्तेमाल के उन खास मामलों पर समुदाय के सुझाव की सराहना करेंगे जिन पर डोमेन की तय सीमा का असर पड़ सकता है. इससे टीम, उपयोगकर्ता की निजता को सुरक्षित रखते हुए, इस्तेमाल के इन मामलों को ठीक करने के तरीके खोज पाएगी." |
| अन्य FPS सबमिशन | FPS के लिए ग्लोबल सूचियां सबमिट करने के अन्य तरीके का प्रस्ताव | फ़िलहाल, हम Chrome में पहले-पक्ष के सेट (FPS) भेजने की तैयारी कर रहे हैं. साथ ही, सेट सबमिट किए गए अनुरोधों को स्वीकार करने के लिए, हमने एक सेंट्रलाइज़्ड GitHub डेटा स्टोर करने की जगह सेट अप की है. हमें उम्मीद है कि तीसरे पक्ष की कुकी का इस्तेमाल रोकने के लिए, एफ़पीएस को मौजूदा वेब प्लैटफ़ॉर्म के समाधानों का इस्तेमाल नहीं किया जा सकेगा. इसलिए, हम उनसे सीखने की उम्मीद करते हैं कि साइट के लेखक, FPS का इस्तेमाल किस तरह करते हैं. समय के साथ जैसे-जैसे सेट की सूची बढ़ती जाएगी और नेटवर्क, तीसरे पक्ष की कुकी वाली दुनिया के हिसाब से ढलता जाएगा, वैसे-वैसे हम इस प्रोसेस को इतना बेहतर बना सकते हैं कि हम अलग-अलग डीसेंट्रलाइज़्ड स्कीम के बारे में सोचें, जैसे कि पहले बताई गई स्कीम. मौजूदा प्रोसेस के साथ, हम तय समयसीमा रखने की उम्मीद करते हैं, जो हमें समय के साथ इनटेक प्रोसेस को बेहतर बनाने में मदद करेगी. सबमिशन की प्रक्रिया पूरी होने के बाद, हम इस आइडिया पर फिर से एक बार फिर से विचार कर सकते हैं. |
| रेपो मॉडरेशन | गलत इस्तेमाल को रोकने के लिए, FPS (फ़्रेम प्रति सेकंड) सबमिशन रेपो का कम्यूनिटी मॉडरेशन लागू करना होगा. बुरे मकसद से काम करने वाले लोग या ग्रुप में, बर्नर ऑरिजिन का इस्तेमाल करके, सेट का सुझाव देने की प्रोसेस को आसानी से समझ सकते हैं. साथ ही, बहुत ज़्यादा अनुरोध मिलने पर, सेट प्रपोज़ल के काम करने के तरीके पर असर पड़ सकता है. | हम तकनीकी पुष्टि से जुड़ी जांचों पर भरोसा करके, जांच को ज़्यादा से ज़्यादा सटीक बनाने की कोशिश कर रहे हैं. हमारा मानना है कि सबमिशन प्रोसेस के लिए यह सबसे बेहतर तरीका है. इस लक्ष्य को ध्यान में रखते हुए, हम यह भी पक्का करने की कोशिश करेंगे कि यह प्रोसेस, स्पैम / बर्नर सबमिशन से बचा जा सके. |
| जुड़े हुए सबसेट | क्या FPS, इनसे जुड़े सबसेट की मदद से, तीसरे पक्ष के वेंडर/SaaS फ़्लो के इस्तेमाल के उदाहरणों के साथ काम कर पाएगा? | तीसरे पक्ष के वेंडर / SaaS फ़्लो, इस्तेमाल का कोई ऐसा उदाहरण नहीं है जिसे फ़िलहाल पहले पक्ष के सेट के दायरे में शामिल किया गया हो. इस्तेमाल के इन उदाहरणों के लिए, क्रॉस-साइट कुकी का इस्तेमाल कैसे किया जाता है, इस बारे में हम अतिरिक्त सुझाव पाने का स्वागत करते हैं. |
| FPS और CHIPS इंटिग्रेशन | A/B टेस्टिंग जैसे इस्तेमाल के उदाहरणों के लिए, एफ़पीएस और सीएचआईपीएस के इंटिग्रेशन का अनुरोध करना | हम इस्तेमाल के इस उदाहरण पर चर्चा कर रहे हैं और डब्ल्यूआईसीजी कॉल में इस बारे में ज़्यादा चर्चा कर रहे हैं. हम यहां अन्य जानकारी का स्वागत करते हैं. |
| जीडीपीआर | जीडीपीआर कॉन्सेप्ट के बाद, नए FPS (फ़्रेम प्रति सेकंड) सबसेट का मॉडल बनाने का प्रस्ताव | हमने इस प्रस्ताव पर अपनी अंदरूनी चर्चा की और इसे अन्य सुझाव, शिकायत या राय के साथ-साथ अपने निजता से जुड़े लक्ष्यों के हिसाब से रखा. हमने जवाब दिया है, जिसमें बताया गया है कि हम इस समय इस प्रस्ताव को क्यों लागू नहीं करेंगे. |
| मेमोरी | FPS (फ़्रेम प्रति सेकंड) सूची को शामिल किए जाने पर, ब्राउज़र की मेमोरी के साइज़ में संभावित बदलाव | ब्राउज़र पर इस तरह की सूचियों को सेव करने के उदाहरण पहले से ही हैं. उदाहरण के लिए, 'डिसकनेक्ट ट्रैकिंग सुरक्षा सूची'. इसका इस्तेमाल, मेमोरी पर कम से कम असर के साथ किया जाता है. पहले पक्ष के सेट की सूची को हर Chrome क्लाइंट के डिवाइस पर कॉपी किया जाएगा. हालांकि, हम फ़ाइल के साइज़ को मॉनिटर करते रहेंगे और हमें भरोसा है कि हम मेमोरी फ़ुटप्रिंट को ऑप्टिमाइज़ कर सकते हैं. |
फ़ेंस किए गए फ़्रेम का एपीआई
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| फ़ेंस किए गए फ़्रेम की सीमाएं | फ़ेंस किए गए फ़्रेम की वजह से लगने वाली सीमाओं की साफ़ तौर पर जानकारी | मार्च में, हमने फ़ेंस किए गए फ़्रेम पर जानकारी देने वाले दस्तावेज़ को अपडेट किया था. इसमें, इसकी क्षमताओं के बारे में जानकारी दी गई थी. साथ ही, अगर आपके पास कोई अतिरिक्त सुझाव है, तो हम उसका स्वागत करते हैं. |
| ऐक्सेस की जानकारी वाली विंडो को बड़ा करें | आस-पास के फ़्रेम के आस-पास की जानकारी पर ऐक्सेस बढ़ाने का अनुरोध करें. | हम इस बारे में ज़्यादा जानना चाहते हैं कि हमारे प्लैटफ़ॉर्म को यह ज़रूरी क्यों है. हम किसी भी अन्य सुझाव, राय या शिकायत का स्वागत करते हैं. |
| फ़ेंस किए गए फ़्रेम और iframe | फ़ेंस किए गए फ़्रेम और iframes के बीच, सुविधाओं की समानता से जुड़े सवाल | सभी उपलब्ध Privacy Sandbox APIs और रिपोर्ट, iframe और FencedFrames के लिए एक ही तरह से उपलब्ध कराई जाएंगी. |
| फ़ेंस किए गए फ़्रेम का साइज़ बदलना | फ़्रेम के साइज़ में बदलाव करने से, इस्तेमाल के कुछ मामलों पर असर पड़ता है. | हम इस्तेमाल के उन उदाहरणों के बारे में ज़्यादा जानना चाहते हैं जिन पर इस पाबंदी का असर पड़ता है. साथ ही, हम इसके अतिरिक्त सुझाव भी पाना चाहते हैं. |
शेयर किया गया स्टोरेज एपीआई
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| तीसरे पक्ष के वर्कलेट | क्या तीसरे पक्ष, ऑरिजिन के हिसाब से बांटे गए, शेयर किए गए स्टोरेज में सेव कर सकते हैं? इसके अलावा, क्या तीसरे पक्ष के मेज़रमेंट के लिए दूसरे वर्कलेट को कॉल करना है? | जहां कोड चलाया जा रहा है, ब्राउज़ करने के संदर्भ के ऑरिजिन से यह तय होता है कि डेटा किसके शेयर किए गए स्टोरेज में लिखा गया है. जब तीसरे पक्ष के कोड को किसी पेज पर जोड़ा जाता है, तो तीसरे पक्ष के कोड को अपने ब्राउज़िंग कॉन्टेक्स्ट के साथ iframe के तौर पर जोड़ा जा सकता है. इससे, तीसरे पक्ष के कोड को अपने ऑरिजिन पर लिखने की अनुमति मिलती है. तीसरे पक्ष के कोड को iframe के बजाय, स्क्रिप्ट के तौर पर भी एम्बेड किया जा सकता है. यह कोड ब्राउज़िंग के कॉन्टेक्स्ट को नहीं बदलता. तीसरा पक्ष, एम्बेड करने वाले व्यक्ति के शेयर किए गए स्टोरेज में लिख सकता है. ध्यान दें कि शेयर किए गए स्टोरेज का मालिक ही उस स्टोरेज से जानकारी पढ़ सकता है. |
| डिडुप्लिकेशन | Chrome नेटवर्क के बाहर होने वाले इंटरैक्शन के लिए, डुप्लीकेट कॉपी हटाने की सुविधा नहीं होगी. | शेयर किया गया स्टोरेज, Chrome ब्राउज़र पर आधारित यूनीक रीच आउटपुट के लिए Chrome में उपलब्ध है. हम विज्ञापन तकनीकों के साथ काम करना चाहते हैं, ताकि हम यह समझ सकें कि इन आउटपुट का इस्तेमाल उनके बड़े पहुंच मॉडल के तौर पर कैसे किया जा सकता है. हम समझते हैं कि आउटपुट खुद सिर्फ़ इंटरैक्शन के एक हिस्से के लिए हैं और उनकी दिलचस्पी विज्ञापन टेक्नोलॉजी के साथ काम करने के लिए मॉडलिंग के दूसरे तरीकों को एक्सप्लोर करने में है. |
| कन्वर्ज़न लुकबैक विंडो | समय के साथ कन्वर्ज़न में होने वाले बदलाव देखने के लिए, कन्वर्ज़न रेट के लिए लुकबैक विंडो का अनुरोध करें | इसे शेयर किए गए स्टोरेज का इस्तेमाल करके क्लाइंट साइड पर अलग-अलग कन्वर्ज़न पाथ प्रोसेस करके लागू किया जा सकता है. यह बिना बांटे गए ब्राउज़र स्टोरेज के मुकाबले बेहतर आंकड़ों के लिए ज़्यादा सुविधा देता है. |
| आइटम की समयसीमा खत्म होने की समय अवधि | समयसीमा खत्म होने की अवधि को 90 दिनों के लिए बढ़ाने का अनुरोध करें | डेटा के रखरखाव की नीति को नवंबर 2022 में अपडेट किया गया था. इसमें बताया गया है कि पिछली बार डेटा मिलने के 30 दिनों के बाद, हर कुंजी को हटा दिया जाता है. हम आपके लिए कुछ और सुझाव, शिकायत या राय जानना चाहते हैं. इससे हमें यह पता चलेगा कि नई नीति, हमारे नेटवर्क पर काम करेगी या नहीं. |
| क्रिएटिव रोटेशन | क्रिएटिव रोटेशन के इस्तेमाल के उदाहरण, नीलामी के बाद की जाने वाली असल कार्रवाइयों को नहीं दिखाते हैं. | हम विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली दूसरी कंपनियों से जानना चाहते हैं कि क्रिएटिव रोटेशन दस्तावेज़ सही है या नहीं. |
सीएचआईपी
इस तिमाही के लिए कोई सुझाव या राय नहीं मिली.
FedCM
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| आइडेंटिटी के दावे का एंडपॉइंट | पहचान के दावे के एंडपॉइंट पर, मनचाहे तरीके से अनुरोध करने की अनुमति साफ़ तौर पर दें. | हम साइट को वापस लाने के इस अनुरोध पर, Mozilla के साथ मिलकर काम कर रहे हैं. ऐसा इसलिए किया जा रहा है, ताकि उपयोगकर्ता की परेशानी पैदा किए बिना, वेबसाइट के लिए क्रॉस-ऑरिजिन क्रेडेंशियल वाले अनुरोध करने की सुविधा सीमित की जा सके. साथ ही, हम अन्य सुझावों की समीक्षा भी करते रहेंगे और उन पर कार्रवाई भी करते रहेंगे. |
| पहचान की जानकारी अपने-आप भरना | क्या FedCM का इस्तेमाल, FedCM सूची में मौजूद आइडेंटिटी प्रोवाइडर की मदद से साइन इन फ़ॉर्म में अपने-आप जानकारी भरने के लिए किया जा सकता है? | इस इस्तेमाल के मामले में चिंता यह है कि जब कोई साइट उपयोगकर्ता से नहीं जुड़ी है, तो जानकारी लीक हो सकती है. हम इस समस्या पर और चर्चा कर रहे हैं और अन्य सुझाव, शिकायत या राय का स्वागत है. |
| कॉन्टेंट के हिसाब से खाता चुनना | खाता चुनने के यूज़र इंटरफ़ेस (यूआई) में, काम के सिग्नल जोड़ने का प्रस्ताव | हम इस प्रस्ताव पर विचार कर रहे हैं और अन्य चर्चाओं का स्वागत करते हैं. |
स्पैम और धोखाधड़ी को रोकना
Private State Token API (और अन्य एपीआई)
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
|---|---|---|
| सर्वे में मिलने वाली अनुमतियां | पहली तिमाही की शुरुआत में, हमने अपने सर्वे के नतीजों को इकट्ठा किया. जिनसे धोखाधड़ी-विरोधी मामलों के लिए क्षमताओं की ज़रूरत होती है और उन्हें सार्वजनिक तौर पर शेयर किया जाता है (मिनट, नतीजे) | हम इस सुझाव को तब शामिल करेंगे, जब हम धोखाधड़ी रोकने वाले टूल के लिए, निजता बनाए रखने वाले एपीआई के नए प्रपोज़ल और प्रोटोटाइप बनाएंगे. हमें उम्मीद है कि हम डेवलपमेंट को प्राथमिकता देंगे, जहां ज़रूरत के मुताबिक ज़रूरत होगी. साथ ही, उपयोगकर्ता की निजता को बनाए रखते हुए, वेब पर इसे उपलब्ध कराने के लिए कोई मौजूदा टेक्नोलॉजी बनाई जा सकती है. उदाहरण के लिए, डिवाइस और बूट इंटिग्रिटी की रैंकिंग बहुत अच्छी थी. साथ ही, कई प्लैटफ़ॉर्म पर ऐसे एपीआई पहले से मौजूद हैं जो डिवाइस इंटिग्रिटी का आकलन सुरक्षित तरीके से शेयर करते हैं. इसलिए, कम्यूनिटी ग्रुप में एक्सप्लोरेशन (विश्लेषण का तरीका) को बेहतर बनाना एक अच्छा विकल्प है. |
| सुझाव, शिकायत या राय भेजने के लिए पीएसटी का इंटेंट | निजता पास को भेजने के इरादे से, हमें आगे की कार्रवाई के बारे में चिंता हुई. ऐसा इसलिए कि हम निजता पास का पुराना वर्शन इस्तेमाल कर रहे हैं. हमें यह सुझाव भी मिला कि कुछ सेक्शन में स्पेसिफ़िकेशन के बारे में साफ़ तौर पर नहीं बताया गया था. साथ ही, ब्राउज़र के साथ काम करने लायक बनाने के लिए इसमें सुधार किया जाना चाहिए. | हम GA में शिपिंग से पहले सुझाए गए कई खास बदलावों को लागू करने की योजना बना रहे हैं. साथ ही, एपीआई में कुछ बदलाव भी लागू करने वाले हैं. पहली तिमाही के आखिर में यह सुझाव आया था. इसलिए, हम GitHub से जुड़ी समस्याओं के बारे में खास जानकारी और अपने लॉन्च प्लान में अपडेट के बारे में फ़ॉलो कर रहे हैं. यह फ़ीडबैक रिपोर्ट के पब्लिश होने के दौरान जारी है. एपीआई में होने वाले बड़े बदलावों के लिए, हम इन पर विचार करने को तैयार हैं, लेकिन हमारा मानना है कि इसे सामान्य रूप से उपलब्ध कराना और ज़्यादा डेवलपर से सुझाव लेना ही बेहतर होगा. हमें उम्मीद है कि हम इस चर्चा को जारी रखेंगे और ब्राउज़र के लिए स्टैंडर्ड तय करेंगे. अगर कोई नया मानक सामने आता है, तो उस पर सावधानी से ट्रांज़िशन करने के लिए, हम एक प्लान बनाने और उसे अपनाने के बारे में सोचेंगे. |