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

साल 2022 की चौथी तिमाही की तिमाही रिपोर्ट, जिसमें Privacy Sandbox के प्रस्तावों और Chrome के जवाब पर, नेटवर्क से मिले सुझाव/राय या शिकायतों की खास जानकारी दी गई है.

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

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

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

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

हो सकता है कि रिपोर्टिंग की मौजूदा अवधि खत्म होने के बाद मिले सुझाव/शिकायत/राय पर, Chrome ने अब तक कोई जवाब न दिया हो.

सीएचआईपीएस
कुकीज़ हैविंग इंडिपेंडेंट पार्टिशन्ड स्टेट
डीएसपी
डिमांड-साइड प्लैटफ़ॉर्म
FedCM
फ़ेडरेटेड क्रेडेंशियल मैनेजमेंट
एफ़पीएस
फ़र्स्ट पार्टी सेट
IAB
Interactive Advertising Bureau
IDP
पहचान की पुष्टि करने वाली सेवा
आईईटीएफ़
इंटरनेट इंजीनियरिंग टास्क फ़ोर्स
आईपी
इंटरनेट प्रोटोकॉल पता
openRTB
रीयल-टाइम बिडिंग
OT
Origin ट्रायल
PatCG
निजी विज्ञापन टेक्नोलॉजी कम्यूनिटी ग्रुप
आरपी
भरोसा करने वाली पार्टी
SSP
सप्लाई-साइड प्लैटफ़ॉर्म
टीईई
ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट
UA
यूज़र एजेंट स्ट्रिंग
UA-CH
User-Agent Client Hints
W3C
वर्ल्ड वाइड वेब कंसोर्टियम
WIPB
जान-बूझकर आईपी ब्लाइंडनेस

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

सुझाव, राय या शिकायत की थीम खास जानकारी Chrome का जवाब
(इसकी जानकारी तीसरी तिमाही में भी दी गई है)

अलग-अलग तरह के हिस्सेदारों के लिए काम की जानकारी		 Privacy Sandbox की टेक्नोलॉजी, बड़े डेवलपर के लिए फ़ायदेमंद हैं. साथ ही, खास (छोटी) साइटें, सामान्य (बड़ी) साइटों से ज़्यादा योगदान देती हैं तीसरे सवाल के जवाब में कोई बदलाव नहीं किया गया है:

"Google ने सीएमए को यह वादा किया है कि वह Privacy Sandbox के प्रस्तावों को इस तरह से डिज़ाइन और लागू करेगा कि Google अपने कारोबार को प्राथमिकता देकर, प्रतिस्पर्धा को गलत तरीके से न प्रभावित करे. साथ ही, वह डिजिटल विज्ञापन में प्रतिस्पर्धा और पब्लिशर और विज्ञापन देने वालों पर पड़ने वाले असर को ध्यान में रखेगा. भले ही, उनके कारोबार का साइज़ कुछ भी हो. हम सीएमए के साथ मिलकर काम करते रहेंगे, ताकि यह पक्का किया जा सके कि हमारा काम इन प्रतिबद्धताओं के मुताबिक हो.

Privacy Sandbox की टेस्टिंग के दौरान, हम यह आकलन करेंगे कि अलग-अलग तरह के हिस्सेदारों के लिए, नई टेक्नोलॉजी कैसा परफ़ॉर्म करती हैं. इस मामले में, सुझाव, शिकायत या राय देना ज़रूरी है. खास तौर पर, ऐसा सुझाव, शिकायत या राय देना जो काम की हो और जिस पर कार्रवाई की जा सके. इससे, हमें तकनीकी डिज़ाइन को और बेहतर बनाने में मदद मिल सकती है.

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

हमें खुशी है कि डेवलपर को हमारा मौजूदा कॉन्टेंट मददगार लगा. हम ज़्यादा कॉन्टेंट उपलब्ध कराने के लिए प्रतिबद्ध हैं, ताकि डेवलपर यह समझ सकें कि नई टेक्नोलॉजी उनके लिए कैसे काम कर सकती हैं. पिछली तिमाही में, हमने privacysandbox.com पर "खबरें और अपडेट" सेक्शन जोड़ा था. साथ ही, इस बारे में पूरी जानकारी पब्लिश की थी कि Privacy Sandbox, आने वाले समय में उपयोगकर्ताओं के हिसाब से विज्ञापन दिखाने में कैसे मदद कर सकता है.

हमने डेवलपर के लिए ऑफ़िस में कामकाज के घंटों के दौरान सार्वजनिक सेशन भी आयोजित किए हैं. इनमें, सबसे सही तरीके और डेमो शेयर किए गए. साथ ही, प्रॉडक्ट और इंजीनियरिंग लीड के साथ सवाल-जवाब वाले सेशन भी आयोजित किए गए, ताकि लाइव चर्चा/सवाल पूछे जा सकें.
Core Web Vitals Privacy Sandbox API के इंतज़ार का समय, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी पर कैसे असर डालता है? Privacy Sandbox API को डिज़ाइन करते समय, इंतज़ार का समय कम से कम रखने पर ज़्यादा ध्यान दिया गया है. हमारी मौजूदा उम्मीद है कि एपीआई के इंतज़ार का समय, साइट के मुख्य वेब विटल पर कम से कम असर डालेगा. ऐसा इसलिए, क्योंकि ज़्यादातर एपीआई को वेबसाइट के शुरुआती रेंडर होने के बाद कॉल किया जाता है. हम हर एपीआई के लिए इंतज़ार का समय कम करने के लिए, लगातार निगरानी करते हैं और उसमें सुधार करते रहते हैं. साथ ही, हम लगातार जांच करने और सुझाव देने का सुझाव देते हैं.

रीयल टाइम बिडिंग प्रोसेस में लगने वाले समय के बारे में, "FLEDGE नीलामियों की परफ़ॉर्मेंस" सेक्शन में FLEDGE सेक्शन में बताया गया है
इंटरोऑपरेबिलिटी अन्य संभावित समाधानों के साथ इंटरऑपरेबिलिटी (दूसरे सिस्टम के साथ काम करना) से जुड़ी समस्याएं Privacy Sandbox का मकसद, वेब नेटवर्क की ज़रूरतों को पूरा करते हुए, उपयोगकर्ताओं को क्रॉस-साइट ट्रैकिंग से बचाना है. हम तीसरे पक्ष की कुकी जैसी लेगसी ब्राउज़र टेक्नोलॉजी का इस्तेमाल बंद करके, इस लक्ष्य को हासिल करना चाहते हैं. इन टेक्नोलॉजी की जगह, हम खास इस्तेमाल के उदाहरणों के लिए बनाई गई नई टेक्नोलॉजी उपलब्ध कराएंगे.

Privacy Sandbox के प्रस्तावों से, उपयोगकर्ता के डिवाइस से बाहर भेजे जाने वाले डेटा को सीमित करके निजता को बेहतर बनाया जा सकता है. इन प्रस्तावों में, ब्राउज़र से इकट्ठा किए गए डेटा को शेयर करने या किसी अन्य तरीके से प्रोसेस करने की वेबसाइट की क्षमता पर तकनीकी पाबंदियां नहीं लगाई गई हैं. इसलिए, ये टेक्नोलॉजी कंपनियों को "डेटा स्टीवर्डशिप" समझौते या इसी तरह के किसी अन्य कानूनी समझौते में शामिल होने से नहीं रोकती हैं. इसी तरह, वे उपयोगकर्ताओं को अन्य तरीकों से अपना डेटा शेयर करने की सहमति देने से नहीं रोकते.

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

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

विषय

सुझाव, राय या शिकायत की थीम खास जानकारी Chrome का जवाब
Google Search की रैंकिंग पर असर इस बारे में पूछताछ कि किसी वेबसाइट के Topics API के साथ काम करने की सुविधा का इस्तेमाल, Google Search के नतीजों की रैंकिंग के लिए संभावित सिग्नल के तौर पर किया जाएगा या नहीं कुछ वेबसाइटें, Topics API से ऑप्ट-आउट कर सकती हैं. Privacy Sandbox की टीम ने Search के संगठन से यह समन्वय नहीं किया है या अनुरोध नहीं किया है कि वे Topics API को अपनाने के लिए, वेबसाइटों को पेज रैंकिंग के तौर पर इंसेंटिव दें. Google ने सीएमए को पुष्टि की है कि Google Search, Topics API से ऑप्ट-आउट करने के किसी साइट के फ़ैसले का इस्तेमाल, रैंकिंग सिग्नल के तौर पर नहीं करेगा.
विषयों की कैटगरी तय करने वाला वेबपेज के विषय का पता लगाने के लिए, होस्टनेम के साथ-साथ यूआरएल और पेज का कॉन्टेंट जोड़ें. इससे, अलग-अलग हिस्सेदारों के लिए, वेबपेज को ज़्यादा काम का बनाया जा सकता है. फ़िलहाल, उपयोगकर्ता के ब्राउज़िंग इतिहास को वेबसाइट के होस्टनेम का इस्तेमाल करके बांटा जाता है. Chrome, विषयों के क्लासिफ़िकेशन में पेज लेवल के मेटाडेटा (जैसे, पेज के यूआरएल और/या कॉन्टेंट के सभी या कुछ कॉम्पोनेंट) को शामिल करने के विकल्पों का आकलन करता रहता है. किसी भी सुविधा में सुधार करते समय, निजता और गलत इस्तेमाल से जुड़े जोखिमों को ध्यान में रखना ज़रूरी है.

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

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

Topics API के लिए, विषयों को बांटने के दो काम के कॉम्पोनेंट हैं: (1) सबसे लोकप्रिय 10 हज़ार साइटों और उनके विषयों की सूची, और (2) डिवाइस पर मौजूद एमएल मॉडल, जो होस्टनेम को विषयों में बांटता है. बदलाव करने की सूची (1) को बड़ा करके, हम उन इलाकों के लिए क्लासिफ़िकेशन की परफ़ॉर्मेंस को बेहतर बना सकते हैं जहां क्लासिफ़ायर की परफ़ॉर्मेंस खराब हो सकती है.
एक हफ़्ते का इकोपॉच एक हफ़्ते का इकोसिस्टम, कम समय के फ़ैसले लेने वाले उपयोगकर्ताओं के लिए बहुत लंबा है. हम इस बात पर काम कर रहे हैं कि एपर्च का सही समय क्या होना चाहिए. साथ ही, हम इस बारे में ज़्यादा सुझाव/राय देने के लिए आपका स्वागत करते हैं कि नेटवर्क के लिए कौनसा एपर्च बेहतर होगा.
एचटीटीपी हेडर को वापस पाना विषयों के एचटीटीपी हेडर को वापस पाने के बारे में ज़रूरत के मुताबिक जानकारी नहीं है हेडर और fetch() के लिए काम जारी है. इस बारे में ज़्यादा जानकारी यहां उपलब्ध है. हमने एक्सप्लेनर में skipObservation की जानकारी भी जोड़ी है.
Topics का मकसद, सिर्फ़ विज्ञापन देने वालों की मदद करना है, न कि उपयोगकर्ताओं की Topics/Privacy Sandbox, इंडस्ट्री पर फ़ोकस करने वाला तरीका है. उपयोगकर्ताओं को मिलने वाले फ़ायदे के बारे में उतनी जानकारी नहीं दी गई है जितनी इंडस्ट्री को मिलने वाले फ़ायदे के बारे में दी गई है. हमारा मानना है कि Topics की मदद से, उपयोगकर्ताओं को दिलचस्पी के हिसाब से विज्ञापन दिखाए जा सकते हैं. इससे वेब को मुफ़्त और ओपन रखा जा सकता है. साथ ही, हमारा यह भी मानना है कि तीसरे पक्ष की कुकी की तुलना में, Topics की मदद से निजता को काफ़ी बेहतर बनाया जा सकता है. तीसरे पक्ष की कुकी को हटाने पर, पब्लिशर पर बुरा असर पड़ सकता है. साथ ही, इससे ज़्यादा खराब तरीके
अपनाए जा सकते हैं. ये तरीके ज़्यादा निजी नहीं होते, पारदर्शी नहीं होते, और इन्हें उपयोगकर्ता रीसेट नहीं कर सकते या कंट्रोल नहीं कर सकते. कई कंपनियां, Topics और Sandbox API की लगातार टेस्टिंग कर रही हैं. हम निजता को बेहतर बनाने और वेब को बेहतर बनाने के लिए टूल उपलब्ध कराने के लिए प्रतिबद्ध हैं.


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

FLEDGE

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

Privacy Sandbox के अन्य हिस्से, ट्रैकिंग को कवर करने के लिए पहले से ही कम करने की सुविधा देते हैं. इनके बारे में जानने के लिए, UA-CH, आईपी पते की सुरक्षा, और बाउंस ट्रैकिंग को कम करने की सुविधाएं देखें. साथ ही, समय के साथ इनमें और भी सुधार किए जाएंगे. Google का मकसद, FLEDGE को टारगेटिंग का एकमात्र मान्य समाधान बनाना नहीं है. इसके बजाय, हम Chrome ब्राउज़र में निजता बनाए रखने वाली विज्ञापन टेक्नोलॉजी को बेहतर बनाने के लिए, इंडस्ट्री और रेगुलेटर के साथ मिलकर काम करने के लिए प्रतिबद्ध हैं.
मशीन लर्निंग के इस्तेमाल के उदाहरण इस बारे में ज़्यादा जानकारी कि नीलामी बिडिंग एल्गोरिदम को ट्रेन करने के लिए, मशीन लर्निंग के इस्तेमाल के उदाहरणों को FLEDGE और एट्रिब्यूशन रिपोर्टिंग में कैसे शामिल किया जाएगा हम यह समझते हैं कि टेस्टर को Privacy Sandbox की टेक्नोलॉजी को लागू करने के सबसे काम के तरीके ढूंढने में मदद की ज़रूरत है. हमने मशीन लर्निंग के इनपुट के तौर पर, Privacy Sandbox API के अलग-अलग पहलुओं के इस्तेमाल से जुड़े दिशा-निर्देश पब्लिश करना शुरू कर दिया है. हाल ही में पब्लिश किए गए विज्ञापन को ज़्यादा काम का बनाने के बारे में जानकारी वाले लेख में बताया गया है कि विज्ञापन इंडस्ट्री, मशीन लर्निंग के लिए इन सिग्नल का इस्तेमाल कैसे कर सकती है. आने वाले समय में, हम इस तरह के दिशा-निर्देश पब्लिश करते रहेंगे.
FLEDGE की कुंजी वैल्यू (K/V) सर्वर से क्वेरी करना K/V सर्वर पर सार्वजनिक तौर पर क्वेरी क्यों की जा सकती है? K/V सर्वर का मकसद, FLEDGE नीलामियों को रीयल टाइम सिग्नल देना है. इसलिए, K/V सर्वर को उन जगहों से ऐक्सेस किया जा सकता है जहां FLEDGE नीलामियां होती हैं. ये नीलामियां उपयोगकर्ता के डिवाइसों पर होती हैं. इसलिए, यह ज़रूरी है कि सर्वर सार्वजनिक तौर पर उपलब्ध हो. K/V सर्वर में सेव की गई वैल्यू को सिर्फ़ वह पार्टी ऐक्सेस कर सकती है जिसके पास पहले से ही उसकी कुंजी है — इसलिए, अगर कोई विज्ञापन टेक्नोलॉजी कंपनी सिर्फ़ उन ब्राउज़र को कुंजियां देती है जो इंटरेस्ट ग्रुप में शामिल हैं और ऐसे कुंजियों का इस्तेमाल नहीं करती जिनका अनुमान लगाया जा सकता है, तो सिर्फ़ वे ब्राउज़र ही वैल्यू को ऐक्सेस कर पाएंगे जिन्हें अपनी नीलामी चलाने के लिए वैल्यू की ज़रूरत है.
तारीख/समय के हिसाब से टारगेटिंग कैसे करें? बिडिंग लॉजिक फ़ंक्शन में तारीख ऑब्जेक्ट के लिए सहायता. ऐसा करने के कई तरीके हैं. खरीदार, सेलर से मौजूदा तारीख और समय की जानकारी मांग सकते हैं. साथ ही, सेलर के लिए सभी खरीदारों को यह जानकारी देना आसान होना चाहिए. खरीदार, रीयल टाइम में की-वैल्यू के जवाब में तारीख और समय भी दे सकते हैं. आखिर में, खरीदार हर खरीदार के सिग्नल में अपने संदर्भ के हिसाब से जवाब के हिस्से के तौर पर तारीख और समय दे सकते हैं. सेलर, इस जानकारी को खरीदार की generateBid स्क्रिप्ट को पास कर सकता है.
उपयोगकर्ता प्राथमिकताएं उपयोगकर्ताओं को FLEDGE या अन्य तरीकों से दिखाए जाने वाले विज्ञापनों के लिए, विज्ञापन देने वाले के क्रिएटिव को ब्लॉक करने का विकल्प मिलता है. उपयोगकर्ता, Chrome में Ads API से ऑप्ट आउट कर सकते हैं. खास विज्ञापनों के लिए, काम की विज्ञापन टेक्नोलॉजी, सबसे अच्छी स्थिति में होती है. इससे यह कंट्रोल किया जा सकता है कि कौनसे क्रिएटिव दिखाए जाएं या उन्हें कैसे चुना जाए.
टाइमलाइन को साफ़ तौर पर दिखाना FLEDGE में निजता की सुरक्षा से जुड़ी सुविधाओं की उपलब्धता के बारे में ज़्यादा जानकारी का अनुरोध करें. जैसे, फ़ेंस किए गए फ़्रेम की ज़रूरत. हम साल की पहली तिमाही में, ज़्यादा जानकारी वाली टाइमलाइन पब्लिश करेंगे.
भ्रम की स्थिति की शिकायत करना इस बारे में ज़्यादा जानकारी का अनुरोध करें कि FLEDGE रिपोर्टिंग, फ़ेंस किए गए फ़्रेम और निजी एग्रीगेशन एपीआई जैसे अन्य एपीआई के साथ कैसे काम करेगी. हम आने वाले हफ़्तों में, निजी एग्रीगेशन एपीआई, FLEDGE, और फ़ेंस किए गए फ़्रेम के बीच इंटरैक्शन के बारे में जानकारी देने वाला लेख पब्लिश करेंगे.
रीयल-टाइम बिडिंग और FLEDGE FLEDGE को स्टैंडर्ड रीयल-टाइम बिडिंग के साथ इंटिग्रेट करने के तरीके के बारे में दिशा-निर्देश. विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली कंपनी के लिए, रीयल-टाइम बिडिंग की सुविधा को इस्तेमाल करना मुश्किल हो जाता है. इसकी दो मुख्य वजहें हैं: इवेंट लेवल का डेटा ऐक्सेस करना और ARA में आसानी से इंटिग्रेट होना. हम साल की पहली तिमाही में, इन दोनों सुविधाओं के बारे में अपडेट और जानकारी भेजने वाले हैं.
FLEDGE नीलामियों की परफ़ॉर्मेंस टेस्टर की ओर से मिली रिपोर्ट में बताया गया है कि FLEDGE नीलामियों में इंतज़ार का समय ज़्यादा है टेस्टर से मिले नतीजों और इस्तेमाल के उदाहरणों की रिपोर्ट हमें अच्छी लगीं. साथ ही, हमने FLEDGE की परफ़ॉर्मेंस को बेहतर बनाने के तरीके के बारे में कुछ सुझाव भी शेयर किए हैं.

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

हम आने वाले हफ़्तों में, इंटिग्रेशन गाइड शेयर करने वाले हैं. इनमें, इस बारे में ज़्यादा जानकारी होगी कि FLEDGE, पहले पक्ष (ग्राहक) के डेटा के साथ कैसे इंटिग्रेट होगा.
K-anonymity वैल्यू "K" की वैल्यू को "k-anon" में कैसे बदला जाएगा और क्या इसे पब्लिश किया जाएगा? "K" वैल्यू को अभी तक फ़ाइनल नहीं किया गया है. हम अपने प्लान के बारे में ज़्यादा जानकारी तब शेयर करेंगे, जब वे तैयार हो जाएंगे. हम इस बारे में ज़्यादा जानना चाहते हैं कि किसी अनजान k वैल्यू की वजह से, FLEDGE की तैयारी और एमएल मॉडल की ट्रेनिंग में कैसे रुकावट आ सकती है. साथ ही, इस विषय पर ज़्यादा सुझाव/राय/शिकायत/राय देने के लिए हम आपका स्वागत करते हैं.
एक से ज़्यादा एसएसपी के साथ काम करना FLEDGE में एक से ज़्यादा एसएसपी कैसे काम करेंगे? FLEDGE, एक से ज़्यादा सेलर की नीलामियों के साथ काम करता है, जैसा कि इस प्रपोज़ल में बताया गया है.
बिडिंग लॉजिक की जानकारी डीएसपी बिडिंग लॉजिक को JavaScript में एक्सपोज़ होने की चिंता बिडिंग के मौजूदा डिज़ाइन लॉजिक के साथ, JavaScript को दूसरे लोग ऐक्सेस कर सकते हैं. हालांकि, हम इस बारे में ज़्यादा सुझाव/राय या शिकायत का स्वागत करते हैं कि डीएसपी के लिए यह समस्या क्यों हो सकती है.
prebid.js FLEDGE में prebid.js के साथ काम करने की टाइमलाइन क्या है? FLEDGE मॉड्यूल, Prebid.js के सिर्फ़ 7.14 और उसके बाद के वर्शन के साथ काम करता है. जिन पब्लिशर को टेस्ट करना है उन्हें FLEDGE मॉड्यूल जोड़ना होगा और अपने Prebid इंस्टेंस को अपग्रेड करना होगा.
FLEDGE में उपयोगकर्ता के तय किए गए फ़ंक्शन FLEDGE में, उपयोगकर्ता के तय किए गए फ़ंक्शन (यूडीएफ़) कैसे काम करेंगे? ये ऐसे फ़ंक्शन हैं जिन्हें एंड यूज़र प्रोग्राम कर सकते हैं, ताकि एपीआई की सुविधाओं को बेहतर बनाया जा सके. ज़्यादा जानकारी के लिए यहां जाएं. इस सुविधा को अभी और बेहतर बनाया जा रहा है. इसलिए, इस्तेमाल के उदाहरणों के बारे में ज़्यादा सुझाव/राय दें या शिकायत करें.
एक जैसी दिलचस्पी वाले ग्रुप के संसाधनों पर, एक ही ऑरिजिन से जुड़ी पाबंदी को कम करना विज्ञापन टेक्नोलॉजी के कुछ इस्तेमाल के उदाहरणों को चालू करने के लिए, एक ही ऑरिजिन की पाबंदी को हटाने का अनुरोध FLEDGE के मौजूदा वर्शन में, biddingLogicUrl, biddingWasmHelperUrl, dailyUpdateUrl, और trustedBiddingSignalsUrl का ऑरिजिन, इंटरेस्ट ग्रुप के मालिक के ऑरिजिन से मेल खाना चाहिए.

यह पाबंदी, हमलावरों के कुछ खास तरीकों का इस्तेमाल करने से रोकने के लिए है. इस बारे में यहां बताया गया है.
interestGroup Ownership यह तय करने का अनुरोध कि विज्ञापन टेक्नोलॉजी कंपनी, सभी साइटों पर एक ही इंटरेस्ट ग्रुप के लिए joinInterestGroup का इस्तेमाल कर सकती है या नहीं हमारा ध्यान इस बात पर है कि ऑडियंस का इस्तेमाल कैसे किया जाता है, न कि उन्हें बनाने के तरीके पर. हम संभावित तरीकों के बारे में चर्चा कर रहे हैं. साथ ही, हमें इस बारे में और सुझाव, राय या शिकायतें भेजने में खुशी होगी.
Key Value Server की कुंजी की समयसीमा खत्म होना मिलते-जुलते इंटरेस्ट ग्रुप की समयसीमा खत्म होने के बाद, सर्वर पासकोड हटाने के बारे में चर्चा हम पासकोड की समयसीमा खत्म होने की समस्या को हल करने के तरीके ढूंढ रहे हैं. साथ ही, हमें इस बारे में राय, सुझाव या शिकायत चाहिए.

डिजिटल विज्ञापनों की परफ़ॉर्मेंस का आकलन करना

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

सुझाव, राय या शिकायत की थीम खास जानकारी Chrome का जवाब
ऑरिजिन ट्रायल का ट्रैफ़िक यूटिलिटी टेस्टिंग करने के लिए, मौजूदा ऑरिजिन ट्रायल ट्रैफ़िक काफ़ी नहीं है. मौजूदा ऑरिजिन ट्रायल, इकोसिस्टम के प्लेयर के लिए हैं. इनकी मदद से, फ़ंक्शनल टेस्टिंग की जा सकती है, ताकि यह पक्का किया जा सके कि एपीआई सही तरीके से काम कर रहा है या नहीं. हम समझते हैं कि Privacy Sandbox के अलग-अलग एपीआई के डेवलपमेंट के बाद, यूटिलिटी टेस्टिंग के लिए ज़्यादा ट्रैफ़िक की ज़रूरत होगी. टेस्टिंग की मौजूदा टाइमलाइन के मुताबिक, यह सुविधा 2023 की तीसरी तिमाही में, सार्वजनिक तौर पर उपलब्ध हो जाएगी.इसका मतलब है कि डेटा इस्तेमाल करने के उदाहरणों के लिए टेक्नोलॉजी लॉन्च हो जाएंगी और वे Chrome के 100% ट्रैफ़िक के लिए उपलब्ध हो जाएंगी. privacysandbox.com पर हमारी अप-टू-डेट टाइमलाइन देखें. डेटा इस्तेमाल करने के उदाहरणों की टेस्टिंग के लिए, ज़्यादा ट्रैफ़िक की ज़रूरत पड़ने पर, हमें अन्य सुझाव, शिकायत या राय भेजें.
Privacy Sandbox के अलग-अलग मेज़रमेंट एपीआई की सुविधाओं में ओवरलैप Privacy Sandbox में मेज़रमेंट के कई तरीकों के ओवरलैप होने से समस्याएं बढ़ेंगी. उदाहरण के लिए, Attribution Reporting API और Private Aggregation API. हम एपीआई के इस्तेमाल के अलग-अलग उदाहरणों को साफ़ तौर पर बताने के लिए, बेहतर दस्तावेज़ बनाने पर काम कर रहे हैं. साथ ही, हम उन अन्य सुझावों, राय या शिकायतों का स्वागत करते हैं जिनमें एपीआई के इस्तेमाल के बारे में ज़्यादा जानकारी चाहिए. उदाहरण के लिए, Attribution Reporting API का मकसद खास तौर पर कन्वर्ज़न मेज़रमेंट की सुविधा देना है. वहीं, Private Aggregation API और Shared Storage, सामान्य काम के लिए बने एपीआई हैं. इनका मकसद, अलग-अलग साइटों पर मेज़रमेंट के इस्तेमाल के उदाहरणों की एक बड़ी रेंज के साथ काम करना है.
रिपोर्ट के लिए किया गया अनुरोध पूरा न होने पर, फिर से कोशिश करना रिपोर्ट करने के अनुरोध के पूरा न होने पर, उसे कितनी बार भेजा जाता है. हमने इस बारे में दिशा-निर्देश पब्लिश किए हैं. खास जानकारी के लिए, रिपोर्ट सिर्फ़ तब भेजी जाती हैं, जब ब्राउज़र चालू/ऑनलाइन हो. पहली बार रिपोर्ट भेजने में समस्या आने के बाद, पांच मिनट बाद फिर से कोशिश की जाती है. दो बार कोशिश करने के बाद, 15 मिनट बाद फिर से रिपोर्ट भेजने की कोशिश की जाती है. इसके बाद, रिपोर्ट नहीं भेजी जाती.
रिपोर्टिंग में देरी रिपोर्टिंग में कितनी देरी हो सकती है? हमें रिपोर्टिंग में हो रही देरी के बारे में, नेटवर्क से ज़्यादा सुझाव, शिकायत या राय चाहिए. इससे हमें इस देरी का आकलन करने में मदद मिलेगी.
पेजों को पहले से रेंडर करना क्या एआरए एट्रिब्यूशन, पहले से रेंडर किए गए पेजों पर काम करेगा? एट्रिब्यूशन रजिस्ट्रेशन को तब तक के लिए रोक दिया जाता है, जब तक कि पेज को ऐक्टिव नहीं किया जाता (असल क्लिक या व्यू नहीं होता). इसका मतलब है कि हम `attributionsrc` अनुरोध पिंग को बाद के लिए टाल देंगे.
कन्वर्ज़न लिफ़्ट को मेज़र करना एक ही डोमेन पर A/B टेस्टिंग की मदद से कन्वर्ज़न लिफ़्ट को मेज़र करने का तरीका वेबसाइटें, एट्रिब्यूशन रिपोर्टिंग की मदद से एक ही डोमेन पर A/B टेस्टिंग की मदद से कन्वर्ज़न लिफ़्ट को मेज़र कर सकती हैं. वे एग्रीगेट एपीआई का इस्तेमाल करके, अपने A/B पैरामीटर को कीवर्ड के तौर पर कोड कर सकते हैं. इसके बाद, उन कीवर्ड बकेट के हिसाब से कन्वर्ज़न वैल्यू की खास जानकारी वाली रिपोर्ट पा सकते हैं.
(तीसरी तिमाही में भी रिपोर्ट किए गए) क्रॉस-डोमेन कन्वर्ज़न क्रॉस-डोमेन कन्वर्ज़न को ट्रैक करने का तरीका. जैसे, दो या उससे ज़्यादा डेस्टिनेशन के साथ चौथी तिमाही का अपडेट:

हमने लैंडिंग पेज डेस्टिनेशन की पाबंदी हटाने के लिए, एक प्रस्ताव पब्लिश किया है. इससे क्रॉस-डोमेन बातचीत को ट्रैक किया जा सकेगा. यह प्रस्ताव लागू कर दिया गया है.
(तीसरी तिमाही में भी रिपोर्ट की गई)
कन्वर्ज़न रिपोर्ट में समयसीमा की सेटिंग 		रिपोर्ट फ़िल्टर / 24 घंटे से कम समय के लिए एक्सपायर होने की सुविधा के लिए अनुरोध चौथी तिमाही का अपडेट:

हमने यह पुल रिक्वेस्ट शेयर किया है. इससे, रिपोर्टिंग विंडो और समयसीमा खत्म होने की अवधि अलग-अलग हो जाएगी. इससे, रिपोर्टिंग में लगने वाले समय और कन्वर्ज़न की समयसीमा खत्म होने के बीच के अंतर को कम करने में मदद मिलेगी. इसे अब M110 वर्शन में लॉन्च किया गया है.
धोखाधड़ी और गलत इस्तेमाल विज्ञापन देने वाले और मार्केटर से मिले अनुरोध, ताकि वे उन पब्लिशर साइटों के आधार पर डेटा को अलग-अलग हिस्सों में बांट सकें और इकट्ठा कर सकें जहां उनके विज्ञापन दिखाए जाते हैं. इससे, धोखाधड़ी वाले संभावित विज्ञापन तरीकों के बारे में ज़्यादा जानकारी भी मिलेगी इस सुझाव/राय/शिकायत पर यहां चर्चा की जा रही है. साथ ही, हम इस बारे में और सुझाव/राय/शिकायतें पाने के लिए तैयार हैं.
(इसकी शिकायत तीसरी तिमाही में भी की गई थी) इवेंट लेवल की रिपोर्टिंग में देरी कुछ इस्तेमाल के उदाहरणों के लिए, इवेंट लेवल की रिपोर्टिंग में 2 से 30 दिन की देरी बहुत ज़्यादा हो सकती है. इवेंट लेवल की रिपोर्टिंग में, रिपोर्टिंग विंडो की डिफ़ॉल्ट अवधि 2, 7, और 30 दिन होती है. "expiry" पैरामीटर का इस्तेमाल करके, इसमें बदलाव किया जा सकता है. विज्ञापन टेक्नोलॉजी कंपनियां, कम से कम एक दिन के लिए एक्सपायर होने की सुविधा को कॉन्फ़िगर कर सकती हैं, ताकि दो दिन से कम समय में संभावित रिपोर्ट मिल सकें. हम निजता की सुरक्षा के लिए, डेटा मिटाने की समयसीमा को एक दिन तक सीमित रखते हैं. ज़्यादा जानकारी वाली रिपोर्टिंग से, टाइमिंग अटैक हो सकते हैं. इसके अलावा, हम इवेंट लेवल और एग्रीगेट रिपोर्ट के लिए, अलग-अलग "समयसीमा" पैरामीटर सेट करने की अनुमति देते हैं. यहां देखें. इसके अलावा, Google Ads को ऐसी कोई खास रिपोर्टिंग विंडो नहीं मिलेगी जो एट्रिब्यूशन रिपोर्टिंग एपीआई के ज़रिए, अन्य विज्ञापन टेक्नोलॉजी कंपनियों को नहीं मिलती.
रिपोर्टिंग के ऑरिजिन के लिए एक ही ज़रूरी शर्त सोर्स रजिस्टर करने के ऑरिजिन को कन्वर्ज़न रजिस्टर करने के ऑरिजिन से मेल खाने की ज़रूरी शर्त हटाने का अनुरोध हमारा सुझाव है कि इस इस्तेमाल के उदाहरण को हल करने के लिए, रजिस्टर करने की प्रक्रिया को किसी दूसरे को सौंपने के लिए एचटीटीपी रीडायरेक्ट का इस्तेमाल करें. नए दिशा-निर्देशों के बारे में अन्य सुझाव, शिकायत या राय देने के लिए, हम आपका स्वागत करते हैं.
कन्वर्ज़न ट्रैकिंग यह पता लगाना ज़रूरी है कि कन्वर्ज़न, विज्ञापन देने वाले के तय किए गए कुछ घंटों से पहले/बाद में हुआ है या नहीं Attribution Reporting API, सोर्स एट्रिब्यूशन के लिए समयसीमा की विंडो और प्राथमिकता सेट करने की सुविधा देता है. दोनों का इस्तेमाल करके, तकनीकी तौर पर X दिनों की विंडो के अंदर हुए कन्वर्ज़न को, X दिनों के बाद हुए कन्वर्ज़न से अलग एट्रिब्यूट किया जा सकता है.
शोर का सिम्युलेशन कम कन्वर्ज़न वाले विज्ञापन देने वालों पर पड़ने वाले असर को समझने के लिए, हर बकेट के लिए कन्वर्ज़न के अलग-अलग वॉल्यूम को सिम्युलेट करने का अनुरोध करना हम Noise Lab के आने वाले वर्शन में, इसे सिम्युलेट करने के तरीके जोड़ने की कोशिश कर रहे हैं. अगर आपका कोई और सुझाव, राय या शिकायत है, तो हमें बताएं.
मोबाइल पर रिपोर्टिंग क्या मोबाइल पर बैकग्राउंड में Chrome चलने पर भी रिपोर्ट भेजी जाएगी? फ़िलहाल, मोबाइल पर भी Chrome के बैकग्राउंड में होने पर रिपोर्ट नहीं भेजी जाएगी. जब एपीआई, Android Privacy Sandbox के साथ इंटिग्रेट होगा, तो यह बदल सकता है. यहां देखें. ध्यान दें कि Android Privacy Sandbox, सीएमए के स्वीकार किए गए वादे का हिस्सा नहीं है.
डेटा की उपलब्धता Privacy Sandbox API की मदद से, Google के पास डेटा का ज़्यादा ऐक्सेस होगा पहला, Google Ads को Attribution Reporting API या Privacy Sandbox के अन्य एपीआई से मिलने वाले डेटा का कोई खास ऐक्सेस नहीं मिलता. इस समस्या के बारे में, "इंटरऑपरेबिलिटी" में मौजूद सामान्य सुझाव/राय/शिकायत/राय वाले सेक्शन में भी बताया गया है. इस सेक्शन में, Google की जवाबदेही के बारे में ज़्यादा जानकारी दी गई है.

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

गुप्त ट्रैकिंग को सीमित करना

यूज़र-एजेंट रिडक्शन

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

हमारे पास कुछ सबूत हैं कि एसयूए को डिप्लॉय किया गया है और यह आज उपलब्ध है. इस बात की जानकारी Scientia Mobile के ब्लॉग पोस्ट में दी गई है. इसमें, एसयूए बनाने के लिए UA-CH और WURFL API का इस्तेमाल करने का तरीका बताया गया है.

###

यूज़र-एजेंट क्लाइंट हिंट

सुझाव, राय या शिकायत की थीम खास जानकारी Chrome का जवाब
गुप्त ट्रैकिंग की रोकथाम के लिए इस्तेमाल की जाने वाली अन्य तकनीकों के साथ UA-CH को टेस्ट करना एक साथ सभी Privacy Sandbox API और फ़िंगरप्रिंट करने की तकनीकों को टेस्ट करने के तरीके के बारे में दिशा-निर्देश हमारा टेस्टिंग प्लान इस तरह से डिज़ाइन किया गया था कि फ़िंगरप्रिंटिंग को रोकने के कुछ उपायों को डेवलप करने के लिए, अलग-अलग समयसीमाएं तय की जा सकें. यह प्लान, Sandbox के अन्य प्रस्तावों के मुकाबले अलग था. इससे यह ज़ाहिर होता है कि फ़िंगरप्रिंटिंग को रोकने के कुछ उपाय (जैसे, निजता बजट, आईपी सुरक्षा, और बाउंस ट्रैकिंग को कम करना) पूरी तरह से तैयार हो जाएंगे और तीसरे पक्ष की कुकी के बंद होने के बाद ही, सभी के लिए उपलब्ध कराए जा सकेंगे.

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

उपयोगकर्ता एजेंट हेडर में दी गई जानकारी को कम करने और UA-CH API के प्लान, 18 मार्च, 2022 को W3C के धोखाधड़ी रोधी कम्यूनिटी ग्रुप को दिखाए गए थे. साथ ही, 20 जनवरी, 2022 को वेब पेमेंट्स वर्किंग ग्रुप और वेब पेमेंट्स सिक्योरिटी इंटरेस्ट ग्रुप, दोनों को दिखाए गए थे. प्रज़ेंटेशन के दौरान या उसके बाद, कोई गंभीर समस्या नहीं बताई गई.

Google ने सुझाव, शिकायत या राय पाने के लिए, 100 से ज़्यादा साइट ऑपरेटर से संपर्क किया है. इसके अलावा, Google ने Blink-Dev चैनलों का इस्तेमाल करके, उपयोगकर्ता-एजेंट को कम करने के रोल-आउट के बारे में सार्वजनिक तौर पर बताया है. यह जानकारी, नेटवर्क के हिस्सेदारों के सुझावों और राय के आधार पर दी गई है.
समयावधि रोल आउट के समय और इंडस्ट्री की तैयारी के बारे में बताई गई समस्याएं UA-CH से जुड़ा खास सेक्शन यहां देखें
Chrome Platform Status UA-CH के लिए, chromestatus पेज को अपडेट करने का अनुरोध किया गया chromestatus की एंट्री को 19 दिसंबर को "मिक्स्ड सिग्नल" के तौर पर अपडेट किया गया था.

आईपी प्रोटेक्शन (पहले इसे Gnatcatcher कहा जाता था)

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

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

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

हम उन लोगों के साथ मिलकर काम कर रहे हैं जो इस मामले से जुड़े हैं. इससे यह पक्का किया जा सकेगा कि Chrome, आईपी पतों के लिए सही इस्तेमाल के उदाहरणों के साथ काम करता रहे. हम आईपी की भौगोलिक जानकारी के बारे में ज़्यादा जानकारी देने के लिए, यहां नेटवर्क के सदस्यों से सुझाव, राय या शिकायतें मांग रहे हैं.

प्राइवसी बजट

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

इस प्रस्ताव के पूरी तरह से तैयार होने पर, हम इसकी ज़्यादा जानकारी शेयर करेंगे. इस बीच, हम सभी हिस्सेदारों से अपना सुझाव, राय या शिकायत शेयर करने का अनुरोध करते हैं. इससे हमें इस प्रस्ताव को बेहतर बनाने में मदद मिलेगी.

अलग-अलग साइटों पर निजता की सीमाओं को बेहतर बनाना

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

सुझाव, राय या शिकायत की थीम खास जानकारी Chrome का जवाब
(तीसरी तिमाही में भी रिपोर्ट की गई) डोमेन की सीमा खाते से जुड़े डोमेन की संख्या बढ़ाने का अनुरोध करना चौथी तिमाही का अपडेट:

हमने स्थानीय टेस्टिंग के लिए FPS रिलीज़ किया है. इसमें GitHub पर, मॉक सेट सबमिशन की प्रोसेस और rSA और rSAFor को स्थानीय तौर पर टेस्ट करने के लिए एक फ़्लैग शामिल है. हमने डेवलपर के लिए एफ़पीएस के बारे में दो ओपन मीटिंग भी होस्ट की हैं. इनमें, एफ़पीएस के सबसेट के इस्तेमाल के उदाहरणों से जुड़े सवालों के जवाब दिए गए हैं. हमारा सुझाव है कि डेवलपर, एफ़पीएस की सुविधा को टेस्ट करें. इससे उन्हें यह फ़ीडबैक देने में मदद मिलेगी कि इससे उनके इस्तेमाल के उदाहरणों के लिए, एफ़पीएस के इस्तेमाल पर कैसे असर पड़ेगा.

हमने WICG कॉल में साफ़ तौर पर बताया है कि Chrome, उपयोगकर्ताओं की निजता को ध्यान में रखते हुए, काम का सलूशन उपलब्ध कराने के लिए प्रतिबद्ध है. इसलिए, हम कम्यूनिटी से सुझाव, शिकायत या राय पाना पसंद करेंगे. इन सुझावों, शिकायतों या राय में, ऐसे खास इस्तेमाल के उदाहरणों के बारे में बताया जाना चाहिए जिन पर डोमेन की सीमा का असर पड़ सकता है. इससे हमारी टीम, उपयोगकर्ता की निजता की सुरक्षा करते हुए, इन इस्तेमाल के उदाहरणों को हल करने के तरीकों पर विचार कर पाएगी.
गलत इस्तेमाल को कम करने के उपायों के बारे में ज़्यादा जानकारी का अनुरोध करना अगर किसी डोमेन को किसी ऐसे सेट में जोड़ा जाता है जिसकी सहमति उसने नहीं दी है, तो क्या होगा? हमने 2 दिसंबर, 2022 को पहले पक्ष के सेट सबमिट करने के दिशा-निर्देश यहां पब्लिश किए हैं.

सबमिशन के दिशा-निर्देशों में बताया गया है कि बदलाव मैनेज करने की कोई भी सेट की गई प्रोसेस, GitHub पर पुष्टि करने की प्रोसेस का पालन करेगी और उसका सम्मान करेगी. इसमें मालिकाना हक की पुष्टि भी शामिल है. इससे इस जोखिम को कम किया जा सकता है.
बुरे बर्ताव को कम करना फ़र्स्ट-पार्टी सेट फ़ॉर्मेशन का गलत इस्तेमाल किया जा सकता है हम सबसेट टाइप के लिए तकनीकी जांच को बढ़ाने के तरीकों पर काम कर रहे हैं. साथ ही, यहां कम्यूनिटी से ज़्यादा इनपुट पाने की कोशिश कर रहे हैं.
विज्ञापनों के इस्तेमाल के उदाहरण विज्ञापन टारगेटिंग के लिए, पहले पक्ष के सेट का इस्तेमाल किया जाना चाहिए या नहीं, इस बारे में सवाल हम पहले पक्ष के सेट के लिए, विज्ञापन टारगेटिंग के इस्तेमाल के उदाहरणों को इस्तेमाल करने की कोशिश नहीं कर रहे हैं. हमारा सुझाव है कि ऐसे इस्तेमाल के उदाहरणों के लिए, उपलब्ध Ads API का इस्तेमाल करें.
(इसकी शिकायत तीसरी तिमाही में भी की गई थी) नीति यह चिंता है कि एफ़पीएस, "लागू होने वाले डेटा सुरक्षा कानून" के बारे में सीएमए की प्रतिबद्धताओं के मुताबिक नहीं है. इसकी वजह यह है कि जीडीपीआर, किसी सेट में साइटों की संख्या पर कोई सीमा नहीं लगाता, जबकि एफ़पीएस में तीन की सीमा तय की गई है तीसरे सवाल के जवाब में कोई बदलाव नहीं हुआ है:

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

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

इस विकल्प के बारे में बताए जाने के बाद, Chrome ने फ़र्स्ट-पार्टी सेट के प्रस्ताव को अपडेट किया है. साथ ही, नए सेट बनाने के लिए सबमिट करने के दिशा-निर्देश पब्लिश किए हैं.

Fenced Frames API

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

Shared Storage API

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

हमारा अनुमान है कि विज्ञापनों के इस्तेमाल के उदाहरणों के लिए, डीएसपी और मेज़रमेंट सलूशन देने वाली कंपनियां मुख्य इंटिग्रेटर होंगी.

CHIPs

सुझाव, राय या शिकायत की थीम खास जानकारी Chrome का जवाब
(तीसरी तिमाही में भी रिपोर्ट की गई) पार्टीशन की ज़रूरत पहले पक्ष की कुकी पर "अलग-अलग हिस्सों में बांटी गई" एट्रिब्यूट के लिए, व्यवहार से जुड़ी साफ़ तौर पर बताई गई ज़रूरी शर्त जोड़ें. चौथी तिमाही का अपडेट:

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

FedCM

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

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

(FedCM स्पेसिफ़िकेशन में, क्रॉस-साइट कॉर्रेलेशन को एपीआई से जुड़े निजता जोखिम के तौर पर पहचाना जाता है. साथ ही, इसे कम करने के लिए, डायरेक्टेड (हर साइट के लिए) आइडेंटिफ़ायर के बारे में बताया जाता है. हालांकि, डायरेक्टेड आइडेंटिफ़ायर का इस्तेमाल करने का फ़ैसला, आईडीपी को लेना होता है. ब्राउज़र इस पर कोई फ़ैसला नहीं लेता.)

FedCM, उपयोगकर्ता को पहचान से जुड़ी पसंद का विकल्प पहले से ही देता है. उदाहरण के लिए, अगर किसी उपयोगकर्ता के पास एक ही आईडीपी (जैसे, वर्क प्रोफ़ाइल और निजी प्रोफ़ाइल) के साथ कई पहचानें हैं, तो FedCM उपयोगकर्ता को यह चुनने का विकल्प देता है कि उसे आरपी की साइट में लॉग इन करने के लिए, किसका इस्तेमाल करना है. इसके अलावा, हर आरपी यह तय करता है कि उसकी साइट पर कौनसे आईडीपी काम करेंगे. इस फ़ैसले का एक पहलू यह है कि आईडीपी किस तरीके का इस्तेमाल करता है. भले ही, वह FedCM हो या कोई दूसरी टेक्नोलॉजी. फिर से, ब्राउज़र आरपी या आईडीपी के लिए ये विकल्प तय नहीं करता.

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

Private State Token API

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