फ़ीडबैक रिपोर्ट - 2022 की चौथी तिमाही

साल 2022 की चौथी तिमाही की तिमाही रिपोर्ट, जिसमें प्राइवसी सैंडबॉक्स के प्रपोज़ल और Chrome से मिले रिस्पॉन्स के बारे में नेटवर्क से मिले सुझावों की खास जानकारी दी गई है.

सीएमए को लेकर अपनी जवाबदेही के तहत, Google ने प्राइवसी सैंडबॉक्स के प्रपोज़ल के लिए, पार्टनर के जुड़ाव की प्रोसेस की तीन महीने में तीन रिपोर्ट सार्वजनिक तौर पर उपलब्ध कराने की सहमति दी है. कमीमेंट के पैराग्राफ़ 12 और 17(c)(ii) देखें. प्राइवसी सैंडबॉक्स से जुड़ी फ़ीडबैक की खास जानकारी वाली ये रिपोर्ट, अलग-अलग सोर्स से मिले सुझावों को इकट्ठा करके जनरेट की जाती हैं. इन सोर्स की जानकारी फ़ीडबैक खास जानकारी में दी गई है. इसमें इनके अलावा, और भी चीज़ें शामिल हो सकती हैं: GitHub समस्याएं, privacysandbox.com पर उपलब्ध कराए गए सुझाव फ़ॉर्म. Chrome, नेटवर्क से मिले सुझाव, शिकायत या राय का स्वागत करता है. साथ ही, वह डिज़ाइन से जुड़े फ़ैसलों में सीखने के तरीकों को शामिल करने के तरीके खोज रहा है.

सुझाव, शिकायत या राय की थीम, हर एपीआई की संख्या के हिसाब से रैंक की जाती हैं. इसके लिए, Chrome टीम को मिले सुझाव, शिकायत या राय को किसी तय थीम के आधार पर इकट्ठा करके और उन्हें घटते हुए क्रम में व्यवस्थित किया जाता है. फ़ीडबैक से जुड़ी सामान्य थीम की पहचान करने के लिए, हमने सार्वजनिक मीटिंग (W3C, PatCG, IETF), सीधे तौर पर सुझाव/शिकायत/राय, GitHub पर चर्चा के विषयों और Google की इंटरनल टीम और पब्लिक फ़ॉर्म की मदद से अक्सर पूछे जाने वाले सवालों की समीक्षा की.

खास तौर पर, वेब स्टैंडर्ड बॉडी मीटिंग के लिए तय किए गए समय की समीक्षा की गई और सीधे सुझाव के लिए, Google के 1:1 हिस्सेदारों की मीटिंग के रिकॉर्ड, अलग-अलग इंजीनियर को मिले ईमेल, एपीआई ईमेल पाने वाले लोगों की सूची, और लोगों के सुझाव देने वाले फ़ॉर्म पर विचार किया गया. इसके बाद, Google ने टीम के बीच इन अलग-अलग आउटरीच गतिविधियों को शामिल किया, ताकि यह पता लगाया जा सके कि हर एपीआई के बारे में उभर रही थीम की लोकप्रियता कितनी है.

फ़ीडबैक पर Chrome ने क्या जवाब दिए, यह जानने के लिए अक्सर पूछे जाने वाले सवालों, हिस्सेदारों की ओर से उठाए गए मुद्दों पर असल जवाब, और खास तौर पर सार्वजनिक रिपोर्टिंग की प्रोसेस के लिए एक स्थिति तय की गई है. डेवलपमेंट और टेस्टिंग के मौजूदा फ़ोकस को दिखाते हुए, हमें खास तौर पर Topics, फ़्लैज, और एट्रिब्यूशन रिपोर्टिंग एपीआई के बारे में सवाल और सुझाव मिले.

हो सकता है कि मौजूदा रिपोर्टिंग अवधि के खत्म होने के बाद मिलने वाले फ़ीडबैक को अभी तक Chrome के जवाब के तौर पर न माना जाए.

संक्षिप्त नाम की शब्दावली

सीएचआईपीएस

कुकी, इंडिपेंडेंट पार्टिशन्ड स्टेट है

डीएसपी

डिमांड-साइड प्लैटफ़ॉर्म

FedCM

फ़ेडरेटेड क्रेडेंशियल मैनेजमेंट

FPS (फ़्रेम प्रति सेकंड)

पहले पक्ष के सेट

IAB

इंटरैक्टिव विज्ञापन ब्यूरो

आईडीपी

पहचान देने वाली कंपनी

आईईटीएफ़

इंटरनेट इंजीनियरिंग टास्क फ़ोर्स

IP

इंटरनेट प्रोटोकॉल पता

openRTB

रीयल-टाइम बिडिंग

OT

ऑरिजिन ट्रायल

PatCG

प्राइवेट ऐडवर्टाइज़िंग टेक्नोलॉजी कम्यूनिटी ग्रुप

RP

भरोसेमंद पार्टी

एसएसपी

सप्लाई-साइड प्लैटफ़ॉर्म

TEE

भरोसेमंद तरीके से एक्ज़ीक्यूशन एनवायरमेंट

UA

उपयोगकर्ता एजेंट स्ट्रिंग

UA-CH

उपयोगकर्ता-एजेंट क्लाइंट हिंट

W3C

वर्ल्ड वाइड वेब कंसोर्टियम

डब्ल्यूआईपीबी

विलफ़ुल आईपी ब्लाइंडनेस

सामान्य सुझाव, किसी खास एपीआई/टेक्नोलॉजी के आधार पर नहीं

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
(तीसरी तिमाही में भी रिपोर्ट की गई है) अलग-अलग तरह के हिस्सेदारों के लिए उपयोगिता	यह चिंता की बात है कि प्राइवसी सैंडबॉक्स टेक्नोलॉजी, बड़े डेवलपर को पसंद आती है. साथ ही, सामान्य (बड़ी) साइटों के मुकाबले, खास (छोटी) साइटों का योगदान ज़्यादा होता है	हमारा जवाब, तीसरी तिमाही से कोई बदलाव नहीं है: "Google ने प्राइवसी सैंडबॉक्स के प्रपोज़ल को इस तरह डिज़ाइन और लागू करने के लिए प्रतिबद्ध है कि खुद के कारोबार को प्राथमिकता देकर, प्रतिस्पर्धा को गलत न बताए. साथ ही, डिजिटल विज्ञापन और पब्लिशर और विज्ञापन देने वाले लोगों या कंपनियों पर पड़ने वाले असर को भी ध्यान में रखा जाए, भले ही उनका साइज़ कुछ भी हो. हम CMA के साथ मिलकर काम करते रहते हैं, ताकि यह पक्का कर सकें कि हमारा काम इन वादे का पालन करे. प्राइवसी सैंडबॉक्स की टेस्टिंग आगे बढ़ने पर, हम इस अहम सवाल का आकलन करेंगे कि नई टेक्नोलॉजी, अलग-अलग तरह के हिस्सेदारों के लिए कैसा परफ़ॉर्म कर रही है. इस मामले में सुझाव, शिकायत या राय बहुत अहम है. खास तौर पर, सटीक और कार्रवाई करने लायक सुझाव, शिकायत या राय की मदद से हम तकनीकी डिज़ाइन को और बेहतर बना सकते हैं. हमने सीएमए के साथ मिलकर, संख्यात्मक टेस्टिंग के लिए अपना तरीका डेवलप किया है. साथ ही, हम प्रयोग के डिज़ाइन पर नोट पब्लिश करने में हमारी सहायता कर रहे हैं, ताकि बाज़ार में हिस्सा लेने वाले लोगों को ज़्यादा जानकारी दी जा सके और सुझाए गए तरीकों पर टिप्पणी करने का मौका मिल सके."
(तीसरी तिमाही में भी रिपोर्ट किया गया है) दस्तावेज़ों के अनुरोध	टेस्टिंग, विश्लेषण, और लागू करने की प्रोसेस को मैनेज करने के तरीके की जानकारी देने वाले ज़्यादा संसाधनों के अनुरोध	चौथा सवाल: हम इस बात के लिए आपकी सराहना करते हैं कि डेवलपर को हमारे मौजूदा कॉन्टेंट से मदद मिली. साथ ही, हम उन्हें ज़्यादा से ज़्यादा कॉन्टेंट उपलब्ध कराने के लिए लगातार काम कर रहे हैं, ताकि डेवलपर समझ पाएं कि नई टेक्नोलॉजी उनके लिए कैसे काम कर सकती है. पिछली तिमाही में, हमने privacysandbox.com में एक "News और अपडेट" सेक्शन जोड़ा है. साथ ही, इस बात की पूरी समीक्षा पब्लिश की है कि आने वाले समय में प्राइवसी सैंडबॉक्स, विज्ञापन को ज़्यादा काम का बनाने में कैसे मदद कर सकता है. सबसे सही तरीके और डेमो शेयर करने के लिए, हमने पब्लिक डेवलपर के ऑफ़िस आवर्स सेशन भी आयोजित किए हैं. इनमें प्रॉडक्ट और इंजीनियरिंग लीड के साथ सवाल-जवाब के सेशन भी शेयर किए गए थे, ताकि लोग लाइव चर्चा या सवालों के जवाब दे सकें.
वेबसाइट की परफ़ॉर्मेंस के बारे में जानकारी	प्राइवसी सैंडबॉक्स एपीआई के इंतज़ार की अवधि से, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी पर क्या असर पड़ता है?	Privacy Sandbox APIs का मुख्य मकसद, लेटेंसी को कम से कम रखना है. हमें फ़िलहाल यह उम्मीद है कि एपीआई के इंतज़ार का समय, साइट की वेबसाइट की परफ़ॉर्मेंस की जानकारी देने वाली मेट्रिक पर कम से कम असर डालेगा. ऐसा इसलिए होता है, क्योंकि ज़्यादातर एपीआई को वेबसाइट की शुरुआती रेंडरिंग के बाद ही कॉल किया जाता है. हम हर एपीआई पर नज़र रखते हैं और उसमें सुधार करते रहते हैं, ताकि हर एपीआई के लिए इंतज़ार का समय और कम किया जा सके. साथ ही, हम जांच करने और सुझाव देने के लिए लगातार काम कर रहे हैं. रीयल टाइम बिडिंग प्रोसेस में इंतज़ार के समय का पता लगाने के लिए, "FLEDGE की नीलामियों की परफ़ॉर्मेंस" सेक्शन में, FLEDGE सेक्शन देखें
इंटरोऑपरेबिलिटी (दूसरे सिस्टम के साथ काम करना)	अन्य संभावित समाधानों के साथ इंटरऑपरेबिलिटी (दूसरे सिस्टम के साथ काम करना) से जुड़ी समस्याएं	प्राइवसी सैंडबॉक्स का मकसद, वेब नेटवर्क की ज़रूरतों को पूरा करने के साथ-साथ, उपयोगकर्ताओं को क्रॉस-साइट ट्रैकिंग से बचाना है. ऐसा करने के लिए, हम ऐसी लेगसी ब्राउज़र टेक्नोलॉजी का इस्तेमाल करना बंद कर रहे हैं जो क्रॉस-साइट ट्रैकिंग को चालू करती हैं, जैसे कि तीसरे पक्ष की कुकी. इसके बाद, हम उनकी जगह पर नई टेक्नोलॉजी उपलब्ध कराना चाहते हैं, ताकि खास मामलों में मदद मिल सके. प्राइवसी सैंडबॉक्स के प्रपोज़ल, उपयोगकर्ता के डिवाइस में मौजूद डेटा को सीमित रखते हैं और निजता को बेहतर बनाते हैं. प्रस्ताव ब्राउज़र से इकट्ठा किए जाने के बाद किसी वेबसाइट के डेटा को शेयर या प्रोसेस करने की क्षमता पर तकनीकी प्रतिबंध नहीं लगाते. इसलिए, ये टेक्नोलॉजी, कंपनियों को "डेटा मैनेजमेंट" या इससे मिलते-जुलते किसी भी कानूनी समझौते में शामिल होने से नहीं रोकती. इसी तरह, वे दूसरे तरीकों से डेटा शेयर करने की सहमति देने के लिए, उपयोगकर्ताओं को पाबंदी नहीं लगाते. साफ़ तौर पर बता दें कि Google, प्राइवसी सैंडबॉक्स से जुड़ी टेक्नोलॉजी को सभी वेबसाइटों पर एक ही तरह से लागू करने के लिए प्रतिबद्ध है. इनमें, Google के प्रॉडक्ट और सेवाएं शामिल हैं. Chrome के तीसरे पक्ष की कुकी का इस्तेमाल बंद करने के बाद, वे वादे यह भी साफ़ करते हैं कि Google, डिजिटल विज्ञापन की टारगेटिंग या मेज़रमेंट के लिए उपयोगकर्ताओं को ट्रैक करने के लिए, अन्य निजी डेटा, जैसे कि उपयोगकर्ताओं के सिंक किए गए Chrome ब्राउज़िंग इतिहास का इस्तेमाल नहीं करेगा.

काम का कॉन्टेंट और विज्ञापन दिखाएं

विषय

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
Google पर खोज के नतीजों में रैंकिंग पर पड़ने वाला असर	इस बारे में पूछताछ करना कि Google Search के नतीजों की रैंकिंग तय करने के लिए, वेबसाइट की Topics API सपोर्ट का इस्तेमाल किया जाएगा या नहीं	कुछ वेबसाइटें, Topics API से ऑप्ट-आउट कर सकती हैं. प्राइवसी सैंडबॉक्स की टीम ने Search Network से जुड़े संगठन से, न तो कोई कोऑर्डिनेट और अनुरोध किया है और न ही यह अनुरोध किया है कि वह वेबसाइटों को Topics API का इस्तेमाल करने के लिए, पेज की रैंकिंग को इंसेंटिव के तौर पर इस्तेमाल करती है. Google ने सीएमए से पुष्टि की है कि Google Search, Topics API से ऑप्ट-आउट करने के साइट के फ़ैसले का इस्तेमाल, रैंकिंग सिग्नल के तौर पर नहीं करेगा.
टॉपिक क्लासिफ़ायर	वेब पेज का विषय तय करने के लिए होस्टनेम के अलावा, यूआरएल और पेज का कॉन्टेंट भी जोड़ें. इससे, अलग-अलग हिस्सेदारों के लिए ज़्यादा सुविधाएं मिलेंगी.	किसी उपयोगकर्ता के ब्राउज़िंग इतिहास को फ़िलहाल वेबसाइट के होस्टनेम का इस्तेमाल करके बांटा जाता है. Chrome, विषयों की कैटगरी में पेज लेवल के मेटाडेटा (जैसे, पेज यूआरएल के सभी या कुछ कॉम्पोनेंट और/या कॉन्टेंट) को ध्यान में रखने के विकल्पों का आकलन करता रहता है. बिजली, पानी जैसी सुविधाओं में किए गए किसी भी तरह के सुधार, निजता और इसके गलत इस्तेमाल को ध्यान में रखकर किए जाने चाहिए. उदाहरण के लिए, मेटाडेटा के मामले में, खास तौर पर इसके कुछ जोखिम ये हैं: - अलग-अलग (और संभावित रूप से संवेदनशील) मतलब को विषयों में एन्कोड करने के तरीके के रूप में पेज-लेवल मेटाडेटा में बदलाव करने वाली साइटें; - वित्तीय फ़ायदे के लिए अपने विषयों को गलत तरीके से पेश करने के लिए, पेज लेवल मेटाडेटा में बदलाव करने वाली साइटें; - क्रॉस-साइट ट्रैकिंग के लिए, पेज लेवल मेटाडेटा में डाइनैमिक तौर पर बदलाव करने वाली साइटें
(तीसरी तिमाही में भी रिपोर्ट की गई है) पहले पक्ष के सिग्नल पर असर	टॉपिक के सिग्नल काफ़ी अहम हो सकते हैं. इसकी वजह से, पहले पक्ष की दिलचस्पी के हिसाब से मिलने वाले अन्य सिग्नल की वैल्यू कम हो जाती है.	हमारा जवाब, तीसरी तिमाही से कोई बदलाव नहीं है: "हमारा मानना है कि दिलचस्पी के हिसाब से विज्ञापन दिखाना, वेब के इस्तेमाल के लिए एक अहम उदाहरण है. साथ ही, Topics को इस्तेमाल के उदाहरण के हिसाब से डिज़ाइन किया गया है. जैसा कि [तीसरी तिमाही की हमारी रिपोर्ट में] बताया गया है, नेटवर्क के दूसरे हिस्सेदारों ने इस बात को लेकर चिंता जताई है कि Topics, शायद कारोबार के लिए फ़ायदेमंद न हो. इन सभी मामलों में, टेक्सॉनमी को बेहतर बनाने की कोशिश लगातार जारी है. हमें उम्मीद है कि नेटवर्क की अलग-अलग टेस्टिंग और इनपुट के हिसाब से, टेक्सॉनमी इस कैटगरी में बेहतर होगी."
टेक्सॉनमी अपडेट करना	टेक्सॉनमी सूची कैसे अपडेट की जाएगी?	हम कैटगरी के बारे में सुझाव, शिकायत या राय जानना चाहते हैं. ऐसा इसलिए किया जा रहा है, ताकि नेटवर्क के लिए, इन सब सवालों के जवाब मिल सकें. Topics API के शुरुआती प्रस्ताव में शामिल की गई कैटगरी को, फ़ंक्शनल टेस्टिंग को चालू करने के लिए डिज़ाइन किया गया था. Chrome, अलग-अलग कैटगरी में जानकारी अपडेट करने के लिए, लगातार कई तरीकों पर विचार कर रहा है. उदाहरण के लिए, Chrome हर विषय के लिए कुछ व्यावसायिक वैल्यू का इस्तेमाल कर सकता है, ताकि यह तय किया जा सके कि आने वाले समय में होने वाली क्वेरी में किस कैटगरी को शामिल किया जाए.
विषयों की रीजनल क्लासिफ़ायर परफ़ॉर्मेंस	क्षेत्रीय डोमेन में, विषयों की कैटगरी तय करने वाली टेक्नोलॉजी खराब परफ़ॉर्म कर रही है	क्लासिफ़ायर को बेहतर बनाने के लिए अभी कोशिश की जा रही है. हमें मिले फ़ीडबैक के आधार पर, विषय ओवरराइड सूची को बड़ा करने की संभावना पर विचार किया जा रहा है. हमारे विश्लेषण से पता चलता है कि इससे वैश्विक कवरेज में बढ़ोतरी होगी और ज़्यादा सटीक नतीजे मिलेंगे. यह समझाने के लिए, Topics API क्लासिफ़िकेशन के दो कॉम्पोनेंट हैं: (1) टॉप 10 हज़ार साइटें और उनके विषय की ओवरराइड वाली सूची और (2) उपयोगकर्ता के डिवाइस पर मौजूद एमएल मॉडल, जो होस्टनेम को विषयों में बांटता है. ओवरराइड लिस्ट (1) को बड़ा करके, हम उन इलाकों की कैटगरी तय करने की परफ़ॉर्मेंस को बेहतर बना सकते हैं जहां क्लासिफ़ायर खराब परफ़ॉर्म कर रहा हो.
एक हफ़्ते का समय	एक हफ़्ते का epoch उन उपयोगकर्ताओं के लिए बहुत लंबा है जो कम अवधि के फ़ैसले लेना चाहते हैं.	हम इस पर लगातार काम कर रहे हैं कि युग की अवधि किस तरह की होनी चाहिए. साथ ही, हम इस बारे में आगे की राय का स्वागत करते हैं कि नेटवर्क के लिए कौनसा युग बेहतर हो सकता है.
एचटीटीपी हेडर वापस पाना	चिंता करें कि विषयों की एचटीटीपी हेडर वापस पाने के बारे में ज़्यादा जानकारी नहीं है	हेडर और फ़ेच() पर काम चल रहा है. हमारे पास यहां भी जानकारी उपलब्ध है. हमने एक्सप्लेनर (जानकारी देने वाले सेक्शन में) में स्किप ऑब्ज़र्वेशन जानकारी भी जोड़ी है.
Topics का मकसद सिर्फ़ विज्ञापन देने वालों की मदद करना है, न कि उपयोगकर्ताओं को	विषय/प्राइवसी सैंडबॉक्स, इंडस्ट्री पर फ़ोकस करता है. उपयोगकर्ताओं को मिलने वाले फ़ायदे, उद्योग के लिए मिलने वाले फ़ायदे के बराबर नहीं हैं.	हमारा मानना है कि उपयोगकर्ताओं को यह फ़ायदा होगा कि Topics में दिलचस्पी के आधार पर विज्ञापन दिखाए जा सकते हैं. ये विज्ञापन, वेब पर सभी के लिए बिना किसी शुल्क के और ओपन डेटा उपलब्ध कराते हैं. साथ ही, हमारा यह भी मानना है कि यह तीसरे पक्ष की कुकी की तुलना में, निजता को बहुत बेहतर बनाता है. कोई दूसरा विकल्प चुने बिना, तीसरे पक्ष की कुकी को हटाने से पब्लिशर पर बुरा असर पड़ सकता है. साथ ही, इससे काम के और भी खराब तरीके पैदा हो सकते हैं जो कम निजी होते हैं, पारदर्शी नहीं होते, और न ही उन्हें रीसेट किया जा सकता है और न ही उपयोगकर्ता उन्हें कंट्रोल कर सकते हैं. कई कंपनियां, Topics और Sandbox APIs को लगातार टेस्ट कर रही हैं. साथ ही, हम निजता को बेहतर बनाने और वेब के साथ काम करने के लिए टूल उपलब्ध कराने का वादा करते हैं. W3C टेक्निकल आर्किटेक्चर ग्रुप ने हाल ही में Topics API के बारे में शुरुआती जानकारी पब्लिश की है. हम इस पर सार्वजनिक तौर पर जवाब देंगे. फ़िलहाल, Google को नेटवर्क से यह सवाल मिला है कि इस समीक्षा के आधार पर, Topics API के डेवलपमेंट और लॉन्च पर क्या असर पड़ सकता है. इसलिए, हम इस साल अपने प्लान को Chrome स्टेबल पर उपलब्ध कराने की फिर से पुष्टि करना चाहते हैं. Googles, W3C टेक्निकल आर्किटेक्चर ग्रुप के इनपुट की सराहना करता है, लेकिन वह CMA और नेटवर्क के सुझाव से विषयों को डेवलप करने और टेस्ट करने की कोशिशों को जारी रखना सबसे अहम मानता है.
डेटा लीक होना	इस बात की चिंता कि अनुमति के बिना विषयों को दूसरी साइटों पर लीक किया जा सकता है	Topics API के डिज़ाइन की वजह से, किसी एक पब्लिशर (यहां तक कि पब्लिशर के छोटे ग्रुप) का डेटा भी किसी भी तरह से लीक हो सकता है. पब्लिशर वेबसाइटों का Topics API पर भी पूरा कंट्रोल है. साथ ही, वे अनुमति की नीति के ज़रिए इस एपीआई के ऐक्सेस पर पाबंदी लगा सकती हैं.
जांच के लिए विज्ञापन देने वालों की कमी	पब्लिशर को लगता है कि वे फ़िलहाल विज्ञापन देने वालों को टॉपिक की वैल्यू नहीं दिखा पा रहे हैं.	साल 2023 की दूसरी छमाही में, हम इंटिग्रेशन टेस्ट के लिए विज्ञापनों से जुड़े सभी एपीआई उपलब्ध कराने की योजना बना रहे हैं. साथ ही, हम विज्ञापन देने वालों के लिए, Topics की वैल्यू के नेटवर्क का विश्लेषण चालू करने का प्लान भी कर रहे हैं. नतीजों की जांच और प्रकाशन की निगरानी, सीएमए करेगा. इसके बाद डेटा, विश्लेषण, और तरीके की समीक्षा की जाएगी. नेटवर्क को Google और CMA के साथ सुझाव शेयर करने के लिए बढ़ावा दिया जाता है.
विषय और FLEDGE	FLEDGE के बिडिंग लॉजिक में Topics इस्तेमाल करने के तरीके के बारे में ज़्यादा जानकारी पाने का अनुरोध	FLEDGE के बिडिंग लॉजिक में विषयों का इस्तेमाल किया जा सकता है. एक इंटिग्रेशन गाइड भी बनाई जा रही है. इसमें, इसे लागू करने के बारे में ज़्यादा जानकारी दी गई है.
विषय कॉल करने वाले (कॉलर) के लिए पसंद के मुताबिक रैंकिंग	कॉलर के हिसाब से रैंकिंग तैयार करने की अनुमति दें	हर विज्ञापन टेक्नोलॉजी के लिए, पसंद के मुताबिक विषय की रैंकिंग या वैल्यू के साथ एक चुनौती यह है कि यह एक ऐसी तकनीक बन सकती है जिससे विज्ञापन टेक्नोलॉजी, दिखाए जाने वाले विषयों पर असर डाल सकती है. इसलिए, यह एक फ़िंगरप्रिंटिंग वेक्टर है.
टॉपिक कॉलर की प्राथमिकता सूची	कॉल करने वालों को विषयों की रैंक की गई प्राथमिकता वाली सूची उपलब्ध कराने की अनुमति दें, जिसे Topics API मंज़ूरी के आधार पर दिखाएगा.	फ़िलहाल, हम इस आइडिया पर चर्चा कर रहे हैं और अन्य इनपुट का स्वागत कर रहे हैं.

फ़्लेज

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
Google Ad Manager	ध्यान रखें कि FLEDGE नीलामियों के लिए आखिरी फ़ैसला Google Ad Manager ही होगा और यह Google पब्लिशर टैग और Google Ad Manager को प्राथमिकता देगा.	FLEDGE की मदद से, हर पब्लिशर नीलामी का स्ट्रक्चर चुन सकता है. इसमें टॉप लेवल और कॉम्पोनेंट सेलर का विकल्प भी शामिल है. कॉम्पोनेंट नीलामी में हर खरीदार और विक्रेता को पता होता है कि टॉप लेवल का सेलर कौन है. साथ ही, वे यह चुन सकते हैं कि बिडिंग करनी है या नहीं.
FLEDGE का टेस्ट करने वाले लोगों की संख्या कम है	ज़्यादा कंपनियों को FLEDGE टेस्ट करने के लिए बढ़ावा देने का अनुरोध करें. उदाहरण के लिए, एपीआई के फ़ंक्शन में सुधार करना और फ़िंगरप्रिंट की सुविधा से निजता में रुकावट डालने वाले विकल्पों को बढ़ावा देना	प्राइवसी सैंडबॉक्स, कई चरणों में आगे बढ़ रहा है. इसके लिए, CMA और आईसीओ के दिशा-निर्देशों का पालन किया जा रहा है. फ़ंक्शनल FLEDGE की टेस्टिंग ने ज़रूरी स्थिरता और क्षमता दिखाई है. Google, नेटवर्क को Sandbox एपीआई की जांच करने के लिए लगातार बढ़ावा दे रहा है. हमने हाल ही में अपने "विज्ञापन के हिसाब से कीवर्ड के इस्तेमाल को बढ़ाएं" दस्तावेज़ पब्लिश किया है. इसमें, यह दिखाया गया है कि तीसरे पक्ष की कुकी का इस्तेमाल बंद होने के बाद, FLEDGE और अन्य एपीआई, विज्ञापन इंडस्ट्री के इस्तेमाल के ज़रूरी मामलों में कैसे मदद कर सकते हैं. Privacy Sandbox के अन्य हिस्से, ट्रैकिंग को कवर करने के लिए पहले से ही खतरों को कम करने की प्रोसेस में मदद कर रहे हैं. (UA-CH, आईपी प्रोटेक्शन, और बाउंस ट्रैकिंग पर लागू होने वाली पाबंदियां देखें) और समय के साथ इन्हें बेहतर बनाया जाएगा. Google का लक्ष्य, सिर्फ़ व्यावहारिक टारगेटिंग (विज्ञापन के लिए सही दर्शक चुनना) के लिए FLEDGE को समाधान नहीं बनाना है. इसके बजाय, वह इंडस्ट्री और रेगुलेटर के साथ मिलकर काम कर रहा है, ताकि Chrome ब्राउज़र में निजता बनाए रखने वाली विज्ञापन टेक्नोलॉजी को बेहतर बनाया जा सके.
मशीन लर्निंग के इस्तेमाल के उदाहरण	नीलामी बोली लगाने वाले एल्गोरिदम को ट्रेनिंग देने के लिए, मशीन लर्निंग के इस्तेमाल के उदाहरणों के बारे में ज़्यादा जानकारी, FLEDGE और एट्रिब्यूशन रिपोर्टिंग में उपलब्ध कराई जाएगी	हम जानते हैं कि प्राइवसी सैंडबॉक्स टेक्नोलॉजी को लागू करने के सबसे सही तरीके ढूंढने में, टेस्टर की मदद करना ज़रूरी है. हमने खास तौर पर, मशीन लर्निंग के इनपुट के तौर पर प्राइवसी सैंडबॉक्स एपीआई के अलग-अलग पहलुओं के इस्तेमाल से जुड़े दिशा-निर्देश पब्लिश करना शुरू कर दिया है. हाल ही में, "विज्ञापन के हिसाब से कीवर्ड कितना सही है" में बताया गया है कि विज्ञापन इंडस्ट्री, मशीन लर्निंग के लिए इन सिग्नल का इस्तेमाल कैसे कर सकती है. आने वाले समय में भी, हम इस तरह के दिशा-निर्देशों को पब्लिश करते रहने की योजना बना रहे हैं.
FLEDGE कुंजी मान (K/V) सर्वर की क्वेरी की जा रही है	K/V सर्वर सार्वजनिक रूप से क्वेरी करने लायक क्यों है?	K/V सर्वर का मकसद, FLEDGE नीलामियों को रीयल-टाइम सिग्नल देना है. इसलिए, K/V सर्वर को वहां से ऐक्सेस किया जाना चाहिए जहां से FLEDGE नीलामियां की जाती हैं. उपयोगकर्ता के डिवाइसों पर इसका ऐक्सेस सार्वजनिक तौर पर होना चाहिए. के/वी सर्वर में सेव की गई वैल्यू सिर्फ़ वही पक्ष हासिल कर सकता है जिसके पास पहले से कुंजी हो. इसलिए, अगर कोई विज्ञापन टेक्नोलॉजी, दिलचस्पी वाले ग्रुप में शामिल ब्राउज़र के लिए सिर्फ़ कुंजियां उपलब्ध कराती है और उन कुंजियों का इस्तेमाल नहीं करती जिनका बिना किसी क्रम के अनुमान लगाया जा सकता है, तो वे ब्राउज़र ही वैल्यू हासिल कर पाएंगे.
तारीख/समय के हिसाब से टारगेटिंग कैसे करें?	बिडिंग लॉजिक फ़ंक्शन में, तारीख वाले ऑब्जेक्ट के लिए सहायता.	ऐसा करने के कई तरीके हैं. खरीदार अपने सेलर से, मौजूदा तारीख और समय की जानकारी देने के लिए कह सकते हैं. सेलर के लिए, यह जानकारी सभी खरीदारों को देना आसान होना चाहिए. खरीदार, अपने रीयल-टाइम की-वैल्यू रिस्पॉन्स में तारीख और समय भी दे सकते हैं. आखिर में, खरीदार हर खरीदार-सिग्नल में अपने प्रासंगिक जवाब के हिस्से के तौर पर तारीख और समय की जानकारी दे सकते हैं, जिसे विक्रेता खरीदार की generateबिड स्क्रिप्ट में भेज सकता है.
उपयोगकर्ता प्राथमिकताएं	FLEDGE या अन्य विकल्पों की मदद से, विज्ञापन देने वाले के क्रिएटिव को ब्लॉक करने का विकल्प, उपयोगकर्ताओं के लिए उपलब्ध है.	उपयोगकर्ता, Chrome में Ads API से ऑप्ट आउट कर सकते हैं. खास विज्ञापनों के लिए, काम की विज्ञापन टेक्नोलॉजी सबसे बेहतर तरीके से यह कंट्रोल करती है कि कौनसे क्रिएटिव दिखाए जाएं या उन्हें कैसे चुना जाए.
समयावधि के बारे में साफ़ तौर पर जानकारी पाएं	FLEDGE में निजता सुरक्षा की उपलब्धता के बारे में ज़्यादा जानकारी के लिए अनुरोध करें. जैसे, फ़ेंस किए गए फ़्रेम की ज़रूरत के बारे में जानकारी.	हम पहली तिमाही में, टाइमलाइन के बारे में ज़्यादा जानकारी पब्लिश करने वाले हैं.
भ्रम की स्थिति की रिपोर्ट करना	इस बारे में ज़्यादा साफ़ तौर पर अनुरोध करने के लिए कि FLEDGE की रिपोर्टिंग, Fenced Frames और Private एग्रीगेशन API जैसे अन्य एपीआई के साथ कैसे काम करेगी.	हम आने वाले हफ़्तों में Private एग्रीगेशन API, FLEDGE, और Fenced Frames के बीच होने वाले इंटरैक्शन के बारे में जानकारी देने वाले वीडियो पब्लिश करेंगे.
रीयल-टाइम बिडिंग और FLEDGE	FLEDGE, स्टैंडर्ड रीयल-टाइम बिडिंग के साथ कैसे इंटिग्रेट होता है, इस बारे में दिशा-निर्देश.	इवेंट लेवल के डेटा का ऐक्सेस और ARA में आसान इंटिग्रेशन, विज्ञापन टेक्नोलॉजी की रीयल-टाइम बिडिंग की सुविधा के काम करने की क्षमता को मुश्किल बना सकते हैं. हम पहली तिमाही में, इन दोनों के बारे में अपडेट और ज़्यादा जानकारी भेजने की योजना बना रहे हैं.
FLEDGE नीलामियों की परफ़ॉर्मेंस	जांच करने वाले लोगों से मिली रिपोर्ट कि FLEDGE नीलामियों में इंतज़ार का समय ज़्यादा होता है	जांच करने वाले लोगों से मिली रिपोर्ट, उनके नतीजे और इस्तेमाल के उदाहरण शेयर करने पर हमें बहुत पसंद आईं. साथ ही, हमने FLEDGE की परफ़ॉर्मेंस को बेहतर बनाने के तरीके से जुड़े कुछ सुझाव शेयर किए. इसके साथ-साथ, हमने ब्राउज़र में टूल जोड़ा है. इससे डेवलपर, इस बात का बेहतर तरीके से पता लगा पाएंगे कि किन वजहों से नीलामी धीमी हो रही है. साथ ही, हम इंतज़ार के समय के मुख्य सोर्स का व्यवस्थित तरीके से पता लगा रहे हैं. हाल ही के सुधारों में, धीमी नीलामियों का समय खत्म होना, तेज़ बिडर फ़िल्टर करने की तकनीक, स्टार्टअप लागत का पेमेंट करने से बचने के लिए FLEDGE वर्कलेट का फिर से इस्तेमाल, और FLEDGE स्टार्टअप समय और नेटवर्क फ़ेच के साथ साथ-साथ चलने वाले विज्ञापन अनुरोध को अनुमति देने के लिए, चल रहे काम शामिल हैं. हमें उम्मीद है कि Chrome डेवलपर और FLEDGE के टेस्टर के बीच, एपीआई का इस्तेमाल करने के अनुभव के आधार पर, इंतज़ार के समय का ऑप्टिमाइज़ेशन जारी रहेगा.
दिलचस्पी वाले ग्रुप के साइज़ की मेमोरी की सीमा	एक इंटरेस्ट ग्रुप के साइज़ की सीमा को 50 केबी से बढ़ाने का अनुरोध करें.	हम अनुरोध पर गंभीरता से विचार कर रहे हैं. साथ ही, हम इस बारे में राय जानना चाहते हैं कि सीमा की कौनसी वैल्यू काम कर रही है.
FLEDGE से मिले डेटा को पहले-पक्ष की कुकी के साथ जोड़ना	क्या FLEDGE, विज्ञापन देने वाले के पहले पक्ष (ग्राहक) के डेटा के साथ इंटिग्रेशन की मदद करेगा?	FLEDGE को इसलिए बनाया गया, ताकि विज्ञापन देने वाले के पास पहले से मौजूद पहले पक्ष (ग्राहक) के डेटा का इस्तेमाल करके, विज्ञापन दिखाए जा सकें. हालांकि, FLEDGE का मकसद, विज्ञापन देने वाले किसी व्यक्ति के ब्राउज़िंग व्यवहार को विज्ञापन देने वाले की अपनी साइट के अलावा, किसी दूसरी वेबसाइट पर सीखने के लिए करना नहीं है. पहले पक्ष (ग्राहक) के डेटा के साथ ऑफ़-साइट ब्राउज़िंग व्यवहार को अटैच करना, प्राइवसी सैंडबॉक्स के लक्ष्यों के उलट है. आने वाले हफ़्तों में, FLEDGE पहले पक्ष (ग्राहक) के डेटा के इंटिग्रेशन के लिए कैसे काम करेगा, इस बारे में ज़्यादा जानकारी के साथ हम इंटिग्रेशन गाइड शेयर करेंगे.
K-पहचान छिपाकर दी गई वैल्यू	"K" से "k-anon" वैल्यू का पता कैसे लगाया जाएगा और क्या इसे पब्लिश किया जाएगा?	"K" वैल्यू को अब भी तय किया जा रहा है. हमारा प्लान डेवलप होने पर, हम ज़्यादा जानकारी शेयर करेंगे. हम इस बारे में ज़्यादा जानना चाहते हैं कि अज्ञात k वैल्यू की वजह से, FLEDGE की तैयारी और एमएल मॉडल की ट्रेनिंग का दायरा कैसे बदल सकता है. हम इस विषय पर अतिरिक्त सुझावों का स्वागत करते हैं.
एक से ज़्यादा SSP को सपोर्ट करना	FLEDGE में एक से ज़्यादा SSP कैसे काम करेंगे?	जैसा कि इस प्रस्ताव में बताया गया है, FLEDGE, एक से ज़्यादा सेलर वाली नीलामियों के साथ काम करता है.
बिडिंग लॉजिक किसको दिखे	चिंता करें कि DSP बिडिंग लॉजिक को JavaScript में दिखाया जाएगा	मौजूदा डिज़ाइन वाले बिडिंग लॉजिक का इस्तेमाल करके, दूसरे लोग JavaScript को ऐक्सेस कर सकते हैं. हालांकि, हमें ज़्यादा सुझाव मिलेंगे कि यह डीएसपी के लिए समस्या क्यों हो सकती है.
prebid.js	FLEDGE में prebid.js को सपोर्ट करने में टाइमलाइन क्या है?	Prebid.js के 7.14 और उसके बाद के वर्शन में ही FLEDGE मॉड्यूल काम करता है. टेस्टिंग में दिलचस्पी रखने वाले सभी पब्लिशर को FLEDGE मॉड्यूल जोड़ना होगा और अपना Prebid इंस्टेंस अपग्रेड करना होगा.
FLEDGE में उपयोगकर्ता के तय किए गए फ़ंक्शन	FLEDGE में, यूज़र डेफ़िनिशन फ़ंक्शन (यूडीएफ़) कैसे काम करेंगे? इन फ़ंक्शन को असली उपयोगकर्ता प्रोग्राम कर सकते हैं, ताकि वे एपीआई के फ़ंक्शन को बेहतर बना सकें.	ज़्यादा जानकारी यहां उपलब्ध है. इसे अब भी तैयार किया जा रहा है, इसलिए हम इस्तेमाल के उदाहरणों से जुड़े अतिरिक्त सुझावों का स्वागत करते हैं.
दिलचस्पी के ग्रुप के संसाधनों पर एक ही ऑरिजिन के कंस्ट्रेंट को आराम देना	विज्ञापन टेक्नोलॉजी से जुड़ी कुछ टेक्नोलॉजी के इस्तेमाल को चालू करने के लिए, दिलचस्पी ग्रुप के संसाधनों पर एक जैसे ऑरिजिन की सीमा को कम करने का अनुरोध करें	FLEDGE के मौजूदा लागू किए गए वर्शन में, biddingLogicUrl, biddingWasmHelperUrl, dailyUpdateUrl, और trustedBiddingSignalsUrl का ऑरिजिन, इंटरेस्ट ग्रुप के मालिक के ऑरिजिन से मेल खाना चाहिए. हम पाबंदी का इस्तेमाल, हमलावरों के कुछ गलत इस्तेमाल को रोकने के लिए करते हैं. इसके बारे में यहां बताया गया है.
रुचियां समूह का मालिकाना हक	यह सीमित करने का अनुरोध करें कि विज्ञापन टेक्नोलॉजी, साइटों में एक जैसे दिलचस्पी वाले ग्रुप के लिए,joinInterestGroup का इस्तेमाल कर सकती है	हमारा ध्यान इस बात पर है कि ऑडियंस का इस्तेमाल कैसे किया जाता है, न कि उन्हें कैसे बनाया जाता है. हम यहां संभावित तरीकों के बारे में चर्चा कर रहे हैं. साथ ही, अन्य इनपुट का स्वागत करें.
कुंजी मान सर्वर कुंजी की समाप्ति	संबंधित इंटरेस्ट ग्रुप की समयसीमा खत्म होने पर, सर्वर कुंजियों को हटाने के बारे में चर्चा	हम कुंजी के इस्तेमाल की समयसीमा खत्म करने के तरीके ढूंढ रहे हैं. साथ ही, हमें यहां आपके सुझाव, शिकायत या राय का इंतज़ार है.

डिजिटल विज्ञापनों का आकलन करना

एट्रिब्यूशन रिपोर्टिंग (और दूसरे एपीआई)

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
ऑरिजिन ट्रायल का ट्रैफ़िक	यूटिलिटी टेस्टिंग करने के लिए, मौजूदा ऑरिजिन ट्रायल का ट्रैफ़िक काफ़ी नहीं है.	मौजूदा ऑरिजिन ट्रायल, नेटवर्क के खिलाड़ियों के लिए हैं, ताकि वे फ़ंक्शन की जांच कर सकें, ताकि यह पक्का किया जा सके कि एपीआई सही तरीके से काम कर रहा है. हम यह समझते हैं कि प्राइवसी सैंडबॉक्स एपीआई के डेवलपमेंट के पूरी तरह से समझदार होने के बाद, यूटिलिटी टेस्टिंग करने के लिए, बड़ी संख्या में ट्रैफ़िक की ज़रूरत होगी. टेस्टिंग की मौजूदा टाइमलाइन के हिसाब से, यह सुविधा साल 2023 की तीसरी तिमाही में, जनरल अवेलेबिलिटी के आधार पर उपलब्ध होगी. उदाहरण के लिए, जब इस्तेमाल के उदाहरण के लिए टेक्नोलॉजी लॉन्च की जाएगी और Chrome के 100% ट्रैफ़िक के लिए उपलब्ध होगी. इस्तेमाल के उदाहरण की जांच के लिए, ज़्यादा ट्रैफ़िक की ज़रूरत पड़ने पर, हम किसी अन्य सुझाव का स्वागत करते हैं.
प्राइवसी सैंडबॉक्स मेज़रमेंट के अलग-अलग एपीआई के फ़ंक्शन का ओवरलैप	प्राइवसी सैंडबॉक्स से, मेज़रमेंट के कई तरीकों के ओवरलैप होने की समस्याएं बढ़ जाएंगी. जैसे, Attribution Reporting API और Private एग्रीगेशन API.	हम एपीआई के इस्तेमाल के अलग-अलग उदाहरणों को साफ़ तौर पर बताने के लिए, बेहतर दस्तावेज़ बनाने पर काम कर रहे हैं. साथ ही, जिन क्षेत्रों में जानकारी की कमी है उसके बारे में अतिरिक्त सुझाव/राय दें या शिकायत करें. उदाहरण के लिए, Attribution Reporting API को खास तौर पर कन्वर्ज़न मेज़रमेंट के लिए बनाया गया है. वहीं, Private एग्रीगेशन API और Shared Storage, अलग-अलग कामों के लिए इस्तेमाल किए जाने वाले एपीआई हैं. ये क्रॉस-साइट मेज़रमेंट के इस्तेमाल के उदाहरणों के साथ काम करते हैं.
विफल रिपोर्ट अनुरोध का पुनः प्रयास करें	यह साफ़ तौर पर बताना कि अगर रिपोर्ट का अनुरोध फ़ेल हो जाता है, तो कितनी बार उसकी कोशिश की गई.	हमने इस बारे में दिशा-निर्देश पब्लिश किए हैं. संक्षेप में, रिपोर्ट सिर्फ़ तब भेजी जाती हैं, जब ब्राउज़र चल रहा होता है/ऑनलाइन होता है. पहली बार भेजने में असफल होने पर, पांच मिनट बाद फिर से रिपोर्ट भेजने की कोशिश की जाती है. दूसरी बार गड़बड़ी होने के 15 मिनट बाद, रिपोर्ट को फिर से सबमिट करने की कोशिश की जाती है. इसके बाद रिपोर्ट नहीं भेजी जाती.
रिपोर्टिंग में देरी	रिपोर्टिंग में कितनी देरी हो सकती है?	अगर किसी को रिपोर्टिंग में देरी हो रही है, तो हम नेटवर्क से ज़्यादा से ज़्यादा सुझाव और राय पाना चाहते हैं. ऐसा इसलिए, क्योंकि हम डेटा इकट्ठा करने के साथ-साथ, इन देरी का आकलन करने के लिए भी इसका इस्तेमाल कर रहे हैं.
पेजों को पहले से रेंडर करें	क्या ARA एट्रिब्यूशन, पहले से रेंडर किए गए पेजों पर काम करेगा?	एट्रिब्यूशन रजिस्ट्रेशन को पहले से रेंडर किए गए पेजों पर तब तक के लिए टाल दिया जाता है, जब तक कि इसे चालू नहीं किया जाता (असल क्लिक या व्यू नहीं होता). इसका मतलब है कि हम `Attributionsrc` के अनुरोध को स्वीकार करने के लिए पिंग करेंगे.
कन्वर्ज़न लिफ़्ट को मेज़र करना	एक ही डोमेन पर, एबी टेस्टिंग की मदद से कन्वर्ज़न लिफ़्ट मेज़र करने का तरीका	वेबसाइटें, एट्रिब्यूशन रिपोर्टिंग की मदद से, एक ही डोमेन पर A/B टेस्टिंग की मदद से, कन्वर्ज़न लिफ़्ट मेज़र कर सकती हैं. वे एग्रीगेट किए गए एपीआई का इस्तेमाल करके, अपने A/B पैरामीटर को कुंजियों के तौर पर कोड में बदल सकते हैं. इसके बाद, उन कुंजी बकेट से कन्वर्ज़न वैल्यू के लिए खास जानकारी वाली रिपोर्ट पा सकते हैं.
(Q3 में भी रिपोर्ट किया गया) क्रॉस-डोमेन कन्वर्ज़न	क्रॉस-डोमेन वाले कन्वर्ज़न, जैसे कि दो या उससे ज़्यादा डेस्टिनेशन वाले कन्वर्ज़न को ट्रैक करने का तरीका	चौथे तिमाही के लिए अपडेट: हमने लैंडिंग पेज के डेस्टिनेशन से जुड़ी पाबंदी को हटाने का प्रस्ताव पब्लिश किया है. इस पाबंदी की वजह से, क्रॉस-डोमेन बातचीत को ट्रैक किया जा सकता है. यह प्रस्ताव लागू कर दिया गया है.
(तीसरी तिमाही में भी रिपोर्ट की गई है) कन्वर्ज़न रिपोर्ट में समयसीमा खत्म होने की सेटिंग	रिपोर्ट फ़िल्टर / समयसीमा खत्म होने की तारीख 24 घंटे से कम रखने की सुविधा देने का अनुरोध	चौथे तिमाही में अपडेट: हमने पुल अनुरोध का यह अपडेट शेयर किया है. यह ऐक्सेस खत्म होने की तारीख और रिपोर्टिंग विंडो को अलग कर देगा. इससे रिपोर्टिंग में होने वाली देरी और कन्वर्ज़न की समयसीमा खत्म होने के बीच के मुकाबले ट्रेड ऑफ़ को कम किया जाएगा. इसे अब M110 में लॉन्च किया गया है.
धोखाधड़ी और गलत इस्तेमाल	विज्ञापन देने वाले लोगों या कंपनियों और मार्केटर की ओर से ऐसे अनुरोध जो उन पब्लिशर की साइटों के आधार पर डेटा को अलग-अलग हिस्सों में बांटने और इकट्ठा करने में मदद करते हैं जहां उनके विज्ञापन दिखाए जाते हैं. इससे, आपको धोखाधड़ी वाली संभावित विज्ञापन गतिविधियों के बारे में ज़्यादा जानकारी भी मिलेगी	इस सुझाव पर यहां काम किया जा रहा है. हम अन्य इनपुट का भी स्वागत करते हैं.
(तीसरी तिमाही में भी रिपोर्ट की गई है) इवेंट लेवल की रिपोर्टिंग में देरी	इस्तेमाल के कुछ मामलों के लिए, इवेंट लेवल की रिपोर्टिंग में 2 से 30 दिन ज़्यादा लग सकते हैं.	इवेंट लेवल रिपोर्टिंग में डिफ़ॉल्ट रिपोर्टिंग विंडो 2, 7, और 30 दिन की होती है. "खत्म होने की तारीख" पैरामीटर का इस्तेमाल करके, इसमें बदलाव किया जा सकता है. विज्ञापन टेक्नोलॉजी, समयसीमा खत्म होने की तारीख को कॉन्फ़िगर कर सकती हैं. समयसीमा को कम से कम एक दिन में सेट किया जा सकता है, ताकि आपको दो दिन से कम समय में संभावित रिपोर्ट मिल सकें. निजता सुरक्षा के तरीके के तौर पर, हम यह तय करते हैं कि समयसीमा खत्म होने की जानकारी एक दिन तक ही दी जाए. ऐसा इसलिए है, क्योंकि बारीकी से रिपोर्टिंग करने पर, समय के साथ अलग-अलग तरह की गड़बड़ियां पैदा हो सकती हैं. इसके अलावा, हम इवेंट लेवल और एग्रीगेट रिपोर्ट के लिए, अलग से "समयसीमा खत्म होने की तारीख" पैरामीटर सेट करने की अनुमति देते हैं. यहां देखें. इसके अलावा, Google Ads को ऐसी कोई खास रिपोर्टिंग विंडो नहीं मिलेगी जो अन्य विज्ञापन टेक्नोलॉजी को Attribution Reporting API से नहीं मिलती.
रिपोर्टिंग ऑरिजिन से जुड़ी एक जैसी शर्तें	सोर्स रजिस्ट्रेशन के ऑरिजिन और कन्वर्ज़न रजिस्ट्रेशन ऑरिजिन से जुड़ी ज़रूरी शर्त को हटाने का अनुरोध करें	हमारा सुझाव है कि इस्तेमाल के इस उदाहरण को हल करने के लिए, डेलिगेट रजिस्ट्रेशन के लिए एचटीटीपी रीडायरेक्ट का इस्तेमाल किया जाए. हम चाहते हैं कि नए दिशा-निर्देशों के बारे में, अन्य सुझाव, शिकायत या राय दें.
कन्वर्ज़न ट्रैकिंग	यह पता लगाना ज़रूरी है कि कन्वर्ज़न, विज्ञापन देने वाले की तरफ़ से सेट किए गए कुछ घंटों के पहले या बाद में हुआ था	Attribution Reporting API की मदद से, सोर्स एट्रिब्यूशन के लिए, समयसीमा खत्म होने की विंडो और प्राथमिकता सेट की जा सकती है. दोनों का इस्तेमाल करके, तकनीकी रूप से X दिन की विंडो में होने वाले किसी कन्वर्ज़न को, X के बाद होने वाले कन्वर्ज़न से अलग एट्रिब्यूट किया जा सकेगा.
शोर सिम्युलेशन	कम कन्वर्ज़न वाले विज्ञापन देने वालों पर पड़ने वाले असर को समझने के लिए, हर बकेट के लिए कन्वर्ज़न की अलग-अलग संख्या को सिम्युलेट करने का अनुरोध करें	हम शोर लैब के आने वाले वर्शन में, ऐसा करने के तरीके जोड़ने पर काम कर रहे हैं. अगर आपको कोई और सुझाव/राय देनी है या शिकायत करनी है, तो हमें बताएं.
मोबाइल पर रिपोर्टिंग	क्या मोबाइल पर Chrome बैकग्राउंड में चलने के दौरान भी रिपोर्ट भेजी जाएगी?	फ़िलहाल, मोबाइल पर भी Chrome के बैकग्राउंड में होने पर रिपोर्ट नहीं भेजी जाएगी. एपीआई को Android प्राइवसी सैंडबॉक्स के साथ इंटिग्रेट करने पर, यह बदलाव हो सकता है. यहां देखें. ध्यान दें कि Android प्राइवसी सैंडबॉक्स, CMA की स्वीकार की गई प्रतिबद्धता का हिस्सा नहीं है.
डेटा की उपलब्धता	इस बात की समस्याएं कि Google को Privacy Sandbox APIs के ज़रिए, डेटा का ज़्यादा ऐक्सेस मिल जाएगा	पहला, Google Ads को Attribution Reporting API या अन्य प्राइवसी सैंडबॉक्स एपीआई के डेटा का ऐक्सेस नहीं मिलता. इस समस्या का हल, "इंटरऑपरेबिलिटी" के तहत सामान्य सुझाव वाले सेक्शन में भी दिया गया है. इसमें, Google की प्रतिबद्धता के बारे में ज़्यादा जानकारी शामिल है. दूसरी बात, छोटी और बड़ी साइटों के बीच के अंतर पर, Google यह मानता है कि ग़ैर-ज़रूरी आवाज़ों के आधार पर की जाने वाली निजता सुरक्षा की सुविधा, डेटा के छोटे हिस्सों पर बेहतर असर डाल सकती है. हालांकि, कुछ तरीकों से यह समस्या हल हो सकती है: उदाहरण के लिए, लंबे समय तक एग्रीगेट करने जैसे तरीकों से यह समस्या हल हो सकती है. हालांकि, यह साफ़ तौर पर नहीं बताया जा सकता कि क्या डेटा के बहुत छोटे हिस्सों (जैसे, एक या दो खरीदारी) पर आधारित नतीजे, विज्ञापन देने वाले लोगों या कंपनियों के लिए काम के हैं या नहीं. ऑरिजिन ट्रायल के दौरान, Google ने टेस्टर को निजता और ग़ैर-ज़रूरी आवाज़ों के अलग-अलग पैरामीटर के साथ एक्सपेरिमेंट करने की सलाह दी है, ताकि वे इस समस्या के बारे में सटीक सुझाव दे सकें.

कवर ट्रैकिंग को सीमित करें

उपयोगकर्ता-एजेंट को कम करना

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
वेब नेटवर्क के पूरी तरह तैयार होने तक, उपयोगकर्ता-एजेंट को कम करने की प्रोसेस रोकें	आने वाले समय में, उपयोगकर्ता-एजेंट में कमी से जुड़े बदलावों को समझने के लिए अभी काफ़ी समय नहीं है.	इस सुझाव के बारे में बताने के लिए, "हिस्सेदारों की समस्याएं" सेक्शन में पूरी रिपोर्ट तैयार की गई है. यह रिपोर्ट "सीएमए के साथ Google की बातचीत" सेक्शन में मौजूद है.
वेब नेटवर्क के पूरी तरह तैयार होने तक, उपयोगकर्ता-एजेंट को कम करने की प्रोसेस रोकें	स्ट्रक्चर्ड उपयोगकर्ता एजेंट (एसयूए) के डिप्लॉय होने तक, उपयोगकर्ता-एजेंट को कम करने की सुविधा के लॉन्च में देरी का अनुरोध	Google Ads की टीम ने अक्टूबर 2021 में, OpenRTB में स्ट्रक्चर्ड उपयोगकर्ता-एजेंट को जोड़ने (जानकारी देखें) का प्रस्ताव दिया था. साथ ही, इसे अप्रैल 2022 में रिलीज़ किए गए 2.6 स्पेसिफ़िकेशन अपडेट में शामिल किया गया है. हमारे पास इस बात के कुछ सबूत मौजूद हैं कि एसयूए को आज डिप्लॉय किया गया है और यह उपलब्ध है. इस बारे में Scientia Mobile ब्लॉग पोस्ट में बताया गया है. इसमें एसयूए बनाने के लिए UA-CH और WURFL API का इस्तेमाल करने का तरीका बताया गया है.

###

उपयोगकर्ता-एजेंट क्लाइंट हिंट

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
एंटी-कवर्ट ट्रैकिंग की अन्य तकनीकों की मदद से UA-CH की जांच करें	सभी प्राइवसी सैंडबॉक्स के एपीआई और फ़िंगरप्रिंटिंग की तकनीकों को टेस्ट करने के बारे में दिशा-निर्देश, जो एक साथ बेहतर तरीके से दिए गए हैं	हमारी परीक्षण योजना को शेष सैंडबॉक्स प्रस्तावों के विपरीत कुछ एंटी-फ़िंगरप्रिंटिंग उपाय विकसित करने के लिए एसिंक्रोनस समयावधि को दिखाने के लिए डिज़ाइन किया गया था. इससे हम यह पुष्टि कर पाते हैं कि फ़िंगरप्रिंट से जुड़ी कुछ दवाओं (जैसे कि निजता बजट, आईपी सुरक्षा, और बाउंस ट्रैकिंग पर लागू होने वाली पाबंदियां) का पूरी तरह से डेवलपमेंट किया जाएगा. साथ ही, तीसरे पक्ष की कुकी के बंद होने के बाद ही इन्हें सभी के लिए उपलब्ध कराया जा सकेगा. हालांकि, फ़िंगरप्रिंटिंग को रोकने वाले इन तरीकों को क्वांटिटेटिव टेस्ट में शामिल नहीं किया जाएगा, लेकिन इनके लिए क्वालिटेटिव आकलन किया जाएगा. यह आकलन, स्टैंडस्टिल के समय उपलब्ध तथ्यों के आधार पर किया जाएगा.
(दूसरी तिमाही में इसकी रिपोर्ट भी दी गई) परफ़ॉर्मेंस	क्रिटिकल-CH के ज़रिए संकेत मिलने में लगने वाले समय से जुड़ी समस्याएं (पहले पेज के लोड होने पर)	नीचे दिया गया UA-CH सेक्शन देखें
अपर्याप्त फ़ीडबैक	UA-सीएच में हुए बदलाव के बारे में नेटवर्क से मिला सुझाव काफ़ी नहीं है. इसकी वजह से, नेटवर्क में जागरूकता की कमी होने की समस्या पैदा हो सकती है.	हम लगातार अपने प्लान शेयर कर रहे हैं, ताकि प्रोजेक्ट को सावधानी से लॉन्च किया जा सके, ताकि किसी भी तरह की रुकावट न आए. यूज़र-एजेंट रिडक्शन और UA-CH एपीआई के प्लान, 18 मार्च, 2022 को W3C एंटी-फ़्रॉड कम्यूनिटी ग्रुप के सामने पेश किए गए थे. वहीं, वेब पेमेंट वर्किंग ग्रुप और वेब पेमेंट सिक्योरिटी इंटरेस्ट ग्रुप, दोनों के लिए 20 जनवरी, 2022 को ये प्लान पेश किए गए थे. प्रज़ेंटेशन के दौरान या उसके बाद, कोई अहम चिंता नहीं बताई गई. Google ने सुझाव पाने के लिए 100 से ज़्यादा साइट ऑपरेटर के साथ मिलकर काम किया है. इसके अलावा, नेटवर्क के हिस्सेदारों से मिले सुझावों के आधार पर, Google ने उपयोगकर्ता-एजेंट की कमी के बारे में सार्वजनिक तौर पर जानकारी देने के लिए भी Blink-Dev चैनलों का इस्तेमाल किया है.
समस्या शुरू होने का समय	रोल आउट के समय और उद्योग की तैयारी से जुड़ी समस्याएं	नीचे दिया गया UA-CH सेक्शन देखें
Chrome प्लैटफ़ॉर्म की स्थिति	UA-CH के लिए chromestatus पेज को अपडेट करने का अनुरोध किया गया	chromestatus एंट्री 19 दिसंबर को "मिक्स्ड सिग्नल" पर अपडेट की गई थी.

आईपी सुरक्षा (पहले इसे Gnatcatcher कहा जाता था)

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
ऑप्ट-इन या ऑप्ट आउट	क्या आईपी पते की निजता नीति के लिए ऑप्ट-इन या ऑप्ट-आउट करना है?	हमारा लक्ष्य सभी उपयोगकर्ताओं को आईपी सुरक्षा उपलब्ध कराना है. इस लक्ष्य को ध्यान में रखते हुए, हम फ़िलहाल आईपी की सुरक्षा के लिए, लोगों की पसंद के विकल्पों का आकलन कर रहे हैं.
पहले पक्ष (ग्राहक) के डेटा के लिए आईपी पते के इस्तेमाल का उदाहरण	क्या आईपी सुरक्षा के बाद, पहले-पक्ष के डोमेन पर उपयोगकर्ता के सफ़र को एक साथ जोड़ने के लिए, आईपी पतों का इस्तेमाल किया जा सकता है?	जैसा कि पहले पब्लिश किया गया है, आईपी सुरक्षा की सुविधा शुरुआत में तीसरे पक्ष के आधार पर ट्रैकिंग करने पर ध्यान देगी. इसका मतलब है कि पहले पक्ष के डोमेन पर इसका कोई असर नहीं होगा.
विज्ञापन टेक्नोलॉजी के इस्तेमाल के उदाहरण	कंपनियां, आईपी सुरक्षा की मदद से धोखाधड़ी रोकने के उपाय कैसे सेट अप कर सकती हैं?	हम आज के वेब में धोखाधड़ी रोकने की कोशिशों के लिए, आईपी पते की अहमियत को समझते हैं. CMA को लेकर हमारी प्रतिबद्धता (पैराग्राफ़ 20) के हिस्से के तौर पर, हमने कहा है कि हम आईपी सुरक्षा को लागू नहीं करेंगे. ऐसा करने के लिए, हम वेबसाइटों को स्पैम रोकने और धोखाधड़ी रोकने वाली कोशिशों में मदद करने के लिए ज़रूरी कदम उठाएंगे. हमारी मुख्य प्राथमिकताओं में से एक यह है कि आईपी सुरक्षा की सुविधा, धोखाधड़ी रोकने और इस्तेमाल के मामलों और पहचान करने की क्षमताओं पर किस तरह असर डालती है. इससे हम निजता को बनाए रखने वाली उन टेक्नोलॉजी में और निवेश कर सकेंगे जो कंपनियों को वेब सुरक्षा को बनाए रखने में मदद कर सकती हैं. हम सुरक्षा और धोखाधड़ी रोकने वाली कंपनियों की ज़रूरतों को पूरा करने के लिए, सुझाव/राय देने या शिकायत करने और नए प्रस्तावों पर इनपुट देने को बढ़ावा देते हैं. भले ही, समय के साथ सिग्नल बदलते रहते हों.
धोखाधड़ी और गलत इस्तेमाल	क्या आईपी सुरक्षा में, सेवा में रुकावट (डीओएस) से जुड़ी सुरक्षा शामिल है?	हम वेब को सुरक्षित रखते हुए, निजता को बेहतर बनाने के लिए लगातार काम कर रहे हैं. साथ ही, सेवा में रुकावट डालने से जुड़े हमलों से बचाव करना, डेटा के गलत इस्तेमाल को रोकने का एक अहम मामला है. हमें उम्मीद है कि हम डीओएस की सुरक्षा पर पड़ने वाले असर को कम करने के लिए, आईपी सुरक्षा के डिज़ाइन और गलत इस्तेमाल को रोकने के नए तरीकों का इस्तेमाल करेंगे. आईपी सुरक्षा का फ़ोकस शुरुआती तौर पर, तीसरे पक्ष की एम्बेड की गई सेवाओं पर है. इसलिए, कुछ हिस्सेदारों ने बताया कि पहले पक्ष की साइटों के लिए, DoS सुरक्षा पर इसका सीमित असर होना चाहिए. हालांकि, हम डीओएस के इस्तेमाल के मामलों से जुड़े जोखिम का आकलन करने के लिए, लोगों से सुझाव मांगते रहते हैं. खास तौर पर, तीसरे पक्ष की एम्बेड की गई सेवाओं से जुड़े जोखिम का आकलन करने के लिए ऐसा किया जाता है. इसके साथ-साथ, हम गलत इस्तेमाल के बारे में शिकायत करने और क्लाइंट को ब्लॉक करने के तरीकों की खोज कर रहे हैं. इनकी मदद से, कोई साइट या सेवा, स्पैम करने वाले उपयोगकर्ता की पहचान किए बिना उसे ब्लॉक कर पाएगी.
कॉन्टेंट को फ़िल्टर करना	आईपी सुरक्षा की मदद से कॉन्टेंट को फ़िल्टर करना	अलग-अलग कंपनियों की ज़रूरतें भी अलग-अलग होती हैं, जैसे कि कॉन्टेंट को फ़िल्टर करना और उपयोगकर्ता अनुभव को पसंद के मुताबिक बनाना. इस्तेमाल के ऐसे कई उदाहरण, फ़िलहाल आईपी पतों पर निर्भर नहीं होते हैं. इसलिए, इन पर आईपी सुरक्षा का कोई असर नहीं होगा. उदाहरण के लिए, अगर कोई पब्लिशर अपने कॉन्टेंट में बदलाव करना चाहता है और उसे ज़्यादा यूज़र ऐक्टिविटी के लिए प्रेरित करना है, तो वह उपयोगकर्ता की दिलचस्पियों और पब्लिशर के साथ पिछले इंटरैक्शन को समझने के लिए, पहले-पक्ष की कुकी या तीसरे पक्ष की पार्टिशन्ड कुकी (सीएचआईपी) का इस्तेमाल कर सकता है. इसके अलावा, सही उपयोगकर्ता को सही विज्ञापन दिखाने पर फ़ोकस करने वाला विज्ञापन टेक्नोलॉजी पार्टनर, FLEDGE और Topics को शामिल कर सकता है. उदाहरण के लिए, तीसरे पक्ष की कुकी या क्रॉस-साइट ट्रैकिंग टेक्नोलॉजी की मदद से, विज्ञापन के मिलते-जुलते नतीजे दिखाने के लिए ऐसा किया जा सकता है. हम आईपी सुरक्षा में निजता बनाए रखने से जुड़ी नई सुविधाएं जोड़ने पर भी काम कर रहे हैं. जैसे, सामान्य जियोलोकेशन, ताकि कॉन्टेंट फ़िल्टर करने की टेक्नोलॉजी में और सुधार किए जा सकें. ऐसा करने के लिए, शायद मौजूदा तरीके काफ़ी न हों. हम कॉन्टेंट को फ़िल्टर करने के ऐसे मामलों के बारे में आपसे ज़्यादा सुझाव/राय देने या शिकायत करने का स्वागत करते हैं जिस पर आईपी सुरक्षा की वजह से असर पड़ सकता है.
(तीसरी तिमाही में भी रिपोर्ट की गई) जगह से जुड़ी जानकारी के इस्तेमाल के उदाहरण	आईपी सुरक्षा की वजह से, आने वाले समय में किसी भौगोलिक स्थान के इस्तेमाल के मामलों को सही तरीके से काम करने से रोका जा सकता है. उदाहरण के लिए, किसी भौगोलिक स्थान पर आधारित कॉन्टेंट को उपयोगकर्ता के मनमुताबिक बनाने की सुविधा.	चौथा सवाल: हम हिस्सेदारों के साथ काम कर रहे हैं, ताकि यह पक्का कर सकें कि Chrome, आईपी पतों के इस्तेमाल के उचित उदाहरणों के साथ काम करता रहे. हम यहां आईपी जियोलोकेशन की जानकारी के स्तर के बारे में नेटवर्क से जुड़ा सुझाव, शिकायत या राय जानना चाहते हैं.

निजता बजट

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
ज़्यादा साफ़ तौर पर जानकारी देने वाला दस्तावेज़	ऐसे और उदाहरण, ताकि पार्टनर यह अनुमान लगा सकें कि निजता बजट लागू होने के बाद चीज़ें सीमित हो सकती हैं	निजता बजट के प्रस्ताव पर अब भी चर्चा चल रही है और इसे किसी भी ब्राउज़र ने लागू नहीं किया है. स्केल की गई उपलब्धता की सबसे पहली तारीख, वह शुरुआती तारीख होती है जब निजता बजट लागू किया जा सकता है. साल 2024 में, तीसरे पक्ष की कुकी के हटाए जाने से पहले ऐसा नहीं होगा. फ़िलहाल, हमारे पास शेयर करने के लिए कोई अतिरिक्त दस्तावेज़ नहीं है. जब इस पर कोई फ़ैसला लिया जाएगा, तब हम इसके बारे में ज़्यादा जानकारी शेयर करेंगे. इस दौरान, हम हिस्सेदारों का स्वागत करते हैं कि वे ऐसा कोई भी सुझाव शेयर करें जिससे प्रस्ताव को बनाने में मदद मिले.

क्रॉस-साइट निजता की सीमाओं को मज़बूत बनाएं

पहले पक्ष के सेट

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
(Q3 में भी रिपोर्ट की गई) डोमेन की सीमा	इससे जुड़े डोमेन की संख्या बढ़ाने का अनुरोध करें	Q4 अपडेट: हमने लोकल टेस्टिंग के लिए FPS (फ़्रेम प्रति सेकंड) रिलीज़ किए हैं. इसमें, GitHub पर मॉक सेट सबमिट करने की प्रोसेस और स्थानीय स्तर पर rSA और rSAFor को टेस्ट करने के लिए एक फ़्लैग शामिल है. हमने डेवलपर के लिए दो ओपन मीटिंग भी होस्ट की हैं, ताकि वे सहयोगी सबसेट के इस्तेमाल के उदाहरणों से जुड़े सवालों के जवाब देना जारी रख सकें. हम डेवलपर को सुझाव देते हैं कि वे FPS (फ़्रेम प्रति सेकंड) की सुविधा को टेस्ट करें. इससे वे यह सुझाव दे पाएंगे कि जुड़े हुए सबसेट के लिए, डोमेन की तय सीमा का उनके इस्तेमाल के उदाहरण में एफ़पीएस के इस्तेमाल पर क्या असर पड़ेगा. हमने डब्ल्यूआईसीजी कॉल में साफ़ तौर पर बताया है कि Chrome, उपयोगकर्ताओं की निजता से जुड़े हितों को ध्यान में रखते हुए, इस्तेमाल करने लायक समाधान उपलब्ध कराने की कोशिश करता है. इसे ध्यान में रखते हुए, हम इस्तेमाल के उन खास मामलों पर समुदाय के सुझावों की सराहना करेंगे जिन पर डोमेन की सीमा का असर पड़ सकता है. इससे हमारी टीम, उपयोगकर्ता की निजता को बनाए रखते हुए, इस्तेमाल के इन उदाहरणों को हल करने के तरीके ढूंढ पाएगी.
गलत इस्तेमाल को कम करने के तरीकों के बारे में ज़्यादा जानकारी पाने का अनुरोध	अगर किसी डोमेन को ऐसे सेट में जोड़ा जाता है जिसके लिए उसने सहमति नहीं दी थी, तो क्या होगा?	हमने 2 दिसंबर, 2022 को पहले पक्ष के सेट के लिए, सबमिशन से जुड़े दिशा-निर्देश यहां पब्लिश किए हैं. सबमिट करने के दिशा-निर्देशों में बताया गया है कि किसी भी सेट किए गए बदलाव को मैनेज करने के लिए, GitHub पर पुष्टि की प्रक्रिया का पालन किया जाएगा. इसमें मालिकाना हक की पुष्टि भी शामिल है. इस प्रोसेस से इस जोखिम को कम किया जा सकता है.
गलत इस्तेमाल को कम करना	इस बात की चिंता है कि पहले पक्ष के सेट फ़ॉर्मैट का गलत इस्तेमाल हो सकता है	हम अलग-अलग तरह के सबसेट के लिए, तकनीकी जांच का दायरा बढ़ाने की कोशिश कर रहे हैं. साथ ही, यहां कम्यूनिटी से और इनपुट मांग रहे हैं.
विज्ञापनों के इस्तेमाल के उदाहरण	विज्ञापन टारगेटिंग के साथ काम करने के लिए, पहले पक्ष के सेट का इस्तेमाल करने से जुड़े सवाल	हम पहले पक्ष के सेट के लिए, Google Ads टारगेटिंग के इस्तेमाल के उदाहरणों के साथ काम करने की कोशिश नहीं कर रहे हैं. हमारा सुझाव है कि इस्तेमाल के ऐसे उदाहरणों के लिए, Ads API का इस्तेमाल करें.
(तीसरी तिमाही में भी रिपोर्ट की गई) नीति	चिंता का विषय, "लागू डेटा सुरक्षा कानून" से जुड़े CMA प्रतिबद्धताओं के मुताबिक FPS नहीं होता. इस आधार पर कि जीडीपीआर किसी सेट में साइटों की संख्या पर कोई सीमा लागू नहीं करता, जबकि FPS की सीमा तीन होनी चाहिए	हमारा जवाब तीसरी तिमाही से नहीं है: "Google, प्राइवसी सैंडबॉक्स के प्रपोज़ल को डिज़ाइन और लागू करने के लिए लगातार काम कर रहा है. इसमें, Google के कारोबार को प्राथमिकता देकर, प्रतिस्पर्धा को गलत तरीके से इस्तेमाल करने के लिए तैयार किया गया है. साथ ही, डिजिटल विज्ञापन, पब्लिशर, और विज्ञापन देने वाली कंपनियों में प्रतिस्पर्धा पर पड़ने वाले असर को ध्यान में रखा जाएगा. साथ ही, लागू डेटा सुरक्षा कानून में बताए गए डेटा की सुरक्षा के सिद्धांतों के पालन पर असर को भी ध्यान में रखा जाएगा. ज़ाहिर की गई चिंता में, जीडीपीआर के साथ किसी भी तरह की गड़बड़ी ज़ाहिर नहीं की गई है. हम यह पक्का करने के लिए सीएमए के साथ मिलकर काम करते रहते हैं कि हमारा काम इन वादे का पालन करे."
वैकल्पिक प्रस्ताव	जीडीपीआर की पुष्टि किए गए सेट	"जीडीपीआर की पुष्टि किए गए सेट" को लागू करने के प्रस्ताव पर नेटवर्क से मिले सुझाव के अलावा, Chrome के मन में इस वैकल्पिक प्रस्ताव की इन सीमाओं को लेकर भी चिंता है: "जीडीपीआर की पुष्टि वाले सेट" जीडीपीआर "से अलाइन" होने का दावा करते हैं (हालांकि, यह साफ़ तौर पर नहीं बताया गया है कि इसका क्या मतलब है). वहीं दूसरी ओर, Google ने जो वादे किए हैं उनके लिए यह ज़रूरी है कि सामान्य तौर पर, "निजता से जुड़े नतीजों पर पड़ने वाले असर" को ध्यान में रखा जाए. शर्तों को स्वीकार करते हुए, सीएमए बताते हैं कि Google, "लागू डेटा सुरक्षा कानून में बताए गए डेटा की सुरक्षा के सिद्धांतों के पालन" को ध्यान में रखने की Google की जवाबदेही से अलग है. सीएमए के मुताबिक, यह तथ्य बताता है कि Google, लागू डेटा सुरक्षा कानून से बाध्य है. Google, डेटा की सुरक्षा से जुड़े कानून के हिसाब से बाध्य है. आम तौर पर, यह जवाबदेही पर लागू होता है. डोमेन को कई सेट में दिखाने की अनुमति देने के प्रस्ताव को लेकर, हमारी निजता को लेकर चिंता है. पहले पक्ष के सेट, इस्तेमाल के कुछ खास मामलों में उपलब्ध कराए जाने के लिए बनाए गए हैं, जो फ़िलहाल क्रॉस-साइट ट्रैकिंग को चालू किए बिना तीसरे पक्ष की कुकी पर निर्भर हैं. डोमेन को एक से ज़्यादा सेट में शामिल होने की अनुमति देने पर, पहले पक्ष के सेट के प्रस्ताव में पहले से मौजूद मुख्य निजता सुरक्षा हटा दी जाएगी. इसके लिए, कोई अन्य ज़रूरी पाबंदी लागू नहीं होगी. जीडीपीआर की पुष्टि वाले सेट "सेट को ऐसे डेटा कंट्रोलर और प्रोसेसर के ग्रुप के तौर पर परिभाषित करें जो इस्तेमाल की एक जैसी नीति को शेयर करते हों." यह हमारे पहले पक्ष के सेट से जुड़े मूल प्रस्ताव की ज़रूरी शर्त से मिलता-जुलता है, जिसमें बताया गया है कि सेट के सभी पक्षों के लिए, एक ही निजता नीति एक जैसी होनी चाहिए. तब से, हमने उस शर्त को हटा दिया है. ऐसा, नेटवर्क से मिले बेहतरीन सुझाव, राय या शिकायत के आधार पर किया गया है. इसमें, निजता नीति से जुड़ी ज़रूरी शर्तों को लेकर चिंता जताई गई थी. उदाहरण के लिए, हमें साइट के पब्लिशर से पता चला कि एक सामान्य निजता नीति बनाए रखना संभव नहीं है. इसकी वजह प्रॉडक्ट और भौगोलिक अंतर है. ऐसा W3C कम्यूनिटी (1, 2, 3) के सदस्यों की तरफ़ से उठाई गई दूसरी चुनौतियों की वजह से भी होता है. हमें लगता है कि इस प्रस्ताव में भी यही चुनौतियां लागू होंगी. इस विकल्प के लागू होने के बाद, Chrome ने पहले पक्ष के सेट से जुड़े प्रस्ताव को अपडेट किया है. साथ ही, नए सेट बनाने के लिए, सबमिशन के दिशा-निर्देश पब्लिश किए हैं.

फ़ेंस किए गए फ़्रेम का एपीआई

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
ओटी के दौरान फ़ेंस्ड फ़्रेम से जुड़ी पाबंदियां	ऑरिजिन ट्रायल अवधि के दौरान, फ़ेंस किए गए फ़्रेम से जुड़ी मौजूदा पाबंदियां क्या हैं?	हम, पाबंदियों और उन्हें लागू करने की स्थिति से जुड़े दस्तावेज़ पर काम कर रहे हैं. साथ ही, हम साल 2023 की पहली तिमाही में इन्हें शेयर करेंगे.
एक फ़ेंस्ड फ़्रेम में कई विज्ञापन	विज्ञापन देने वाले कई लोगों को एक नीलामी में एक फ़ेंस किए गए फ़्रेम में दिखाने का अनुरोध करना	फ़िलहाल, इस अनुरोध पर अभी काम नहीं किया जा रहा है. हालांकि, अगर नेटवर्क इस्तेमाल करने वाले लोगों को यह सुविधा ज़रूरी लगती है, तो हम अन्य सुझावों का स्वागत करते हैं.
वेब बंडल	फ़ेंस किए गए फ़्रेम वाले वेब बंडल के लिए, क्या ज़रूरी शर्तें और सहायता की योजना है?	फ़िलहाल, हमने इस बारे में कोई अपडेट नहीं दिया है कि आने वाले समय में इसे ज़रूरी बनाया जाएगा या नहीं. किसी भी बदलाव का एलान पहले से किया जाएगा और तीसरे पक्ष की कुकी के इस्तेमाल को रोकने से पहले इसे लागू नहीं किया जाएगा. मौजूदा स्थिति के बारे में जानने के लिए, जानकारी देने वाला यह लेख देखें.

शेयर किया गया स्टोरेज एपीआई

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
AdTech के लिए शेयर किया गया स्टोरेज	AdTech के इस्तेमाल के उदाहरणों के लिए, शेयर किए गए स्टोरेज के इस्तेमाल को लेकर अनिश्चितता	शेयर किए गए स्टोरेज और निजी एग्रीगेशन एपीआई का इस्तेमाल, अलग-अलग तरह के मेज़रमेंट के लिए किया जा सकता है. इन कामों के लिए, क्रॉस-साइट स्टोरेज मेज़रमेंट की ज़रूरत होती है. कुछ उदाहरण यहां दिए गए हैं. हमें लगता है कि डीएसपी और मेज़रमेंट की सुविधा देने वाली कंपनियां, विज्ञापनों के इस्तेमाल के उदाहरणों के लिए मुख्य इंटिग्रेटर हैं.

सीएचआईपी

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
(तीसरी तिमाही में भी रिपोर्ट की गई है) डेटा को बांटने की ज़रूरी शर्त	पहले-पक्ष की कुकी पर, "सेगमेंट में बांटी गई" एट्रिब्यूट के लिए, व्यवहार से जुड़ी साफ़ तौर पर बताई गई ज़रूरी शर्त जोड़ें.	चौथा सवाल: GitHub और PrivacyCG कॉल पर चर्चा करने के बाद, हमने इन नीतियों में यह बदलाव किया है कि पहले-पक्ष की कुकी पर सेट की गई पार्टिशन्ड कुकी, (A,A) की पार्टिशन कुंजी का इस्तेमाल करेंगी. वहीं, "A" टॉप लेवल साइट है. इस व्यवहार के बारे में, हम जानकारी और स्पेसिफ़िकेशन में जानकारी देंगे.
कुकी मैनेजमेंट	क्या पहले-पक्ष या तीसरे पक्ष की कुकी को मैनेज/कंट्रोल करने के लिए टूल मौजूद हैं?	Chrome DevTools और NetLog का इस्तेमाल, उन साइटों की जांच करने के लिए किया जा सकता है जिनमें तीसरे पक्ष की कुकी ब्लॉक करने की सुविधा चालू है. दोनों टूल, उपयोगकर्ता के कॉन्फ़िगरेशन की वजह से कुकी ब्लॉक होने की जानकारी देते हैं. ऑडिटिंग की किस तरह की वेबसाइटें चाहिए, इस बारे में हम आपके सुझाव, शिकायत या राय का स्वागत करते हैं.

FedCM

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
सेशन की अनुमति देने के लिए, आईडीपी को आरपी की जानकारी होना ज़रूरी है	जब कोई उपयोगकर्ता दो अलग-अलग आरपी से, फ़ेडे आईडीपी (IdP) में लॉग इन करने की कोशिश करता है	हम इस समस्या के संभावित समाधानों के बारे में यहां चर्चा कर रहे हैं.
इंटरोऑपरेबिलिटी (दूसरे सिस्टम के साथ काम करना)	उपयोगकर्ताओं और उन वेबसाइटों के बीच संबंध पर FedCM के असर से जुड़ी समस्याएं जिन्हें वे FedCM का इस्तेमाल करके लॉग इन करते हैं. साथ ही, वेबसाइटों के बीच "इंटरऑपरेबिलिटी" के असर से जुड़ी समस्याएं	FedCM का मकसद फ़ेडरेटेड-आइडेंटिटी से जुड़ी उन सेवाओं को सपोर्ट करना जारी रखना है जो Chrome से तीसरे पक्ष की कुकी हटाए जाने के बाद, फ़िलहाल तीसरे पक्ष की कुकी का इस्तेमाल करती हैं. हमें उम्मीद है कि ऐसी सेवाओं के लिए FedCM का सिर्फ़ एक विकल्प उपलब्ध होगा. आइडेंटिटी प्रोवाइडर (आईडीपी) और भरोसेमंद पक्ष (आरपी), अपनी ज़रूरतों के हिसाब से बेहतर टेक्नोलॉजी का इस्तेमाल कर सकते हैं. ऐसा लगता है कि उपयोगकर्ता-आरपी के संबंध और "इंटरऑपरेबिलिटी" से जुड़ी समस्याओं की वजह से, FedCM प्रस्ताव को लेकर गलतफ़हमी हुई है. FedCM, आईडीपी (IdP) पर छोड़ देता है. इससे यह तय किया जाता है कि आरपी की कौनसी जानकारी शेयर की जाए. साथ ही, जब कोई उपयोगकर्ता आरपी की साइट पर साइन इन करने का विकल्प चुनता है, तो वह किस फ़ॉर्मैट में जानकारी शेयर करेगा. FedCM को "हर उस [RP] के लिए पहचान बताने वाले यूनीक आइडेंटिफ़ायर के लिए आईडीपी (IdP) की ज़रूरत नहीं है जिसके साथ उपयोगकर्ता ने पुष्टि की है." इसके बजाय, FedCM हर आईडीपी (IdP) के लिए उपलब्ध है. वह यह चुन सकता है कि उपयोगकर्ता का असल आइडेंटिफ़ायर शेयर करना है या उस आइडेंटिफ़ायर का हर साइट के लिए वर्शन शेयर करना है या इस जानकारी का कोई अन्य वर्शन शेयर करना है. (FedCM स्पेसिफ़िकेशन में, क्रॉस-साइट कोरिलेशन को एपीआई से जुड़े निजता जोखिम के तौर पर पहचाना जाता है. साथ ही, इसमें बताए गए (हर साइट) आइडेंटिफ़ायर के बारे में चर्चा की गई है. हालांकि, डायरेक्ट आइडेंटिफ़ायर के इस्तेमाल का फ़ैसला, आईडीपी (IdP) पर निर्भर करता है. इसे ब्राउज़र लागू नहीं करता.) FedCM में पहले से ही, पहचान के संबंध में उपयोगकर्ता को विकल्प चुनने की सुविधा दी गई है. उदाहरण के लिए, अगर किसी उपयोगकर्ता के पास एक ही आईडीपी (जैसे, वर्क प्रोफ़ाइल और निजी प्रोफ़ाइल) वाली कई पहचान हैं, तो FedCM की मदद से उपयोगकर्ता यह चुन सकता है कि आरपी की साइट पर लॉग इन करने के लिए उसे किस प्रोफ़ाइल का इस्तेमाल करना है. इसके अलावा, हर आरपी अपने हिसाब से यह तय करता है कि अपनी साइट पर कौनसे आईडीपी (IdP) को जोड़ना है. इस फ़ैसले का एक पहलू यह है कि आईडीपी (IdP) किस तरह पर निर्भर करता है, फिर चाहे वह FedCM हो या कोई दूसरी टेक्नोलॉजी. ध्यान दें, ब्राउज़र, आरपी या आईडीपी (IdP) के लिए, इन विकल्पों को तय नहीं करता.

स्पैम और धोखाधड़ी को रोकना

प्राइवेट स्टेट टोकन एपीआई

सुझाव की थीम	खास जानकारी	Chrome रिस्पॉन्स
बॉट को संभालना	अगर जारी करने वाले को पता चलता है कि बॉट को प्राइवेट स्टेट टोकन जारी किए गए हैं, तो क्या होगा?	बॉट को लंबे समय तक नेटवर्क में बचे रहने से रोकने के लिए, जारी करने वालों को समय-समय पर उन कुंजियों को बदलना चाहिए जिनका इस्तेमाल वे टोकन पर साइन करने के लिए करते हैं. इससे यह पक्का हो पाएगा कि जारी करने के लॉजिक के हिसाब से जो पुराने टोकन जारी किए जा चुके हैं उनकी समयसीमा खत्म हो जाए. साथ ही, साइटें नए टोकन को रिडीम करें.
एक ही साइट के लिए फ़ॉर्म सबमिट करना	क्या प्राइवेट स्टेट टोकन का इस्तेमाल, एक ही साइट के फ़ॉर्म सबमिशन के लिए किया जा सकता है, जिसमें फ़ेच/XMLHttpRequest एपीआई के अनुरोध के बजाय फ़ुल-पेज नेविगेशन (जैसे, Content-Type: app/x-www-form-urlencoded) शामिल हो?	फ़िलहाल, यह प्राइवेट स्टेट टोकन के पहले वर्शन में काम नहीं करता. अगर इस इस्तेमाल के उदाहरण की ज़्यादा मांग है, तो हम नेटवर्क से सुझाव, शिकायत या राय का स्वागत करते हैं.
सर्वर-साइड पर की गई पुष्टि	यह सवाल इस बारे में है कि प्राइवेट स्टेट टोकन की पुष्टि सर्वर साइड की जा सकती है या नहीं	टोकन, जारी करने वाले के पास रिडीम किए जाते हैं. इसके बाद, कार्ड जारी करने वाला बैंक, रिडेंप्शन रिकॉर्ड बनाता है. इसमें टोकन या टोकन से मिली साइन की गई कुछ वैल्यू शामिल हो सकती हैं. इसके अलावा, सर्वर टोकन की प्रामाणिकता की पुष्टि करने के लिए रिडेंप्शन रिकॉर्ड का इस्तेमाल कर सकते हैं. हम उम्मीद करते हैं कि कार्ड जारी करने वाले अलग-अलग नेटवर्क में, रिडेम्शन रिकॉर्ड को समझने के लिए अलग-अलग स्टैंडर्ड बनाए जाएंगे.