साल 2023 की तीसरी तिमाही की तिमाही रिपोर्ट, जिसमें Privacy Sandbox के प्रस्तावों और Chrome के जवाब पर, नेटवर्क से मिले सुझाव/राय या शिकायत की खास जानकारी दी गई है.
सीएमए के साथ किए गए अपने वादे के तहत, Google ने अपने निजता सैंडबॉक्स के प्रस्तावों के लिए, हिस्सेदारों के साथ जुड़ाव की प्रोसेस के बारे में सार्वजनिक तौर पर हर तीन महीने की रिपोर्ट देने पर सहमति दी है. समझौते के पैराग्राफ़ 12 और 17(c)(ii) देखें. Privacy Sandbox के सुझाव/राय/शिकायत/राय देने वाले फ़ॉर्म की खास जानकारी वाली ये रिपोर्ट, सुझाव/राय/शिकायत/राय देने वाले फ़ॉर्म की खास जानकारी में बताए गए अलग-अलग सोर्स से मिले सुझाव/राय/शिकायत/राय को इकट्ठा करके जनरेट की जाती हैं. इनमें ये सोर्स शामिल हैं, लेकिन इन तक ही सीमित नहीं हैं: GitHub पर मौजूद समस्याएं, privacysandbox.com पर उपलब्ध सुझाव/राय/शिकायत/राय देने वाला फ़ॉर्म, इंडस्ट्री के हिस्सेदारों के साथ हुई मीटिंग, और वेब स्टैंडर्ड फ़ोरम. Chrome, नेटवर्क से मिले सुझावों/शिकायतों/राय का स्वागत करता है. साथ ही, डिज़ाइन से जुड़े फ़ैसलों में, इन सुझावों/शिकायतों/राय को शामिल करने के तरीकों को लगातार एक्सप्लोर कर रहा है.
सुझाव, शिकायत या राय की थीम को हर एपीआई के हिसाब से, उनकी संख्या के आधार पर रैंक दी जाती है. ऐसा करने के लिए, Chrome की टीम को किसी थीम के बारे में मिले सुझावों, राय या शिकायतों की संख्या को इकट्ठा किया जाता है. इसके बाद, उन्हें संख्या के हिसाब से कम से ज़्यादा के क्रम में लगाया जाता है. आम तौर पर मिलने वाले सुझाव/राय/शिकायत/राय के विषयों की पहचान करने के लिए, सार्वजनिक मीटिंग (W3C, PatCG, IETF), सीधे सुझाव/राय/शिकायत/राय, GitHub, और Google की इंटरनल टीमों और सार्वजनिक फ़ॉर्म से पूछे जाने वाले आम सवालों के विषयों की समीक्षा की गई.
खास तौर पर, वेब स्टैंडर्ड बॉडी की मीटिंग के मिनट की समीक्षा की गई. साथ ही, सीधे फ़ीडबैक के लिए, Google के 1:1 हिस्सेदारों की मीटिंग के रिकॉर्ड, अलग-अलग इंजीनियरों को मिले ईमेल, एपीआई की मेलिंग सूची, और सार्वजनिक फ़ीडबैक फ़ॉर्म को ध्यान में रखा गया. इसके बाद, Google ने इन अलग-अलग आउटरीच गतिविधियों में शामिल टीमों के बीच समन्वय किया, ताकि यह पता लगाया जा सके कि हर एपीआई के लिए, कौनसी थीम सबसे ज़्यादा लोकप्रिय हैं.
Chrome पर मिले सुझाव, शिकायत या राय के जवाबों के बारे में जानकारी, पब्लिश किए गए अक्सर पूछे जाने वाले सवालों, हिस्सेदारों की ओर से उठाई गई समस्याओं के जवाबों, और सार्वजनिक तौर पर रिपोर्ट करने के मकसद से किसी खास बात पर फ़ैसला लेने के आधार पर दी गई है. डेवलपमेंट और टेस्टिंग के मौजूदा फ़ोकस को दिखाते हुए, हमें Topics, Protected Audience, और एट्रिब्यूशन रिपोर्टिंग एपीआई के बारे में खास तौर पर सवाल और सुझाव मिले.
हो सकता है कि रिपोर्टिंग की मौजूदा अवधि खत्म होने के बाद मिले सुझाव/शिकायत/राय पर, Chrome ने अब तक कोई जवाब न दिया हो.
शॉर्ट फ़ॉर्म की ग्लॉसरी
- सीएचआईपीएस
- कुकीज़ हैविंग इंडिपेंडेंट पार्टिशन्ड स्टेट
- डीएसपी
- डिमांड-साइड प्लैटफ़ॉर्म
- FedCM
- फ़ेडरेटेड क्रेडेंशियल मैनेजमेंट
- एफ़पीएस
- फ़र्स्ट पार्टी सेट
- IAB
- Interactive Advertising Bureau
- IDP
- पहचान की पुष्टि करने वाली सेवा
- आईईटीएफ़
- इंटरनेट इंजीनियरिंग टास्क फ़ोर्स
- आईपी
- इंटरनेट प्रोटोकॉल पता
- openRTB
- रीयल-टाइम बिडिंग
- OT
- Origin ट्रायल
- PatCG
- निजी विज्ञापन टेक्नोलॉजी कम्यूनिटी ग्रुप
- आरपी
- भरोसा करने वाली पार्टी
- SSP
- सप्लाई-साइड प्लैटफ़ॉर्म
- टीईई
- ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट
- UA
- यूज़र एजेंट स्ट्रिंग
- UA-CH
- User-Agent Client Hints
- W3C
- वर्ल्ड वाइड वेब कंसोर्टियम
- WIPB
- जान-बूझकर आईपी ब्लाइंडनेस
सामान्य सुझाव, राय या शिकायत, किसी खास एपीआई या टेक्नोलॉजी के लिए नहीं
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| ईकोसिस्टम के लिए तैयारी | एसएसपी ने इस बात पर चिंता जताई कि पब्लिशर तैयार नहीं हैं और डिप्लॉयमेंट से जुड़ा ज़रूरी काम नहीं कर रहे हैं. | प्राइवसी सैंडबॉक्स के आउटरीच में, पब्लिशर को शिक्षित करने पर खास तौर पर फ़ोकस किया गया है. इसमें, पब्लिशर और एसएसपी, दोनों के साथ वेबिनार और मीटिंग शामिल हैं. इनका मकसद, प्राइवसी सैंडबॉक्स को डिप्लॉय करने के काम को आगे बढ़ाना है. |
| तीसरे पक्ष की कुकी का इस्तेमाल बंद होना | इंडस्ट्री के टेक्नोलॉजी ब्लैकआउट की वजह से, 2023 की चौथी तिमाही में तीसरे पक्ष की कुकी के इस्तेमाल को रोकने (3PCD) से जुड़ी चिंताएं बढ़ गई हैं. | सीएमए के साथ प्राइवसी सैंडबॉक्स की टाइमलाइन पर चर्चा की गई है. इसकी मदद से, साल 2024 की दूसरी छमाही तक इसे लॉन्च करने की तैयारी की जा रही है. Privacy Sandbox, 3PCD को ज़्यादा से ज़्यादा लोगों के लिए उपलब्ध कराने के क्रम के बारे में ज़्यादा जानकारी पब्लिश करेगा. प्रतिबद्धताओं के तहत, सीएमए की प्रतिस्पर्धा से जुड़ी समस्याओं को हल करने के लिए, 3PCD को ज़रूरी शर्तें पूरी करनी होंगी. |
| Google Ad Manager | Google Ad Manager, API प्लैटफ़ॉर्म को एक्सपोज़ करने से मना करता है, जिससे टेस्टिंग करना मुश्किल हो जाता है. | Google Ad Manager का जवाब: Google Ad Manager के इस जवाब में बताई गई वजहों से, Google Ad Manager के Protected Audience API इंटिग्रेशन के प्लान में, टॉप-लेवल नीलामी के कंट्रोल के बिना, Google के पब्लिशर विज्ञापन सर्वर को शामिल नहीं किया गया है. |
| Google Ad Manager | Google Ad Manager में एक गुप्त फ़्लोर प्राइस होती है, जो सिर्फ़ AdX या ओपन बिडिंग एसएसपी को दिखती है. | Google Ad Manager के सार्वजनिक दस्तावेज़ के मुताबिक, कॉन्टेक्स्ट के हिसाब से होने वाली नीलामी में विजेता को टॉप-लेवल स्कोरिंग लॉजिक में भेजा जाता है, न कि AdX या ओपन बिडिंग जैसी किसी भी कॉम्पोनेंट नीलामी में. इसके अलावा, उस दस्तावेज़ में स्कोरिंग के टॉप-लेवल लॉजिक के बारे में बताया गया है: "Ad Manager, हर कॉम्पोनेंट नीलामी की विजेता बिड की तुलना करेगा. इसमें, खरीदारों के इंटरेस्ट ग्रुप बिड के लिए Ad Manager की अपनी कॉम्पोनेंट नीलामी के साथ-साथ, सबसे अच्छा कॉन्टेक्स्ट विज्ञापन (जिसे डाइनैमिक ऐलोकेशन की मदद से चुना जाता है) भी शामिल है. साथ ही, Ad Manager सबसे ज़्यादा बिड वाले विज्ञापन को दिखाएगा." |
| Google Ad Manager | Google Ads के प्रॉडक्ट पर वही नियम लागू होने चाहिए जो तीसरे पक्ष के विज्ञापन प्रॉडक्ट पर लागू होते हैं. | Google Ads के प्रॉडक्ट पर पहले से ही वही नियम लागू होते हैं जो तीसरे पक्ष के प्रॉडक्ट पर लागू होते हैं. |
| Chrome की मदद से टेस्टिंग | A या B में शामिल नहीं किए गए ब्राउज़र के लिए लेबल जोड़ें. | फ़िलहाल, हम ऐसा नहीं कर रहे हैं. ऐसा इसलिए, क्योंकि हमारी जांच में पता चला है कि एक्सपेरिमेंट के अलावा अन्य लेबल जोड़ने से, गुप्त मोड में ट्रैफ़िक से जुड़ी निजता से जुड़ी समस्याएं बढ़ सकती हैं. |
| विज्ञापन एजेंसी | क्या वेबसाइटों पर JavaScript का इस्तेमाल न करने वाली एजेंसियां या कंपनियां, Privacy Sandbox API का इस्तेमाल कर सकती हैं? | Privacy Sandbox API को कोई भी कॉल कर सकता है. अगर कोई एजेंसी या कोई और व्यक्ति, सीधे एपीआई पर टेक्नोलॉजी बनाना चाहता है, तो वह ऐसा कर सकता है. क्लाइंट-साइड एपीआई को क्लाइंट के साथ इंटिग्रेट करना ज़रूरी है, ठीक वैसे ही जैसे कुकी को करना होता है. कुकी की तरह ही, कई एपीआई में एचटीटीपी हेडर इंटरफ़ेस भी होता है. हमने पहले ही विज्ञापन इंडस्ट्री के एक फ़्रेमवर्क, Prebid को एपीआई के साथ क्लाइंट-साइड इंटिग्रेशन बनाते हुए देखा है. अन्य संगठन भी ऐसा कर सकते हैं. |
| क्लाइंट-साइड समाधान | Google, Privacy Sandbox के लिए क्लाइंट-साइड समाधान क्यों अपना रहा है, जबकि एक इंजीनियर ने साल 2012 में ऐसे समाधानों के स्केलेबल होने पर चिंता जताई थी? | निजता को बेहतर बनाने से जुड़ी टेक्नोलॉजी (पीईटी) के तौर पर, अध्ययन के क्षेत्र में साल 2012 से काफ़ी बदलाव हुआ है. साथ ही, इससे व्यावसायिक तौर पर काम करने वाले ऐप्लिकेशन भी तैयार हुए हैं. Privacy Sandbox के मुख्य हिस्से में, पीईटी के ऐसे कॉम्बिनेशन हैं जो 10 साल पहले काम नहीं करते थे. इसके अलावा, व्यक्तिगत कंप्यूटिंग की क्षमता बढ़ी है. साथ ही, उपभोक्ताओं की ब्राउज़र से जुड़ी उम्मीदें और निजता से जुड़ी नियामक उम्मीदें भी बढ़ी हैं. |
| मशीन लर्निंग | Google, मशीन लर्निंग के लिए प्राइवसी सैंडबॉक्स का इस्तेमाल कैसे करेगा? | फ़िलहाल, विज्ञापन टेक्नोलॉजी का ज़्यादातर इकोसिस्टम, मशीन लर्निंग का इस्तेमाल करता है. हमें उम्मीद नहीं है कि इसमें कोई बदलाव होगा. प्राइवसी सैंडबॉक्स, विज्ञापन टेक्नोलॉजी कंपनियों या किसी और को मशीन लर्निंग का इस्तेमाल जारी रखने से नहीं रोकता. साथ ही, Privacy Sandbox के लिए यह ज़रूरी नहीं है कि एपीआई के साथ इंटिग्रेट करने वाली कंपनियां, मशीन लर्निंग का इस्तेमाल करें. यह उम्मीद की जा सकती है कि कंपनियां अपने ग्राहकों की ज़रूरतों को पूरा करने के लिए, प्रॉडक्ट और सेवाएं बनाती रहेंगी. भले ही, इसमें मशीन लर्निंग का इस्तेमाल किया जाए या नहीं. Privacy Sandbox इंटिग्रेटर जो भी मशीन लर्निंग बनाते हैं, वह उनके लिए ज़ाहिर तौर पर उपलब्ध होगी. इसलिए, उन्हें इसकी जानकारी होगी. |
| डेटा की पुष्टि | कंपनियां इस बात की पुष्टि कैसे कर सकती हैं कि प्राइवसी सैंडबॉक्स का इस्तेमाल करके उन्हें जो डेटा मिलता है वह सटीक है. साथ ही, क्या Google, मीडिया रेटिंग काउंसिल (एमआरसी) जैसी किसी इकाई के ज़रिए अपनी समीक्षा कराने को तैयार है? | Privacy Sandbox API, उस ओपन-सोर्स प्लैटफ़ॉर्म पर बनाए गए हैं जिस पर Chrome काम करता है. भरोसेमंद प्रोसेसिंग एनवायरमेंट में चलने वाले एपीआई के हिस्से भी ओपन सोर्स हैं और इनकी ऑडिट की जा सकती है. कोड की जांच करने के लिए, एमआरसी के साथ-साथ कोई भी व्यक्ति अनुरोध कर सकता है. |
| (पिछली तिमाहियों में भी रिपोर्ट की गई) प्रोडक्शन सपोर्ट | Chrome में Privacy Sandbox की तकनीकी समस्याओं और इकोसिस्टम पर असर डालने वाली समस्याओं को हल करने के लिए क्या प्रोसेस अपनाई जाती है? | Google, विज्ञापन टेक्नोलॉजी विशेषज्ञों को तकनीकी समस्याओं की शिकायत करने और उन्हें हल करने के लिए, कई चैनल उपलब्ध कराता है. इसके अलावा, Chrome को उम्मीद है कि वह तकनीकी समस्याओं और ऐसे मामलों को हल करने के लिए, एक प्रोसेस को और बेहतर बनाएगा और उसे बड़े पैमाने पर लागू करेगा जिनसे नेटवर्क पर असर पड़ता है. Chrome इस प्रोजेक्ट के लिए ज़रूरी संसाधन उपलब्ध कराने के लिए प्रतिबद्ध है. अपनी शिकायत दर्ज करने और सुझाव/राय देने के लिए, कृपया हमारे सार्वजनिक और निजी फ़ोरम देखें. |
| Chrome की मदद से होने वाली टेस्टिंग के मोड | Chrome की मदद से टेस्टिंग करने के मोड के लिए, समयसीमा और सही तरीके से लागू करने के बारे में ज़्यादा जानकारी. | हमने टेस्टिंग मोड के बारे में एक ब्लॉग पोस्ट शेयर की है. हम जल्द ही ज़्यादा जानकारी शेयर करेंगे. हम टेस्टिंग मोड लेबल के साइज़ के लिए सुझावों का स्वागत करते हैं. |
| इंडस्ट्री के अन्य स्टैंडर्ड के साथ इंटिग्रेशन | क्या Privacy Sandbox API, टीसीएफ़ v2.* और सहमति मोड, दोनों में से किसी एक या दोनों से कनेक्ट होंगे? | हम Privacy Sandbox APIs को सीधे तौर पर, टीसीएफ़ वर्शन 2 या सहमति मोड के साथ इंटिग्रेट करने की योजना नहीं बना रहे हैं. हालांकि, कंपनियां और इंडस्ट्री के ट्रेड ग्रुप, अपने प्रॉडक्ट और फ़्रेमवर्क को Privacy Sandbox API के साथ काम करने के लिए बदल सकते हैं. उदाहरण के लिए, टीसीएफ़ जैसे फ़्रेमवर्क के साथ, हर पार्टनर को टीसीएफ़ सिग्नल और उससे जुड़ी टीसीएफ़ नीतियों के आधार पर, नीति का पालन करने का अपना तरीका तय करना होगा. हमें उम्मीद है कि कंपनियां यह तय करेंगी कि Privacy Sandbox के बिल्डिंग ब्लॉक की अलग-अलग सुविधाओं का इस्तेमाल कब और कैसे किया जाए. |
रजिस्टर करना और पुष्टि करना
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| प्रतिबंध | रजिस्टर करने की प्रोसेस का मतलब है कि Google यह तय कर सकता है कि नेटवर्क में कौनसी कंपनी, Privacy Sandbox API का इस्तेमाल कर सकती है. | रजिस्टर करने और पुष्टि करने की प्रोसेस में, इकाई की पुष्टि करना ज़रूरी है. उदाहरण के लिए, इकाई के पास डीयूएनएस नंबर होना चाहिए, वह निजता नीति का लिंक दे सकती है वगैरह. साथ ही, एपीआई को कॉल करने के लिए, सार्वजनिक पुष्टि करना ज़रूरी है. रजिस्टर करने की ज़रूरी शर्तें पूरी करने वाली इकाइयों की पुष्टि की जाएगी. जिन कंपनियों के पास डीयूएनएस नंबर नहीं है उनके लिए, हम Dun & Bradstreet की मदद से डीयूएनएस नंबर पाने की प्रोसेस को तेज़ कर रहे हैं. साथ ही, इसके लिए कोई शुल्क नहीं लिया जा रहा है. इसका मकसद, एपीआई की निजता को बेहतर तरीके से सुरक्षित करना है. इसके लिए, ऊपर बताए गए तरीकों का इस्तेमाल किया जाएगा. साथ ही, Privacy Sandbox API में पारदर्शिता को बढ़ाया जाएगा, ताकि दिलचस्पी रखने वाले पक्ष यह बेहतर तरीके से समझ सकें कि कौनसे एपीआई का इस्तेमाल किया जा रहा है और कौनसे एट्रिब्यूशन दिए जा रहे हैं. हम इस समस्या पर इंडस्ट्री से मिले सुझावों या राय को स्वीकार करने के लिए तैयार हैं. इनका इस्तेमाल, इस प्रोसेस को बेहतर बनाने के लिए पहले ही किया जा चुका है. |
| फिर से रजिस्टर करने में लगने वाला समय | पुष्टि करने वाली फ़ाइल की समयसीमा हर 12 महीने में खत्म हो जाती है. इसके बाद, वेबसाइटों को फिर से रजिस्टर करना पड़ता है. | हमने नेटवर्क से सुझाव/राय/शिकायतें सुनी हैं और उसी हिसाब से अपने तरीके में बदलाव किया है. इसका मतलब है कि फ़ाइलों की समयसीमा अब 12 महीने या किसी तय समय के बाद खत्म नहीं होगी. हम रजिस्टर करने के लिए डेवलपर गाइड को अपडेट कर रहे हैं. इसमें ज़्यादा जानकारी शामिल की जाएगी. |
| अटेस्टेशन फ़ाइल | पुष्टि करने वाली फ़ाइल का इस्तेमाल कैसे किया जाता है? | Relevance और मेज़रमेंट एपीआई का इस्तेमाल करने वाली सभी कंपनियों को, नीतियों के उल्लंघन ठीक करने की समयसीमा खत्म होने से पहले, अपनी साइट पर अटेस्टेशन फ़ाइल अपलोड करनी होगी. साथ ही, इसे सार्वजनिक तौर पर तब तक दिखाना होगा, जब तक एपीआई का इस्तेमाल जारी रहेगा. Privacy Sandbox से वेबसाइटों को हर घंटे एक अनुरोध मिल सकता है. साथ ही, अन्य संभावित इकाइयां भी क्वेरी कर सकती हैं. यह प्रोसेस, रजिस्टर करने की सुविधा देने वाले सिस्टम के अपने तरीके से की जाएगी. इससे, रजिस्टर की गई इकाइयों के सर्वर से क्वेरी की जा सकेगी और यह पक्का किया जा सकेगा कि पुष्टि करने वाली फ़ाइल मान्य है. पुष्टि करने वाले दस्तावेज़, पारदर्शिता रिपोर्ट में शामिल किए जाएंगे. साथ ही, ये आम लोगों को दिखेंगे. हम उम्मीद करते हैं कि कंपनियां, अपने एटेस्टेशन के मुताबिक काम करेंगी. साथ ही, बाकी के नेटवर्क और संबंधित नियम-कानून बनाने वाली संस्थाएं भी ऐसा ही करेंगी. |
| रजिस्ट्रेशन | क्या हर साइट या हर ऑरिजिन के लिए रजिस्ट्रेशन किया जाता है? | रजिस्ट्रेशन, साइट के लेवल पर होता है. |
काम का कॉन्टेंट और विज्ञापन दिखाना
विषय
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| परफ़ॉर्मेंस | यूरोपियन इकनॉमिक एरिया में, Topics के लिए ऑप्ट-इन रेट के असर से जुड़ी परफ़ॉर्मेंस से जुड़ी समस्याएं. | हमारा सुझाव है कि इस समस्या के बारे में, संबंधित हिस्सेदार अपनी डेटा प्रोटेक्शन अथॉरिटी से संपर्क करें. ये ऐसी समस्याओं को हल करने के लिए सबसे सही हैं. साथ ही, इनसे यह तय करने में भी मदद मिलती है कि निजता को बेहतर बनाने वाली टेक्नोलॉजी के ऐप्लिकेशन को कानूनों के तहत बढ़ावा दिया जाए या उन्हें ट्रैकिंग की तरह माना जाए. इसके लिए, सहमति लेने के लिए एक जैसे तरीके अपनाने होंगे. |
| रजिस्ट्रेशन | क्या अपस्ट्रीम एसएसपी से Topics सिग्नल का इस्तेमाल करने के लिए, डाउनस्ट्रीम बिडर को Topics API में रजिस्टर करना होगा? | Topics API के शुरुआती कॉलर के अलावा, Topics के डाउनस्ट्रीम रिसीवर को रजिस्टर करने की ज़रूरत नहीं है. हालांकि, कई रिसीवर को एपीआई के दूसरे इस्तेमाल के लिए रजिस्टर किया जा सकता है. Privacy Sandbox में रजिस्टर करने वाले लोगों की सूची, प्रोग्राम के पारदर्शिता के प्रयासों के तहत प्रोग्राममैटिक तरीके से उपलब्ध कराई जाएगी. इससे Topics API का इस्तेमाल करने वाले किसी व्यक्ति को यह पता चल पाएगा कि वह जिस व्यक्ति को विषय भेज रहा है वह रजिस्टर है या नहीं. |
| विषयों को फ़िल्टर करना | किसी दूसरे कॉलर के उन विषयों पर फ़िल्टर लागू करने का अनुरोध करें जिन्हें वे पेज पर ढूंढते हैं. ऐसा इसलिए किया जाता है, ताकि सिर्फ़ वही जानकारी शेयर की जा सके जिसे खरीदार ढूंढ सकते हैं. | हम इस अनुरोध पर विचार कर रहे हैं. साथ ही, हम इकोसिस्टम से ज़्यादा सुझाव, राय या शिकायत का स्वागत करते हैं. |
| साइट एक्सक्लूज़न | उपयोगकर्ता के विषयों में योगदान देने से वेबसाइटों को बाहर रखना. | विषयों को डिफ़ॉल्ट रूप से नहीं बुलाया जाता. यह ध्यान रखना ज़रूरी है कि विषयों को चुनते समय, किसी भी पेज के कॉन्टेंट को ध्यान में नहीं रखा जाता. साथ ही, सभी विषयों को इस तरह से चुना जाता है कि वे संवेदनशील न हों. कोई वेबसाइट, अपनी साइट को विषय के हिसाब से ट्रैफ़िक के हिसाब लगाने की सुविधा में शामिल होने से रोक सकती है. इसके लिए, उसे अनुमति से जुड़ी नीति के इस हेडर का इस्तेमाल करना होगा: Permissions-Policy:
browsing-topics=() |
| विषयों के बारे में जानकारी | पब्लिशर को Chrome को अनुमतियां देने की सुविधा दें, ताकि वह पेज के कॉन्टेंट (जैसे, हेड या मुख्य हिस्सा) के आधार पर विषयों को अलग-अलग कैटगरी में बांट सके. | हमने पहले, पेज के कॉन्टेंट के आधार पर साइटों को विषयों में बांटने की सुविधा देने पर विचार किया था. हालांकि, निजता और सुरक्षा से जुड़ी चिंताओं की वजह से, हमने इस सुविधा को लॉन्च नहीं किया. इस प्रस्ताव से, उनमें से कुछ समस्याओं को कम किया जा सकता है. हालांकि, यह साफ़ तौर पर नहीं बताया जा सकता कि यह समस्या कितनी हद तक कम होगी. सीएमए के प्रयोग की आने वाली अवधि की वजह से, हमें उम्मीद नहीं है कि यह बदलाव 3PCD से पहले होगा. अगर आपके पास कोई और सुझाव है, तो यहां बताएं. |
| विषयों के बारे में जानकारी | पब्लिशर के लिए, अनुमति से जुड़ी ज़्यादा बेहतर नीतियां उपलब्ध कराएं. | पब्लिशर के लिए, अनुमति से जुड़ी ज़्यादा बेहतर नीतियां उपलब्ध कराने से, पब्लिशर की साइटों को पूरे पारिस्थितिक तंत्र के लिए Topics API की उपयोगिता पर बुरा असर डालने में मदद मिलेगी. हालांकि, इससे साइट के लिए Topics API की उपयोगिता पर कोई असर नहीं पड़ेगा. इस विषय के बारे में ज़्यादा जानकारी के लिए, GitHub पर 'डेटा वापस पाना' और 'डेटा को मॉनिटर करना' के लिए अलग-अलग अनुमतियों का इस्तेमाल करने की सुविधा देने के लिए, अनुमतियों की नीति अपडेट करें समस्या देखें. |
| मेडिकल और हेल्थ से जुड़े विषय | टॉपिक टैक्सोनॉमी में, मेडिकल या स्वास्थ्य से जुड़ी कैटगरी के विषय शामिल क्यों नहीं हैं? | चिकित्सा और स्वास्थ्य से जुड़ी कैटगरी को संवेदनशील विषय माना जाता है. इसलिए, इन्हें विषयों की टैक्सोनॉमी से बाहर रखा गया है. |
| विषयों को वापस लाना | हेडर का इस्तेमाल किए बिना, Topics पाने का तेज़ तरीका, जो डीएसपी के लिए उपलब्ध है. | हेडर के तरीके, क्रॉस-ऑरिजिन iframe बनाने और उससे document.browsingTopics() कॉल करने की तुलना में बेहतर परफ़ॉर्म करते हैं और कम खर्चीले होते हैं. (कॉल के लिए, क्रॉस-ऑरिजिन iframe का इस्तेमाल करना ज़रूरी है, क्योंकि किसी विषय को देखने के लिए, टॉप-लेवल का संदर्भ उस संदर्भ से मेल खाना चाहिए जिससे विषयों को ऐक्सेस किया जाता है.) इस बारे में यहां ज़्यादा जानकारी दी गई है. |
| विषयों को वापस लाना | अलग-अलग डोमेन के स्क्रिप्ट टैग के अनुरोधों पर, हेडर के ज़रिए Topics को पास करने के लिए अनुरोध. | सुरक्षा के लिहाज़ से, ऐसा नहीं किया जा सकता. हर दस्तावेज़ और उसका लागू करने का माहौल, दस्तावेज़ के ऑरिजिन से जुड़ा होता है. उसी एनवायरमेंट में लोड और चलाए गए तीसरे पक्ष के सब-रिसॉर्स का मालिकाना हक, दस्तावेज़ के ऑरिजिन के पास माना जाता है. ऐसा इसलिए किया जाता है, ताकि बिना सहमति के डेटा को एक सोर्स से दूसरे सोर्स में भेजने से रोका जा सके. इसके अलावा, <script> टैग पर browsingTopics एट्रिब्यूट का इस्तेमाल भी किया जा सकता है. यह सुरक्षा के लिहाज़ से साफ़ होना चाहिए और इसमें अतिरिक्त इंतज़ार का समय नहीं होना चाहिए. हम दिलचस्पी रखने वाले लोगों या कंपनियों से
राय, सुझाव या शिकायत लेते हैं. |
| जागरूकता | Topics API और एपीआई के इस्तेमाल के बारे में लोगों की जागरूकता बढ़ाएं. | हमने इस सुझाव/राय/शिकायत देने वाले हिस्सेदार से संपर्क किया है. साथ ही, इस समस्या को GitHub पर ठीक कर दिया गया है.
आने वाले समय में, हम एपीआई के बारे में नेटवर्क को बेहतर तरीके से समझने में मदद करते रहेंगे. साथ ही, हमें हिस्सेदारों के सुझावों और राय का इंतज़ार रहेगा. इस बीच, हमारा सुझाव है कि Topics API के बारे में ज़्यादा जानने के लिए, Chrome डेवलपर गाइड में दिए गए दस्तावेज़ पढ़ें. |
| सूचना | जब किसी वेबसाइट पर उपयोगकर्ता के विषयों को देखा जा रहा हो, तब उसे चेतावनी देने के लिए सूचना. | हमने GitHub पर इस सुझाव/राय/शिकायत का जवाब दिया है. उपयोगकर्ता, Chrome सहायता केंद्र में जाकर, Topics के कंट्रोल के बारे में ज़्यादा जान सकते हैं. |
| मशीन लर्निंग | उपयोगकर्ता के विषयों का अनुमान लगाने के लिए, एमएल का इस्तेमाल कैसे किया जा सकता है? | हम इस समस्या पर चर्चा कर रहे हैं. साथ ही, अन्य सुझाव, राय या शिकायतें पाने के लिए हमेशा तैयार हैं. |
| अलग-अलग तरह के हिस्सेदारों के लिए फ़ायदेमंद होना | हो सकता है कि विज्ञापन टेक्नोलॉजी से जुड़ी छोटी कंपनियां, ब्राउज़र के हिसाब लगाने के तरीके की वजह से विषयों को न देख पाएं. | सिर्फ़ उन विज्ञापन टेक्नोलॉजी को विषय मिलेगा जिन्होंने उपयोगकर्ता को पिछले तीन हफ़्तों में, उस विषय से जुड़े पेज पर जाते हुए देखा है. अगर विज्ञापन टेक्नोलॉजी ने उस उपयोगकर्ता के लिए, उस विषय से जुड़ी साइट पर पिछले तीन हफ़्तों में एपीआई को कॉल नहीं किया है, तो रिटर्न की गई वैल्यू खाली होगी. इस सुविधा का मतलब है कि जिन विज्ञापन टेक्नोलॉजी की सेवाओं का इस्तेमाल, ज़्यादा संख्या में साइट के मालिक करते हैं उन्हें अन्य विज्ञापन टेक्नोलॉजी की तुलना में ज़्यादा विषय मिल सकते हैं. इसकी वजह यह है कि किसी उपयोगकर्ता की साइट विज़िट को मॉनिटर करने के लिए, उनके पास ज़्यादा अवसर होते हैं. यह सुविधा, एपीआई की निजता की सुरक्षा के लिए ज़रूरी है. इसकी मदद से, किसी उपयोगकर्ता की जानकारी सिर्फ़ उन पक्षों के लिए उपलब्ध होती है जो पहले से ही उस जानकारी को देख सकते हैं. फ़िलहाल, यह जानकारी तीसरे पक्ष की कुकी के ज़रिए देखी जाती है. |
| एक्सएचआर अनुरोध | XMLHttpRequest (XHR) अनुरोधों में Topics को शामिल करने की सुविधा कब बंद की जाएगी? |
Chrome ने अगस्त 2023 में एलान किया था कि Origin Trial से सामान्य उपलब्धता पर स्विच करते समय, XHR के लिए सहायता बंद कर दी जाएगी. Topics के ज़्यादा से ज़्यादा लोगों तक पहुंचने के साथ-साथ, XHR के इस्तेमाल की सुविधा सिर्फ़ उन उपयोगकर्ताओं के लिए उपलब्ध कराई गई थी जिनके लिए OT की सुविधाएं चालू थीं. साथ ही, OT के अलग-अलग एक्सपेरिमेंट ग्रुप को मर्ज करने के बाद, इस सुविधा को पूरी तरह बंद कर दिया गया था. अगर XHR के साथ Topics का इस्तेमाल किया जा रहा था, तो आपकी साइटें काम करती रहेंगी. टॉपिक, आपके XHR अनुरोध हेडर में नहीं जोड़े जाएंगे. हमारा सुझाव है कि आप अपने अनुरोध के लिए fetch पर ट्रांज़िशन करें, iframe एट्रिब्यूट का इस्तेमाल करें या विषयों को वापस पाने के लिए JavaScript API का इस्तेमाल करें. फ़ेच की सुविधा सभी मॉडर्न ब्राउज़र पर काम करती है. हालांकि, यह सुविधा Internet Explorer या Opera Mini पर काम नहीं करती. |
| टैक्सोनॉमी और क्लासिफ़ायर को अपडेट करने की प्रोसेस | Topics टैक्सोनॉमी और क्लासिफ़ायर रिलीज़ के क्रम के बारे में ज़्यादा जानकारी. साथ ही, इस बारे में भी जानकारी दी गई है कि कंपनियां ऐसे अपडेट के लिए कैसे तैयारी कर सकती हैं. | हमारा जवाब, दूसरी तिमाही में दिए गए जवाब से अब भी वही है: हाल ही की ब्लॉग पोस्ट में बताया गया है कि हम उम्मीद करते हैं कि टैक्सोनॉमी समय के साथ बेहतर होती रहेगी. साथ ही, टैक्सोनॉमी को मैनेज करने की ज़िम्मेदारी, आखिर में इंडस्ट्री के सभी हिस्सेदारों का प्रतिनिधित्व करने वाली किसी बाहरी पार्टी को दे दी जाएगी. हमने topics-announce group में, रैंप-अप प्लान भी शेयर किया है. |
| गलत इस्तेमाल | रीडायरेक्ट चेन की मदद से संभावित हमला. | हम इस समस्या पर विचार कर रहे हैं और हमें इस बारे में और सुझाव, राय या शिकायत मिल सकती है. |
| पब्लिशर इन्वेंट्री के टाइप | Protected Audience और Topics की जांच करने की सुविधा, पब्लिशर की किस तरह की इन्वेंट्री के साथ काम करेगी? | Protected Audience और विषयों को, किसी भी तरह की इन्वेंट्री के लिए इस्तेमाल किया जा सकता है. |
| रैंप-अप का समय | हमारा सुझाव है कि नई टैक्सोनॉमी को 100% तक पहुंचने के लिए, रैंप-अप समय न दें. | नेटवर्क से मिले सुझाव/राय/शिकायत और PATCG की मीटिंग के दौरान हुई चर्चा के बाद, हमने नई टैक्सोनॉमी को रोल आउट करने के अपने प्लान का एलान किया है. |
Protected Audience API (पहले इसे FLEDGE के नाम से जाना जाता था)
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| टॉप-लेवल ऑक्शन | Google के पब्लिशर विज्ञापन सर्वर का इस्तेमाल करने की सुविधा, साथ ही Google Ad Manager को टॉप-लेवल Protected Audience API नीलामी का कंट्रोल न देना. | Google Ad Manager का जवाब: Protected Audience API के लिए, Google Ad Manager के प्लान में, टॉप-लेवल की Protected Audience नीलामी के कंट्रोल के बिना, Google के पब्लिशर विज्ञापन सर्वर को इस्तेमाल करने की सुविधा शामिल नहीं है. ऐसा इन वजहों से किया गया है. पब्लिशर विज्ञापन दिखाने वाले मार्केट में अपने ग्राहकों को सही तरीके से सेवा देने के लिए, Google के पब्लिशर विज्ञापन सर्वर को टॉप-लेवल की सुरक्षित ऑडियंस की नीलामी का कंट्रोल बनाए रखना होगा. पब्लिशर विज्ञापन सर्वर के तौर पर, हमारी भूमिका यह है कि हम पब्लिशर को अनुमानित जानकारी दें, ताकि वे ओवरबुकिंग किए बिना, डायरेक्ट तौर पर बेचे जाने वाले कैंपेन के लिए बातचीत कर सकें. साथ ही, वे अपने डायरेक्ट रिज़र्वेशन को बेहतर तरीके से डिलीवर और मैनेज कर सकें. ऐसा करने के लिए, ज़रूरी शर्तें पूरी करने वाली सभी डायरेक्ट और इनडायरेक्ट मांग की तुलना करने के लिए, फ़ाइनल नीलामी चलानी होगी. पेड विज्ञापन दिखाने वाले पब्लिशर, विज्ञापन सर्वर से अनुमान लगाने और पेसिंग की मुख्य सुविधाओं की उम्मीद करते हैं. सटीक अनुमान के बिना, पब्लिशर अपनी इन्वेंट्री को ज़्यादा बिक्री के लिए उपलब्ध करा सकते हैं. इससे उनके कारोबार की साख को खतरा हो सकता है. विज्ञापन देने वालों के साथ किए गए रिज़र्वेशन कॉन्ट्रैक्ट को पूरा न कर पाने से, पब्लिशर और विज्ञापन देने वाले के बीच के सीधे संबंध पर भी असर पड़ सकता है. इससे पब्लिशर के कारोबार पर भी काफ़ी असर पड़ सकता है. इसलिए, हम पब्लिशर के विज्ञापन सर्वर की गतिविधि को, टॉप-लेवल की Protected Audience नीलामी को चलाने के तौर पर नहीं देखते. यह गतिविधि, पब्लिशर के विज्ञापन सर्वर की अन्य गतिविधियों से अलग होती है. |
directFrom |
directFromकी मदद से, Google Ad Manager पब्लिशर को कॉन्टेक्स्टुअल नीलामी की कीमत देखने से रोक सकता है. |
Chrome का जवाब:runAdAuction() में भेजी गई जानकारी, सेलर से तब तक नहीं आती, जब तक सेलर अपने iframe से runAdAuction() को कॉल नहीं करता. कई सेलर वाली नीलामी में, सभी सेलर के लिए runAdAuction() को कॉल करने वाला फ़्रेम बनाना असंभव हो जाता है. directFromSellerSignals ने इस समस्या को हल करने के लिए, सेलर के ऑरिजिन से लोड किए गए सब-रिसॉर्स बंडल से कॉन्टेंट लोड किया. इससे यह पक्का होता है कि सेलर-नीलामियों के कॉन्फ़िगरेशन से नीलामी में भेजी गई जानकारी की प्रामाणिकता और पूरी सुरक्षा को बदला नहीं जा सकता. अगर पब्लिशर, Protected Audience API का इस्तेमाल करके यह समझना चाहते हैं कि टेक्नोलॉजी से जुड़ी सेवा देने वाली कंपनियां, Protected Audience नीलामियों में कौनसी जानकारी दे रही हैं, तो वे उन कंपनियों से इस सुविधा के लिए अनुरोध कर सकते हैं.Google Ad Manager का जवाब: हमने नीलामी में सभी के लिए समानता बनाए रखने पर कई सालों से ध्यान दिया है. इसमें यह वादा भी शामिल है कि नीलामी में बिड करने से पहले, किसी भी पब्लिशर के ऐसे विज्ञापन स्रोतों की कीमत किसी दूसरे खरीदार के साथ शेयर नहीं की जाएगी जिनके लिए कोई गारंटी नहीं दी जाती. इनमें, गारंटी नहीं वाली लाइन आइटम की कीमतें भी शामिल हैं. हमने बाद में, फ़्रेंच कॉम्पिटीशन अथॉरिटी के साथ किए गए अपने वादों में भी इस बात की पुष्टि की है. सुरक्षित ऑडियंस नीलामियों के लिए, हम directFromSellerSignals का इस्तेमाल करके अपने वादे को पूरा करना चाहते हैं. साथ ही, हम एक से ज़्यादा सेलर वाली नीलामियों के पूरा होने से पहले, नीलामी में हिस्सा लेने वाले किसी भी व्यक्ति की बिड को किसी दूसरे व्यक्ति के साथ शेयर नहीं करेंगे. साफ़ तौर पर बता दें कि हम कॉन्टेक्स्टुअल नीलामी की कीमत, अपनी कॉम्पोनेंट नीलामी के साथ भी शेयर नहीं करेंगे. इस बारे में टॉप-लेवल नीलामी की डाइनैमिक के बारे में ज़्यादा जानकारी अपडेट में बताया गया है. |
| जानकारी का एक्सपोज़र | ब्राउज़र, कारोबार के संवेदनशील लॉजिक और कानूनी समझौते की जानकारी को ज़ाहिर कर सकता है. | वेब ब्राउज़र का इस्तेमाल करने वाला व्यक्ति, ब्राउज़र में होने वाली हर गतिविधि देख सकता है. जब ब्राउज़र में विज्ञापन नीलामी होती है, तो यह सच है कि जिस व्यक्ति का ब्राउज़र है वह नीलामी को देख सकता है. साथ ही, यह भी देख सकता है कि अलग-अलग पक्षों ने कितनी बिडिंग की है. ब्राउज़र, उपयोगकर्ता का एजेंट होता है. इसलिए, हमें नहीं लगता कि इसे बदला जा सकता है या ऐसा करना सही है. हालांकि, ब्राउज़र का इस्तेमाल करने वाले व्यक्ति को ही इन कार्रवाइयों की जानकारी दिखती है. Protected Audience API का इस्तेमाल करके, डिवाइस पर होने वाली नीलामी को Google के साथ-साथ किसी भी सर्वर से नहीं देखा जा सकता. |
PerBuyerExperiment |
PerBuyerExperimentकी मौजूदा वैल्यू रेंज की मदद से, खरीदार, संदर्भ के हिसाब से डेटा को भरोसेमंद सर्वर के अनुरोध से जोड़ सकते हैं. |
Protected Audience API का इस तरह इस्तेमाल करना, Privacy Sandbox के ज़रूरी एटेस्टेशन के मुताबिक नहीं है. एपीआई के उपयोगकर्ता, Privacy Sandbox की सुरक्षा को बायपास करने की कोशिश नहीं करेंगे. आने वाले समय में, यह ज़रूरी होगा कि की-वैल्यू सर्वर, ट्रस्टेड एक्सीक्यूशन एनवायरमेंट (टीईई) में चलें. इससे इस तरह के हमले से तकनीकी सुरक्षा मिलेगी. |
| सेम-ऑरिजिन नीति | सबडोमेन को अनुमति देने के लिए, एक ही ऑरिजिन से जुड़ी नीति में ढील दें. | हम इस अनुरोध पर विचार कर रहे हैं. साथ ही, हम इकोसिस्टम से अतिरिक्त सुझाव, राय या शिकायत का स्वागत करते हैं. |
| एपीआई वर्शन | Protected Audience API में किए गए बदलावों के लिए, वर्शन और रिलीज़ नोट का अनुरोध करना. | हम इस अनुरोध पर विचार कर रहे हैं. साथ ही, हम इकोसिस्टम से अतिरिक्त सुझाव, राय या शिकायत का स्वागत करते हैं. |
| मल्टी-एसएसपी नीलामियां | टॉप लेवल के ऑक्शन सिग्नल को, कॉम्पोनेंट सिग्नल auctionSignals के साथ JSON मर्ज करने की अनुमति दें. |
हम इस अनुरोध पर विचार कर रहे हैं. साथ ही, हम इकोसिस्टम से अतिरिक्त सुझाव, राय या शिकायत का स्वागत करते हैं. |
| बोली सीमा | बिड में शामिल होने वाले विज्ञापन कॉम्पोनेंट की संख्या की सीमा को 20 से बढ़ाकर 40 करें. | हम इस अनुरोध पर विचार कर रहे हैं. साथ ही, हम नेटवर्क से जुड़े लोगों से ज़्यादा सुझाव चाहते हैं कि यह सुविधा क्यों काम की होगी. |
| (पिछली तिमाहियों में भी रिपोर्ट की गई थी) Protected Audience API से जुड़ी नीलामियों की परफ़ॉर्मेंस |
टेस्टर की रिपोर्ट से पता चलता है कि Protected Audience API से जुड़ी नीलामियों में रिस्पॉन्स मिलने में ज़्यादा समय लगता है. | इंतज़ार के समय से जुड़े सवालों के लिए, Protected Audience API ने आम तौर पर, कंट्रोल बनाने के मौजूदा स्टैंडर्ड पैराडाइम का पालन किया है. इससे सेलर यह तय कर सकते हैं कि बिड लगाने वाले लोग कितना समय और संसाधन खर्च कर सकते हैं. साथ ही, खरीदार यह तय कर सकते हैं कि उनके पास उपलब्ध संसाधनों का सबसे सही तरीके से इस्तेमाल कैसे किया जाए. ये कंट्रोल और टूल आम तौर पर आज भी उपलब्ध हैं. हालांकि, इनका पूरा फ़ायदा तब ही मिलेगा, जब खरीदार और सेलर इन्हें अपनाएंगे. इसके अलावा, Chrome नीलामी की स्पीड को बेहतर बनाने के लिए, इन्फ़्रास्ट्रक्चर में कई तरह के सुधार कर रहा है (crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev.com/1197323). हम इंतज़ार के समय को कम करने के लिए किए जा रहे इन दोनों कामों के बारे में सुझाव, राय या शिकायत देने के लिए आप सभी का स्वागत करते हैं: खरीदारों और सेलर के लिए काम के नए टूल और उन समस्याओं की रिपोर्ट जिनकी Chrome के इंजीनियरों को जांच करनी चाहिए. |
| बाय-साइड फ़िल्टरिंग | दिलचस्पी के ग्रुप के आधार पर, बाय-साइड फ़िल्टर करने की सुविधा जोड़ी गई है. | हमने एसएसपी और डीएसपी को कई तरीके सुझाए हैं, जिनसे वे इस समस्या को हल करने के लिए अपने डिज़ाइन में बदलाव कर सकते हैं:
|
| पब्लिशर के इंटरेस्ट ग्रुप का कंट्रोल | पब्लिशर के लिए सहायता, ताकि वे पब्लिशर के बनाए गए दिलचस्पी के ग्रुप का इस्तेमाल करने का अधिकार, किसी और को दे सकें. | हमने अनुरोध के बारे में कई पक्षों के साथ बातचीत की है. हमारा मानना है कि पब्लिशर के बनाए गए दिलचस्पी के ग्रुप को "डीलेगेट" करने से जुड़े सभी इस्तेमाल के उदाहरणों को अब शामिल किया जा सकता है. साथ ही, आने वाले समय में कुछ इस्तेमाल के उदाहरणों को आसानी से लागू करने के लिए, हमें ज़्यादा सहायता उपलब्ध करानी चाहिए. |
| (इसकी जानकारी दूसरी तिमाही में भी दी गई थी) ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट | सार्वजनिक क्लाउड एनवायरमेंट के बजाय, ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) के लिए सहायता. | हमारा जवाब पिछली तिमाहियों के जवाब से मिलता-जुलता है: हम सार्वजनिक क्लाउड-आधारित समाधानों के अलावा, अन्य विकल्पों के लिए सहायता का पता लगा रहे हैं. हालांकि, फ़िलहाल हमारे पास ऑन-प्राइमिस टीईई के लिए सहायता देने का कोई प्लान नहीं है. इस समय, Privacy Sandbox की सुरक्षा से जुड़ी ज़रूरी शर्तों और ऑन-प्राइमिस डिप्लॉयमेंट से जुड़ी अहम चुनौतियों को देखते हुए, हमें लगता है कि क्लाउड पर आधारित डिप्लॉयमेंट को बढ़ाना और बेहतर बनाना (उदाहरण के लिए, AWS के साथ-साथ Google Cloud के साथ काम करना) नेटवर्क के लिए सबसे ज़्यादा फ़ायदेमंद है. हालांकि, हम इस बारे में ज़्यादा सुझाव, राय या शिकायत पाना चाहते हैं कि निजता और सुरक्षा से जुड़ी पाबंदियों को देखते हुए, यह ज़रूरी और मुमकिन क्यों है कि उपयोगकर्ताओं को इस तरह की जानकारी देनी पड़े. |
| ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट | टीईई सर्विंग पाथ में मौजूद कॉम्पोनेंट, जैसे कि लोड बैलेंसर, सभी ट्रैफ़िक को मॉनिटर कर सकते हैं. साथ ही, उनके पास हर अनुरोध के आईपी पते की जानकारी होती है. | फ़िलहाल, आईपी पते को अनुरोध हेडर में मेटाडेटा के तौर पर भेजा जाता है. ऐसा, बिडिंग और नीलामी, दोनों के मामले में किया जाता है. साथ ही, डिवाइस पर सुरक्षित ऑडियंस की नीलामियों के लिए भी ऐसा किया जाता है. ज़्यादा जानकारी के लिए, मेटाडेटा फ़ॉरवर्ड करना लेख पढ़ें. लंबे समय में, हमारा प्लान है कि हम विज्ञापन टेक्नोलॉजी और ट्रैकर ट्रैफ़िक को आईपी प्रॉक्सी के ज़रिए प्रॉक्सी करें. इससे कॉम्पोनेंट, विज्ञापन दिखाने के पाथ में मौजूद सभी ट्रैफ़िक को मॉनिटर नहीं कर पाएंगे. |
| टाइम-टू-लिव (टीटीएल) | क्या सेवाओं को नई कुंजियों का अनुरोध करने से पहले, टाइम-टू-लिव (टीटीएल) सेट किया जाएगा या इसे बदला जा सकता है (या डाइनैमिक)? | आम तौर पर, टीटीएल स्टैटिक होता है. फ़िलहाल, सार्वजनिक कुंजियों के लिए टीटीएल आठ दिन का है और रोटेशन हर सात दिन में होता है. एग्रीगेशन सेवा के मामले में, निजी कुंजियों के लिए भी टीटीएल एक जैसा है. बिडिंग और नीलामी की सेवाओं के मामले में, निजी और सार्वजनिक पासकोड को हर N घंटे में, अनुरोध वाले पाथ के बजाय किसी दूसरे पाथ से फ़ेच किया जाता है और मेमोरी में कैश मेमोरी किया जाता है. इससे, पासकोड बदलने और सर्वर के पास इन पासकोड के पहुंचने में, N घंटे से ज़्यादा का इंतज़ार नहीं करना पड़ता. पासकोड बदलने और उसकी समयसीमा खत्म होने के बीच एक दिन का बफर होता है. इससे यह पक्का किया जाता है कि पासकोड जनरेट न होने पर भी, सेवाएं काम करती रहें. हम टीटीएल को बढ़ाने पर विचार कर रहे हैं, ताकि रुकावटों के दौरान भी आपका खाता काम करता रहे. अगर कुंजी लीक हो जाती है, तो हम मैन्युअल तरीके से कुंजी जनरेट करने की सुविधा चालू करेंगे और कुंजियों को जल्द से जल्द अमान्य कर देंगे. ध्यान दें कि क्लाइंट पर सार्वजनिक कुंजियों को कैश मेमोरी में सेव किया जाता है. फ़िलहाल, इन्हें 24 घंटे के लिए सेव किया जाता है. इससे यह पक्का किया जाता है कि कोऑर्डिनेटर के बंद होने पर भी सेवाएं काम करती रहें. |
| ट्रैफ़िक शेपिंग | बिडिंग और नीलामी से जुड़ी सेवाओं के लिए, ट्रैफ़िक शेपिंग की सुविधा. | पब्लिशर के पहले पक्ष के डेटा या संदर्भ के हिसाब से डेटा के आधार पर, खरीदार सुरक्षित ऑडियंस की नीलामियों की मांग कर सकते हैं. सेलर, अपने विज्ञापन सर्वर या Ad Exchange सर्वर में भी इसी तरह के फ़ैसले ले सकते हैं. मॉडल को 1P डेटा और सुरक्षित ऑडियंस नीलामियों से मिली किसी भी एग्रीगेट रिपोर्ट पर ट्रेन किया जा सकता है. सेलर इस जानकारी का इस्तेमाल करके, बिडिंग और नीलामी सर्वर को अनुरोध भेजने से बच सकते हैं. ऐसा तब किया जा सकता है, जब Protected Audience नीलामियों की कोई मांग न हो. हमें लगता है कि ट्रैफ़िक बढ़ाने के लिए, यह एक असरदार तरीका हो सकता है. |
| कॉम्पोनेंट नीलामी | कॉम्पोनेंट सेलर के साथ कौनसे टॉप लेवल auctionSignals शेयर किए जाते हैं? | कॉम्पोनेंट की नीलामी में, खरीदारों को सिर्फ़ कॉम्पोनेंट बेचने वाले से सिग्नल मिलते हैं. हम जल्द ही हेडर बिडिंग और सुरक्षित ऑडियंस नीलामी के साथ, एक साथ होने वाली नीलामी के पूरे क्रम के बारे में दस्तावेज़ शेयर करने वाले हैं. |
| वीडियो रेंडरिंग | Protected Audience और फ़ेंस किए गए फ़्रेम का इस्तेमाल करके, वीडियो रेंडर करने की सुविधा. | Protected Audience API, iframes पर आधारित एक तरीके का इस्तेमाल करके वीडियो रेंडरिंग की सुविधा देता है. हालांकि, हमने अब तक ऐसा समाधान नहीं बनाया है जो फ़ेंस किए गए फ़्रेम के साथ काम करता हो. यही वजह है कि हमने फ़ेंस किए गए फ़्रेम को लागू करने की प्रक्रिया को 2026 तक के लिए टाल दिया है. इसका मतलब है कि अगर कोई पार्टनर अब फ़ेंस किए गए फ़्रेम लागू करने का फ़ैसला लेता है, तो उसे वीडियो के लिए सहायता नहीं मिलेगी. |
| फ़्रीक्वेंसी कैपिंग | (पिछली तिमाहियों में भी रिपोर्ट की गई) कैंपेन और विज्ञापन ग्रुप में, हर उपयोगकर्ता के हिसाब से फ़्रीक्वेंसी कंट्रोल. |
हमारी पिछली रिपोर्ट में दिया गया जवाब अब भी लागू है: सुरक्षित ऑडियंस, डिवाइस पर होने वाली नीलामियों के साथ-साथ, कॉन्टेक्स्ट और ब्रैंडिंग कैंपेन के लिए भी फ़्रीक्वेंसी कैपिंग की सुविधा देगी. शेयर किए गए स्टोरेज और साइट के हिसाब से तय किए गए कैप का इस्तेमाल, फ़्रीक्वेंसी कैपिंग के अन्य कंट्रोल के लिए भी किया जा सकता है. |
| विज्ञापन की प्राथमिकताएं | क्या Protected Audience API, विज्ञापन देने वाली साइटों के हिसाब से ऑप्ट-आउट करने या ब्लॉकलिस्ट करने का विकल्प देता है? क्या यह एक ही मालिक के सभी इंटरेस्ट ग्रुप को छोड़ने का विकल्प देता है? | उपयोगकर्ता, Protected Audience API और Privacy Sandbox की अन्य सुविधाओं का ऐक्सेस ब्लॉक करने के कई तरीके अपना सकते हैं. |
| बिडिंग और नीलामी स्क्रिप्ट के सोर्स यूआरएल के लिए, एक ही सोर्स की नीति | स्क्रिप्ट या JSON लोड करने के लिए यूआरएल बताने वाले सभी फ़ील्ड, मालिक के साथ एक ही ऑरिजिन होने चाहिए. | फ़िलहाल, हम इस अनुरोध पर विचार कर रहे हैं. साथ ही, इकोसिस्टम से ज़्यादा सुझाव, राय या शिकायतें पाने के लिए तैयार हैं. |
forDebuggingOnly |
अगर forDebuggingOnly को तीन पीसीडी के बाद भी बरकरार रखा जाता है, तो इसका गलत इस्तेमाल किया जा सकता है. |
पिछले कुछ सालों से, हमें तीसरे पक्ष की कुकी के बंद होने के बाद, Protected Audience के फ़ंक्शन में अंतर के बारे में, नेटवर्क से जुड़े प्लैटफ़ॉर्म से सुझाव मिल रहे हैं. इसलिए, हम Privacy Sandbox के लक्ष्यों को बनाए रखते हुए, 3PCD के बाद इन सुविधाओं को इस्तेमाल करने के लिए एक प्लान बना रहे हैं. अगर आपको लगता है कि इस प्लैटफ़ॉर्म में कोई सुविधा मौजूद नहीं है, तो हमें इस बारे में सुझाव/राय दें या शिकायत करें. |
| एक जैसी दिलचस्पी वाले कई ग्रुप | एक ही बिड में कई इंटरेस्ट ग्रुप का इस्तेमाल करना. | फ़िलहाल, Protected Audience API में ऐसा नहीं किया जा सकता. ऐसा करने से, निजता मॉडल में बदलाव होगा. यहां इस बारे में और बातचीत करने के लिए, हम आपका स्वागत करते हैं. |
| डिवाइस पर होने वाली नीलामियां | क्या Android पर Chrome, डिवाइस पर सुरक्षित ऑडियंस वाली नीलामियों के साथ काम करेगा? | हां, Android पर Chrome में, उपयोगकर्ता के डिवाइस पर होने वाली नीलामियां काम करेंगी. |
| (साल 2023 की दूसरी तिमाही में रिपोर्ट किया गया) क्लिक से जुड़ा डेटा | browserSignals में क्लिक से जुड़ा डेटा जोड़ें. | हम इस सुविधा के अनुरोध का आकलन करते रहेंगे. साथ ही, इस बारे में ज़्यादा सुझाव/राय देने के लिए आपका स्वागत है कि इस सुविधा को प्राथमिकता क्यों दी जानी चाहिए. |
| ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) की सेवा देने वाली कंपनियां | क्या क्लाउड सेवा देने वाली अलग-अलग कंपनियों के ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट की सुविधाओं में कोई खास अंतर है? | हमें इनमें कोई बड़ा फ़र्क़ नहीं दिख रहा है. हालांकि, हमारा सुझाव है कि इकोसिस्टम, डिप्लॉयमेंट से जुड़ी सार्वजनिक गाइड देखें और यह पता लगाएं कि उनकी ज़रूरतों के हिसाब से कौनसा समाधान सबसे सही है. Google Cloud. AWS. |
| (पिछली तिमाहियों में रिपोर्ट की गई ) दिलचस्पी न रखने वाले ग्रुप को टारगेटिंग से बाहर रखने के लिए सहायता |
नेगेटिव इंटरेस्ट ग्रुप टारगेटिंग के लिए इस्तेमाल किया जाने वाला एपीआई: यह सिर्फ़ तब विज्ञापन दिखाता है, जब कोई उपयोगकर्ता किसी इंटरेस्ट ग्रुप से नहीं जुड़ा हो. | हम इस सुविधा को लागू करने पर काम कर रहे हैं और इस अनुरोध पर चर्चा कर रहे हैं. |
| कॉन्टेंट का उल्लंघन | ऐसी सुविधाएं जो उपयोगकर्ताओं को, फ़ेंस किए गए फ़्रेम में, Protected Audience API की मदद से दिखाए गए खराब विज्ञापनों की शिकायत करने की अनुमति देती हैं. | हमारा मानना है कि फ़ेंस किए गए फ़्रेम वाले विज्ञापनों की रिपोर्टिंग के मौजूदा तरीके से, विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली उन कंपनियों को अच्छे विकल्प मिलते हैं जो उपयोगकर्ता से जनरेट होने वाले "खराब विज्ञापनों" की शिकायत करने का तरीका चाहते हैं. इससे, गलत विज्ञापनों की शिकायत करने के तरीके में कोई बदलाव नहीं होगा. यह तरीका, मौजूदा इंडस्ट्री स्टैंडर्ड से मेल खाता है. अगर कोई समस्या रहती है, तो हम सुविधा से जुड़े और अनुरोधों का स्वागत करते हैं. इनमें तीसरे पक्ष की कुकी हटाने के बाद, फ़ेंस किए गए फ़्रेम की रेंडरिंग का ज़्यादा इस्तेमाल होने से पहले की अवधि भी शामिल है. |
| Private Aggregation API की रिपोर्टिंग | हम उस दिलचस्पी के ग्रुप में उपयोगकर्ता के बिताए गए समय का हिसाब कैसे लगा सकते हैं? | Chrome M116 और उसके बाद के वर्शन में, pull/639 में बताए गए तरीके से, हाल ही में देखे गए आइटम की जानकारी का इस्तेमाल किया जा सकता है. |
| K-Anonymity सर्वर | K-Anonymity सर्वर के बारे में ज़्यादा जानकारी. | हमने K-Anonymity सर्वर के बारे में यहां ज़्यादा जानकारी शेयर की है. साथ ही, हमें इस बारे में और सुझाव, राय या शिकायत भेजने में खुशी होगी. |
| डाइनैमिक क्रिएटिव यूआरएल | क्रिएटिव यूआरएल के लिए, पहले से एलान किए बिना भी क-अनामिटी का पालन किया जा सकता है. | हम इस सुविधा के अनुरोध पर विचार कर रहे हैं. साथ ही, इस बारे में ज़्यादा सुझाव, राय या शिकायत भेजने के लिए आपका स्वागत है. |
| K-anonymity की ज़रूरी शर्त | क्या इंटरेस्ट ग्रुप के अपडेट के लिए, क-अनामिटी की ज़रूरी शर्त फिर से लागू की जाएगी? | हमें नहीं लगता कि इस GitHub पोस्ट में बताई गई स्थिति में कोई बदलाव होगा. जैसा कि उस पोस्ट में बताया गया था, हमने सुरक्षित ऑडियंस के इंटरेस्ट ग्रुप के अपडेट पर, 'क-अनामता' की ज़रूरी शर्त को हटाने का फ़ैसला लिया है. इसका असर, एपीआई की निजता की सुरक्षा से जुड़ी सभी सुविधाओं पर काफ़ी नहीं पड़ेगा. साथ ही, हम आने वाले समय में, ज़्यादा सीधे तौर पर निजता की सुरक्षा करने वाली अन्य सुविधाओं (जैसे, आईपी पते की निजता या भरोसेमंद अपडेट सर्वर) पर विचार करेंगे. ऐसा तब किया जाएगा, जब इनसे जुड़ी टेक्नोलॉजी ज़्यादा बेहतर हो जाएंगी, उन्हें डिप्लॉय किया जाएगा, और उन्हें अपनाया जाएगा. |
| बिडिंग और नीलामी से जुड़ी सेवाओं की बीटा टेस्टिंग | बिडिंग और नीलामी से जुड़ी सेवाओं के बीटा वर्शन की टेस्टिंग कब शुरू होगी? | टाइमलाइन और रोडमैप में बताए गए मुताबिक, बिडिंग और नीलामी सेवाओं की टेस्टिंग का पहला चरण नवंबर 2023 से शुरू होगा. |
| रोडब्लॉक | विज्ञापन नेटवर्क के लिए क्रिएटिव कोऑर्डिनेशन की सुविधा का अनुरोध करना (एसएसपी और डीएसपी एक ही कंपनी या प्रॉपर्टी में हैं). | इस इस्तेमाल के उदाहरण के लिए, आपके सुझाव/राय/शिकायत देने के लिए धन्यवाद. हम यह समझने की कोशिश कर रहे हैं कि क्या ज़्यादा विज्ञापन टेक्नोलॉजी कंपनियां, इस सुविधा के साथ काम करना चाहती हैं. अन्य सुझाव, शिकायत या राय देने के लिए, हम आपका स्वागत करते हैं. |
| नेटिव विज्ञापन | नेटिव विज्ञापन के लिए फ़ेंस्ड फ़्रेम की सुविधा. | हम इस इस्तेमाल के उदाहरण को शामिल करने पर विचार कर रहे हैं. साथ ही, इससे जुड़ी समस्याओं को हल करने के तरीकों पर चर्चा कर रहे हैं. |
| K-anonymity | मैं k-anon के थ्रेशोल्ड को पूरा करने वाले, दिलचस्पी के ग्रुप के विज्ञापनों को कैसे बढ़ाऊं? | हमने इस विषय पर कुछ रणनीतिक दिशा-निर्देश शेयर किए हैं. |
| पोस्ट से जुड़ी सहायता | पोस्ट अनुरोधों के ज़रिए नीलामी का डेटा भेजने के लिए सहायता. | हम इस सुविधा के अनुरोध की समीक्षा कर रहे हैं. साथ ही, GitHub पर इस समस्या के बारे में और सबमिशन का स्वागत करते हैं. इनमें यह बताएं कि इस समस्या को प्राथमिकता क्यों दी जानी चाहिए. |
| रिपोर्टिंग की बारीकी | एक से ज़्यादा हिस्सों वाले विज्ञापनों के लिए, फ़ेंस किए गए फ़्रेम वाले विज्ञापन की रिपोर्टिंग में ज़्यादा जानकारी क्या है? | मौजूदा डिज़ाइन में, प्रॉडक्ट आईडी या पोज़िशन कैप्चर करने की अनुमति नहीं है, क्योंकि इससे उपयोगकर्ता की निजता को खतरा हो सकता है. सिर्फ़ reserved.top_navigation को ट्रिगर किया जा सकता है. यह तब भेजा जाएगा, जब विज्ञापन कॉम्पोनेंट के फ़ेंस किए गए फ़्रेम पर उपयोगकर्ता ऐक्टिवेशन (जैसे, क्लिक) होता है. इससे टॉप-लेवल नेविगेशन होता है. |
| विज्ञापन नीलामी | क्या कॉम्पोनेंट नीलामी में हिस्सा लेने वाला एसएसपी, खुद ही किसी दूसरी कॉम्पोनेंट नीलामी को ट्रिगर कर सकता है? | componentSeller में componentAuctions भी शामिल नहीं किया जा सकता.एक से ज़्यादा सेलर वाली नीलामी में सिर्फ़ दो लेवल होते हैं: 1. एक साथ होने वाली कॉम्पोनेंट नीलामियां. 2. टॉप-लेवल नीलामी (जहां हर componentAuction से जीतने वाला विज्ञापन मुकाबला करता है). |
| बिडिंग और नीलामी से जुड़ी सेवाओं की उपलब्धता | क्या Chrome की मदद से टेस्टिंग के दौरान बिडिंग और नीलामी की सुविधा उपलब्ध होगी? | Chrome की मदद से टेस्टिंग के दौरान, बिडिंग और ऑक्शन सर्वर उपलब्ध नहीं होंगे. |
| बिडिंग सिग्नल | ब्राउज़र को बिडिंग सिग्नल का अनुरोध करने और उन्हें मिटाने की अनुमति दें. | हम इस अनुरोध पर चर्चा कर रहे हैं. साथ ही, इस बारे में ज़्यादा सुझाव, राय या शिकायत भेजने के लिए आपका स्वागत है कि इसे प्राथमिकता क्यों दी जानी चाहिए. |
generateBid() |
updateURL की मदद से, interestGroup का userBiddingSignals अपडेट करने की सुविधा. |
हम इस प्रस्ताव पर विचार कर रहे हैं. साथ ही, अन्य सुझावों और राय का स्वागत करते हैं. |
| पब्लिशर इन्वेंट्री के टाइप | सुरक्षित ऑडियंस और TOPICS की जांच की सुविधा, पब्लिशर की किस तरह की इन्वेंट्री के साथ काम करेगी? | Protected Audience और विषयों को, किसी भी तरह की इन्वेंट्री के लिए इस्तेमाल किया जा सकता है. |
| सर्वर-टू-सर्वर इंटिग्रेशन | क्या सुरक्षित ऑडियंस के लिए, एसएसपी और डीएसपी के बीच सीधे इंटिग्रेशन की ज़रूरत है? | अगर डीएसपी को प्रोसेस की गई जानकारी को अपने डिवाइस पर बिडिंग फ़ंक्शन में पास करने के लिए, अपने सर्वर में कॉन्टेक्स्ट के हिसाब से सिग्नल को प्रोसेस करने की ज़रूरत नहीं है, तो एसएसपी और डीएसपी के बीच सीधे तौर पर इंटिग्रेशन की ज़रूरत नहीं होती. |
B&A में bid_currency फ़ील्ड |
बिडिंग और नीलामी सेवा में bid_currency फ़ील्ड के लिए सहायता. |
फ़िलहाल, B&A में bid_currency का इस्तेमाल नहीं किया जा सकता. हालांकि, हम जनवरी 2024 के आखिर तक इसकी सुविधा उपलब्ध कराने वाले हैं. टाइमलाइन यहां देखें. |
perBuyerSignals |
क्या perBuyerSignals के लिए साइज़ की कोई सीमा है? |
हर खरीदार के सिग्नल की संख्या पर कोई सीमा नहीं है. हालांकि, बहुत ज़्यादा डेटा भेजने से ब्राउज़र की परफ़ॉर्मेंस पर बुरा असर पड़ सकता है. |
| अलग-अलग साइटों पर इस्तेमाल के उदाहरण | क्या Protected Audience API के इंटरेस्ट ग्रुप का इस्तेमाल, एक से ज़्यादा वेबसाइटों पर किया जा सकता है? | Protected Audience को ऐसे इस्तेमाल के उदाहरणों के लिए डिज़ाइन नहीं किया गया है, जैसा कि turtledove/issues/282 में बताया गया है. |
| इंटरेस्ट ग्रुप के एचटीटीपी अनुरोध | एचटीटीपी हेडर में, एक जैसी दिलचस्पी वाले ग्रुप का ब्लॉब शामिल करें. | हम इस अनुरोध पर विचार कर रहे हैं. साथ ही, इस अनुरोध के बारे में ज़्यादा सुझाव, राय या शिकायत भेजने के लिए आपका स्वागत है. |
| विज्ञापन की क्वालिटी कंट्रोल करना | अलग-अलग साइटों की जानकारी से जुड़े विज्ञापन की क्वालिटी कंट्रोल की सुविधा का बंद होना. | हम इस सुझाव पर विचार कर रहे हैं. साथ ही, अन्य सुझाव, राय या शिकायत भेजने के लिए आपका स्वागत है. |
| Chrome DevTools | Protected Audience के लिए नेटवर्क से किए गए अनुरोध, Chrome डेवलपर टूल के नेटवर्क टैब में दिखने चाहिए. | हम नेटवर्क टैब में इस सुविधा को चालू करने पर काम कर रहे हैं. साथ ही, इस सुविधा को प्राथमिकता क्यों दी जानी चाहिए, इस बारे में ज़्यादा सुझाव/राय देने के लिए आपका स्वागत है. |
| ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट | भरोसेमंद एक्सीक्यूशन एनवायरमेंट की मॉनिटरिंग के बारे में बताने वाले लेख में, निजता पर असर डालने वाली मेट्रिक और उनके असर की जानकारी कब जोड़ी जाएगी? | हम इस जानकारी के साथ, एक्सप्लेनर वीडियो को अपडेट कर रहे हैं. अपडेट किया गया एक्सप्लेनर, नवंबर 2023 तक उपलब्ध होगा. |
directFrom |
directFrom को वेब बंडल के तौर पर पैकेज क्यों नहीं किया गया है? |
हमने इस फ़ैसले की वजह यहां शेयर की है. |
| इंप्रेशन का ऐक्सेस देना | क्या इंप्रेशन का डेलिगेशन करने का कोई ऐसा तरीका है जिसमें चुने गए एक जैसी दिलचस्पी वाले ग्रुप का नतीजा, टारगेटिंग की कोई और कार्रवाई हो? | नेस्ट की गई कई नीलामियां, हमारे निजता लक्ष्यों के साथ काम नहीं करतीं. ऐसा दो वजहों से होता है. पहला, जब नीलामी में जीतने वाला विज्ञापन फ़ेंस किए गए फ़्रेम में रेंडर होता है, तो सुरक्षित ऑडियंस के लिए हमारे निजता लक्ष्यों में, कॉन्टेक्स्ट के बारे में जानकारी के बिना क्रिएटिव रेंडरिंग शामिल होती है: आस-पास के पेज का यूआरएल या पहले पक्ष की कुकी, निजता का उल्लंघन है. उस एनवायरमेंट में, नेस्ट की गई नीलामी काम नहीं करती. दूसरा, सुरक्षित ऑडियंस मॉडल के मुताबिक, हर नीलामी में विजेता सिर्फ़ एक अतिरिक्त साइट के डेटा के आधार पर चुना जाना चाहिए. नेस्ट की गई नीलामियां, इस समस्या को हल करने का एक तरीका हो सकती हैं. इनकी मदद से, कई साइटों की प्रोफ़ाइल के आधार पर विज्ञापन चुने जा सकते हैं. |
| इनऐक्टिव डेटा से जुड़ी शर्त | पासकोड/वैल्यू सेवा के ट्रस्ट मॉडल में, 'स्टोर किया गया डेटा' की शर्त के बारे में ज़्यादा जानकारी दें. | कुंजी वैल्यू सेवा में मौजूद डेटा को मेमोरी में लोड किया जाता है और फिर उसे वहां से दिखाया जाता है. इसके लिए, डेटा को रीड-थ्रू कैश मेमोरी में सेव नहीं किया जाता. |
| खरीदार का डेटा सिग्नल | क्या डीएसपी से मिले buyer_data सिग्नल के साइज़ की कोई तय सीमा है? |
फ़िलहाल, डीएसपी से मिले buyer_data सिग्नल के लिए, ब्राउज़र की ओर से कोई सीमा नहीं लगाई गई है. |
डिजिटल विज्ञापनों की परफ़ॉर्मेंस का आकलन करना
एट्रिब्यूशन रिपोर्टिंग (और अन्य एपीआई)
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| क्रॉस डिवाइस | Attribution Reporting API के लिए, अलग-अलग डिवाइसों पर काम करने की सुविधा के लिए प्लान बनाएं. | क्रॉस-डिवाइस सुविधा, 3PC के साथ-साथ निजता से जुड़ी नई चुनौतियां भी पेश करती है. साथ ही, उपयोगकर्ता के डिवाइसों और प्लैटफ़ॉर्म की रेंज को देखते हुए, टेक्नोलॉजी डिस्ट्रिब्यूशन से जुड़ी चुनौतियां भी पैदा करती है. हम संभावित समाधानों को एक्सप्लोर कर रहे हैं. हालांकि, फ़िलहाल हम एट्रिब्यूशन रिपोर्टिंग की मदद से इस्तेमाल के उन अहम उदाहरणों पर फ़ोकस कर रहे हैं जिनके लिए तीसरे पक्ष की कुकी की ज़रूरत होती है. साथ ही, तीसरे पक्ष की कुकी हटाने से पहले, हम अलग-अलग डिवाइसों पर काम करने की सुविधा को लॉन्च नहीं करेंगे. |
| (पिछली तिमाहियों में भी रिपोर्ट किया गया) ट्रिगर डेटा का साइज़ |
ट्रिगर डेटा का साइज़ तीन बिट तक ही क्यों सीमित है? | इसका साइज़ 3 बिट और आठ अलग-अलग वैल्यू तक सीमित होता है. इससे यह पक्का किया जाता है कि किसी उपयोगकर्ता के बारे में क्रॉस-साइट और क्रॉस-कॉन्टेक्स्ट की जानकारी सीमित हो. हम इकोसिस्टम के खिलाड़ियों का सुझाव, राय या शिकायत सबमिट करने का स्वागत करते हैं. इससे हमें यह जानने में मदद मिलेगी कि इवेंट-लेवल रिपोर्टिंग के लिए, मौजूदा पैरामीटराइज़ेशन काफ़ी है या नहीं. |
| कन्वर्ज़न फ़नल | कन्वर्ज़न में इस्तेमाल किए गए कई डोमेन की रिपोर्ट करें. | एक से ज़्यादा डेस्टिनेशन जोड़ने की वजह से, इस तरह के इस्तेमाल का उदाहरण दिया जा सकता है. अन्य सुझाव, शिकायत या राय भेजने के लिए, हम आपका स्वागत करते हैं. |
| अलग-अलग देशों में एक ही डोमेन का इस्तेमाल करने की सुविधा | क्या एट्रिब्यूशन रिपोर्टिंग उन वेबसाइटों के साथ काम करती है जिनका एक ही डोमेन है, लेकिन देश के कई टीएलडी हैं? | इस समस्या पर, सवाल पूछने वाले हिस्सेदार के साथ चर्चा की गई है और उसे हल कर दिया गया है. अगर किसी विज्ञापन टेक्नोलॉजी कंपनी को एक से ज़्यादा देशों के TLD का इस्तेमाल करना है, तो उसे एक से ज़्यादा बार रजिस्टर करना होगा. हर देश के TLD के लिए एक बार रजिस्टर करना होगा. |
| Protected Audience और एट्रिब्यूशन रिपोर्टिंग | क्या विज्ञापन टेक्नोलॉजी, सुरक्षित ऑडियंस ऑक्शन के लिए व्यू-थ्रू कन्वर्ज़न (दर्शक का ग्राहक बनना) और एट्रिब्यूशन रिपोर्टिंग के लिए क्लिक-थ्रू कन्वर्ज़न, दोनों को ऐक्सेस कर सकती हैं? | हां, Privacy Sandbox, सुरक्षित ऑडियंस में वीटीसी और सीटीसी, दोनों के साथ काम करना चाहिए. |
| एग्रीगेट की जा सकने वाली रिपोर्ट में देरी | एग्रीगेट की जा सकने वाली रिपोर्ट में होने वाली देरी को और कम करें. | हमने हाल ही में इस बारे में सुझाव/राय/शिकायतें/राय पाई हैं. हमने यहां कुछ आइडिया शेयर किए हैं. हमें इस बारे में और सुझाव, शिकायत या राय मिल सकती है. |
| एग्रीगेट की जा सकने वाली रिपोर्ट में देरी | सर्वर मीडिएशन की सुविधा जोड़कर, देरी को कम करना. | हम इस प्रस्ताव पर विचार कर रहे हैं. साथ ही, अन्य सुझाव, राय या शिकायत का स्वागत करते हैं. |
| इवेंट-लेवल की रिपोर्ट में देरी | इवेंट-लेवल की रिपोर्ट में लगने वाले समय को कम करना. | इवेंट-लेवल के लिए ज़रूरत के मुताबिक कॉन्फ़िगरेशन में बताया गया, इवेंट-लेवल के लिए पूरी तरह से ज़रूरत के मुताबिक बनाया गया प्रस्ताव, इवेंट-लेवल की रिपोर्टिंग में लगने वाले समय को कम करके एक घंटे तक कर सकता है. हालांकि, इसके लिए आपको कुछ नॉइज़ का सामना करना पड़ सकता है. |
| हर सोर्स के लिए सोर्स रिपोर्टिंग का ऑरिजिन | हर सोर्स रिपोर्टिंग साइट के लिए, सोर्स रिपोर्टिंग के ज़्यादा से ज़्यादा सोर्स की सीमा तय करने से, विज्ञापन टेक्नोलॉजी किसी एक पब्लिशर के सोर्स के लिए, अलग-अलग रिपोर्टिंग सोर्स से सोर्स रजिस्टर नहीं कर पाती. | इस बारे में उस हिस्सेदार के साथ बातचीत की गई है जिसने समस्या को उठाया था. साथ ही, रीडायरेक्ट से जुड़े अन्य संभावित समाधानों को आज़माने से पहले, हर सोर्स-रिपोर्टिंग साइट के लिए एक रिपोर्टिंग ऑरिजिन का इस्तेमाल करने के संभावित समाधान की जांच की जा रही है. हम इस सीमा के बारे में, नेटवर्क से जुड़े किसी भी सुझाव, राय या शिकायत को स्वीकार करने के लिए तैयार हैं. |
| समस्या की शिकायत करना | हम Chrome को Attribution Reporting API से जुड़ी गड़बड़ियों या समस्याओं की शिकायत कैसे कर सकते हैं? | फ़िलहाल, हमारा सुझाव है कि विज्ञापन टेक्नोलॉजी विशेषज्ञ, एट्रिब्यूशन रिपोर्टिंग एपीआई से जुड़ी किसी भी गड़बड़ी की शिकायत GitHub पर करें. अगर उन्हें Chrome से जुड़ी कोई समस्या आ रही है, तो हमारा सुझाव है कि वे Chromium के लिए गड़बड़ी की शिकायत करें. संपर्क करें और सुझाव/राय दें या शिकायत करें में जाकर, किसी भी समस्या को फ़्लैग करने के तरीके और जगह के लिंक देखे जा सकते हैं. |
| डिडुप्लिकेशन | हम अलग-अलग पाइपलाइन और डिवाइसों में मौजूद कन्वर्ज़न की डुप्लीकेट कॉपी को कैसे हटा सकते हैं? | सभी डिवाइसों और मेज़रमेंट पाइपलाइन से डुप्लीकेट डेटा हटाना एक ऐसी चुनौती है जिसका सामना विज्ञापन टेक्नोलॉजी को आज भी 3PCs के साथ करना पड़ता है. एट्रिब्यूशन रिपोर्टिंग एपीआई की मदद से, विज्ञापन टेक्नोलॉजी विशेषज्ञ यह तय कर सकते हैं कि किसी खास कन्वर्ज़न को कब रजिस्टर किया जाए. साथ ही, वे खास मेटाडेटा जोड़ सकते हैं, ताकि यह पता चल सके कि कन्वर्ज़न ट्रैक करने के लिए, उन्होंने किन मेज़रमेंट पाइपलाइन का इस्तेमाल किया है. दूसरे शब्दों में, एग्रीगेशन बटन का हिस्सा. इसकी तुलना अन्य मेज़रमेंट पाइपलाइन से की जा सकती है. हम इस बारे में, नेटवर्क से जुड़े किसी भी सुझाव, राय या शिकायत को स्वीकार करने के लिए तैयार हैं. |
| डुप्लीकेट कॉपी हटाने की तकनीक और प्राथमिकता | डुप्लीकेट कॉपी हटाने से पहले, प्राथमिकता देने का अनुरोध करें. | हम इस अनुरोध पर विचार कर रहे हैं. साथ ही, अतिरिक्त सुझाव, राय या शिकायत भेजने के लिए आपका स्वागत है. |
| धोखाधड़ी से बचाव | नुकसान पहुंचाने वाले उपयोगकर्ता के इवेंट-लेवल के डेटा में छेड़छाड़ करने का जोखिम. | रिपोर्ट की पुष्टि करने की सुविधा, इवेंट-लेवल की रिपोर्टिंग के लिए काम नहीं करती. इसकी वजहें, यह सुविधा, इवेंट-लेवल की रिपोर्ट के साथ क्यों काम नहीं करती? में बताई गई हैं. |
| कन्वर्ज़न टाइप | एट्रिब्यूशन रिपोर्टिंग में, व्यूथ्रू और नेविगेशन के बीच का अंतर कैसे किया जा सकता है? | हमारे पास फ़िल्टर करने के लिए, पहले से मौजूद यह विकल्प है: source_type.
ज़्यादा जानकारी यहां उपलब्ध है. |
एग्रीगेशन सेवा
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| बजट वापस पाना | कुछ विज्ञापन टेक्नोलॉजी विशेषज्ञों ने, रिपोर्ट को फिर से प्रोसेस करने की सुविधा का अनुरोध किया है. ऐसा उन मामलों में किया जा सकता है जहां उनकी रिपोर्ट प्रोसेस नहीं हो पाती हैं, उनमें गड़बड़ियां होती हैं या उन्हें मिटा दिया जाता है. | हमारी टीम इस समस्या को हल करने के लिए, निजता बनाए रखने के तरीकों पर काम कर रही है. |
| साइट का रजिस्ट्रेशन | कई विज्ञापन टेक्नोलॉजी विशेषज्ञों ने एक ही खाते में कई ऑरिजिन को प्रोसेस करने के लिए सहायता का अनुरोध किया है. इसका इस्तेमाल, डेटा को जगह और विज्ञापन देने वाले के हिसाब से बांटने जैसे कामों के लिए किया जा सकता है. विज्ञापन टेक्नोलॉजी के विशेषज्ञों को भी इस तरह के व्यवहार की उम्मीद है, क्योंकि क्लाइंट एपीआई का रजिस्ट्रेशन अब साइट के हिसाब से होता है, न कि ऑरिजिन के हिसाब से. ऑरिजिन से साइट के रजिस्ट्रेशन पर माइग्रेट करने से, क्लाइंट के रजिस्ट्रेशन की प्रोसेस के साथ मिलते-जुलते तरीके से, विज्ञापन टेक्नोलॉजी को ऑनबोर्ड करने की प्रोसेस को आसान बनाया जा सकता है. | हम जल्द ही एग्रीगेशन सेवा के लिए, ऑरिजिन रजिस्ट्रेशन से साइट रजिस्ट्रेशन पर माइग्रेशन की सुविधा लॉन्च करेंगे. साथ ही, इकोसिस्टम से मिलने वाले सुझावों और राय का स्वागत करेंगे. |
| रिलीज़ और बंद करने का प्लान | पब्लिश की गई एग्रीगेशन सेवा की सुविधाओं और पैच के लिए, रिलीज़ और डेप्रिसिएशन शेड्यूल. इस प्लान का मकसद, विज्ञापन टेक्नोलॉजी विशेषज्ञों को रिलीज़ से जुड़ी हमारी नीतियों के बारे में जानकारी देना है. इससे वे आने वाली रिलीज़ और बंद होने वाली सेवाओं के लिए तैयार हो पाएंगे. साथ ही, यह पक्का कर पाएंगे कि वे सेवाओं के सुरक्षित और स्थिर वर्शन चला रहे हैं. | हमने हाल ही में एग्रीगेशन सेवा के रिलीज़ और बंद करने के प्लान के लिए एक प्रस्ताव पब्लिश किया है. अतिरिक्त सुझाव/राय/शिकायत देने के लिए, हम आपका स्वागत करते हैं. |
| कोऑर्डिनेटर | अगर एग्रीगेशन सेवा के लिए कोऑर्डिनेटर काम नहीं कर रहे हैं, तो क्या होगा? | सिस्टम के सही तरीके से काम करने के लिए, दोनों कोऑर्डिनेटर का पूरी तरह से उपलब्ध होना ज़रूरी है. अगर कोई कोऑर्डिनेटर कुछ समय के लिए उपलब्ध नहीं है, तो हमारी क्लाइंट लाइब्रेरी में फिर से कोशिश की जाती है. अगर दोनों में से कोई एक कोऑर्डिनेटर लंबे समय तक उपलब्ध नहीं है, तो एग्रीगेशन जॉब पूरा नहीं हो पाएंगे. अगर निजता के लिए तय किया गया बजट अब तक खर्च नहीं हुआ है, तो जॉब फिर से चलाए जा सकते हैं. अगर किसी सेवा में हुई गड़बड़ी की वजह से, विज्ञापन टेक्नोलॉजी के स्टोरेज में खास जानकारी वाली रिपोर्ट लिखे बिना बजट खर्च हो गया है, तो हमारा सुझाव है कि वे लोकल टेस्टिंग टूल का इस्तेमाल करके नतीजे पाने के लिए, डीबग रिपोर्ट का इस्तेमाल करें. हम ऐसी सुविधाओं पर भी काम कर रहे हैं जिनकी मदद से, विज्ञापन टेक्नोलॉजी विशेषज्ञ, विज्ञापन दिखाने में होने वाली गड़बड़ियों के मामले में बजट को वापस पा सकें. |
Private Aggregation API
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| ब्लॉब का यूआरएल | शेयर किए गए स्टोरेज में ब्लॉब यूआरएल का इस्तेमाल करने की सुविधा जोड़ने का अनुरोध. | Chrome M116 में, ब्लॉब यूआरएल के लिए सहायता जोड़ी गई है. |
गुप्त ट्रैकिंग को सीमित करना
यूज़र-एजेंट रिडक्शन और यूज़र-एजेंट क्लाइंट हिंट
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| JavaScript API | User-Agent Client Hints JavaScript API की उपलब्धता. | हम इस सुविधा को हटाने के बारे में नहीं सोच रहे हैं, क्योंकि यह उन पार्टनर के लिए हमारा मुख्य समाधान है जो फ़्रीज़ किए गए और कम किए गए यूए में डिफ़ॉल्ट रूप से उपलब्ध डेटा के अलावा, ज़्यादा एन्ट्रॉपी वाले डेटा को ऐक्सेस करना चाहते हैं. |
| डिवाइस और फ़ॉर्म फ़ैक्टर की जानकारी | वेबसाइटों के लिए, इनपुट, आउटपुट, और ऐसी अन्य जानकारी को समझने की सुविधा जो वेबसाइट पर आने वाले डिवाइस पर काम कर सकती है. | नेटवर्क से मिले सुझाव/राय/शिकायत के आधार पर, हमने इस अनुरोध के लिए सहायता जोड़ी है. |
आईपी प्रोटेक्शन (पहले इसे Gnatcatcher कहा जाता था)
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| ज़रूरी शर्तें पूरी करने वाला तीसरे पक्ष का ट्रैफ़िक | एक्सप्लेनर में "ज़रूरी शर्तें पूरी करने वाला तीसरे पक्ष का ट्रैफ़िक" किस बारे में बता रहा है? | हम इस सवाल की अहमियत समझते हैं. इसलिए, हम यह पता लगाने के लिए लगातार काम कर रहे हैं कि तीसरे पक्ष का कौनसा ट्रैफ़िक ज़रूरी शर्तें पूरी करता है और कौनसा नहीं. इस विषय पर सुझाव, राय या शिकायत करने के लिए, आपका स्वागत है. |
| नेटवर्क ट्रैफ़िक के ऑडिट | एंटरप्राइज़ के लिए, अपने नेटवर्क के ट्रैफ़िक का ऑडिट करने की सुविधा. | इससे सिर्फ़ पहले पक्ष की साइटों में एम्बेड किए गए तीसरे पक्ष के ट्रैफ़िक पर असर पड़ेगा. इससे, फ़िल्टर करने के लिए ज़रूरी ट्रैफ़िक की संख्या कम हो जाएगी. इसके अलावा, हम उपयोगकर्ताओं को यह विकल्प देने जा रहे हैं कि वे आईपी पते की सुरक्षा की सुविधा का इस्तेमाल करें या नहीं. साथ ही, एंटरप्राइज़ के कंट्रोल वाले Chrome के लिए, आईपी पते की सुरक्षा की सुविधा बंद करने के लिए एंटरप्राइज़ नीतियां होंगी. आखिर में, हम यह पता लगा रहे हैं कि आईपी पते की सुरक्षा की सुविधा बंद करने के लिए, नेटवर्क ऑपरेटर को कौनसे कंट्रोल (अगर कोई है) दिए जाएंगे. इस विषय पर सुझाव, राय या शिकायत देने के लिए, आपका स्वागत है. |
| ऐक्सेस कंट्रोल | आईपी पते की सुरक्षा की सुविधा से, उन वेब सेवाओं पर असर पड़ सकता है जो ऐक्सेस कंट्रोल के लिए आईपी पतों का इस्तेमाल करती हैं. | हम धोखाधड़ी रोकने के लिए इस्तेमाल किए जाने वाले उदाहरणों की अहमियत और उन पर पड़ने वाले संभावित असर को समझते हैं. हम नेटवर्क से जुड़े लोगों से सुझाव, राय या शिकायतें चाहते हैं. इससे हमें यह जानने में मदद मिलेगी कि धोखाधड़ी रोकने के लिए, आईपी पते के आधार पर काम करने वाले तरीकों को कैसे बेहतर बनाया जा सकता है. |
| दो-हॉप प्रॉक्सी के बीच कम्यूनिकेशन | यह कैसे पक्का करें कि प्रॉक्सी के बीच कोई जानकारी न हो. | हम प्रॉक्सी इंटरैक्शन को डिज़ाइन करने की प्रोसेस में हैं. हमारा लक्ष्य, कारोबार, प्रोसेस, और तकनीकी तरीकों से इस तरह की जानकारी शेयर करने की संभावनाओं को कम करना है. |
| Google से बाहर की पुष्टि करने की सेवाएं | Google से बाहर के पुष्टि करने वाले ऐप्लिकेशन के साथ काम करना. | हम आने वाले समय में, खाते की पुष्टि करने के बारे में ज़्यादा जानकारी पब्लिश करेंगे. हालांकि, हमने कुछ शुरुआती बातें शेयर की हैं. |
| ट्रैकर की कैटगरी | आईपी पते की सुरक्षा की सुविधा यह कैसे तय करेगी कि ट्रैकर और उसके वैरिएंट में क्या शामिल है? | हम इस सवाल की अहमियत समझते हैं. इसलिए, हम यह पता लगाने के लिए लगातार काम कर रहे हैं कि तीसरे पक्ष का कौनसा ट्रैफ़िक ज़रूरी शर्तें पूरी करता है और कौनसा नहीं. इस विषय पर सुझाव, राय या शिकायत करने के लिए, आपका स्वागत है. |
| Analytics | आईपी सुरक्षा की सुविधा से, आंकड़े जुटाने वाली सेवाओं के सटीक होने पर असर पड़ सकता है. | हम आईपी प्रोटेक्शन के असर को और बेहतर तरीके से समझना चाहते हैं. साथ ही, हम इकोसिस्टम से और सुझाव/राय या शिकायतें पाने के लिए तैयार हैं. |
| प्रॉक्सी | अगर कोई उपयोगकर्ता प्रॉक्सी का इस्तेमाल कर रहा है या उसने मैन्युअल तरीके से प्रॉक्सी सेट की है, तो इस मामले में आईपी मास्क कैसे काम करेगा? | हम यह समझने की कोशिश कर रहे हैं कि आईपी प्रोटेक्शन की सुविधा, अन्य प्रॉक्सी पर क्या असर डाल सकती है. फ़िलहाल, हमारे पास इस बारे में कोई जानकारी शेयर करने का कोई प्लान नहीं है. इस विषय पर हमें सुझाव/राय दें या शिकायत करें. |
| प्रीमियम ऑफ़र | क्या आईपी पते की सुरक्षा की सुविधा के लिए पैसे चुकाने होंगे? | आईपी पते की सुरक्षा की सुविधा, Chrome इस्तेमाल करने वाले लोगों के लिए ब्राउज़र के मुख्य अनुभव के तौर पर उपलब्ध होगी. यह सुविधा पैसे चुकाकर नहीं ली जा सकेगी. |
| प्रॉक्सी सर्वर | क्या उपयोगकर्ता के सेशन के दौरान, एक ही प्रॉक्सी सर्वर का इस्तेमाल किया जाएगा? | एचटीटीपी/एस कनेक्शन, प्रॉक्सी के एक जोड़े का इस्तेमाल करेगा और ऑरिजिन को एक मास्क किया गया आईपी पता दिखाएगा. इसके अलावा, अलग-अलग एचटीटीपी/एस कनेक्शन के लिए, एक ही सर्वर का इस्तेमाल करने की कोई ज़रूरी शर्त नहीं है. |
| प्लैटफ़ॉर्म से जुड़ी सहायता | आईपी पते की सुरक्षा की सुविधा किस प्लैटफ़ॉर्म पर काम करेगी? | आईपी सुरक्षा की सुविधा, शुरुआत में Android और डेस्कटॉप के लिए Chrome पर उपलब्ध होगी. हम इस बात का आकलन कर रहे हैं कि इस सुरक्षा को अन्य प्लैटफ़ॉर्म पर कैसे उपलब्ध कराया जा सकता है. |
| ऑप्ट-आउट करना | क्या उपयोगकर्ता, आईपी पते की सुरक्षा की सुविधा को बंद कर पाएंगे? | हम उपयोगकर्ताओं को यह विकल्प देने जा रहे हैं कि उन्हें आईपी प्रोटेक्शन का इस्तेमाल करना है या नहीं. |
| पहचान छिपाना | आईपी पते की सुरक्षा के तहत, किस तरह के अनुरोधों की पहचान छिपाई जाएगी? | ज़रूरी शर्तें पूरी करने वाले तीसरे पक्ष के डोमेन के लिए, एचटीटीपी/एस और डीएनएस अनुरोधों को निजता प्रोक्सी की मदद से गुमनाम किया जाता है. हम आने वाले समय में एक एक्सप्लेनेर में ज़्यादा जानकारी देंगे. इसमें हम यह तय करने का तरीका बताएंगे कि किन डोमेन को शामिल किया जाएगा. बाकी ट्रैफ़िक (उदाहरण के लिए, बाकी डीएनएस अनुरोध या अन्य एचटीटीपी/एस ट्रैफ़िक) पर इसका कोई असर नहीं पड़ता. |
| डेटा किसको दिखे | आईपी प्रोटेक्शन में पहले हॉप के दौरान, नेटवर्क पतों को ऐक्सेस किया जा सकता है. | दो-हॉप प्रॉक्सी मॉडल में, पहला हॉप (Google के कंट्रोल में) सिर्फ़ सोर्स क्लाइंट आईपी और दूसरे हॉप से कनेक्ट करने का अनुरोध देखता है. वहीं, दूसरा हॉप (बाहरी सीडीएन के कंट्रोल में) सिर्फ़ पहले हॉप (प्रॉक्सी आईपी + पोर्ट) और डेस्टिनेशन आईपी पर टुपल देखता है. ऑरिजिन से वापस आने वाले रिस्पॉन्स के लिए, दूसरा हॉप, रिस्पॉन्स को अनुरोध से जुड़े पहले हॉप प्रॉक्सी+पोर्ट पर फ़ॉरवर्ड कर सकता है. साथ ही, उसे ओरिजनल क्लाइंट आईपी के बारे में कुछ भी जानने की ज़रूरत नहीं है. पहला हॉप, डेस्टिनेशन आईपी के बारे में कुछ भी जाने बिना, क्लाइंट को सिर्फ़ रिस्पॉन्स दिखाता है. इस तरह, पहला होप सिर्फ़ क्लाइंट आईपी और दूसरा होप सीखता है, जबकि दूसरा होप सिर्फ़ डेस्टिनेशन आईपी सीखता है. |
| WebView | क्या आने वाले समय में, Android वेबव्यू के लिए आईपी पते की सुरक्षा की सुविधा उपलब्ध होगी? | फ़िलहाल, हमारे पास इस बारे में कोई जानकारी शेयर करने का कोई प्लान नहीं है. हालांकि, हमारा मकसद इस सुरक्षा को ज़्यादा से ज़्यादा लोगों को उपलब्ध कराना है. |
बाउंस ट्रैकिंग को कम करने की सुविधा
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| इंटरैक्शन ट्रैकिंग | उपयोगकर्ता के इंटरैक्शन को कैसे ट्रैक किया जाता है? | बाउंस ट्रैकिंग की क्षमता को कंट्रोल करने की सुविधा, उपयोगकर्ता के दो तरह के इंटरैक्शन को ट्रैक करती है:
ये इंटरैक्शन, उन पेजों पर मौजूद टॉप-लेवल साइट से जुड़े होते हैं जहां ये इंटरैक्शन होते हैं. उदाहरण के लिए, अगर कोई उपयोगकर्ता एम्बेड किए गए iframe पर क्लिक करता है, तो इंटरैक्शन टॉप-लेवल साइट से जुड़ा होता है, न कि एम्बेड की गई साइट से. इंटरैक्शन को एक डेटाबेस में सेव किया जाता है. इसमें स्कीमलेस etld+1 और इंटरैक्शन का समय शामिल होता है. इंटरैक्शन, उस डोमेन को 45 दिनों तक बाउंस ट्रैकिंग के कम करने वाले स्टेटस को मिटाने से बचाते हैं. |
| अनुमति वाली सूची में शामिल छूट | क्या डोमेन को छूट दी जा सकती है? | हम इस अनुरोध पर विचार कर रहे हैं. साथ ही, इकोसिस्टम से और सुझाव, राय या शिकायत का भी स्वागत करते हैं. |
प्राइवसी बजट
इस तिमाही में कोई सुझाव, राय या शिकायत नहीं मिली.
अलग-अलग साइटों पर निजता की सीमाओं को बेहतर बनाना
मिलती-जुलती वेबसाइट के सेट (पहले इन्हें फ़र्स्ट-पार्टी सेट कहा जाता था)
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| सेंट्रलाइज़्ड अप्रोच | मिलती-जुलती वेबसाइट के सेट मैनेज करने के लिए, एक ही जगह पर मौजूद डेटा स्टोर करने के तरीके को लेकर चिंता. | आरडब्ल्यूएस के डिज़ाइन के लिए, सार्वजनिक और आसानी से ऐक्सेस की जा सकने वाली रिपॉज़िटरी ज़रूरी है, क्योंकि इससे सबमिशन के लिए जवाबदेही तय की जा सकती है. तीसरे पक्ष की कुकी की सुविधा, Storage Access API या rSAFor API का इस्तेमाल करके दी जाती है. RWS की सदस्यता के साथ, ऐक्सेस अपने-आप मिल जाता है. यह सुविधा, Storage Access API के प्रॉम्प्ट के ज़रिए नहीं मिलती. हमें लगता है कि आरडब्ल्यूएस सबमिशन प्रोसेस जैसा तरीका, तीसरे पक्ष की कुकी के अपने-आप मिलने वाले ऐक्सेस के लिए सही ज़रूरी शर्त है. |
| JSON फ़ाइल का नाम बदलना | एपीआई के नाम में बदलाव होने के बाद, क्या होस्ट की गई JSON फ़ाइल का नाम बदलना होगा? | हां, सबमिशन के दिशा-निर्देश बदल गए हैं. साथ ही, प्राइमरी डोमेन को /.well-known/related-website-set.json पर JSON फ़ाइल दिखानी होगी. आरडब्ल्यूएस की सूची में मौजूद सेट में बदलाव करने की ज़रूरत नहीं है. हालांकि, अगर मौजूदा सेट में बदलाव सबमिट किए गए हैं, तो JSON फ़ाइल में बदलाव करना ज़रूरी है. |
| (पिछली तिमाहियों में भी रिपोर्ट की गई) डोमेन की सीमा | खाते से जुड़े डोमेन की संख्या बढ़ाने का अनुरोध करना | जैसा कि 31 अगस्त को एक ब्लॉग पोस्ट में बताया गया था, हमने एक ही खाते से मैनेज किए जा सकने वाले डोमेन की संख्या को बढ़ाकर पांच कर दिया है. ऐसा, नेटवर्क से मिले सुझावों और राय के आधार पर किया गया है. हमने एक प्राइमरी डोमेन के साथ पांच डोमेन जोड़ने का फ़ैसला लिया है. यह संख्या, किसी दूसरे बड़े ब्राउज़र के साथ तुलना करने पर सबसे सही है. |
| तीसरे पक्ष की कुकी | क्या मिलती-जुलती वेबसाइट के सेट, सिर्फ़ तीसरे पक्ष की कुकी बंद होने पर काम करेंगे? | मिलती-जुलती वेबसाइट के सेट तब भी काम करेंगे, जब उपयोगकर्ता ने तीसरे पक्ष की कुकी को ब्लॉक न किया हो. हालांकि, इसका कोई असर नहीं होगा, क्योंकि काम की कुकी, मिलती-जुलती वेबसाइट के सेट और स्टोरेज ऐक्सेस एपीआई के बिना भी उपलब्ध होती हैं. |
| मान्य बदलाव | मिलती-जुलती वेबसाइट के सेट का रिपॉज़िटरी, सेट में बदलाव करने से उन लोगों को कैसे रोकता है जिनके पास मालिकाना हक नहीं है? | सबमिट करने से जुड़ी गाइड के मुताबिक, first_party_sets.JSON फ़ाइल में बदलाव करने के लिए, कोई भी व्यक्ति GitHub पर एक पीआर सबमिट कर सकता है. हालांकि, अगर पीआर को मंज़ूरी मिल जाती है (तकनीकी पुष्टि वगैरह), तो Google हर हफ़्ते एक बार (ईस्टर्न समय के मुताबिक मंगलवार को दोपहर 12 बजे) कैननिकल एफ़पीएस सूची में, मैन्युअल तरीके से एक साथ कई पीआर को मर्ज कर देगा.अगर कोई नुकसान पहुंचाने वाला व्यक्ति या इकाई, किसी ऐसे सेट में बदलाव करने की कोशिश करता है जिसका मालिकाना हक उसके पास नहीं है, तो कोई समस्या नहीं होनी चाहिए. ऐसा इसलिए, क्योंकि वह .well-known फ़ाइलों में बदलाव नहीं कर पाएगा और इसलिए, पुष्टि नहीं हो पाएगी. |
| डोमेन हाइजैकिंग | डोमेन हाइजैकिंग की वजह से, उससे जुड़े डोमेन का डेटा बिना अनुमति वाले तीसरे पक्षों को दिख सकता है. | ऐसा नहीं किया जा सकता. इस बारे में सुरक्षित ऑडियंस से जुड़ी इस GitHub समस्या में बताया गया है. |
Fenced Frames API
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| कॉन्टेंट का उल्लंघन | उपयोगकर्ताओं को संदिग्ध विज्ञापनों की शिकायत करने की अनुमति दें. | फ़ेंस किए गए फ़्रेम की मदद से, संदिग्ध विज्ञापन की शिकायत को रोका नहीं जा सकता. उपयोगकर्ता अब भी विज्ञापन के साथ इंटरैक्ट कर सकते हैं और सामान्य तरीके से विज्ञापन टेक्नोलॉजी को संदिग्ध विज्ञापनों की शिकायत कर सकते हैं. |
| आस-पास की साइटों के साथ इंटरैक्शन | आस-पास या टॉप लेवल की वेबसाइट के साथ इंटरैक्ट करने की अनुमति दें. | हम यह समझने की कोशिश कर रहे हैं कि यह अनुरोध क्यों ज़रूरी है. साथ ही, हम इकोसिस्टम से और सुझाव/राय पाना चाहते हैं. |
| नेटिव विज्ञापन | नेटिव विज्ञापन के लिए फ़ेंस्ड फ़्रेम की सुविधा. | हम इस इस्तेमाल के उदाहरण को शामिल करने पर विचार कर रहे हैं. साथ ही, समस्या को हल करने के तरीकों और समाधानों पर चर्चा कर रहे हैं. |
Shared Storage API
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| क्रॉस-डोमेन | स्थानीय स्टोरेज के लिए, अलग-अलग डोमेन के बीच डेटा ट्रांसफ़र करने की अनुमति दें. | फ़िलहाल, इस इस्तेमाल के उदाहरण में, शेयर किए गए स्टोरेज के ऐसे आउटपुट गेट का इस्तेमाल नहीं किया जा सकता जो उपयोगकर्ता की निजता को बनाए रखते हैं. हालांकि, हम ज़्यादा जानकारी का स्वागत करते हैं, क्योंकि हम बिना सेक्शन वाले स्टोरेज के लिए सुझाव दे रहे हैं. |
| ब्लॉब का यूआरएल | शेयर किए गए स्टोरेज में ब्लॉब यूआरएल का इस्तेमाल करने की सुविधा जोड़ने का अनुरोध. | Chrome M116 में, ब्लॉब यूआरएल के लिए सहायता जोड़ी गई है. |
CHIPs
इस तिमाही में कोई सुझाव, राय या शिकायत नहीं मिली.
FedCM
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| तीसरे पक्ष की कुकी | क्या फ़िलहाल, Chrome की सेटिंग में "तीसरे पक्ष की कुकी ब्लॉक करें" को चालू करने पर, FedCM बंद हो जाता है? | हां, फ़िलहाल FedCM बंद है. जांच करने के लिए, हमारा सुझाव है कि आप chrome://flags/#fedcm- को भी चालू करें.हम आने वाले समय में, तीसरे पक्ष की कुकी के बिना FedCM की सुविधा उपलब्ध कराने की कोशिश कर रहे हैं. |
स्पैम और धोखाधड़ी को रोकना
Private State Token API (और अन्य एपीआई)
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| टोकन की समयसीमा खत्म होना | Google Chrome को अनइंस्टॉल करने के बाद, क्या टोकन मिट जाएगा या उसे कैश मेमोरी में सेव कर लिया जाएगा? | अगर उपयोगकर्ता Google Chrome को अनइंस्टॉल करता है, तो टोकन मिट जाएगा. |
| टोकन की जानकारी | जारी करने वाले पक्ष, निजी स्टेट टोकन में जारी की गई जानकारी को निजी कैसे रख सकते हैं? | जानकारी को हमेशा टोकन में निजी रखा जाता है. साथ ही, तीसरे पक्ष के ऐसे लोग जिन्हें पासकोड नहीं दिया गया है वे इसे डिक्रिप्ट नहीं कर सकते. |
| डेमो में गड़बड़ी | निजी स्टेटस टोकन का डेमो चलाने के दौरान गड़बड़ी. | हमने डेमो को अपडेट कर दिया है और अब यह सही तरीके से काम कर रहा है. |