साल 2025 की दूसरी तिमाही की रिपोर्ट. इसमें Privacy Sandbox के प्रस्तावों और Chrome के जवाबों के बारे में, नेटवर्क से जुड़े लोगों से मिले सुझाव, शिकायत या राय की खास जानकारी दी गई है.
Google ने यह तिमाही रिपोर्ट, पैराग्राफ़ 12, 17(c)(ii), और 32(a) के तहत, Competition and Markets Authority ('CMA') के लिए अपनी ज़िम्मेदारियों के तहत तैयार की है. इस रिपोर्ट में, Privacy Sandbox के सुझावों पर Google की प्रोग्रेस के बारे में बताया गया है. साथ ही, इसमें अपडेट किए गए टाइमलाइन के बारे में बताया गया है. इसमें यह भी बताया गया है कि Google ने तीसरे पक्षों की टिप्पणियों को कैसे ध्यान में रखा है. साथ ही, इसमें Google और सीएमए के बीच हुए इंटरैक्शन की खास जानकारी दी गई है. इसमें सीएमए से मिले सुझाव/राय/शिकायत और Google के सुझाव/राय/शिकायत को हल करने के तरीके के बारे में भी बताया गया है.
Google, सीएमए को Privacy Sandbox के प्रपोज़ल की प्रोग्रेस के बारे में अपडेट देता रहा है. इसके लिए, वह नियमित तौर पर स्टेटस मीटिंग करता है. ये मीटिंग, कमिटमेंट के पैराग्राफ़ 17(b) के मुताबिक शेड्यूल की जाती हैं. इसके अलावा, टीम डेवलपर के दस्तावेज़ का रखरखाव करती है. इसमें निजता बनाए रखकर विज्ञापन दिखाने की मुख्य सुविधाओं और कुकी में हुए बदलावों के बारे में खास जानकारी दी गई है. साथ ही, एपीआई लागू करने और स्टेटस की जानकारी भी दी गई है. अहम अपडेट, डेवलपर ब्लॉग पर शेयर किए जाते हैं. साथ ही, टारगेट किए गए अपडेट, डेवलपर की ईमेल पाने वाले लोगों की अलग-अलग सूचियों के साथ शेयर किए जाते हैं.
तीसरे पक्षों की टिप्पणियों को ध्यान में रखकर
शॉर्ट फ़ॉर्म की शब्दावली
- एआरए
- Attribution Reporting API
- सीएचआईपीएस
- कुकीज़ हैविंग इंडिपेंडेंट पार्टिशन्ड स्टेट
- डीएसपी
- डिमांड-साइड प्लैटफ़ॉर्म
- FedCM
- Federated Credential Management
- IAB
- Interactive Advertising Bureau
- IDP
- पहचान देने वाली सेवा
- आईईटीएफ़
- इंटरनेट इंजीनियरिंग टास्क फ़ोर्स
- आईपी
- इंटरनेट प्रोटोकॉल पता
- openRTB
- रीयल-टाइम बिडिंग
- OT
- ऑरिजिन ट्रायल
- PA API
- Protected Audience API (पहले इसे FLEDGE के नाम से जाना जाता था)
- PatCG
- विज्ञापन टेक्नोलॉजी से जुड़ी प्राइवेट कम्यूनिटी ग्रुप
- आरपी
- Relying Party
- RWS
- Related Website Sets (पहले इन्हें First-Party Sets कहा जाता था)
- एसएसपी
- सप्लाई-साइड प्लैटफ़ॉर्म
- UA
- यूज़र एजेंट स्ट्रिंग
- UA-CH
- User-Agent Client Hints
- W3C
- वर्ल्ड वाइड वेब कंसोर्टियम
- WIPB
- जान-बूझकर आईपी पते की जानकारी छिपाना
सामान्य सुझाव/राय/शिकायत, किसी खास एपीआई/टेक्नोलॉजी के बारे में नहीं
| फ़ीडबैक की थीम | खास जानकारी | Chrome Response |
|---|---|---|
| Privacy Sandbox का आने वाला समय | उपयोगकर्ता को तीसरे पक्ष की कुकी (3PC) के लिए विकल्प चुनने की सुविधा उपलब्ध न कराने के एलान के बाद, कुछ एपीआई तब ज़्यादा काम के होते हैं, जब 3PC मौजूद हों. वहीं, कुछ एपीआई को ज़्यादा काम का बनाने के लिए, उनमें बदलाव करने की ज़रूरत होगी. Privacy Sandbox API के अलावा, Chrome में निवेश करने के लिए अन्य संभावित क्षेत्र भी हैं. | हम आपके सुझाव/राय/शिकायत की सराहना करते हैं. हम हितधारकों के साथ मिलकर काम कर रहे हैं, ताकि यह आकलन किया जा सके कि आने वाले समय में Privacy Sandbox API की क्या भूमिका हो सकती है. साथ ही, हम आने वाले समय में निवेश के लिए नए क्षेत्रों का पता लगा रहे हैं. ऐसा Google के अप्रैल 2025 के उस एलान के बाद किया जा रहा है जिसमें कहा गया था कि Chrome में उपयोगकर्ताओं को 3PC चुनने का विकल्प देने का मौजूदा तरीका जारी रहेगा. |
| Privacy Sandbox | इकोसिस्टम में शामिल कुछ लोगों या कंपनियों को इस बात से निराशा हुई है कि 3PC के लिए, उपयोगकर्ता की पसंद के मुताबिक काम करने वाले सिस्टम को लागू नहीं किया जाएगा. हालांकि, उन्हें इस बात पर गर्व है कि उन्होंने इस दिशा में काम किया. उन्होंने Privacy Sandbox से जुड़ी तकनीकी चुनौतियों की सराहना की. साथ ही, Chrome के साथ मिलकर काम करने के फ़ायदे और मार्केट टेस्टिंग ग्रांट की अहमियत पर ज़ोर दिया. | हम आपके सुझावों के लिए आपका धन्यवाद करते हैं. हम इस बात से सहमत हैं कि Chrome, डेवलपर के साथ मिलकर ऐसी टेक्नोलॉजी बना सकता है जिससे ऑनलाइन निजता को बेहतर बनाया जा सके. साथ ही, विज्ञापन दिखाने की सुविधा वाले इंटरनेट को सुरक्षित रखा जा सके. |
| ब्राउज़र का डेटा शेयर करना | ब्राउज़र की मदद से डेटा शेयर करने की सुविधा, एक बेहतरीन टेक्नोलॉजी है. इसमें बाज़ार की कमियों और भरोसे से जुड़ी समस्याओं को हल करने की क्षमता है. ब्राउज़र, तीसरे पक्ष के एक्ज़ीक्यूशन कॉन्टेक्स्ट के तौर पर काम करता है, ताकि सहयोग किया जा सके. | हम आपके सुझावों के लिए आपका धन्यवाद करते हैं. हम इस बात से सहमत हैं कि Chrome, डेवलपर को ऐसी टेक्नोलॉजी बनाने में मदद कर सकता है जिससे डेवलपर और उपयोगकर्ताओं के बीच भरोसा बढ़े. |
| Chrome का ट्रैफ़िक | Chrome पर कुकी रहित ट्रैफ़िक का हिस्सा कितना है और गुप्त मोड के लिए ट्रैफ़िक का हिस्सा कितना है? | सीएमए ने "कमिटमेंट रिलीज़ करने के इरादे की सूचना" में बताया है कि गुप्त मोड का असर, ब्राउज़िंग गतिविधि के बहुत छोटे हिस्से पर पड़ता है. यूनाइटेड किंगडम और ईईए में, Chrome के गुप्त मोड में ब्राउज़िंग करने वाले लोगों की संख्या: Android ऑपरेटिंग सिस्टम पर काम करने वाले डिवाइसों पर, 10% से कम है. साथ ही, Windows ऑपरेटिंग सिस्टम पर काम करने वाले डिवाइसों पर, 10% से कम है.
ये मेट्रिक, सिर्फ़ यूके और ईईए में Chromium पर आधारित Chrome पर किए गए नेविगेशन से जुड़ी हैं. हम उन ब्राउज़र का डेटा शेयर नहीं करते जो तीसरे पक्ष की कुकी को ब्लॉक करते हैं. डेवलपर यह तय कर सकते हैं कि कुकी को कब बांटा जाए. इसके लिए, वे Storage Access Headers का इस्तेमाल कर सकते हैं. साथ ही, उपलब्ध शमन तकनीकों का इस्तेमाल कर सकते हैं. |
| Chrome Testing के लेबल | Chrome का, कुकी रहित 1% ट्रैफ़िक के लिए क्या प्लान है? इस ट्रैफ़िक को 2024 में टेस्टिंग के लिए चालू किया गया था. | फ़िलहाल, हमारे पास शेयर करने के लिए कोई प्लान नहीं है. हालांकि, उपलब्ध होने पर हम उन्हें सार्वजनिक तौर पर शेयर करेंगे. |
| Chrome Testing | क्या मौजूदा टेस्टिंग लेबल सेटअप में, उन स्थितियों के लिए कोई ट्रीटमेंट शामिल है जहां तीसरे पक्ष की दोनों कुकी उपलब्ध हैं और Privacy Sandbox API चालू हैं? | फ़िलहाल, टेस्टिंग लेबल सेटअप में मोड A के तौर पर, तीसरे पक्ष की कुकी और Privacy Sandbox API, दोनों के लिए ट्रीटमेंट शामिल है. |
| Privacy Sandbox | विज्ञापन देने वाले कुछ लोगों या कंपनियों को Privacy Sandbox API जटिल लगते हैं. साथ ही, वे पहले से ही तैयारी कर चुके हैं, इसलिए उन्हें अब इसमें दिलचस्पी नहीं है. वे यह जानना चाहती हैं कि शुरुआती तौर पर इसे अपनाने वालों को क्या फ़ायदा मिलेगा. इसके अलावा, वे रीमार्केटिंग, संभावित ग्राहकों को टारगेट करने, और मेज़रमेंट के असर के बारे में जानकारी पाना चाहती हैं. | हमें आपके सुझाव/राय मिली हैं. हम टेक्नोलॉजी से जुड़ी जटिलताओं और तैयारी से जुड़ी गतिविधियों के बारे में आपकी भावनाओं को समझते हैं. Privacy Sandbox की मौजूदा टेक्नोलॉजी की परफ़ॉर्मेंस को समझने के लिए, हमारी टेस्टिंग के नतीजों से पता चला कि Privacy Sandbox के समाधानों की परफ़ॉर्मेंस को समझने के लिए, इकोसिस्टम में हिस्सेदारी करना एक अहम फ़ैक्टर है. कम वॉल्यूम पर टेस्टिंग करने से, मार्केटप्लेस की डाइनैमिक और बड़े पैमाने पर टेक्नोलॉजी का इस्तेमाल करने के इंसेंटिव को फिर से नहीं बनाया जा सका. |
रजिस्ट्रेशन और पुष्टि करना
इस तिमाही में कोई सुझाव, राय या शिकायत नहीं मिली.
काम का कॉन्टेंट और विज्ञापन दिखाना
विषय
| फ़ीडबैक की थीम | खास जानकारी | Chrome Response |
|---|---|---|
| Topics API की परफ़ॉर्मेंस और फ़ायदे से जुड़ी दिलचस्पी के बारे में जानकारी देने वाला दस्तावेज़ | बाय-साइड के स्टेकहोल्डर से मिले सुझावों के मुताबिक, Topics API एक अहम सिग्नल है. साथ ही, इससे विज्ञापन देने वाले व्यक्ति या कंपनी के कैंपेन के लिए, इंप्रेशन के हिसाब से लागत (सीपीएम) का ऐसा डेटा मिलता है जो 3PC ऑडियंस के लिए उपलब्ध डेटा की तुलना में बेहतर होता है. कुछ पब्लिशर, Topics API के सिग्नल को स्टैंडर्ड ओपन वेब सिग्नल की तुलना में ज़्यादा बेहतर मानते हैं. Topics API के इस्तेमाल से जुड़े इस सुझाव, राय या शिकायत के आधार पर, हितधारक इसमें सुधार करने का अनुरोध कर रहे हैं. जैसे, टैक्सोनॉमी की फ़िडेलिटी और एकरूपता को बेहतर बनाना. साथ ही, ज़्यादा से ज़्यादा लोगों तक पहुंचने के लिए, पब्लिशर के कंट्रोल को बढ़ाना. | हम इस सुझाव पर विचार कर रहे हैं. हम यह भी आकलन कर रहे हैं कि आने वाले समय में Privacy Sandbox API की क्या भूमिका होगी. ऐसा इसलिए, क्योंकि Google ने अप्रैल 2025 में यह एलान किया है कि Chrome में उपयोगकर्ताओं को 3PC चुनने का मौजूदा तरीका जारी रहेगा. |
| अलग-अलग तरह के हितधारकों के लिए फ़ायदेमंद होना |
फ़िलहाल, विषयों को कैटगरी में बांटने वाला क्लासिफ़ायर, विषयों को तय करने के लिए सिर्फ़ पेज के होस्टनेम का इस्तेमाल करता है. इसलिए, अलग-अलग तरह के कॉन्टेंट वाली बड़ी साइटें सामान्य विषयों में योगदान दे रही हैं, जबकि छोटी साइटें ज़्यादा विज्ञापन वैल्यू वाले खास विषयों में योगदान दे रही हैं. | हमारा जवाब पिछले क्वार्टर जैसा ही है: 3PC की तरह ही, अलग-अलग साइटों से मिली जानकारी की वैल्यू में अंतर होता है. खास दिलचस्पी वाली साइटों से मिलने वाली वैल्यू में उतार-चढ़ाव होता रहता है: ऐसा इसलिए, क्योंकि सभी खास दिलचस्पी वाली साइटों पर व्यावसायिक रूप से अहम कॉन्टेंट नहीं होता. इसलिए, इनसे कम वैल्यू मिलती है. ये वे साइटें हैं जिन्हें Topics API से फ़ायदा मिलेगा. हमने साइट-लेवल के बजाय पेज-लेवल पर क्लासिफ़िकेशन करने की संभावना पर विचार किया है. हालांकि, इस तरह के क्लासिफ़िकेशन में निजता और सुरक्षा से जुड़ी कई गंभीर समस्याएं हैं. |
| विषयों के हिसाब से टैक्सोनॉमी को ज़्यादा बारीकी से नहीं बांटा गया है | Topics API, समाचार पब्लिश करने वाली ऐसी कंपनियों के लिए ज़्यादा जानकारी नहीं देता जिनके पास एक ही डोमेन में अलग-अलग कॉन्टेंट सेक्शन होते हैं. इससे विज्ञापन टारगेटिंग के लिए, API के फ़ायदे सीमित हो सकते हैं. | हम इस सुझाव पर विचार कर रहे हैं. हम यह भी आकलन कर रहे हैं कि आने वाले समय में Privacy Sandbox API की क्या भूमिका होगी. ऐसा इसलिए, क्योंकि Google ने अप्रैल 2025 में यह एलान किया है कि Chrome में उपयोगकर्ताओं को 3PC चुनने का मौजूदा तरीका जारी रहेगा. |
| क्लासिफ़ायर में सुधार | इस कुकी की मदद से पब्लिशर, Chrome को यह अनुमति दे सकते हैं कि वह पेज के कॉन्टेंट (जैसे, हेड, बॉडी) के आधार पर विषयों को कैटगरी में बांट सके. | हम इस अनुरोध पर विचार कर रहे हैं. अगर आपको कोई और सुझाव/राय देनी है या शिकायत करनी है, तो यहां क्लिक करें. |
| नीति | Topics API के साथ 3PC की जानकारी का इस्तेमाल करने से जुड़े दिशा-निर्देशों के बारे में ज़्यादा जानकारी पाने का अनुरोध. | Topics API और तीसरे पक्ष की कुकी, दोनों का इस्तेमाल करने में कोई समस्या नहीं होती. ऐसा इसलिए, क्योंकि Topics API, तीसरे पक्ष की कुकी की कुछ सुविधाएं उपलब्ध कराता है. |
| Observe-Browse-Topics हेडर | Observe-Browse-Topics हेडर को लागू करने के बारे में ज़्यादा जानकारी पाने का अनुरोध करना. खास तौर पर, यह जानना कि हेडर को लगातार वापस भेजने से समस्याएं होंगी या नहीं. | Observe-Browse-Topics: ?1
हेडर को लगातार वापस भेजने से, कोई तकनीकी समस्या नहीं आएगी.ब्राउज़र इस सिग्नल को आसानी से हैंडल करता है. इसमें सिर्फ़ यह नोट किया जाता है कि पेज पर आने वाले व्यक्ति की विज़िट, विषय के हिसाब से कैलकुलेशन करने की ज़रूरी शर्तें पूरी करती है. इससे डुप्लीकेट या गड़बड़ियां नहीं होती हैं. इसे हर पेज पर भेजना ज़रूरी नहीं है. हालांकि, इसे सभी टॉप-लेवल के दस्तावेज़ों पर स्टैंडर्ड हेडर के तौर पर भेजना एक मान्य और आसान तरीका है. |
| टैक्सोनॉमी कैटगरी | नए विषयों के साथ, Topics की नई टैक्सोनॉमी को अपडेट करने का अनुरोध करें. | हम इस अनुरोध पर विचार कर रहे हैं. साथ ही, हम इस इकोसिस्टम से जुड़े लोगों के सुझाव/राय/शिकायत यहां स्वीकार करते हैं. |
| शून्य वैल्यू | Topics API की परफ़ॉर्मेंस को बेहतर बनाने के बारे में दिशा-निर्देश पाने का अनुरोध करें. साथ ही, शून्य जवाब मिलने की वजहों को समझने का अनुरोध करें. जैसे, फ़िल्टर करना या संवेदनशील जानकारी. | जानकारी के लिए बता दें कि Topics API से null या खाली जवाब मिलना, निजता से जुड़ी एक सुविधा है. यह कोई गड़बड़ी नहीं है.null जवाब इन वजहों से मिल सकता है:• निजता के नियम: null मिलने की 5% संभावना होती है. इसके अलावा, ऐसा इसलिए भी हो सकता है, क्योंकि आपकी स्क्रिप्ट ने उस विषय से जुड़ी साइटों पर उपयोगकर्ता की गतिविधि को "ऑब्ज़र्व" नहीं किया है.• उपयोगकर्ता की स्थिति: ब्राउज़िंग इतिहास काफ़ी नहीं है, गुप्त मोड का इस्तेमाल किया जा रहा है या उपयोगकर्ता ने Chrome की विज्ञापन निजता सेटिंग में ऑप्ट आउट किया है. • तकनीकी गड़बड़ियां: पब्लिशर साइटों को Observe-Browse-Topics: ?1 हेडर भेजना होगा. साथ ही, कॉल करने वाले किसी भी iframe के लिए allow="Browse-topics" अनुमति ज़रूरी है.इसकी जांच करने के लिए, chrome://topics-internals डीबग करने वाले पेज का इस्तेमाल करें. इससे आपको यह पता चलेगा कि आपके ब्राउज़र ने किन विषयों का हिसाब लगाया है और क्यों.निजता से जुड़ी सुविधाओं की वजह से, विज्ञापन इन्वेंट्री के 100% हिस्से पर विज्ञापन नहीं दिखाए जा सकते. हालांकि, इन तरीकों से परफ़ॉर्मेंस को बेहतर बनाया जा सकता है: • पब्लिशर के साथ काम करना: पक्का करें कि आपके पार्टनर, अपनी साइटों पर Observe-Browse-Topics: ?1 हेडर को सही तरीके से भेज रहे हों.• अपने कोड की पुष्टि करना: अगर iframes का इस्तेमाल किया जाता है, तो पुष्टि करें कि allow="Browse-topics" नीति लागू है. |
Protected Audience API
| फ़ीडबैक की थीम | खास जानकारी | Chrome Response |
|---|---|---|
| PA API को अपनाने में लागत और जटिलता की वजह से रुकावटें आ रही हैं | विज्ञापन देने वाले लोग या कंपनियां, Protected Audience API (PA API) इंटिग्रेशन को प्राथमिकता नहीं दे रही हैं या उन्हें वापस ले रही हैं. इसकी वजहें ये हैं: ऑपरेशनल लागत, विज्ञापन देने वाले लोगों या कंपनियों की मांग में कमी, और एक्सचेंज से इन्वेंट्री की कम मात्रा. कुछ लोगों ने PA API के फ़ायदों के बारे में बताया. जैसे, इसकी मदद से लंबे समय तक जुड़े रहने वाली ऑडियंस को टारगेट किया जा सकता है. साथ ही, मैच रेट ज़्यादा होने की वजह से, ज़्यादा लोगों तक पहुंचा जा सकता है. |
हम इस सुझाव पर विचार कर रहे हैं. हम यह भी आकलन कर रहे हैं कि आने वाले समय में Privacy Sandbox API की क्या भूमिका होगी. ऐसा इसलिए, क्योंकि Google ने अप्रैल 2025 में यह एलान किया है कि Chrome में उपयोगकर्ताओं को 3PC चुनने का मौजूदा तरीका जारी रहेगा. |
| क्रॉस-प्लैटफ़ॉर्म पर काम करने की सुविधा | क्रॉस-प्लैटफ़ॉर्म पर काम करने की सुविधा होनी चाहिए. इसके लिए, सभी प्लैटफ़ॉर्म पर PA API का इस्तेमाल किया जाना चाहिए, ताकि ज़्यादा रीटारगेटिंग और ऑडियंस टारगेटिंग की सुविधाएँ अनलॉक की जा सकें. Google को Chrome में रजिस्टर किए गए दिलचस्पी वाले ग्रुप (आईजी) को, नेटिव एनवायरमेंट या वेबव्यू में विज्ञापन दिखाने के दौरान ऐक्सेस करने की अनुमति देनी चाहिए. साथ ही, Android में रजिस्टर किए गए दिलचस्पी वाले ग्रुप, Chrome की नीलामी में उपलब्ध होने चाहिए. | हम इस सुझाव पर विचार कर रहे हैं. हम यह भी आकलन कर रहे हैं कि आने वाले समय में Privacy Sandbox API की क्या भूमिका होगी. ऐसा इसलिए, क्योंकि Google ने अप्रैल 2025 में यह एलान किया है कि Chrome में उपयोगकर्ताओं को 3PC चुनने का मौजूदा तरीका जारी रहेगा. |
| directFromSellerSignals | सदर्भ के हिसाब से होने वाली नीलामी में सीमित जानकारी उपलब्ध कराने से, नीलामी में हिस्सा लेने वाले लोगों को हमेशा Google के विज्ञापन सर्वर के ज़रिए रूट किया जाता है. पब्लिशर को सबसे पहले अपने सभी एक्सचेंज पार्टनर को कॉल करना होगा. इसके बाद, कॉन्टेक्स्ट के हिसाब से नीलामी करने के लिए, Google Ad Manager (GAM) को कॉल करना होगा. आखिर में, GAM को आईजी की नीलामियां शुरू करने की अनुमति देनी होगी. कॉन्टेक्स्ट के हिसाब से होने वाली नीलामी के नतीजे के बारे में रीयल टाइम में जानकारी न होने पर, कोई भी प्रतिस्पर्धी कंपनी सही तरीके से टॉप-लेवल का फ़ैसला नहीं ले सकती. PA API में मौजूद directFromSellerSignals सुविधा, नीलामी की जानकारी के बारे में पारदर्शिता नहीं रखती है. इससे ज़रूरी डेटा को ऐक्सेस करने में समस्या आ सकती है. Google को DirectFromSellerSignals को हटाना चाहिए या उसे अपडेट करना चाहिए, ताकि इसका इस्तेमाल विज्ञापन सर्वर की नीलामी जीतने वाले व्यक्ति या कंपनी की कीमत को छिपाने के लिए न किया जा सके. उदाहरण के लिए, कॉन्टेक्स्ट के हिसाब से तय की गई कीमत को Chrome के ज़रिए पास किया जा सकता है. इसके लिए, पारदर्शी, न बदलने वाला, और हस्ताक्षर किया गया फ़ील्ड इस्तेमाल किया जाता है. इस फ़ील्ड को नीलामी में हिस्सा लेने वाले सभी लोग और पब्लिशर ऐक्सेस कर सकते हैं और इसकी पुष्टि कर सकते हैं. |
पिछले क्वार्टर की तरह, इस बार भी हमारा जवाब यही है: Chrome का जवाब: runAdAuction() में पास की गई जानकारी, सेलर से नहीं मिलती. ऐसा तब तक होता है, जब तक सेलर अपने iframe से runAdAuction() को कॉल नहीं करता. एक से ज़्यादा सेलर वाली नीलामी में, सभी सेलर के लिए runAdAuction() को कॉल करने वाला फ़्रेम बनाना मुमकिन नहीं होता. directFromSellerSignals ने इस समस्या को हल किया. इसके लिए, उसने सेलर के ऑरिजिन से लोड किए गए सब-रिसोर्स बंडल से कॉन्टेंट लोड किया. इससे यह पक्का होता है कि सेलर-ऑक्शन कॉन्फ़िगरेशन से नीलामी में भेजी गई जानकारी की पुष्टि की जा सकती है और उसमें कोई बदलाव नहीं किया जा सकता. अगर पब्लिशर को PA API का इस्तेमाल करके, यह समझना है कि टेक्नोलॉजी सेवा देने वाली कंपनियां, PA ऑक्शन में कौनसी जानकारी पास कर रही हैं, तो वे टेक्नोलॉजी सेवा देने वाली कंपनियों से इस सुविधा के बारे में पूछ सकते हैं. Google Ad Manager का जवाब: हम सालों से नीलामी को निष्पक्ष बनाने पर पूरा ध्यान दे रहे हैं. इसमें हमारा यह वादा भी शामिल है कि पब्लिशर के किसी भी नॉन-गारंटीड विज्ञापन सोर्स से मिली कीमत, किसी दूसरे खरीदार के साथ शेयर नहीं की जाएगी. इसमें नॉन-गारंटीड लाइन आइटम की कीमतें भी शामिल हैं. ऐसा तब तक किया जाएगा, जब तक वह खरीदार नीलामी में बिड नहीं कर लेता. हमने बाद में फ़्रांस की प्रतिस्पर्धा संस्था से किए गए अपने वादों में भी इस बात की पुष्टि की थी. Protected Audience से जुड़ी नीलामियों के लिए, हम अपना वादा निभाना चाहते हैं. इसके लिए, हम directFromSellerSignals का इस्तेमाल करेंगे. साथ ही, कई सेलर वाली नीलामियों में, नीलामी में हिस्सा लेने वाले किसी भी व्यक्ति या कंपनी की बिड को, नीलामी में हिस्सा लेने वाले किसी दूसरे व्यक्ति या कंपनी के साथ शेयर नहीं करेंगे. ऐसा तब तक किया जाएगा, जब तक नीलामी पूरी नहीं हो जाती. हम कॉन्टेक्स्ट के हिसाब से होने वाली नीलामी की कीमत को अपनी कॉम्पोनेंट नीलामी के साथ भी शेयर नहीं करेंगे. इस बारे में इस अपडेट में बताया गया है. |
| रिपोर्टिंग | सेंट्रलाइज़्ड रिपोर्टिंग की सुविधा चालू करने के लिए, Analytics/रिपोर्टिंग इकाई जोड़ने का अनुरोध करें. | हम इस अनुरोध के बारे में यहां चर्चा कर रहे हैं. अगर आपके पास कोई सुझाव/राय/शिकायत है, तो हमें बताएं. |
| buyerReportingId पर K-Anonymity | ऑडियंस को मैनेज करने और तीसरे पक्ष के डेटा उपलब्ध कराने वाली कंपनियों के साथ रिपोर्टिंग से जुड़ी ज़िम्मेदारियों को पूरा करने के लिए, "buyerReportingId" की के-एनोनिमिटी के आधार पर बिड खारिज करने की सुविधा. | हम इस सुझाव पर विचार कर रहे हैं. हम यह भी आकलन कर रहे हैं कि आने वाले समय में Privacy Sandbox API की क्या भूमिका होगी. ऐसा इसलिए, क्योंकि Google ने अप्रैल 2025 में यह एलान किया है कि Chrome में उपयोगकर्ताओं को 3PC चुनने का मौजूदा तरीका जारी रहेगा. |
| generateBid स्क्रिप्ट में डीबग करने की बेहतर सुविधा | जनरेटबिड स्क्रिप्ट में, उस खास स्टेज या "ब्रेकपॉइंट" का पता लगाने के लिए एक ऐसे तरीके का अनुरोध करना जहां प्रोसेस पूरी नहीं हो रही है. | हमें पता है कि डिवाइस पर होने वाली नीलामियों के लिए, ब्रेकपॉइंट-सेटिंग के तरीके के तौर पर रीयल-टाइम मेज़रमेंट का इस्तेमाल किया जाता है. हम इस सुझाव पर विचार कर रहे हैं. साथ ही, हम यह भी आकलन कर रहे हैं कि आने वाले समय में Privacy Sandbox APIs की क्या भूमिका होगी. ऐसा इसलिए, क्योंकि Google ने अप्रैल 2025 में यह एलान किया था कि Chrome में उपयोगकर्ताओं को 3PC चुनने का मौजूदा तरीका जारी रहेगा. |
| runAdAuction की स्थिति पर नज़र रखने के लिए इवेंट लिसनर | PA API के navigator.runAdAuction फ़ंक्शन में इवेंट लिसनर की सुविधा जोड़ने का सुझाव, ताकि विज्ञापन नीलामी के लाइफ़साइकल की बेहतर निगरानी की जा सके. | हम इस अनुरोध की समीक्षा कर रहे हैं. साथ ही, हम चाहते हैं कि इस इकोसिस्टम से जुड़े लोग यहां अपने सुझाव, राय भेजें या शिकायत करें. |
| एपीआई प्रयोग | अनुरोध: कृपया बताएं कि तीसरे पक्ष की कुकी के बिना, पीए एपीआई और एट्रिब्यूशन रिपोर्टिंग एपीआई (एआरए) वेब विज्ञापन के इस्तेमाल के उदाहरणों में कैसे मदद कर सकते हैं. खास तौर पर, उन उपयोगकर्ताओं के लिए जिन्होंने तीसरे पक्ष की कुकी से ऑप्ट आउट किया है, लेकिन Privacy Sandbox API से ऑप्ट आउट नहीं किया है. साथ ही, उन स्थितियों में भी मदद कर सकते हैं जिनमें कुकी सिंक नहीं हो पाती हैं और WebView का इस्तेमाल किया जाता है? | हम इस सुझाव पर विचार कर रहे हैं. हम यह भी आकलन कर रहे हैं कि आने वाले समय में Privacy Sandbox API की क्या भूमिका होगी. ऐसा इसलिए, क्योंकि Google ने अप्रैल 2025 में यह एलान किया है कि Chrome में उपयोगकर्ताओं को 3PC चुनने का मौजूदा तरीका जारी रहेगा. |
| इंतज़ार का समय | PA API से जुड़ी लेटेन्सी की वजह से, इसे अपनाने में समस्या आ सकती है. ऐसा इसलिए, क्योंकि अगर लेटेन्सी बहुत ज़्यादा है, तो पब्लिशर PA API को बंद कर सकते हैं. | पिछले कुछ तिमाहियों में, डिवाइस पर होने वाली प्रोसेसिंग में लगने वाले समय को कम करने के लिए कई सुधार किए गए हैं. बिडिंग और नीलामी (बीऐंडए) से जुड़ी सेवाओं को बनाने और उन्हें बड़े पैमाने पर उपलब्ध कराने का काम जारी रहेगा. लेटेंसी कम करने के सबसे सही तरीकों से जुड़ी हमारी गाइड को अपडेट किया गया है. इसमें इन सुविधाओं का फ़ायदा पाने के तरीके के बारे में ज़्यादा जानकारी शामिल की गई है. हम लेटेन्सी को कम करने के लिए नए तरीके भी ढूंढ रहे हैं. इनमें से कुछ के बारे में यहां देखा जा सकता है. |
| B&A में लॉगिंग का तरीका (टेस्ट बनाम प्रोडक्शन) | B&A सेवाओं के लिए, टेस्ट और प्रोडक्शन मोड के बीच लॉगिंग के तरीके में अंतर के बारे में जानकारी. खास तौर पर, क्लाउड लॉग की उपलब्धता और प्रोडक्शन मोड का लॉगिंग पर असर. | सबसे पहले, prod vs. non_prod बिल्ड और अलग TEST_MODE पैरामीटर के बीच अंतर करना ज़रूरी है. यह पैरामीटर, हार्डकोड की गई टेस्ट एन्क्रिप्शन कुंजी को चालू करता है. यहां दी गई जानकारी में, बिल्ड टाइप पर फ़ोकस किया गया है. non_prod builds में, B&A सर्वर में लॉगिंग के लिए, वर्बोसिटी लेवल को कॉन्फ़िगर करने की सुविधा होती है. ज़्यादा जानकारी वाले ये लॉग, स्टैंडर्ड stdout/stderr स्ट्रीम में लिखे जाते हैं. Google Cloud पर, इन्हें नेटिव लॉगिंग इंटरफ़ेस के ज़रिए ऐक्सेस किया जा सकता है. वहीं, Amazon Web Services पर, ये अटैच किए गए कंसोल लॉग में मिल सकते हैं. प्रोडक्शन बिल्ड के लिए, लॉगिंग का व्यवहार ज़्यादा पाबंदियों वाला होता है. वर्बोसिटी लेवल तय होता है और इसे बदला नहीं जा सकता. हालांकि, निजता से जुड़े कुछ लॉग अब भी stdout/stderr पर प्रिंट किए जाते हैं. जैसे, सर्वर स्टार्टअप मैसेज और क्रैश से जुड़ी ज़्यादातर गड़बड़ियां. हालांकि, इस चैनल के ज़रिए अनुरोध से जुड़े कोई भी लॉग उपलब्ध नहीं हैं. प्रोडक्शन बिल्ड से, अनुरोध के हिसाब से सिर्फ़ उन लॉग को इकट्ठा किया जाता है जिनमें सहमति वाला डीबग टोकन शामिल होता है. इन्हें सिर्फ़ OpenTelemetry के ज़रिए एक्सपोर्ट किया जाता है. सहमति लेकर डीबग करने की सुविधा का इस्तेमाल कम करें. ऐसा इसलिए, क्योंकि ज़्यादा ट्रैफ़िक की वजह से सर्वर की परफ़ॉर्मेंस खराब हो सकती है. साथ ही, इससे हेल्थ-चेक की प्रोसेस पूरी नहीं हो पाती. मेट्रिक के बारे में जानकारी: सभी मेट्रिक, OpenTelemetry के ज़रिए एक्सपोर्ट की जाती हैं. निजता के लिहाज़ से संवेदनशील न मानी जाने वाली मेट्रिक हमेशा बिना किसी बदलाव के एक्सपोर्ट की जाती हैं. इनमें "नोइज़िंग" नहीं की जाती. इसके उलट, निजता के लिहाज़ से संवेदनशील मेट्रिक को प्रॉड मोड में चल रहे सर्वर से एक्सपोर्ट करते समय, हमेशा "नोइज़" किया जाता है. टेलीमेट्री का कॉन्फ़िगरेशन तय करता है कि निजता के लिहाज़ से संवेदनशील मेट्रिक को नॉइज़ के साथ, बिना नॉइज़ के या दोनों तरह से एक्सपोर्ट किया जाए. |
| ब्रैंड सुरक्षा के लिए, भरोसेमंद बिडिंग सिग्नल में पूरे पेज का पाथ शामिल करना | PA API को अपडेट करने का अनुरोध, ताकि भरोसेमंद बिडिंग सिग्नल के लिए फ़ेच अनुरोध में, होस्टनेम के साथ-साथ टॉप-लेवल पेज का पूरा यूआरएल पाथ भी शामिल किया जा सके. इसका मुख्य इस्तेमाल, ब्रैंड सुरक्षा से जुड़े ज़्यादा कंट्रोल चालू करना है. विज्ञापन देने वाले लोगों या कंपनियों को अक्सर किसी डोमेन के कुछ सेक्शन (जैसे, news-site.com/politics) पर विज्ञापन दिखाने से रोकना होता है. हालांकि, उन्हें आम तौर पर डोमेन से कोई समस्या नहीं होती. इन ब्लॉकलिस्ट में लाखों एंट्री हो सकती हैं. इसलिए, इनका आकलन सर्वर-साइड पर किया जाना चाहिए. मौजूदा स्पेसिफ़िकेशन सिर्फ़ होस्टनेम भेजता है. इसलिए, trustedBiddingSignals सर्वर के लिए, पाथ-लेवल का ज़रूरी आकलन करना मुमकिन नहीं है. इससे ब्रैंड सुरक्षा की क्षमताओं पर असर पड़ता है. |
हम इस समस्या पर फ़िलहाल यहां चर्चा कर रहे हैं. इससे पहले, हमने इस पर काफ़ी चर्चा की थी. इसके बारे में यहां पढ़ा जा सकता है. हम आपके सुझावों का स्वागत करते हैं. हालांकि, हम यह साफ़ तौर पर बताना चाहते हैं कि हम इस जानकारी को सिर्फ़ तब जोड़ेंगे, जब trustedBiddingSignals फ़ेच, ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) में चल रहे सर्वर पर जा रहा हो. |
Protected Auction (B&A Services)
| फ़ीडबैक की थीम | खास जानकारी | Chrome Response |
|---|---|---|
| टेस्टिंग की उपलब्धता | Chrome और B&A, दोनों एनवायरमेंट में टेस्टिंग के लिए Key/Value (KV) v2 की उपलब्धता के बारे में जानकारी. | KV v2, B&A और Chrome, दोनों पर उपलब्ध है. ज़्यादा जानकारी यहां उपलब्ध है. |
| KV सर्वर लागू करना | केवी सर्वर के इस्तेमाल के बारे में ज़्यादा जानकारी पाने का अनुरोध करें. खास तौर पर, क्रिएटिव रेंडर यूआरएल को डेटा का अनुरोध करने के लिए मैप करने, रेंडर यूआरएल में पैरामीटर तय करने के लिए एसएसपी और डीएसपी के बीच तालमेल की ज़रूरत, और केवी मोड में ज़रूरी तालमेल और डेटा स्टोरेज के बारे में जानकारी देने वाले दस्तावेज़ की उपलब्धता के बारे में ज़्यादा जानकारी पाने का अनुरोध करें. | KV सेवा, renderURL को कुंजी के तौर पर इस्तेमाल करती है. अगर यूआरएल नया है, तो उसे सेव कर लिया जाता है. अगर यह मौजूद है, तो scoreAd में इस्तेमाल करने के लिए इसकी वैल्यू दिखाई जाती है. जवाब का फ़ॉर्मैट, सेटअप पर निर्भर करता है: "Bring Your Own Server" (BYOS) में किसी भी वैल्यू का इस्तेमाल किया जा सकता है. वहीं, Trusted KV सेवा के लिए User-Defined Function की ज़रूरत होती है. डीएसपी के साथ समन्वय करना हमेशा ज़रूरी नहीं होता. हालांकि, मैक्रो रिप्लेसमेंट (जैसे, ${AD_WIDTH}) में मौजूद है. इससे डाइनैमिक विज्ञापन कस्टमाइज़ेशन और पुष्टि करने की सुविधा मिलती है. हमारा सुझाव है कि आप एक डीएसपी के साथ सामान्य टेस्ट से शुरुआत करें, ताकि आपको ज़रूरी लेवल के कोऑर्डिनेशन के बारे में पता चल सके. हम केवी से जुड़े अपने दस्तावेज़ों को भी अपडेट कर रहे हैं. उपलब्ध होने पर, हम इसे सार्वजनिक तौर पर शेयर करेंगे. |
| B&A के लिए BYOS | B&A, KV के BYOS मोड की तरह BYOS मोड क्यों नहीं देता? | B&A के लिए टीईई की ज़रूरत होती है. इसलिए, इसमें BYOS मॉडल का इस्तेमाल नहीं किया जा सकता. ऐसा इसलिए, क्योंकि यह बहुत संवेदनशील डेटा कॉम्बिनेशन को मैनेज करता है. इसके लिए, निजता से जुड़े नियमों को लागू करना ज़रूरी है. इसके बारे में यहां बताया गया है. डीएसपी के लिए: B&A, पब्लिशर के कॉन्टेक्स्ट (अगर सेलर ने नीलामी के सिग्नल / खरीदार के हिसाब से सिग्नल के ज़रिए साफ़ तौर पर भेजा है, तो पूरा यूआरएल) को प्रोसेस करता है. इसे उपयोगकर्ता के आईजी डेटा के साथ जोड़ा जाता है. इस कॉम्बिनेशन को सुरक्षित तरीके से प्रोसेस करने के लिए, टीईई ज़रूरी है. साथ ही, इससे उपयोगकर्ता की पहचान का अनुमान लगाने से जुड़ी संभावित कोशिशों को रोका जा सकता है. KV BYOS में, पूरा यूआरएल नहीं भेजा जा सकता. एसएसपी के लिए: नीलामी में हिस्सा लेने वाले आईजी (और उनके डीएसपी मालिकों) के कॉम्बिनेशन के बारे में जानने से भी, पहचान करने वाला सिग्नेचर जनरेट किया जा सकता है. ऐसे में, चाफ़िंग का समाधान काम आता है. इसके लिए, टीईई का इस्तेमाल करना ज़रूरी होता है. इसलिए, इन संवेदनशील सिग्नल को सुरक्षित तरीके से प्रोसेस करने और निजता से जुड़े तरीकों को लागू करने के लिए, टीईई के कंट्रोल किए गए और प्रमाणित एनवायरमेंट की ज़रूरत होती है. |
डिजिटल विज्ञापनों की परफ़ॉर्मेंस का आकलन करना
Attribution Reporting (और अन्य एपीआई)
| फ़ीडबैक की थीम | खास जानकारी | Chrome Response |
|---|---|---|
| शोर से जुड़ी नीति | एआरए को लागू करने से, मार्केट में शामिल कुछ लोगों को फ़ायदा हुआ है. साथ ही, Google को इवेंट-लेवल की रिपोर्टिंग जारी रखनी चाहिए. Google को उन स्थितियों में नॉइज़ से जुड़ी नीति में ढील देनी चाहिए जहां एआरए और 3पीसी, दोनों उपलब्ध हैं. परफ़ॉर्मेंस विज्ञापन देने वाले लोग या कंपनियां, ARA फ़्लेक्स इवेंट के मौजूदा 'वैल्यू' फ़ील्ड का इस्तेमाल ज़्यादा से ज़्यादा कर रही हैं. साथ ही, नॉइज़ से जुड़ी नीति में कम पाबंदियां होने से, देरी और गलत रिपोर्टिंग को कम करने में मदद मिलेगी. | यह तरीका, ARA के डिज़ाइन का एक बुनियादी हिस्सा है. इसका मकसद, हर व्यक्ति की ट्रैकिंग को रोककर, उपयोगकर्ता की निजता को सुरक्षित रखना है. हम आवाज़ की वजह से रिपोर्टिंग से जुड़ी समस्याओं के बारे में मिले सुझावों पर ध्यान दे रहे हैं. साथ ही, हम इस बात का आकलन कर रहे हैं कि आने वाले समय में Privacy Sandbox API की क्या भूमिका होगी. हम Google के अप्रैल 2025 के एलान के मुताबिक, आने वाले समय में होने वाले संभावित सुधारों पर भी विचार कर रहे हैं. इस एलान में बताया गया है कि Chrome में उपयोगकर्ताओं को 3PC चुनने का मौजूदा तरीका जारी रहेगा. |
| रोडमैप और लंबे समय तक सहायता | एआरए के लिए प्रॉडक्ट रोडमैप का अनुरोध करना. साथ ही, इस बात की पुष्टि करना कि लंबे समय तक निवेश और सहायता जारी रहेगी. ऐसा इसलिए, क्योंकि 3PC के लिए उपयोगकर्ता की पसंद का तरीका लागू नहीं करने का एलान किया गया है. | Privacy Sandbox की टीम, इस इकोसिस्टम के साथ मिलकर काम कर रही है. इससे यह समझने में मदद मिलेगी कि आने वाले समय में Privacy Sandbox API की क्या भूमिका होगी. साथ ही, इससे आने वाले समय में किए जाने वाले निवेश का आकलन करने में भी मदद मिलेगी. |
| क्रॉस-एनवायरमेंट मेज़रमेंट (ऐप्लिकेशन से वेब) | ऐसे समाधान का अनुरोध करें जिसमें एआरए का इस्तेमाल करके, क्रॉस-एनवायरमेंट मेज़रमेंट को आसान बनाया जा सके. साथ ही, बेहतर और ज़्यादा भरोसेमंद डेटा फ़्लो उपलब्ध कराया जा सके. इसके अलावा, अलग-अलग प्लैटफ़ॉर्म पर उपयोगकर्ता इंटरैक्शन को कनेक्ट करने की सुविधा को बेहतर बनाया जा सके. | ARA, एक ही डिवाइस पर ऐप्लिकेशन से वेब पर स्विच करने की सुविधा पहले से ही देता है. क्रॉस ऐप्लिकेशन और वेब मेज़रमेंट के समाधान के बारे में ज़्यादा जानकारी यहां और यहां दी गई है. |
| क्रॉस-ब्राउज़र एट्रिब्यूशन | एआरए के लिए, अलग-अलग ब्राउज़र पर काम करने वाला एक जैसा सिस्टम होने से, ओपन वेब पर आरओआई को मेज़र करने की क्षमता में काफ़ी सुधार होगा. साथ ही, संभावित कानूनी बदलावों से पहले एक स्थिर विकल्प उपलब्ध होगा. Chrome को इस तरह के समाधान के लिए, Safari की टीम के साथ मिलकर काम करना चाहिए. | हम W3C के PATCG और PATWG ग्रुप में, अन्य ब्राउज़र वेंडर के साथ मिलकर इंटरऑपरेबल एपीआई पर काम कर रहे हैं. यह काम शुरुआती दौर में है. इसलिए, हितधारकों को हमारी प्रोग्रेस के बारे में जानने के लिए, यहां सलाह दी जाती है. |
| क्रॉस-डिवाइस/ऑफ़लाइन मेज़रमेंट | एआरए में क्रॉस-डिवाइस कन्वर्ज़न मेज़रमेंट की सुविधा उपलब्ध न होना एक बड़ी समस्या है. ऑनलाइन से ऑफ़लाइन कन्वर्ज़न को मेज़र करना भी बहुत ज़रूरी है. साथ ही, मेज़रमेंट वेंडर के साथ मिलकर काम करने में ब्राउज़र की भूमिका हो सकती है. | हम इस सुझाव पर विचार कर रहे हैं. हम यह भी आकलन कर रहे हैं कि आने वाले समय में Privacy Sandbox API की क्या भूमिका होगी. ऐसा इसलिए, क्योंकि Google ने अप्रैल 2025 में यह एलान किया है कि Chrome में उपयोगकर्ताओं को 3PC चुनने का मौजूदा तरीका जारी रहेगा. |
| मल्टी-टच एट्रिब्यूशन | विज्ञापन देने वाले लोगों या कंपनियों को, Privacy Sandbox के डेटा का इस्तेमाल करने की अनुमति देने का अनुरोध करें. इससे वे अपने मौजूदा एट्रिब्यूशन मॉडल को मान्य कर सकेंगी और उन्हें कैलिब्रेट कर सकेंगी. इस डेटा को "ग्राउंड ट्रुथ" के तौर पर इस्तेमाल किया जाएगा. इसके लिए, ARA के ब्राउज़र से मिले डेटा का इस्तेमाल भरोसेमंद कैलिब्रेशन सिग्नल के तौर पर किया जा सकता है. इससे, सच्चाई की एक बेसलाइन तैयार की जा सकती है. | हम इस सुझाव पर विचार कर रहे हैं. हम यह भी आकलन कर रहे हैं कि आने वाले समय में Privacy Sandbox API की क्या भूमिका होगी. ऐसा इसलिए, क्योंकि Google ने अप्रैल 2025 में यह एलान किया है कि Chrome में उपयोगकर्ताओं को 3PC चुनने का मौजूदा तरीका जारी रहेगा. |
| सहमति न देने वाले/ऑप्ट-आउट करने वाले ट्रैफ़िक का मेज़रमेंट | निजता बनाए रखने वाले समाधान, जैसे कि इंटरऑपरेबल प्राइवेट एट्रिब्यूशन की मदद से, सहमति न देने वाले ट्रैफ़िक के लिए मेज़रमेंट की सुविधा चालू की जा सकती है. इससे कैंपेन की परफ़ॉर्मेंस को बेहतर तरीके से समझा जा सकेगा. ऐसा इसलिए, क्योंकि इसमें उन उपयोगकर्ताओं का डेटा भी शामिल होगा जिन्होंने ट्रैकिंग से ऑप्ट आउट किया है. साथ ही, इससे सहमति लेने की ज़रूरी शर्तों की वजह से मेज़रमेंट में आने वाली बड़ी समस्या को हल किया जा सकेगा. | हम इस सुझाव पर विचार कर रहे हैं. हम यह भी आकलन कर रहे हैं कि आने वाले समय में Privacy Sandbox API की क्या भूमिका होगी. ऐसा इसलिए, क्योंकि Google ने अप्रैल 2025 में यह एलान किया है कि Chrome में उपयोगकर्ताओं को 3PC चुनने का मौजूदा तरीका जारी रहेगा. |
| सर्वर-टू-सर्वर एट्रिब्यूशन | विज्ञापन टेक्नोलॉजी से जुड़ी कंपनियों को सर्वर-साइड के बेहतर इन्फ़्रास्ट्रक्चर के साथ, ARA के साथ ज़्यादा आसानी से इंटिग्रेट करने की अनुमति देने का अनुरोध. इससे, उन मामलों में ARA का इस्तेमाल किया जा सकेगा जिन्हें सिर्फ़ क्लाइंट साइड पर मैनेज करना मुश्किल होता है. साथ ही, उपयोगकर्ता की निजता को भी बनाए रखा जा सकेगा. | हम इस सुझाव पर विचार कर रहे हैं. हम यह भी आकलन कर रहे हैं कि आने वाले समय में Privacy Sandbox API की क्या भूमिका होगी. ऐसा इसलिए, क्योंकि Google ने अप्रैल 2025 में यह एलान किया है कि Chrome में उपयोगकर्ताओं को 3PC चुनने का मौजूदा तरीका जारी रहेगा. |
| एक से ज़्यादा डोमेन के लिए रजिस्ट्रेशन | ARA में एक से ज़्यादा डोमेन रजिस्टर करते समय, सीमाओं और चेतावनियों के बारे में ज़्यादा जानकारी चाहिए. खास तौर पर, एग्रीगेशन सेवा और क्रॉस-ऑरिजिन एट्रिब्यूशन के बारे में. | एक से ज़्यादा डोमेन के साथ ARA का इस्तेमाल करने पर, ये मुख्य सीमाएं लागू होती हैं: • एट्रिब्यूशन का दायरा सिर्फ़ एक ऑरिजिन तक सीमित होता है. अपने किसी डोमेन से मिले क्लिक को किसी दूसरे डोमेन पर हुए कन्वर्ज़न से मैच नहीं किया जा सकता. एट्रिब्यूशन को सोर्स और ट्रिगर, दोनों के लिए एक ही ऑरिजिन में सैंडबॉक्स किया जाता है. • एग्रीगेशन सेवा, एक से ज़्यादा ऑरिजिन से बैच बनाने की सुविधा के साथ काम नहीं करती. अलग-अलग ओरिजन की रिपोर्ट को बैच में रखा जाना चाहिए और उन्हें अलग-अलग प्रोसेस किया जाना चाहिए. हम आने वाले समय में, इस सुविधा को उपलब्ध कराने के लिए काम कर रहे हैं. संक्षेप में, एक इकाई के तहत कई डोमेन रजिस्टर किए जा सकते हैं. हालांकि, एआरए के सभी फ़ंक्शन, जैसे कि एट्रिब्यूशन और एग्रीगेशन को फ़िलहाल हर ऑरिजिन के हिसाब से मैनेज करना होगा. |
एग्रीगेशन सेवा
इस तिमाही में कोई सुझाव, राय या शिकायत नहीं मिली.
Private Aggregation API
| फ़ीडबैक की थीम | खास जानकारी | Chrome Response |
|---|---|---|
| सीमाएं और शोर का लेवल | Private Aggregation API में, एग्रीगेशन कुंजी के साइज़ और एग्रीगेशन वैल्यू से जुड़ी सीमाओं के बारे में चिंताएं. | एग्रीगेशन कुंजी और वैल्यू के साइज़ को इस तरह से चुना गया था कि नेटवर्क और स्टोरेज की लागत को सीमित करते हुए, ज़्यादा से ज़्यादा जानकारी मिल सके. हमारा यह भी सुझाव है कि ज़्यादा से ज़्यादा फ़्लेक्सिबिलिटी के लिए, कुंजियां असाइन करते समय हैशिंग का इस्तेमाल करें. उपयोगकर्ता के डेटा को सुरक्षित रखने के लिए, अन्य फ़ैक्टर भी मौजूद हैं. हालांकि, Private Aggregation API की निजता सुरक्षा के लिए, नॉइज़ जोड़ना एक अहम हिस्सा है. हम मिले सुझावों और राय पर ध्यान दे रहे हैं. साथ ही, हम सही पैरामीटर चुनने के लिए लगातार आकलन करते रहेंगे. हम यह भी आकलन करते रहेंगे कि आने वाले समय में Privacy Sandbox API की क्या भूमिका होगी. ऐसा इसलिए, क्योंकि Google ने अप्रैल 2025 में यह एलान किया है कि Chrome में उपयोगकर्ताओं को 3PC चुनने का मौजूदा तरीका जारी रहेगा. |
| निजता बनाम काम की सुविधा | Privacy Sandbox का तरीका, निजता को प्राथमिकता दे सकता है. इससे, इसे अपनाने में मुश्किल हो सकती है. मेज़रमेंट और दिलचस्पी के मुताबिक विज्ञापन दिखाने की सुविधा को बेहतर बनाने के लिए, उपयोगकर्ता की सहमति से ज़्यादा जानकारी वाला डेटा शेयर करने का सुझाव. | एग्रीगेशन कुंजी और वैल्यू के साइज़ को इस तरह से चुना गया था कि नेटवर्क और स्टोरेज की लागत को सीमित करते हुए, ज़्यादा से ज़्यादा जानकारी मिल सके. हमारा यह भी सुझाव है कि ज़्यादा से ज़्यादा फ़्लेक्सिबिलिटी के लिए, कुंजियां असाइन करते समय हैशिंग का इस्तेमाल करें. हम इस सुझाव पर विचार कर रहे हैं. हम यह भी आकलन कर रहे हैं कि आने वाले समय में Privacy Sandbox API की क्या भूमिका होगी. ऐसा इसलिए, क्योंकि Google ने अप्रैल 2025 में यह एलान किया है कि Chrome में उपयोगकर्ताओं को 3PC चुनने का मौजूदा तरीका जारी रहेगा. |
Limit Covert Tracking
यूज़र-एजेंट रिडक्शन/यूज़र-एजेंट क्लाइंट हिंट
| फ़ीडबैक की थीम | खास जानकारी | Chrome Response |
|---|---|---|
| स्पैम का पता लगाना | अगर स्पैम का पता लगाने वाले सिस्टम का इस्तेमाल करने वाली वेबसाइट का पहला अनुरोध, क्लाइंट हिंट पर निर्भर करता है, तो ट्रैकिंग या पता लगाने वाला सिस्टम, अनुरोध की पहचान करने या उसे सही तरीके से कैटगरी में रखने में विफल हो सकता है. | जिन इस्तेमाल के उदाहरणों में पहले अनुरोध पर, User-Agent Client Hints (UA-CH) का ऐक्सेस होना ज़रूरी है उन्हें ज़रूरी क्लाइंट हिंट का इस्तेमाल करना चाहिए. |
| एपीआई के बारे में सुझाव, शिकायत या राय | Sec-CH-USA-Wow64 को बंद कर दें, क्योंकि यह अब आधुनिक वेब के लिए काम का नहीं है. | हम इस अनुरोध पर विचार कर रहे हैं. अगर आपको कोई और सुझाव/राय देनी है या शिकायत करनी है, तो यहां क्लिक करें. हमें यह सुझाव भी मिला है कि wow64 को Windows के अलावा अन्य ऑपरेटिंग सिस्टम पर भी उपलब्ध कराया जाना चाहिए. |
आईपी पते की सुरक्षा (पहले इसे Gnatcatcher कहा जाता था)
| फ़ीडबैक की थीम | खास जानकारी | Chrome Response |
|---|---|---|
| कंट्रोल | साइटों के लिए आईपी पते की सुरक्षा की सुविधा को टॉगल करने का अनुरोध. इससे साइटें, गुप्त मोड से बाहर इस सुविधा का इस्तेमाल चुनिंदा तौर पर कर पाएंगी. | हम आपके सुझाव/राय/शिकायत की सराहना करते हैं. इस समस्या के बारे में ज़्यादा जानकारी देने के लिए, यहां क्लिक करें. |
| बुरा व्यवहार | क्या शून्य वैल्यू वाले Probabilistic Reveal Tokens (PRT), पुलिस को आईपी पते का खुलासा करने का अनुरोध करने पर, अपराध करने वाले व्यक्ति की पहचान करने से रोकेंगे? | अगर किसी डोमेन का इस्तेमाल सिर्फ़ धोखाधड़ी और गलत इस्तेमाल का पता लगाने के लिए किया जाता है, तो हो सकता है कि उसे मास्क्ड डोमेन लिस्ट (एमडीएल) में शामिल न किया गया हो. इसलिए, आईपी पते की सुरक्षा की सुविधा का उस पर कोई असर नहीं पड़ता. इसलिए, उन डोमेन के लिए पीआरटी की ज़रूरत नहीं होगी. अगर किसी डोमेन को MDL में शामिल किया गया है, तो फ़िलहाल पीआरटी ही प्रॉक्सी किए गए अनुरोध के लिए, ओरिजनल आईपी पते का पता लगाने का एकमात्र तरीका है. पीआरटी को खास तौर पर एग्रीगेट विश्लेषण के लिए डिज़ाइन किया गया है, न कि व्यक्तिगत पहचान के लिए. इसलिए, यह सही है कि पीआरटी में ज़्यादातर मामलों में आईपी पता शामिल नहीं होगा. हमें उम्मीद है कि इस स्थिति में, इसका असर सीमित होगा. हालांकि, आईपी पते की सुरक्षा की सुविधा सिर्फ़ तीसरे पक्ष के कॉन्टेक्स्ट में लागू होती है. इसका मतलब है कि पब्लिशर को पहले पक्ष की इंटरैक्शन के लिए, बिना प्रॉक्सी वाले आईपी पते मिलते रहेंगे. जैसे, ऑनलाइन प्लैटफ़ॉर्म की साइट पर आने वाले उपयोगकर्ताओं के आईपी पते. |
| धोखाधड़ी से बचाव | आईपी की सुरक्षा के लिए, Google धोखाधड़ी रोकने के लिए कौनसे तरीके अपनाता है? इसमें प्रॉक्सी के ऐक्सेस को सीमित करने और पुष्टि करने वाले टोकन जारी करने के बारे में जानकारी भी शामिल है. साथ ही, पीआरटी के इस्तेमाल के खास उदाहरण क्या हैं? | हम पुष्टि करते हैं कि आईपी पते की सुरक्षा की सुविधा में, दर सीमित करने और पुष्टि करने वाले टोकन को इस तरह से डिज़ाइन किया गया है कि बॉट, प्रॉक्सी को ज़्यादा ऐक्सेस करके विज्ञापन से जुड़ी धोखाधड़ी न कर पाएं. इसके बारे में, धोखाधड़ी और स्पैम रोकने की रणनीति में बताया गया है. PRT के इस्तेमाल के अन्य उदाहरणों के बारे में, PRT के बारे में बताने वाले दस्तावेज़ में यहां बताया गया है. |
| गुप्त मोड | क्या आईपी पते को छिपाने की सुविधा को तीसरे क्वार्टर में गुप्त मोड के लिए लॉन्च करने का प्लान अब भी है? | फ़िलहाल, गुप्त मोड में आईपी सुरक्षा सुविधा लॉन्च करने के लिए, तीसरी तिमाही की समयावधि में कोई बदलाव नहीं किया गया है. |
बाउंस ट्रैकिंग को कम करने की सुविधा
| फ़ीडबैक की थीम | खास जानकारी | Chrome Response |
|---|---|---|
| एपीआई के बारे में सुझाव, शिकायत या राय | Chrome को बाउंस ट्रैकिंग को कम करने के तरीके (बीटीएम) लागू करते समय, कुकी/स्टोरेज के ऐक्सेस को ब्लॉक करना चाहिए. ऐसा करने के बजाय, उन्हें बांटना नहीं चाहिए. इसकी वजह यह है कि Safari की "पार्टिशनिंग" के तरीके से, अनचाही गतिविधि होती है और भ्रम पैदा होता है. | हम इस सुझाव का स्वागत करते हैं. फ़िलहाल, बीटीएम में कुकी/स्टोरेज पार्टिशनिंग शामिल नहीं है. इसके बजाय, यह ग्रेस पीरियड के बाद इसे मिटा देता है. अगर बीटीएम के बाद के किसी डिज़ाइन में कुकी के लिए तुरंत कार्रवाई करने की ज़रूरत होती है, तो हमारा इरादा कुकी को ब्लॉक करने को प्राथमिकता देने का है, न कि उन्हें बांटने का. |
क्रॉस-साइट निजता की सीमाओं को मज़बूत करना
Related Website Sets (पहले इन्हें First-Party Sets कहा जाता था)
इस तिमाही में कोई सुझाव, राय या शिकायत नहीं मिली.
Fenced Frames API
इस तिमाही में कोई सुझाव, राय या शिकायत नहीं मिली.
Shared Storage API
| फ़ीडबैक की थीम | खास जानकारी | Chrome Response |
|---|---|---|
| एपीआई की सुविधा के लिए अनुरोध करना | शेयर किए गए स्टोरेज में विज्ञापन के व्यू और क्लिक जोड़ने का अनुरोध. | हम इस सुझाव पर विचार कर रहे हैं. हम यह भी आकलन कर रहे हैं कि आने वाले समय में Privacy Sandbox API की क्या भूमिका होगी. ऐसा इसलिए, क्योंकि Google ने अप्रैल 2025 में यह एलान किया है कि Chrome में उपयोगकर्ताओं को 3PC चुनने का मौजूदा तरीका जारी रहेगा. |
सीएचआईपीएस
| फ़ीडबैक की थीम | खास जानकारी | Chrome Response |
|---|---|---|
| एपीआई से जुड़ा सवाल | इस बारे में ज़्यादा जानकारी का अनुरोध करें कि Chrome के 3PC कंट्रोल, CHIPS के साथ कैसे इंटरैक्ट करते हैं. खास तौर पर, यह कि क्या 3PC बंद होने पर, नॉन-पार्टिशन की गई कुकी को पार्टिशन की गई कुकी में बदल दिया जाता है और क्या पार्टिशन की गई कुकी चालू रहती हैं. | जब 3PC बंद होते हैं, तब नॉन-पार्टिशन की गई कुकी को तीसरे पक्ष के कॉन्टेक्स्ट में सेव, वापस नहीं पाया जा सकता या भेजा नहीं जा सकता. हालांकि, पार्टिशन की गई कुकी को तीसरे पक्ष के कॉन्टेक्स्ट में सेव, वापस पाई, और भेजा जाता रहेगा. ऐसा इसलिए, क्योंकि इनकी फ़ंक्शनैलिटी पर ब्राउज़र की उन सेटिंग का कोई असर नहीं पड़ता जो तीसरे पक्ष की कुकी को बंद करती हैं. |
| निजता से जुड़ी चिंता | चिंता यह है कि एम्बेड की गई पार्टी, जैसे कि सिंगल साइन-ऑन के लिए, स्थायी आइडेंटिफ़ायर का इस्तेमाल करती है. ऐसे में, वह पार्टीशन की गई कुकी के साथ भी, एम्बेड करने और एम्बेड की गई पार्टियों, दोनों को ग्लोबल डिजिटल आइडेंटिफ़ायर हासिल करने की सुविधा दे सकती है. | एम्बेड किए गए पक्ष के पास परसिस्टेंट आइडेंटिफ़ायर हो सकता है. हालांकि, जब इस आइडेंटिफ़ायर को पार्टीशन की गई कुकी में सेव किया जाता है, तो इसे सिर्फ़ उस साइट पर ऐक्सेस किया जा सकता है जहां एम्बेड किए गए पक्ष ने कुकी सेट की थी. इस आइडेंटिफ़ायर को किसी दूसरी साइट से जोड़ने के लिए, लॉगिन करना ज़रूरी होगा. इससे पहले से ही पुष्टि करने वाले टोकन के तौर पर आइडेंटिफ़ायर को शेयर करने की अनुमति मिल जाती है. इसके लिए, पार्टिशन की गई कुकी का इस्तेमाल करना ज़रूरी नहीं है. |
FedCM
| फ़ीडबैक की थीम | खास जानकारी | Chrome Response |
|---|---|---|
| एपीआई प्रयोग | कई खातों वाले उपयोगकर्ताओं के लिए साइलेंट मीडिएशन काम नहीं कर रहा है. हालांकि, कोई खास गड़बड़ी नहीं हुई है. | साइलेंट मीडिएशन की सुविधा, डिज़ाइन के हिसाब से काम करती है. ऐसा इसलिए है, क्योंकि इसे सिर्फ़ एक उपलब्ध खाते के साथ किसी खास मामले के लिए बनाया गया है. हमारा सुझाव है कि इसके बजाय, "ज़रूरी नहीं" मीडिएशन का इस्तेमाल करें. इसमें अगर साइलेंट मीडिएशन मुमकिन नहीं होता है, तो FedCM उपयोगकर्ता को खाता चुनने का विकल्प दिखाता है. |
| एपीआई प्रयोग | navigator.credentials.get सामान्य गड़बड़ियां दिखाता है. इससे, अस्वीकार किए जाने की खास वजहों को कैप्चर नहीं किया जा सकता. जैसे, उपयोगकर्ता का खारिज करना या कूलडाउन की अवधि. |
डेवलपर, इन बातों के बीच अंतर नहीं कर सकते: उपयोगकर्ता ने FedCM डायलॉग को खारिज कर दिया है, नेटवर्क में गड़बड़ी हुई है या उपयोगकर्ता ने पहले डायलॉग को खारिज कर दिया था, इसलिए FedCM "कूलडाउन पीरियड" में है. यह सुविधा, उपयोगकर्ता की निजता बनाए रखने के लिए डिज़ाइन की गई है. समस्या यह है कि इस सुविधा की मदद से, वेबसाइटें अलग-अलग पहचान देने वाली कंपनियों (आईडीपी) पर उपयोगकर्ता की लॉगिन स्थिति का पता लगा सकती हैं. |
| साइन-इन करें | साइन इन किए गए कई खातों के साथ, खाता चुनने के तरीके में अंतर देखा गया. | यह साफ़ तौर पर नहीं कहा जा सकता कि एक से ज़्यादा खातों में साइन इन करने की सुविधा के दौरान, किसी खास खाते को चुनने में समस्या आ रही है. यह समस्या, FedCM में कभी-कभी होने वाली गड़बड़ी है या टेस्टिंग सिस्टम से जुड़ी कोई समस्या है. हम इस समस्या को हल करने के लिए, शिकायत करने वाले व्यक्ति के साथ मिलकर काम कर रहे हैं. हमने इस समस्या को बेहतर तरीके से समझने के लिए, उससे ज़्यादा जानकारी मांगी है. |
| एपीआई प्रयोग | अगर उपयोगकर्ता, FedCM की मदद से पुष्टि करते समय डायलॉग बॉक्स को खारिज करता है, तो इस बात की जानकारी नहीं दी जाती कि वह कूलडाउन की स्थिति में है. इसके लिए, ऐसी गड़बड़ी का इस्तेमाल किया जाता है जिसे ठीक किया जा सकता है. | हां, ऐसा ही होगा. इससे उपयोगकर्ता की निजता बनाए रखने के लिए, सामान्य गड़बड़ी कोड जनरेट होगा. |
| एपीआई प्रयोग | "अपने-आप फिर से पुष्टि होने" की प्रोसेस पूरी होने के बाद, FedCM 10 मिनट के लिए शांत अवधि में क्यों चला जाता है? | अपने-आप फिर से पुष्टि होने की सुविधा, उपयोगकर्ता की ओर से शुरू की गई कार्रवाई के बिना काम करती है. इसलिए, अगर उपयोगकर्ता को वेबसाइट पर वापस जाना है, लेकिन किसी दूसरे खाते से साइन इन करना है, तो उसे कुछ समय के लिए इस सुविधा को बंद करना होगा. "शांत अवधि" के दौरान, उपयोगकर्ताओं को किसी दूसरे खाते का इस्तेमाल करके मैन्युअल तरीके से साइन इन करने का विकल्प मिलता है. इस "शांत अवधि" के बारे में ज़्यादा जानकारी के लिए, यह ब्लॉग पोस्ट पढ़ें. |
| लाइटवेट FedCM | चिंताएं: लाइटवेट FedCM के सुझाव से, IdP के लिए अतिरिक्त जटिलता पैदा होती है. ऐसा इसलिए, क्योंकि उन्हें दो ऐसे तरीकों को इस्तेमाल करना पड़ता है जो एक-दूसरे के साथ काम नहीं करते (FedCM बनाम लाइटवेट FedCM). | लाइटवेट FedCM, पारंपरिक FedCM के साथ काम करता है. आईडीपी यह चुन सकते हैं कि उन्हें कौनसा तरीका इस्तेमाल करना है. साथ ही, उन्हें दोनों तरीकों के साथ काम करने की ज़रूरत नहीं होगी. लाइटवेट FedCM, FedCM के लिए एक पुश मेकेनिज़्म है. अगर कोई आईडीपी इस सुविधा का इस्तेमाल करना चाहता है, तो वह उपयोगकर्ता के लॉग इन करने पर, खाते की जानकारी को ब्राउज़र पर भेज सकता है. इससे जब कोई भरोसेमंद पक्ष (आरपी) FedCM को चालू करता है, तो खाता आईडीपी के खातों के एंडपॉइंट से नहीं, बल्कि ब्राउज़र से वापस मिल जाएगा. |
| लाइटवेट FedCM | लाइटवेट FedCM के प्रस्ताव में, आरपी को उपयोगकर्ता का निजी डेटा दिखने की चिंताएं. जैसे, नाम, ईमेल, और प्रोफ़ाइल फ़ोटो. | इस सुझाव/राय के बाद, लाइटवेट FedCM के प्रस्ताव को अपडेट कर दिया गया है. इसमें, नाम, ईमेल, और प्रोफ़ाइल इमेज को मेथड रिस्पॉन्स से हटा दिया गया है. |
| लाइटवेट FedCM | Lightweight FedCM के सुझाव में, साइन इन किए गए एक से ज़्यादा खातों को मैनेज करने की सुविधा बहुत सीमित है. फ़िलहाल, इस प्रस्ताव में हर खाते के लिए, अलग-अलग सेशन की लाइफ़टाइम या लॉगिन की स्थितियों के बारे में जानकारी नहीं दी गई है. | फ़िलहाल, क्रेडेंशियल ऑब्जेक्ट में मौजूद IdP के साथ समयसीमा जुड़ी हुई है. हमने हर खाते के लिए सदस्यता की समयसीमा खत्म होने की जानकारी को एक खुले सवाल के तौर पर नोट किया है. साथ ही, हम इस सुझाव को आने वाले समय में होने वाले डेवलपमेंट के लिए ध्यान में रखेंगे. |
| लाइटवेट FedCM | "साइन इन किया गया" और "चुना जा सकता है" के बीच का अंतर साफ़ तौर पर नहीं बताया गया है. इससे Lightweight FedCM के सुझाव के लिए, उपयोगकर्ता अनुभव पर असर पड़ सकता है. | फ़िलहाल, हम FedCM के यूज़र इंटरफ़ेस (यूआई) में यह पता लगाने की सुविधा नहीं देते हैं कि कोई खाता लॉग इन है या लॉग आउट. जिन खातों से लॉग आउट किया गया है उन्हें सूची में शामिल नहीं किया जाना चाहिए. अगर कोई खाता लॉग आउट हो गया है और सूची में शामिल है, तो उपयोगकर्ता के पास ऐसे खाते को चुनने का विकल्प होता है जिसमें वह फ़िलहाल लॉग इन नहीं है. ऐसे में, उपयोगकर्ता को फिर से लॉग इन करने के लिए, Continuation API का इस्तेमाल किया जा सकता है. |
| एपीआई प्रयोग | getUserInfo में मौजूद given_name फ़ील्ड और FedCM यूज़र इंटरफ़ेस (यूआई) में इसके इस्तेमाल के बीच अंतर होना. |
इस समस्या के बारे में Mozilla के साथ यहां ज़्यादा चर्चा की गई है, ताकि यह तय किया जा सके कि getUserInfo में given_name को कैसे हैंडल किया जाना चाहिए. |
| एपीआई प्रयोग | यूज़र इंटरफ़ेस (यूआई) में इस्तेमाल किए गए सभी फ़ील्ड, IdentityProviderAccount से getUserInfo को नहीं दिए जाते हैं. खास तौर पर, tel और username को. इससे पता चलता है कि सिंक्रनाइज़ेशन की ज़रूरत है. |
Mozilla और FedID कम्यूनिटी ग्रुप के अन्य सदस्यों के साथ चर्चा जारी है. इसमें यह तय किया जा रहा है कि IdentityProviderAccount से कौनसे फ़ील्ड getUserInfo. को भेजे जाएं |
| Enterprise FedCM | एंटरप्राइज़ IdP के इस्तेमाल के उदाहरणों के लिए, FedCM की सुविधा का अनुरोध करें. | मुख्य समस्या यह है कि IdP के लिए, भरोसेमंद तरीके की ज़रूरत होती है. इससे वे ब्राउज़र को यह सिग्नल दे पाते हैं कि एडमिन ने पहले से ही सहमति दे दी है. इससे उपयोगकर्ता, खास आरपी को ऐक्सेस कर पाता है. वेब ट्रैकर, इन आरपी की नकल नहीं कर सकते और न ही इनका गलत इस्तेमाल कर सकते हैं. इस बारे में, 22 अप्रैल को हुई FedID CG की मीटिंग में चर्चा की गई थी. कृपया मीटिंग के नोट यहां देखें. साथ ही, ब्राउज़र एक्सटेंशन और एंटरप्राइज़ नीतियों (मैनेज किए जा रहे डिवाइसों के लिए) के कॉम्बिनेशन को संभावित समाधान के तौर पर पेश किया गया था. हम इस समस्या के बारे में आपके सुझाव/राय/शिकायत का स्वागत करते हैं. इसके लिए, यहां क्लिक करें. |
स्पैम और धोखाधड़ी को रोकना
Private State Token API (और अन्य एपीआई)
इस तिमाही में कोई सुझाव, राय या शिकायत नहीं मिली.