साल 2025 की पहली तिमाही की तिमाही रिपोर्ट, जिसमें Privacy Sandbox के प्रस्तावों और Chrome के जवाब पर, नेटवर्क से जुड़े लोगों से मिले सुझाव, शिकायत या राय की खास जानकारी दी गई है.
Google ने यह तिमाही रिपोर्ट, पैराग्राफ़ 12, 17(c)(ii), और 32(a) के तहत, प्रतिस्पर्धा और बाज़ार अथॉरिटी ('सीएमए') को दी गई अपनी प्रतिबद्धताओं के तहत तैयार की है. इस रिपोर्ट में, Privacy Sandbox के प्रस्तावों पर Google की प्रोग्रेस के बारे में बताया गया है. साथ ही, इसमें समय से जुड़ी अपडेट की गई उम्मीदों के बारे में भी बताया गया है. इसमें यह भी बताया गया है कि Google ने तीसरे पक्षों की टिप्पणियों को कैसे ध्यान में रखा है. साथ ही, इसमें Google और सीएमए के बीच हुए इंटरैक्शन की खास जानकारी दी गई है. इसमें सीएमए से मिले सुझाव/राय/शिकायत/राय के साथ-साथ, Google के उन सुझावों/राय/शिकायत/राय को हल करने के तरीके के बारे में भी बताया गया है.
Google, CMA को Privacy Sandbox के प्रपोज़ल की प्रोग्रेस के बारे में अपडेट देता रहा है. यह अपडेट, Google की नियमित स्टेटस मीटिंग में दिया जाता है. ये मीटिंग, दायित्वों के पैराग्राफ़ 17(b) के मुताबिक शेड्यूल की जाती हैं. इसके अलावा, यह टीम डेवलपर दस्तावेज़ को मैनेज करती है. इसमें, निजी विज्ञापन की मुख्य सुविधाओं और कुकी में हुए बदलावों के बारे में खास जानकारी दी गई है. साथ ही, एपीआई लागू करने और स्थिति की जानकारी भी दी गई है. डेवलपर ब्लॉग पर मुख्य अपडेट शेयर किए जाते हैं. साथ ही, डेवलपर की अलग-अलग मेलिंग सूचियों में टारगेट किए गए अपडेट शेयर किए जाते हैं.
शॉर्ट फ़ॉर्म की ग्लॉसरी
- ARA
- Attribution Reporting API
- सीएचआईपीएस
- कुकीज़ हैविंग इंडिपेंडेंट पार्टिशन्ड स्टेट
- डीएसपी
- डिमांड-साइड प्लैटफ़ॉर्म
- FedCM
- फ़ेडरेटेड क्रेडेंशियल मैनेजमेंट
- IAB
- Interactive Advertising Bureau
- IDP
- पहचान की पुष्टि करने वाली सेवा
- आईईटीएफ़
- इंटरनेट इंजीनियरिंग टास्क फ़ोर्स
- आईपी
- इंटरनेट प्रोटोकॉल पता
- openRTB
- रीयल-टाइम बिडिंग
- OT
- Origin ट्रायल
- PA API
- Protected Audience API (पहले इसे FLEDGE के नाम से जाना जाता था)
- PatCG
- निजी विज्ञापन टेक्नोलॉजी कम्यूनिटी ग्रुप
- RP
- भरोसा करने वाली पार्टी
- RWS
- मिलती-जुलती वेबसाइट के सेट (पहले इन्हें पहले पक्ष के सेट कहा जाता था)
- SSP
- सप्लाई-साइड प्लैटफ़ॉर्म
- UA
- यूज़र एजेंट स्ट्रिंग
- UA-CH
- User-Agent Client Hints
- W3C
- वर्ल्ड वाइड वेब कंसोर्टियम
- WIPB
- जान-बूझकर आईपी ब्लाइंडनेस
सामान्य सुझाव, राय या शिकायत, किसी खास एपीआई/टेक्नोलॉजी के लिए नहीं
| फ़ीडबैक की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| उपयोगकर्ता के लिए उपलब्ध विकल्प | यह साफ़ तौर पर नहीं पता कि उपयोगकर्ताओं को ज़्यादा विकल्प देने के लिए, Google का अपडेट किया गया तरीका कैसा होगा. साथ ही, यह भी नहीं पता कि इसे उपयोगकर्ताओं को कैसे दिखाया जाएगा और ऑप्ट-इन/ऑप्ट-आउट की अनुमानित दरें क्या होंगी. तीसरे पक्ष की कुकी के इस्तेमाल को बंद करने से इसे अलग करने के लिए, ज़्यादा जानकारी की ज़रूरत है. | Google ने अप्रैल 2025 में, Chrome पर Privacy Sandbox और ट्रैकिंग सुरक्षा से जुड़े अगले कदम के बारे में एक ब्लॉग पोस्ट पब्लिश किया था. इसमें बताया गया था कि Google ने Chrome में उपयोगकर्ताओं को तीसरे पक्ष की कुकी उपलब्ध कराने के लिए, मौजूदा तरीके को जारी रखने का फ़ैसला लिया है. साथ ही, तीसरे पक्ष की कुकी के लिए कोई नया स्टैंडअलोन प्रॉम्प्ट लॉन्च नहीं किया जाएगा. अन्य अपडेट उपलब्ध होने पर, हम आपको इसकी जानकारी देंगे. |
| ऑनलाइन ट्रैकिंग | Google ने पब्लिशर या मार्केटर के साथ इस बारे में कोई जानकारी शेयर नहीं की है कि वे Google के विज्ञापन सिस्टम के किसी भी विकल्प पर, सामान्य मैच कुंजी (जैसे, फ़िंगरप्रिंट) के तौर पर, ज़्यादा जोखिम वाली उपभोक्ता पहचान का इस्तेमाल किए बिना कैसे भरोसा कर सकते हैं. | हमने Google के अलावा, ऐसे कई विज्ञापन सिस्टम हाइलाइट किए हैं जो पब्लिशर और मार्केटर को Privacy Sandbox API के आधार पर समाधान उपलब्ध करा रहे हैं. इसमें सभी बाज़ारों और चैनलों पर, Google के अलावा दूसरे विज्ञापन सिस्टम शामिल हैं. ज़्यादा जानकारी और केस स्टडी के लिए, privacysandbox.com के 'कारोबार के लिए संसाधन' सेक्शन पर जाएं यहां. |
| Privacy Sandbox | Privacy Sandbox APIs, इंटरनेट डेटा के कॉम्पोनेंट को Google के तैयार प्रॉडक्ट से बदल देंगे. Google का विकल्प एक एपीआई है. इसलिए, यह ऐसे प्रॉडक्ट का ऐक्सेस दे रहा है जिसका मालिकाना हक और कंट्रोल Google के पास है. साथ ही, यह प्रॉडक्ट उन नियमों और शर्तों के मुताबिक है जिन पर Google का अधिकार है. यह उन कॉम्पोनेंट का विकल्प नहीं है जिनका इस्तेमाल दूसरे लोग अपने प्रॉडक्ट बनाने के लिए करते हैं. | Privacy Sandbox API को डेवलप और लागू करने के लिए, नियम बनाने वाली संस्थाओं और नेटवर्क के कई हिस्सेदारों के साथ लगातार बातचीत की गई है. अन्य प्लैटफ़ॉर्म टेक्नोलॉजी की तरह ही, Privacy Sandbox API को भी यह ध्यान रखना होगा कि इनका इस्तेमाल, दूसरे के तैयार प्रॉडक्ट में कॉम्पोनेंट के तौर पर किया जाएगा. साथ ही, हम Privacy Sandbox API के साथ काम करने के लिए, अन्य टेक्नोलॉजी विकसित करने के लिए नेटवर्क की कोशिशों का स्वागत करते हैं. |
| उपयोगकर्ता के लिए उपलब्ध विकल्प | इस बारे में जानकारी का अनुरोध करना कि Chrome पर तीसरे पक्ष के प्लैटफ़ॉर्म के लिए Google का अपडेट किया गया तरीका, कानूनी तौर पर तय की गई कुछ ज़रूरी शर्तों को पूरा करेगा या नहीं. इन शर्तों का पालन न करने पर, हिस्सेदारों के लिए सहमति मैनेजमेंट प्लैटफ़ॉर्म के अनुभव पर असर पड़ सकता है. | Google ने अप्रैल 2025 में, Chrome पर Privacy Sandbox और ट्रैकिंग सुरक्षा से जुड़े अगले कदम के बारे में एक ब्लॉग पोस्ट पब्लिश किया था. इसमें बताया गया था कि Google ने Chrome में उपयोगकर्ताओं को तीसरे पक्ष की कुकी उपलब्ध कराने के लिए, मौजूदा तरीके को जारी रखने का फ़ैसला लिया है. साथ ही, तीसरे पक्ष की कुकी के लिए कोई नया स्टैंडअलोन प्रॉम्प्ट लॉन्च नहीं किया जाएगा. अन्य अपडेट उपलब्ध होने पर, हम आपको इसकी जानकारी देंगे. |
| प्राइवसी सैंडबॉक्स की टाइमलाइन और इसे अपनाना | विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली कंपनियों ने Privacy Sandbox API की टेस्टिंग रोक दी है. साथ ही, वे प्रॉडक्ट और मार्केटिंग गतिविधियों के लिए, इन टेक्नोलॉजी में फिर से निवेश करने की ज़्यादा वजहें ढूंढ रही हैं. फिर से निवेश करने के उनके फ़ैसलों पर, उपयोगकर्ता के विकल्प की टाइमलाइन के बारे में ज़्यादा जानकारी की ज़रूरत का काफ़ी असर पड़ता है. साथ ही, Protected Audience API (PA API) के इंतज़ार के समय और B&A रोडमैप से जुड़ी चिंताओं का भी असर पड़ता है. इसके अलावा, सीएमए की प्रतिबद्धताओं की समीक्षा को लेकर भी चिंताएं हैं. खास तौर पर, तीसरे पक्ष के आइडेंटिफ़ायर पर भरोसा किए बिना, Privacy Sandbox टेक्नोलॉजी को मुख्य रूप से आगे बढ़ाने में Google की भूमिका और निवेश की रणनीतियों के बारे में बताने के लिए, इस पहल के आने वाले समय की दिशा के बारे में. | Google ने अप्रैल 2025 में, Chrome पर Privacy Sandbox और ट्रैकिंग सुरक्षा से जुड़े अगले कदम के बारे में एक ब्लॉग पोस्ट पब्लिश किया था. इसमें बताया गया था कि Google ने Chrome में उपयोगकर्ताओं को तीसरे पक्ष की कुकी उपलब्ध कराने के लिए, मौजूदा तरीके को जारी रखने का फ़ैसला लिया है. साथ ही, तीसरे पक्ष की कुकी के लिए कोई नया स्टैंडअलोन प्रॉम्प्ट लॉन्च नहीं किया जाएगा. उपलब्ध होते ही हम आपको और जानकारी देंगे. Chrome PA API की नीलामियां, साल-दर-साल 35% ज़्यादा तेज़ होती हैं. इसके अलावा, हमें पैरलल ऑक्शन के इस्तेमाल में काफ़ी बढ़ोतरी दिखी है. इससे उन ऑक्शन को ज़्यादा फ़ायदा मिलता है. बिडिंग और ऑप्टिमाइज़ेशन से जुड़ा हमारा मौजूदा रोडमैप यहां उपलब्ध है. |
| प्राइवसी सैंडबॉक्स की टाइमलाइन | Privacy Sandbox की टाइमलाइन वाले पेज में क्या अपडेट किया गया है? | Topics API के बारे में खास जानकारी, हाल ही में Privacy Sandbox की टाइमलाइन वाले पेज पर जोड़ी गई है. |
| Privacy Sandbox | क्या निजता बनाम उपयोगिता के बारे में कोई रिसर्च पेपर है, ताकि Privacy Sandbox के रेवेन्यू पर पड़ने वाले असर को समझा जा सके? | इन सवालों के जवाब देने वाली, काम की मार्केट केस स्टडी यहां उपलब्ध हैं. साथ ही, Privacy Sandbox API की टेस्टिंग के नतीजे यहां उपलब्ध हैं. |
| प्राइवसी सैंडबॉक्स को अपनाना | Privacy Sandbox एपीआई का इस्तेमाल करने वाले शुरुआती लोगों ने बताया कि बड़ी कंपनियों ने इस एपीआई को धीरे-धीरे अपनाया है. इस वजह से, टेस्ट लॉन्च पर असर पड़ा है. हालांकि, इसके बावजूद, प्राइवसी सैंडबॉक्स की टीम के साथ मिलकर काम करने के तरीके और सुझावों पर तुरंत कार्रवाई करने की सराहना की गई. | शुरुआती उपयोगकर्ताओं के सुझाव, शिकायत या राय जानकर हमें खुशी होगी. हम शुरुआती उपयोगकर्ताओं के साथ मिलकर काम करने के लिए प्रतिबद्ध हैं. साथ ही, हम इस नेटवर्क के साथ जुड़े रहेंगे और सुझाव, राय, और शिकायतें इकट्ठा करते रहेंगे. इससे हमें यह पता चलेगा कि Privacy Sandbox की टेक्नोलॉजी, नेटवर्क को बेहतर बनाने में किस तरह मदद कर सकती हैं. |
| Chrome टेस्टिंग | टेस्टिंग लेबल हटाने के बाद, Privacy Sandbox की टेस्टिंग को असरदार तरीके से जारी रखने की चिंता. इन लेबल से, तीसरे पक्ष की कुकी बंद करने वाले Chrome (मोड B) और Chrome की सेटिंग में तीसरे पक्ष की कुकी को खुद बंद करने वाले उपयोगकर्ताओं के बीच, ट्रैफ़िक क्वालिटी में काफ़ी अंतर दिखता है. | हमारा जवाब पिछली तिमाहियों के जवाब से मिलता-जुलता है: Privacy Sandbox की टीम को पता है कि कंपनियां कुकी के इस्तेमाल को बंद करने के लेबल का इस्तेमाल करना जारी रखना चाहेंगी. लेबल की उपलब्धता बढ़ाने की प्रोसेस, ऑरिजिन ट्रायल की अवधि बढ़ाने की प्रोसेस जैसी ही है. लेबल की सुविधा को कई बार बढ़ाया गया है. हम कुकी के इस्तेमाल को बंद करने के लेबल के लिए, सहायता को और भी बढ़ाने का प्रस्ताव दे रहे हैं. उपलब्ध होने पर, हम blink-dev पर अपडेट शेयर करेंगे. |
रजिस्टर करना और पुष्टि करना
इस तिमाही में कोई सुझाव, राय या शिकायत नहीं मिली.
काम का कॉन्टेंट और विज्ञापन दिखाना
विषय
| फ़ीडबैक की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| ऑप्ट-इन/आउट करना | क्या Google की इस पुष्टि से कि Google Search, Topics API से ऑप्ट-आउट करने के किसी साइट के फ़ैसले का इस्तेमाल, रैंकिंग सिग्नल के तौर पर नहीं करेगा, Google को Topics API से ऑप्ट-इन करने के किसी साइट के फ़ैसले का इस्तेमाल, रैंकिंग सिग्नल के तौर पर करने से रोका जाएगा? | हमारा जवाब पिछली तिमाहियों के जवाब से मिलता-जुलता है: Privacy Sandbox की टीम ने Search के संगठन से यह समन्वय नहीं किया है या अनुरोध नहीं किया है कि वे Topics API को अपनाने के लिए, वेबसाइटों को पेज रैंकिंग के तौर पर इंसेंटिव दें. Google Search, किसी साइट के Topics API का इस्तेमाल करने या न करने के फ़ैसले को रैंकिंग सिग्नल के तौर पर इस्तेमाल नहीं करेगा. |
| इस्तेमाल की निगरानी | एसएसपी या सामान्य विज्ञापन टेक्नोलॉजी के लिए, निगरानी करने के तरीके का अनुरोध करना. इससे यह पता चलता है कि Topics API को वेब पर लागू करने का इस्तेमाल किया जा रहा है या नहीं. | हम इस सुविधा के लिए सहायता का आकलन कर रहे हैं. अगर यह सुविधा आपके लिए अहम है, तो हम इकोसिस्टम से ज़्यादा सुझाव, राय या शिकायतें पाने के लिए तैयार हैं. |
| निजता | सहमति और फिर से पहचान करने की संभावना के बारे में सवाल. | फ़िलहाल, हम इस समस्या पर यहां चर्चा कर रहे हैं. साथ ही, हम आपके सुझाव, राय या शिकायतों का स्वागत करते हैं. |
Protected Audience API
| फ़ीडबैक की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| PA API और GAM/AdX | Google, किसी ऐसे पब्लिशर को GAM/AdX की कोई मांग नहीं भेजेगा जो किसी दूसरे पब्लिशर के विज्ञापन सर्वर पर भरोसा करना चाहता है. Google को प्रतिस्पर्धी पब्लिशर को, फ़ाइनल नीलामी को कंट्रोल करने के लिए, टॉप लेवल के अन्य PA API नीलामी सेलर चुनने की सुविधा देनी चाहिए. PA API की जानकारी, GAM के लिए उपलब्ध होगी. हालांकि, यह जानकारी प्रतिस्पर्धी एसएसपी के लिए उपलब्ध नहीं होगी. इस वजह से, पब्लिशर GAM में PA API से मिलने वाली डिमांड की परफ़ॉर्मेंस की तुलना नहीं कर पा रहे हैं. जैसे, AdX या PA API में इंटिग्रेट किए गए एसएसपी से मिलने वाली डिमांड की परफ़ॉर्मेंस की तुलना. | Chrome का जवाब: PA API स्टैंडर्ड को आसानी से इस्तेमाल करने के लिए डिज़ाइन किया गया है. इससे अलग-अलग पक्षों को टॉप-लेवल नीलामी चलाने की अनुमति मिलती है. यह विकल्प, पब्लिशर के विज्ञापन सर्वर (GAM या कोई अन्य) और इकोसिस्टम में हिस्सा लेने वाली अन्य कंपनियों के खास तरीके और सुविधाओं पर निर्भर करता है. PA API के निजता पर आधारित डिज़ाइन की वजह से, सभी हिस्सा लेने वालों के लिए, बारीकी से जानकारी देने वाली रिपोर्टिंग लगातार सीमित रहती है. PA API की नीलामी में रिपोर्ट किया गया खास डेटा, सभी उपयोगकर्ताओं के लिए निजता बनाए रखने के उन नियमों और सीमाओं के दायरे में आता है जिन्हें एपीआई ने तय किया है. इनमें सभी एसएसपी भी शामिल हैं. पब्लिशर, परफ़ॉर्मेंस का आकलन करने के लिए, PA API की एग्रीगेट रिपोर्ट का इस्तेमाल करते हैं. इन रिपोर्ट में उपयोगकर्ता की निजता को बनाए रखा जाता है. इससे, PA API के ज़रिए सोर्स की गई मांग के कुल योगदान का आकलन किया जा सकता है. साथ ही, मांग के अन्य चैनलों की तुलना की जा सकती है. यह तुलना, एपीआई के डिज़ाइन में निजता को ध्यान में रखकर बनाए गए सिद्धांतों के मुताबिक की जाती है. Google Ad Manager का जवाब: पब्लिशर को AdX की मांग को ऐक्सेस करने के लिए, GAM के विज्ञापन सर्वर की सुविधा का इस्तेमाल करने की ज़रूरत नहीं है. इसके अलावा, PA API को यह पता नहीं होता कि नीलामी की शुरुआत किसने की है. यह जानकारी, एक सेलर और एक से ज़्यादा सेलर वाले डिज़ाइन, दोनों में काम करती है. |
| टॉप लेवल सेलर | टॉप-लेवल सेलर (टीएलएस) के पास ऐसी जानकारी का ऐक्सेस होता है जिसका ऐक्सेस, कॉम्पोनेंट बेचने वाले किसी भी दूसरे सेलर के पास नहीं होता. इससे, जानकारी के असमान ऐक्सेस को लेकर चिंता पैदा होती है. कोई भी इकाई टीएलएस हो सकती है. हालांकि, AdX की मांग को ऐक्सेस करने के लिए, पब्लिशर को पब्लिशर विज्ञापन सर्वर के तौर पर GAM का इस्तेमाल करना होगा. इससे, पब्लिशर के विज्ञापन सर्वर के तौर पर GAM का इस्तेमाल करने का बढ़ावा मिलता है. इससे Google को प्रतिस्पर्धी फ़ायदा मिलता है. | Chrome का जवाब: PA API के डिज़ाइन से यह तय नहीं होता कि कौनसी इकाई टीएलएस के तौर पर काम कर सकती है. TLS की भूमिका में, नीलामी को मैनेज करना और एपीआई के स्ट्रक्चर के हिसाब से, नीलामी से जुड़ी जानकारी ऐक्सेस करना ज़रूरी है. Google Ad Manager का जवाब: हमने नीलामी में सभी के लिए समानता बनाए रखने पर कई सालों से ध्यान दिया है. साथ ही, हमने यह वादा किया है कि नीलामी में बिड करने से पहले, पब्लिशर के किसी भी ऐसे विज्ञापन स्रोत की कीमत किसी दूसरे खरीदार के साथ शेयर नहीं की जाएगी जिसकी कोई गारंटी नहीं है. इसमें, गारंटी नहीं वाली लाइन आइटम की कीमतें भी शामिल हैं. हमने बाद में, फ़्रेंच कॉम्पिटीशन अथॉरिटी के साथ किए गए अपने वादे में भी इस बात की पुष्टि की है. PA API नीलामियों के लिए, हम अपना वादा निभाना चाहते हैं. इसलिए, हम मल्टी-सेलर नीलामियों में नीलामी पूरी होने से पहले, नीलामी में हिस्सा लेने वाले किसी भी व्यक्ति की बिड को किसी दूसरे व्यक्ति के साथ शेयर नहीं करेंगे. साफ़ तौर पर बता दें कि हम कॉन्टेक्स्ट के हिसाब से होने वाली नीलामी की कीमत, किसी भी कॉम्पोनेंट की नीलामी के साथ शेयर नहीं करेंगे. इसमें हमारी नीलामी भी शामिल है. इस बारे में इस अपडेट में बताया गया है. इसके अलावा, हम अपनी नीलामी के हिस्से के तौर पर, कॉम्पोनेंट की नीलामी के कॉन्फ़िगरेशन की जानकारी का इस्तेमाल नहीं करते. इसमें, खरीदारों से एसएसपी को मिले सिग्नल भी शामिल हैं. इसके अलावा, जैसा कि ऊपर बताया गया है, GAM के लिए ज़रूरी नहीं है कि पब्लिशर, AdX की मांग को ऐक्सेस करने के लिए, उसके विज्ञापन सर्वर की सुविधा का इस्तेमाल करें. आखिर में, जैसा कि Google की 2024 की दूसरी तिमाही / तीसरी तिमाही की रिपोर्ट में पहले बताया गया था, Google के बायसाइड प्लैटफ़ॉर्म – Google Ads (पहले इसे AdWords कहा जाता था) और DV360 – PA API के ज़रिए, Google से बाहर के एक्सचेंज से इंप्रेशन खरीदते हैं. |
| PA API और GAM/AdX | पब्लिशर के लिए, 100% इन्वेंट्री पर PA API को चालू करना मुश्किल है. इसकी वजह यह है कि विकल्प के लेबल से इसका मकसद साफ़ तौर पर नहीं पता चलता. जिन एसएसपी के लिए इन्वेंट्री को ऐक्सेस करने का मुख्य तरीका, मल्टी-लेवल नीलामी है और GAM, टीएलएस के तौर पर काम करता है उनके लिए GAM के बिना, PA API के ज़रिए टेस्ट करने या कमाई करने का कोई तरीका नहीं है. | Chrome का जवाब: PA API स्टैंडर्ड में, टेक्निकल भूमिकाओं (जैसे, टीएलएस और कॉम्पोनेंट सेलर) और नीलामी की प्रोसेस के बारे में बताया गया है. इससे यह तय करने में मदद मिलती है कि कौनसे प्लैटफ़ॉर्म इन भूमिकाओं को निभाएं. PA API फ़्रेमवर्क का इस्तेमाल करके, प्रोग्राम में हिस्सा लेने की सुविधा देने के लिए, कॉन्फ़िगरेशन, समन्वय, और समझौते जैसी ऑपरेशनल गतिविधियों को लागू करने वाले पक्ष (पब्लिशर, एसएसपी, टीएलएस सेवा देने वाली कंपनियां) उन्हें मैनेज करते हैं. Google Ad Manager का जवाब: हमारे सहायता केंद्र में बताया गया है कि Ad Manager, पब्लिशर को ऐसा कंट्रोल देता है जिससे वे Google के अलावा अन्य कॉम्पोनेंट सेलर, जैसे कि अन्य एसएसपी के साथ टेस्टिंग को चालू कर सकें. ऐसा, पब्लिशर की 100% इन्वेंट्री पर किया जा सकता है, जहां एपीआई का इस्तेमाल किया जा सकता है. इससे, GAM के लागू होने वाले किसी भी सैंपलिंग या थ्रॉटलिंग को बदला जा सकता है. अगर कोई पब्लिशर इस कंट्रोल को चालू करता है, तो जब भी Google से बाहर का कोई कॉम्पोनेंट सेलर नीलामी का कॉन्फ़िगरेशन उपलब्ध कराएगा, तब GAM उस कॉम्पोनेंट की नीलामी के साथ टॉप-लेवल नीलामी चलाने की कोशिश करेगा. हालांकि, इसके लिए ज़रूरी है कि पब्लिशर ने ऐसा करने के लिए उपयोगकर्ता की सहमति ली हो. GAM, पब्लिशर को साफ़ तौर पर बताता है कि इस कंट्रोल से परफ़ॉर्मेंस पर असर पड़ सकता है, ताकि पब्लिशर सही फ़ैसला ले सके. |
| सर्वर-साइड बनाम उपयोगकर्ता के डिवाइस पर | बिडिंग और नीलामी (बी एंड ए) जैसे सर्वर-साइड समाधानों की मदद से, निजता बनाए रखते हुए ट्रैफ़िक-शेपिंग की समस्या को हल किया जा सकता है. सर्वर-साइड के समाधान ही आगे बढ़ने का एकमात्र सही तरीका हैं. Google को डिवाइस पर मौजूद समाधानों को छोड़ देना चाहिए. | Privacy Sandbox का मकसद, सर्वर-साइड (B&A सेवाएं) और डिवाइस पर होने वाली नीलामी के समाधानों, दोनों के साथ काम करना है. इससे, विज्ञापन टेक्नोलॉजी की अलग-अलग ज़रूरतों और इस्तेमाल के उदाहरणों को पूरा करने के विकल्प मिलते हैं. |
| नीलामी की सुरक्षा | PA API बिड पर होने वाले हमले, डिवाइस पर बिडिंग और नीलामियों के लिए बुनियादी तौर पर अमान्य हैं. हिस्सेदारों के मुताबिक, इस समस्या को हल नहीं किया गया है. वे तकनीकी तौर पर इस बात की गारंटी देने का अनुरोध करते रहते हैं कि PA API बिड में छेड़छाड़ न की जाए. साथ ही, वे रीयल-टाइम में समस्या का पता लगाने और बेहतर तरीके से डीबग करने के लिए, बेहतर डीबग मोड का अनुरोध करते रहते हैं. | Privacy Sandbox का मुख्य मकसद, PA API की नीलामी की सुरक्षा को पक्का करना है. इसमें संभावित हमलों को कम करना भी शामिल है. एपीआई के डिज़ाइन में, सुरक्षा से जुड़े उपाय शामिल हैं. हम खास समस्याओं पर तकनीकी चर्चा के लिए तैयार हैं. हमने मई 2024 में, W3C के धोखाधड़ी रोधी कम्यूनिटी ग्रुप की मीटिंग के दौरान, PA API पर होने वाले संभावित हमलों की पूरी सूची पेश की थी और उनसे बचने के तरीकों के बारे में बातचीत की थी. हम इस बारे में आगे चर्चा करने और सुझाव, राय या शिकायत देने के लिए तैयार हैं कि 'PA API बिड पर होने वाले संभावित हमले' किस तरह की समस्याएं पैदा करते हैं. |
| बिना कुकी वाला ट्रैफ़िक | क्या जांच या अन्य कामों के लिए, सिर्फ़ कुकीलेस ट्रैफ़िक पर PA API को चालू करने का कोई तरीका होगा? | विज्ञापन टेक्नोलॉजी से यह पता चल सकता है कि 3PC मौजूद हैं या नहीं. इस बारे में ज़्यादा जानकारी यहां दी गई है. |
| सीट आईडी | सीट आईडी के प्रस्ताव के बारे में, ज़्यादातर बिड रिक्वेस्ट के लिए सीट आईडी की जानकारी ज़रूरी है. इससे, सीट आईडी को क्रिएटिव रजिस्ट्रेशन से जोड़ने को लेकर चिंता होती है. इसके अलावा, क्या यह सिर्फ़ "मुख्य विज्ञापन" पर लागू होगा या कॉम्पोनेंट विज्ञापनों पर भी? | BuyerAndSellerReportingId के प्रस्ताव से, मुख्य विज्ञापन के लिए क्रिएटिव रजिस्टर करने के दौरान, खरीदार के सीट आईडी की कमी से जुड़ी समस्या हल होती है. इस आइडेंटिफ़ायर का मकसद, सेलर को खरीदार का सीट आईडी बताना है. हम कॉम्पोनेंट विज्ञापनों के लिए सहायता का आकलन कर रहे हैं. |
| मॉनिटरिंग और रिपोर्टिंग | रीयल-टाइम मॉनिटरिंग (RTM) की सुविधा का अनुरोध, ताकि (1) रद्द की गई नीलामियों के लिए RTM रिपोर्ट भेजी जा सकें. साथ ही, (2) ब्राउज़र से अपने-आप भरी जाने वाली नई बकेट से यह पता चल सके कि रद्द करने का क्या तरीका अपनाया गया. | ऐसा लगता है कि आरटीएम, हिस्सा लेने की दर की जांच करने के लिए सही समाधान नहीं है. आरटीएम को कम इंतज़ार वाले मॉनिटरिंग एपीआई के तौर पर डिज़ाइन किया गया है, ताकि अचानक होने वाली और कुछ समय के लिए होने वाली गंभीर रुकावटों का पता लगाया जा सके. वहीं, हिस्सा लेने की दर के लिए, इंतज़ार के समय की रिपोर्टिंग की ज़रूरत नहीं होती. साथ ही, यह अचानक होने वाली रुकावट नहीं होती. हिस्सा लेने की दरों से जुड़ी समस्याओं के बारे में, खरीदार उन सेलर से सबसे बेहतर तरीके से जवाब पा सकते हैं जिनके साथ वे मिलकर काम करते हैं. ब्राउज़र की मदद से जांच करने वाले खरीदारों से, इस बारे में जवाब नहीं मिलता. इसके अलावा, रद्द की गई नीलामियां बहुत आम हैं. अगर ब्राउज़र हर रद्द की गई नीलामी से आरटीएम रिपोर्ट जनरेट करता है, तो यह असल रुकावटों के लिए आरटीएम रिपोर्ट को दबा सकता है. |
| दस्तावेज़ जानकारी |
PA API के एक्सप्लेनर में दस्तावेज़ से जुड़ी गड़बड़ी की रिपोर्ट, जिसमें बताया गया है कि नॉन्स एक यूयूआईडी स्ट्रिंग होनी चाहिए, लेकिन यह असल में एक प्रॉमिस दिखाता है. | इस बारे में ज़्यादा जानकारी यहां दी गई है. |
| फ़्रीज़ किया गया कॉन्टेक्स्ट |
फ़्रीज़ किए गए कॉन्टेक्स्ट का इस्तेमाल करते समय, (1) बंडलिंग, (2) बाहरी लाइब्रेरी, और (3) काम न करने वाले डेटा टाइप से जुड़ी समस्याओं और चुनौतियों को हल करने के लिए कौनसे विकल्प उपलब्ध हैं? | हमने इस सवाल का जवाब यहां दिया है. |
| खास जानकारी | Private Aggregation API में, contributeToHistogramOnEvent ऑपरेशन जोड़ा गया है. इस वजह से, PA API में डेफ़िनिशन, ओवरलोड किया गया ऑपरेशन बन गया. साथ ही, वेब आईडीएल ऑपरेशन "इंटरफ़ेस, आंशिक इंटरफ़ेस [...] में ओवरलोड नहीं होने चाहिए". इसलिए, यह डेफ़िनिशन अब अमान्य है. | इस समस्या से पता चलता है कि PA API और Private Aggregation के स्पेसिफ़िकेशन में कुछ समय के लिए अंतर है. ऐसा तब होता है, जब हम दोनों में मिलते-जुलते बदलावों को मर्ज करते हैं. हमने इस समस्या को ठीक करने के लिए, पुल रिक्वेस्ट को मर्ज कर दिया है. |
| एक जैसी दिलचस्पी वाले ग्रुप | कैंपेन के बंद होने पर, किसी इंटरेस्ट ग्रुप (आईजी) की बिडिंग में हिस्सा लेने की सुविधा को खत्म करने के लिए, सुझाए गए और संसाधनों का ज़्यादा से ज़्यादा फ़ायदा पाने वाले तरीके के बारे में दिशा-निर्देश का अनुरोध करें. | हम आपको कुछ सुझाव दे सकते हैं: हमारा मानना है कि रीयल-टाइम बिडिंग सिग्नल का इस्तेमाल करके, generateBid() को बिडिंग बंद करने की सूचना देने के लिए, सबसे कम इंतज़ार, सबसे कम स्थायी, लेकिन कम संसाधन रिलीज़ करने वाला तरीका सबसे अच्छा है. कम रिसॉर्स का इस्तेमाल करने वाला दूसरा विकल्प, रीयल-टाइम बिडिंग सिग्नल के जवाब में उस आईजी के लिए नेगेटिव प्राथमिकता सेट करना होगा. इससे generateBid() को ट्रिगर होने से भी रोका जा सकेगा. तीसरा विकल्प, IG से विज्ञापन हटाना है. इससे भी कम रिसॉर्स का इस्तेमाल होता है. बिना विज्ञापन वाले आईजी में generateBid() चालू नहीं होता. चौथा विकल्प, IG से biddingLogicURL को हटाना है. इससे भी कम रिसॉर्स का इस्तेमाल होता है. इस स्थिति में, IG को फिर से चालू करने के लिए, उसे अपडेट किया जा सकता है या उसमें फिर से शामिल हुआ जा सकता है. IG छोड़ने के लिए, leaveAdInterestGroup() या clearOriginJoinedAdInterestGroups() का इस्तेमाल करें. इसके अलावा, IG की समयसीमा खत्म होने पर भी ऐसा किया जा सकता है.जैसा कि ऊपर हाइलाइट किया गया है, अलग-अलग विकल्पों के लिए, इंतज़ार का समय और संसाधनों की खपत अलग-अलग होती है. विज्ञापन टेक्नोलॉजी कंपनियां, अपने खास इस्तेमाल के उदाहरणों के लिए सबसे अच्छा विकल्प चुन सकती हैं. |
| ऑडियंस | बनाई गई ऑडियंस पर लॉजिकल ऑपरेशन चलाने के लिए, किसी तरीके का अनुरोध करना. उदाहरण के लिए, IG A और B के इंटरसेक्शन को टारगेट करने की सुविधा | PA API की मदद से, एक ही साइट की ऑडियंस पर लॉजिकल ऑपरेशन चलाए जा सकते हैं. फ़िलहाल, अलग-अलग साइटों पर ऑडियंस के लॉजिकल ऑपरेशन काम नहीं करते. ऐसा निजता से जुड़ी वजहों से होता है. इस बारे में हमारे निजता मॉडल में बताया गया है. हम इस क्षेत्र में लगातार रिसर्च कर रहे हैं और आगे भी इस बारे में अपडेट शेयर करते रहेंगे. |
| सुविधा का अनुरोध | अतिरिक्त बिड पर लगी उस पाबंदी को हटाने का प्रस्ताव जिस पर टीएलएस की जानकारी पहले से होनी चाहिए. | फ़िलहाल, हम इस प्रस्ताव पर यहां चर्चा कर रहे हैं. साथ ही, हम आपके सुझाव, राय या शिकायतों का स्वागत करते हैं. |
| Chrome पर तीन पीसी के लिए अपडेट किया गया तरीका | क्या PA API जैसे प्राइवसी सैंडबॉक्स एपीआई, Chrome के स्टैबल वर्शन का इस्तेमाल करने वाले सभी लोगों के लिए उपलब्ध रहेंगे या ये एपीआई (या एपीआई का सबसेट) सिर्फ़ उन लोगों के लिए उपलब्ध होंगे जिन्होंने 3PCs को अस्वीकार किया है? | हमारा मकसद यह नहीं है कि उपयोगकर्ता के तीसरे पक्ष की कुकी को अस्वीकार करने के फ़ैसले का असर, Chrome के स्टैबल वर्शन में Privacy Sandbox API की उपलब्धता पर पड़े. |
| बेहतर सिग्नलिंग | क्या कोई ऐसी सुविधा जोड़ी जा सकती है जिससे पता चल सके कि TLS, PA API नीलामी चलाना चाहता है या नहीं? | हम इस सुविधा के लिए सहायता उपलब्ध कराने पर काम कर रहे हैं. समयावधि के बारे में ज़्यादा जानकारी, उपलब्ध होने पर शेयर की जाएगी. इस अनुरोध के बारे में हमें और सुझाव, शिकायत या राय भेजें. |
| सौदा आईडी | डील आईडी के प्रस्ताव में, केवी सर्वर की ज़रूरत से जुड़ी समस्या, सर्वर-साइड की प्रोसेस हो सकती है. इसमें ज़्यादा समय और पैसे लग सकते हैं. | डील आईडी के प्रस्ताव की मदद से, एसएसपी, पीए नीलामियों के दौरान, चुने गए डील आईडी के मेटाडेटा के बारे में, की-वैल्यू सर्वर से क्वेरी कर सकते हैं. इससे उन्हें डील से जुड़े सभी मेटाडेटा को डिवाइस पर पहले से लोड करने की ज़रूरत नहीं पड़ती. यह प्रस्ताव, एसएसपी के अनुरोधों के जवाब में तैयार किया जा रहा है. हम यहां, इकोसिस्टम के बारे में अन्य सुझाव, शिकायत या राय का स्वागत करते हैं. हम समझते हैं कि की-वैल्यू सर्वर को सेट अप करने के लिए काम करना पड़ता है. हालांकि, हमारा मानना है कि कुल मिलाकर, विज्ञापन टेक्नोलॉजी कंपनियों को इससे फ़ायदा होगा. इस प्रोसेस को आसान बनाने के लिए, हमें सुझाव और राय भेजें. |
| अलग-अलग Instagram खातों के लिए फ़्रीक्वेंसी कैपिंग | PA API की मदद से, अलग-अलग Instagram खातों के लिए फ़्रीक्वेंसी कैपिंग का अनुरोध करना. | क्रॉस-आईजी फ़्रीक्वेंसी कैपिंग में निजता से जुड़ी ऐसी समस्याएं हैं जिनका समाधान हम नहीं कर पाए हैं. अगर आपके लिए यह सुविधा ज़्यादा प्राथमिकता है, तो हमें इस बारे में और सुझाव/राय दें या शिकायत करें. |
| डील आईडी और सीट आईडी की रिपोर्टिंग | एग्रीगेट रिपोर्टिंग में डील या सीट आईडी पाने की सुविधा का अनुरोध करना. | यहां हम रिपोर्टिंग आईडी की सुविधाओं पर काम कर रहे हैं. इनकी मदद से, डील और सीट आईडी की रिपोर्टिंग की जा सकेगी. selectedBuyerAndSellerReportingId, reportResult() को दिया जाता है.इसलिए, इवेंट-लेवल रिपोर्टिंग की मदद से, इसकी रिपोर्ट करना सबसे आसान होता है. जैसे, sendReportTo() को पास किए गए यूआरएल में डील आईडी को कोड में बदलना. अगर एग्रीगेट की गई रिपोर्टिंग का इस्तेमाल किया जाना है, तो ऐसा भी किया जा सकता है. रिपोर्टिंग आईडी की सुविधा, फ़िलहाल Chrome के स्टेबल चैनल के 10% ट्रैफ़िक के लिए लाइव है. हम इस सुविधा को 100% क्रिएटर्स के लिए उपलब्ध कराने पर विचार कर रहे हैं. |
| एक जैसी दिलचस्पी वाले ग्रुप | आईजी चुनने और उसका आकलन करने, दोनों में प्राथमिकता के एक ही क्रम का इस्तेमाल करें. साथ ही, आकलन के सभी मोड में भी प्राथमिकता के उसी क्रम का इस्तेमाल करें. | फ़िलहाल, हम इस बारे में यहां चर्चा कर रहे हैं. अगर आपके पास कोई और सुझाव है, तो हमें बताएं. |
| एक जैसी दिलचस्पी वाले ग्रुप | Privacy Sandbox API का इस्तेमाल बढ़ाने के लिए, ऑडियंस ऐक्टिवेशन और डेलिगेशन का इस्तेमाल करने का सुझाव. | हमें कई हिस्सेदारों से इस अनुरोध के बारे में पता है. हम इस समस्या को हल करने के लिए काम कर रहे हैं. हमें इस बारे में और सुझाव, शिकायत या राय मिल सकती है. |
| एक जैसी दिलचस्पी वाले ग्रुप | PA API IG बनाने से जुड़ी समस्याएं. खास तौर पर, एक से ज़्यादा खरीदारी के लिए या पब्लिशर की ओर से काम करते समय, अधिकार देने और मालिकाना हक से जुड़ी समस्याएं. | हमें कई हिस्सेदारों से, आईजी के ज़्यादा बेहतर प्रतिनिधित्व के लिए अनुरोध मिला है. साथ ही, हमें लगता है कि एसएसपी इस प्रोसेस में अहम भूमिका निभा सकते हैं. हम सबसे अच्छा समाधान ढूंढने के लिए रिसर्च कर रहे हैं, ताकि अलग-अलग पक्ष ऑडियंस एक्सटेंशन की प्रोसेस में हिस्सा ले सकें. हमें इस बारे में और सुझाव, शिकायत या राय मिल सकती है. |
| क्लाइंट-साइड परफ़ॉर्मेंस | इंफ़्रास्ट्रक्चर के खर्च और इंतज़ार के समय को ऑप्टिमाइज़ करने के लिए, trustedBiddingSignals के क्लाइंट-साइड कैश मेमोरी को आसान बनाने के बारे में दिशा-निर्देश का अनुरोध करें. | फ़िलहाल, हम इस बारे में यहां चर्चा कर रहे हैं. अगर आपके पास कोई और सुझाव है, तो हमें बताएं. |
सुरक्षित नीलामी (B&A Services)
| फ़ीडबैक की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| K/V सेवाएं | ब्राउज़र से सेलर के KV सर्वर पर किए गए अनुरोधों को एक साथ कैसे भेजा जाता है? किसी सेलर के लिए, ब्राउज़र से अनुरोध कैसा दिखेगा - GET या POST अनुरोध? इसके अलावा, क-अनामिटी की ज़रूरी शर्तों के बारे में कुछ जानकारी देने की ज़रूरत है. | v1 के लिए, Chrome, सेलर की KV सेवा को एक GET अनुरोध भेजता है. इससे, अनुरोध के क्वेरी पैरामीटर में सिग्नल के साथ trustedScoringSignalsURL को फ़ेच किया जा सकता है. पैरामीटर में hostname, renderUrls, adComponentRenderUrls, और experimentGroupId शामिल होंगे. फ़िलहाल, हम क्रिएटिव स्कैनिंग के लिए ज़्यादा जानकारी भेजने के लिए, कुछ एक्सटेंशन आज़मा रहे हैं. हालांकि, इसे अभी लॉन्च नहीं किया गया है. maxTrustedScoringSignalsURLLength को 0 पर सेट करने पर, Chrome सभी सिग्नल को एक ही अनुरोध में बैच कर सकता है. ऐसा करने पर, हो सकता है कि वह अपने सर्वर पर यूआरएल की लंबाई की तय सीमा से ज़्यादा हो जाए. हालांकि, इसकी कोई गारंटी नहीं है. फ़िलहाल, Chrome एक ही बैच में ऐसे अनुरोध शामिल करता है जो एक-दूसरे से 10 मिलीसेकंड के अंदर भेजे जा सकते हैं. हालांकि, हम इस प्रोसेस को ऑप्टिमाइज़ करने के तरीके पर काम कर रहे हैं.trustedScoringSignals का इस्तेमाल करते समय, यह याद रखना ज़रूरी है कि Chrome, हेडर को कैश मेमोरी में सेव करता है. Stale-While-Revalidate "Cache-Control" हेडर जैसे हेडर, Chrome को कैश मेमोरी में सेव की गई कॉपी का इस्तेमाल करने की अनुमति देकर, औसत इंतज़ार का समय कम कर सकते हैं. साथ ही, अगली नीलामी के लिए कैश मेमोरी को अपडेट भी कर सकते हैं. इससे, क्रिटिकल पाथ से सिग्नल फ़ेच करने की प्रोसेस को असरदार तरीके से हटाया जा सकता है.आखिर में, के-अनामिटी के बारे में, एक्सप्लेनर का खास सेक्शन पुराना लग रहा है. शुरुआत में, हमने भरोसेमंद सिग्नल के यूआरएल के लिए, k-anonymous (किसी व्यक्ति की पहचान छिपाने के लिए इस्तेमाल होने वाला तरीका) की ज़रूरी शर्त रखी थी. हालांकि, बाद में हमने इस शर्त को हटा दिया. हम इस वाक्य को एक्सप्लेनर से हटा देंगे. |
| B&A Services | B&A के नए वर्शन पर अपग्रेड करने में काफ़ी समय लगता है. बिल्ड प्रोसेस को तेज़ी से पूरा करने या पहले से तैयार इमेज का इस्तेमाल करने से फ़ायदा होगा. | विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली कंपनियां, बाइनरी को खुद बना सकती हैं और दिए गए हैश का इस्तेमाल करके पुष्टि कर सकती हैं. हम आने वाले समय में, पहले से बने आर्टफ़ैक्ट उपलब्ध कराने या बिल्ड में लगने वाले समय को कम करने की संभावनाओं पर विचार करेंगे. |
| एपीआई की सुविधा का अनुरोध | स्थानीय डेवलपमेंट और टेस्टिंग को आसान बनाने के लिए, बिडिंग और नीलामी सेवाओं (B&A) की बिल्ड स्क्रिप्ट, कंटेनर इमेज, और कॉल करने वाले टूल के लिए macOS के साथ काम करने की सुविधा का अनुरोध. | फ़िलहाल, amd64 के साथ काम करने वाले वर्शन का इस्तेमाल किया जा सकता है. यह वर्शन, काम करने वाले क्लाउड प्लैटफ़ॉर्म (GCP और AWS) पर डिप्लॉय करने के लिए काफ़ी है. आने वाले समय में, हम अन्य आर्किटेक्चर के लिए भी सहायता उपलब्ध करा सकते हैं. |
| AWS | क्या प्रोडक्शन बिल्ड के लिए, IAM भूमिकाएं बनाना ज़रूरी है? | हां, कोऑर्डिनेटर के साथ सही तरीके से बातचीत करने और ज़रूरी अनुमतियां पाने के लिए, IAM भूमिकाएं ज़रूरी हैं. इन कुंजियों का इस्तेमाल, ProtectedAudienceInput के सिफरटेक्स्ट को डिक्रिप्ट करने के लिए किया जाता है. यह सिफरटेक्स्ट, डिवाइस पर यहां बताए गए तरीके से जनरेट होता है. इसके अलावा, इन भूमिकाओं के लिए ज़रूरी है कि वे उन कोऑर्डिनेटर के साथ प्रोडक्शन बिल्ड के लिए सर्वर/टीईई की पुष्टि कर सकें. इस बारे में ज़्यादा जानकारी के लिए, हमारी सेल्फ़-सर्विस गाइड देखें. |
| B&A फ़्लैग | उपलब्ध B&A फ़्लैग की परिभाषाओं को दस्तावेज़ में शामिल करने का अनुरोध किया जा रहा है. फ़िलहाल, ये परिभाषाएं Terraform कोड, सीसी फ़ाइलों, और प्रोटो फ़ाइलों में मौजूद हैं. हालांकि, विज्ञापन टेक्नोलॉजी को इन फ़्लैग के दस्तावेज़ से फ़ायदा मिलेगा. इससे, उन्हें डिप्लॉयमेंट को पसंद के मुताबिक बनाने का तरीका समझने में मदद मिलेगी. | हम Terraform फ़्लैग की जानकारी को दस्तावेज़ में शामिल करने की संभावना की जांच कर रहे हैं. अगर आपके पास इस बारे में कोई और सुझाव, शिकायत या राय है, तो यहां बताएं. |
| AWS बिडिंग सेवा |
AWS पर बिडिंग सेवा और डिफ़ॉल्ट लॉगिंग व्यवहार और कॉन्फ़िगरेशन के बारे में दिशा-निर्देश चाहिए. | हमारा सुझाव है कि टीईई (जैसे, बिडिंग सेवा) में अपनी बिडिंग सेवाओं को डीबग करने के लिए, विज्ञापन टेक्नोलॉजी की सहमति वाली डीबगिंग का इस्तेमाल करें. इससे, आपको ज़्यादा जानकारी वाली लॉगिंग की सुविधा चालू करने और सीधे अपने क्लाइंट से, खास टेस्ट अनुरोधों के लिए अनुरोध/जवाब का डेटा कैप्चर करने में मदद मिलती है. इससे, डीबग करने में मदद मिलती है. |
| टीईई के/वी दस्तावेज़ |
डेवलपर साइट पर बताए गए टीकेवी लागू करने की प्रोसेस के बारे में जानकारी चाहिए. | हम टीईई का इस्तेमाल करने की ज़रूरी शर्त लागू करने से पहले, आपको इसकी सूचना दे देंगे. तब तक, रीयल-टाइम में पासकोड/वैल्यू सिग्नल के लिए, अपने सर्वर का इस्तेमाल किया जा सकता है. |
| B&A टेस्टिंग और विश्लेषण | बीए और विश्लेषण की जांच करना अब भी महंगा है और ऐसा लगता है कि इसे प्रोडक्शन के लिए तैयार नहीं किया गया है. | इस बारे में ज़्यादा जानकारी पाने के लिए, हमें लागत के विश्लेषण और प्रोडक्शन के लिए तैयार होने के आकलन से जुड़े फ़ैक्टर के बारे में ज़्यादा जानकारी चाहिए. |
| भरोसेमंद सर्वर ऑप्टिमाइज़ेशन | कॉम्पोनेंट सेलर के लिए खास तौर पर बनाए गए पैरामीटर को एक inputsPerSeller पैरामीटर में मर्ज करने का प्रस्ताव. इसकी वैल्यू के लिए, JSON स्ट्रिंग का इस्तेमाल किया जाएगा. | हम इस प्रस्ताव पर चर्चा कर रहे हैं. अगर आपके पास कोई सुझाव, राय या शिकायत है, तो यहां बताएं. |
| सुरक्षा | बीएंडए का इस्तेमाल करके, टीकेवी से जुड़े सुरक्षा जोखिमों को कैसे कम किया जाता है? | टीकेवी पर बाहरी कॉल को रोका जा सकता है. फ़िलहाल, GCP पर यह सुविधा पूरी तरह से काम करती है और इसे कॉन्फ़िगर किया जा सकता है. AWS के लिए, AWS App Mesh की सुविधा बंद होने की वजह से, अतिरिक्त सहायता विकसित करने की ज़रूरत है. इससे पहले, AWS App Mesh की मदद से, इस सुविधा को चालू किया जा सकता था. यहां हमें अपने सुझाव, शिकायत या राय भेजें. |
| B&A Services | B&A ऑप्टिमाइज़ेशन के लिए, एचटीटीपी स्ट्रीमिंग की वैल्यू के बारे में जानकारी/कम्यूनिकेशन के बारे में साफ़ तौर पर बताने का अनुरोध. | Privacy Sandbox, बीए (बिडिंग और विज्ञापन) डेटा को ट्रांसफ़र करने के लिए स्ट्रीमिंग की सुविधाओं का इस्तेमाल करता है. इससे, विज्ञापन टेक्नोलॉजी का इस्तेमाल करने वाले लोगों के लिए, इंतज़ार का समय कम हो जाता है. मिक्स मोड के मामले में, परफ़ॉर्मेंस ऑप्टिमाइज़ेशन ज़रूरी नहीं है. |
| Prebid | पारिस्थितिकी तंत्र के लिए PA API की बिडिंग और ऑप्टिमाइज़ेशन की सुविधाओं को चालू करने के लिए, ओपन सोर्स Prebid लाइब्रेरी में योगदान देने के बारे में अपडेट का अनुरोध करें. | Chrome ने मार्च 2025 में, Prebid के लिए प्रीफ़र्ड ऑप्टिमाइज़ेशन को स्टैबल वर्शन में लॉन्च किया था. इसकी जानकारी B&A के सार्वजनिक रोडमैप में दी गई है (मार्च 2025 देखें). |
| ट्रैफ़िक शेपिंग | B&A को मिले कॉन्टेक्स्ट सिग्नल को लॉग करने के लिए, तरीकों का अनुरोध करें. इससे यह बेहतर तरीके से समझा जा सकेगा कि आईजी कब चालू हो रहे हैं और कॉन्टेक्स्ट के हिसाब से जवाब देने के लिए, "बिड करने का इंटेंट" लॉजिक को बेहतर बनाया जा सकेगा. इससे, "बेकार ट्रैफ़िक" (जिसे ट्रैफ़िक शेपिंग भी कहा जाता है) से बचने के लिए, नेटवर्क संसाधनों का बेहतर तरीके से इस्तेमाल किया जा सकता है. | फ़िलहाल, हम एक प्रस्ताव पर चर्चा कर रहे हैं. इसके बारे में यहां बताया गया है. अगर आपके पास कोई सुझाव या राय है, तो हमें बताएं. |
| दस्तावेज़ जानकारी |
B&A टेस्ट इंटिग्रेशन सेटअप के दौरान, 'Service/Vsock proxy is not reachable' गड़बड़ी का पता चला है. इस बारे में जानकारी चाहिए. | ऐसा, कम से कम मेमोरी की ज़रूरतों की वजह से होता है.इस ज़रूरत को दिखाने के लिए, AWS कॉन्फ़िगरेशन के बारे में बताने वाला लेख अपडेट किया गया है. |
डिजिटल विज्ञापनों को मेज़र करना
एट्रिब्यूशन रिपोर्टिंग (और अन्य एपीआई)
| फ़ीडबैक की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| रीयल-टाइम डेटा | रीयल-टाइम डेटा की कमी से, इंडस्ट्री में मौजूद सभी लोगों पर असर पड़ता है. रीयल-टाइम डेटा में देरी होना, विज्ञापन देने वालों के लिए एक गंभीर समस्या है. इसलिए, खरीदार उन प्लैटफ़ॉर्म पर चले जाते हैं जिनमें Google Analytics है. ऐसा इसलिए, क्योंकि सिर्फ़ यहां उन्हें ऑडियंस तक पहुंचने का सबूत मिल सकता है. | Attribution Reporting API (ARA) का हिस्सा होने वाले रीयल-टाइम डेटा में होने वाली देरी को निजता बनाए रखने के तरीके के तौर पर लागू किया जाता है. इससे, विज्ञापन टेक्नोलॉजी कंपनियों को सभी साइटों पर उपयोगकर्ताओं को ट्रैक करने के लिए, इवेंट-लेवल की रिपोर्ट का इस्तेमाल करने की सुविधा कम मिलती है. हालांकि, ARA, एट्रिब्यूशन रिपोर्ट को डिलीवर करने के तरीके में बदलाव करने की सुविधा देता है. इसके तहत, इवेंट-लेवल रिपोर्ट के लिए, कम से कम एक घंटे की रिपोर्ट विंडो की अनुमति दी जाती है. साथ ही, एग्रीगेट रिपोर्ट को विज्ञापन टेक्नोलॉजी कंपनियों को तुरंत भेजने का विकल्प दिया जाता है. |
| एपीआई प्रयोग | क्रॉस वेब ऐप्लिकेशन एट्रिब्यूशन फ़्लो के लिए सही कॉन्फ़िगरेशन की पुष्टि का अनुरोध करें. खास तौर पर, जब वेब-टू-वेब और वेब-टू-ऐप्लिकेशन एट्रिब्यूशन को एक साथ चलाया जा रहा हो. | वेब-टू-वेब और वेब-टू-ऐप्लिकेशन कैंपेन को एक साथ चलाते समय, विज्ञापन टेक्नोलॉजी को हर सोर्स या ट्रिगर को रजिस्टर करने के लिए सिर्फ़ एक प्लैटफ़ॉर्म चुनना चाहिए, ताकि दो बार गिनती न हो. हमारा सुझाव है कि जहां भी हो सके वहां ऑपरेटिंग सिस्टम (ओएस) का इस्तेमाल करें. ऐसा इसलिए, क्योंकि ओएस में वेब-टू-वेब और वेब-टू-ऐप्लिकेशन, दोनों तरह के एट्रिब्यूशन की सुविधा होती है. हालांकि, इसके लिए ज़रूरी है कि वेब सोर्स और ट्रिगर को सही तरीके से असाइन किया गया हो. इसका मतलब है कि सोर्स के लिए Attribution-Reporting-Register-OS-Source हेडर और ट्रिगर के लिए Attribution-Reporting-Register-OS-Trigger हेडर का इस्तेमाल करके जवाब दिया जाएगा. Attribution-Reporting-Support हेडर का इस्तेमाल करके, यह पता लगाया जा सकता है कि Chrome और/या Android-लेवल पर सहायता उपलब्ध है या नहीं. Attribution-Reporting-Info हेडर तब काम आता है, जब अनुरोध में Attribution-Reporting-Support हेडर मौजूद न हो. ऐसे में, ब्राउज़र उपयोगकर्ता के डिवाइस पर प्लैटफ़ॉर्म सहायता की उपलब्धता के आधार पर, प्लैटफ़ॉर्म रजिस्ट्रेशन का फ़ैसला लेगा. |
| एपीआई स्पेसिफ़िकेशन | Attribution Reporting API की मदद से सेट किए गए Attribution-Reporting-Support एचटीटीपी अनुरोध हेडर के बारे में जानकारी चाहिए. साथ ही, यह भी जानना है कि क्या हेडर में वेब और ओएस, दोनों की कुंजियां होनी चाहिए. भले ही, प्लैटफ़ॉर्म कोई भी हो. | Attribution-Reporting-Support हेडर, ब्राउज़र के "GREASE" पैरामीटर जोड़ने पर निर्भर करता है. इससे यह पक्का होता है कि सर्वर, स्पेसिफ़िकेशन के मुताबिक स्ट्रक्चर्ड हेडर पार्स करने वाले टूल का इस्तेमाल करते हैं. इस हेडर के लिए, सिर्फ़ स्ट्रक्चर्ड-डिक्शनरी कीवर्ड का इस्तेमाल किया जाना चाहिए. फ़िलहाल, वैल्यू और पैरामीटर का इस्तेमाल नहीं किया जा रहा है. इसका उदाहरण यहां देखें. |
| 3PC पर आधारित रिपोर्टिंग | विज्ञापन कैंपेन में ARA और 3PC के बीच मेज़रमेंट में अंतर की समस्या को हल करने का तरीका जानने के लिए अनुरोध किया जा रहा है. | ARA, दो तरह की डीबग रिपोर्ट के साथ काम करता है. इनका इस्तेमाल, अंतर की समस्या को हल करने और डीबग करने के लिए किया जा सकता है. एट्रिब्यूशन-सक्सेस डीबग रिपोर्ट का इस्तेमाल, मेज़रमेंट की अन्य टेक्नोलॉजी के नतीजों के साथ ARA के नतीजों की आसानी से तुलना करने के लिए किया जा सकता है. साथ ही, ज़्यादा जानकारी वाली डीबग रिपोर्ट का इस्तेमाल, ज़्यादा जानकारी पाने और एट्रिब्यूशन रजिस्ट्रेशन में संभावित समस्याओं को हल करने के लिए किया जा सकता है. |
| एपीआई प्रयोग | ARA की जांच करते समय कुछ समस्याएं मिलीं: ज़्यादा जानकारी वाली रिपोर्टिंग की कमी की वजह से, ग़ैर-ज़रूरी डेटा और कैंपेन को ऑप्टिमाइज़ करने में समस्याएं आ रही थीं. साथ ही, विज्ञापन देने वाले छोटे कारोबारों को बाहर रखने के लिए थ्रेशोल्ड की सीमा बहुत ज़्यादा थी. इसके अलावा, मुख्य परफ़ॉर्मेंस इंडिकेटर में अंतर होने की वजह से, कैंपेन की तुलना करने में भी समस्या आ रही थी. | ARA कई पैरामीटर उपलब्ध कराता है, ताकि विज्ञापन टेक्नोलॉजी कंपनियां अपने मेज़रमेंट के इस्तेमाल के उदाहरणों को हासिल करने के लिए, उन्हें पसंद के मुताबिक बना सकें. इवेंट-लेवल रिपोर्ट, इवेंट-लेवल की रिपोर्टिंग के साथ काम करती हैं. इसकी मदद से, विज्ञापन टेक्नोलॉजी विशेषज्ञ अपनी रिपोर्टिंग विंडो, रिपोर्ट की संख्या, और ट्रिगर किए गए उस डेटा को पसंद के मुताबिक बना सकते हैं जिसे उन्हें मेज़र करना है. इससे, उनके डेटा पर ग़ैर-ज़रूरी डेटा का असर कम हो सकता है और वे अलग-अलग इस्तेमाल के उदाहरणों को हासिल कर सकते हैं. इसी तरह, एग्रीगेट रिपोर्ट में विज्ञापन टेक्नोलॉजी विशेषज्ञ, अपने कॉन्फ़िगरेशन को पसंद के मुताबिक बनाने के लिए अलग-अलग तरीके अपना सकते हैं. जैसे, वे ट्रैक किए जाने वाले डाइमेंशन की संख्या, बैच करने की फ़्रीक्वेंसी, और योगदान बजट का इस्तेमाल कर सकते हैं. इससे, ग़ैर-ज़रूरी डेटा के असर को कम करने के साथ-साथ, अलग-अलग कामों के लिए भी डेटा का इस्तेमाल किया जा सकता है. |
| एपीआई स्पेसिफ़िकेशन | ARA के तीसरे पक्ष के सिस्टम पर निर्भर होने के बारे में सवाल. खास तौर पर, यह सवाल कि क्या यह टेस्टिंग के फ़ेज़ में है और इसके लिए तीसरे पक्ष के सिस्टम की ज़रूरत है. | ARA, 3PC के बिना भी चालू किया जा सकता है. हालांकि, ARA के ट्रांज़िशनल डीबग रिपोर्टिंग की अनुमति देने के लिए, 3PC चालू होने चाहिए, ताकि ARA के नतीजों की तुलना कुकी पर आधारित एट्रिब्यूशन के नतीजों से की जा सके. |
| एपीआई प्रयोग | ARA का इस्तेमाल करके, Android के पुराने वर्शन (11, 12, और 13) पर, ऐप्लिकेशन से वेब पर ट्रैकिंग के लिए सोर्स रजिस्टर करने के बारे में जानकारी. | फ़िलहाल, ARA की सुविधा Android S और उसके बाद के वर्शन (12+) पर काम करती है. |
| एपीआई प्रयोग | ARA ऑप्ट-इन की दरों और डिस्ट्रिब्यूशन की जानकारी का अनुरोध करें. | हमारी पिछली तिमाहियों की तुलना में, हमारा जवाब अब भी वही है: "हमारा यह प्लान नहीं है कि हम इस जानकारी को अपने नेटवर्क के साथ शेयर करें. डेवलपर, Privacy Sandbox API की उपलब्धता का अनुमान लगाने के लिए, आज ही उन एपीआई को कॉल कर सकते हैं जिनमें उनका कोड डिप्लॉय किया गया है" |
| एपीआई की उपलब्धता | ARA चालू होने पर, क्या 3PC चालू हैं या बंद हैं? | जब उपयोगकर्ताओं के ब्राउज़र पर ARA चालू होता है, तो इससे उपयोगकर्ताओं की कुकी सेटिंग पर कोई असर नहीं पड़ता. ऐसा हो सकता है कि ARA चालू हो और उपयोगकर्ता ने कुकी को चालू या बंद किया हो. |
| रिपोर्टिंग | क्या "Attribution-reporting-support" हेडर में, वैल्यू की कोई सूची पहले से मौजूद है? | जैसा कि हमारे दिशा-निर्देश में बताया गया है, वैल्यू एक स्ट्रक्चर्ड हेडर डिक्शनरी है. फ़िलहाल, इसमें सिर्फ़ OS और वेब पासकोड की मौजूदगी या अनुपस्थिति के बारे में जानकारी दी गई है. हेडर के अन्य सभी हिस्सों को अनदेखा किया जाना चाहिए. दूसरे शब्दों में, पार्स करने के लिए, स्ट्रिंग मैचिंग के बजाय स्ट्रक्चर्ड हेडर पार्सर का इस्तेमाल करना ज़रूरी है. |
एग्रीगेशन सेवा
| फ़ीडबैक की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| सुविधा का अनुरोध | एग्रीगेशन सेवा के लिए सुविधाओं के अनुरोध: सर्वर-टू-सर्वर इंटिग्रेशन, क्रॉस-डिवाइस मेज़रमेंट, मल्टी-टच एट्रिब्यूशन और योगदान की रिपोर्टिंग को आसान बनाना, ऑमनीचैनल एट्रिब्यूशन, और बेहतर एमएल ऑप्टिमाइज़ेशन लूप के लिए सहायता (उदाहरण के लिए, निजी मॉडल ट्रेनिंग). |
हम इन अनुरोधों की समीक्षा कर रहे हैं. ज़्यादा जानकारी उपलब्ध होने पर, हम आपको इसकी सूचना देंगे. हम चाहते हैं कि नेटवर्क के सदस्य इस बारे में अपने सुझाव, राय भेजें या शिकायत करें कि इन अनुरोधों को प्राथमिकता दी जानी चाहिए या नहीं. |
| सुविधा का अनुरोध | एग्रीगेशन सेवा सेट को अपडेट करते समय, रीसेट से जुड़ी समस्याओं को कम करने के लिए, terraform एनवायरमेंट में ईबीएस delete_on_termination पैरामीटर को 'सही है' पर सेट करने का अनुरोध. | हम इस अनुरोध की समीक्षा कर रहे हैं. ज़्यादा जानकारी उपलब्ध होने पर, हम आपको इसकी जानकारी देंगे. हम ईकोसिस्टम से इस बारे में ज़्यादा सुझाव, राय या शिकायत का स्वागत करते हैं कि क्या इस अनुरोध को प्राथमिकता दी जानी चाहिए. इसके लिए, यहां क्लिक करें. |
| दस्तावेज़ जानकारी |
इस बारे में दिशा-निर्देश का अनुरोध करना कि किन चीज़ों में बदलाव किया जा सकता है (उदाहरण के लिए, मॉनिटरिंग थ्रेशोल्ड) और किन चीज़ों में बदलाव नहीं किया जाना चाहिए. | हम एग्रीगेशन सेवा के लिए, पसंद के मुताबिक बनाने की सुविधाओं के बारे में अतिरिक्त दस्तावेज़ और दिशा-निर्देश पब्लिश करने का आकलन कर रहे हैं. |
| डिप्लॉयमेंट | bazel कमांड पर, नई डिप्लॉयमेंट के काम न करने के बारे में जानकारी का अनुरोध. | एनवायरमेंट में इस्तेमाल किए गए bazel वर्शन की वजह से, डिप्लॉयमेंट पूरा न हो पाना. दस्तावेज़ में बदलाव किया जाएगा, ताकि Terraform के काम न करने पर डीबगिंग की जा सके. साथ ही, इसमें bazel के ज़रूरी वर्शन के बारे में भी बताया जाएगा. |
Private Aggregation API
| फ़ीडबैक की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| एपीआई प्रयोग | लागू करने से जुड़ी कुछ चुनौतियों के बारे में दिशा-निर्देश पाने का अनुरोध. जैसे, शेयर किए गए स्टोरेज की सीमाओं की वजह से डेटा का संभावित नुकसान, एग्रीगेशन सेवा की अनुमति वाली जटिल सूचियों (वाइल्डकार्ड का सुझाव दिया गया है) की ज़रूरत वाले ज़्यादा एलिमेंट वाली समस्याएं, और एग्रीगेशन सेवा के "डुप्लीकेट नहीं" नियम की वजह से टेस्टिंग में लगने वाला ज़्यादा समय. | Shared Storage की सीमाओं के बारे में बताते हुए, हम आपको बता दें कि हर बार 20 योगदान किए जा सकते हैं. यह सीमा हर महीने के लिए नहीं है, बल्कि हर बार के लिए है. इस बारे में ज़्यादा जानकारी यहां दी गई है. इसके अलावा, एपीआई कॉलर इस सीमा को बदल सकते हैं. यह सीमा, एग्रीगेशन सेवा में रिपोर्ट प्रोसेस करने की लागत को मैनेज करने के लिए तय की गई है, न कि रिपोर्टिंग की सुविधा को सीमित करने के लिए. वाइल्डकार्ड क्वेरी के बारे में, हम इस अनुरोध की समीक्षा कर रहे हैं. ज़्यादा जानकारी उपलब्ध होने पर, हम आपको बताएंगे. "डुप्लीकेट नहीं" नियम के बारे में बताते हुए, हम यह बताना चाहते हैं कि टेस्टिंग की सुविधा चालू करने के लिए, हम कुछ समय के लिए डीबग मोड का इस्तेमाल कर सकते हैं. ऐसा इसलिए किया जाता है, ताकि इस नियम को बायपास किया जा सके. इस बारे में ज़्यादा जानकारी यहां दी गई है. |
| आईडी और बकेट फ़िल्टर करना | क्या एग्रीगेशन सेवा से, दो अलग-अलग एग्रीगेशन रन में, दो अलग-अलग फ़िल्टरिंग आईडी वाली एक ही बकेट का अनुरोध किया जा सकता है? इसका मतलब है कि क्या फ़िल्टरिंग आईडी, डोमेन की अतिरिक्त पार्टिशनिंग के तौर पर काम कर सकता है? | हां, यह सुविधा काम करती है. एग्रीगेशन करते समय, सिर्फ़ उन योगदानों को प्रोसेस किया जाएगा जिनका फ़िल्टरिंग आईडी, जॉब पैरामीटर में मौजूद सूची से मेल खाता है. बाकी योगदान, अलग-अलग रन में प्रोसेस किए जा सकेंगे. |
| मल्टी-टच एट्रिब्यूशन | मल्टी-टच एट्रिब्यूशन (एमटीए) लागू करने के बारे में जानकारी पाने के अनुरोध: 1) अगर एग्रीगेशन वैल्यू 2^16 से ज़्यादा नहीं है, तो क्या योगदान की संख्या पर कोई सीमा है? 2) क्या किसी खास संदर्भ के लिए, यूनीक एग्रीगेशन बटन (बकेट) की संख्या को स्टोर करने की कोई सीमा है? 3) जब हर उपयोगकर्ता एजेंट (ब्राउज़र) के पास एक यूनीक एग्रीगेशन पासकोड होता है, तो Aggregation Service खास जानकारी वाली रिपोर्ट को कैसे प्रोसेस करती है, जैसा कि एमटीए में हो सकता है? |
1) हमने योगदान की डिफ़ॉल्ट सीमाएं तय की हैं. हालांकि, एपीआई कॉलर के पास इन सीमाओं को बदलने का विकल्प होता है. इसके बारे में यहां बताया गया है. सीमाओं का मकसद, एग्रीगेशन सेवा में रिपोर्ट प्रोसेस करने की लागत को मैनेज करने में, एपीआई कॉलर की मदद करना है. 2) इसकी कोई सीमा नहीं है. हालांकि, विज्ञापन टेक्नोलॉजी को सिग्नल-टू-नॉइज़ रेशियो को बेहतर बनाने के लिए, एग्रीगेशन पासकोड की बारीकी से जांच करनी चाहिए. इस बारे में ज़्यादा जानकारी यहां दी गई है. 3) कृपया यह दिशा-निर्देश देखें. खास तौर पर, ऊपर दूसरे आइटम में दिए गए, सिग्नल-टू-नॉइज़ के दिशा-निर्देश देखें. |
गुप्त ट्रैकिंग को सीमित करना
यूज़र-एजेंट रिडक्शन/यूज़र-एजेंट क्लाइंट हिंट
| फ़ीडबैक की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| सुविधा का अनुरोध | User-Agent क्लाइंट हिंट (UA-CH) में Sec-CH-UA-Robot जोड़ने का अनुरोध, क्योंकि इससे सर्वर को कॉन्टेंट अडैप्टेशन, सुरक्षा, और आंकड़ों के लिए अपने-आप आने वाले ट्रैफ़िक की पहचान करने में मदद मिलेगी. | यह इस्तेमाल का एक अहम उदाहरण है, जिसकी चर्चा अन्य स्टैंडर्ड ग्रुप में की जा रही है. ज़्यादा जानकारी के लिए यहां देखें. हमारा सुझाव है कि जिन लोगों को इसमें दिलचस्पी है वे अपने सुझाव/राय देकर इसमें हिस्सा लें. हालांकि, हमें लगता है कि UA-CH शायद सही समाधान न हो, क्योंकि ऑटोमेटेड ट्रैफ़िक की मदद से, एचटीटीपी अनुरोध हेडर में आसानी से बदलाव किया जा सकता है. |
आईपी प्रोटेक्शन (पहले इसका नाम Gnatcatcher था)
| फ़ीडबैक की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| आईपी पते की निजता | Google के लिए आईपी पते उपलब्ध कराना, निजता के लिए तय किए गए उसके लक्ष्यों के ख़िलाफ़ है. भले ही, Google का कहना है कि वह आईपी प्रोटेक्शन की मदद से डेटा को गुमनाम कर देता है, लेकिन आईपी प्रोटेक्शन का इस्तेमाल करने के लिए उपयोगकर्ताओं को Chrome में लॉग इन करना होगा. इसलिए, Google अब भी उनकी पहचान जान लेता है. | लॉगिन करने की वजहें, धोखाधड़ी और गलत इस्तेमाल को रोकने के लिए हैं. इनमें, प्रॉक्सी का ऐक्सेस सीमित करना भी शामिल है. इसके अलावा, पुष्टि करने की ज़रूरी शर्तों के संदर्भ में उपयोगकर्ताओं की निजता को सुरक्षित रखने के लिए, हमारे टोकन के डिज़ाइन पर अंधा हस्ताक्षर किया जाता है. इसका मतलब है कि लॉगिन के दौरान जारी किया गया टोकन, प्रॉक्सी के दौरान इस्तेमाल किए गए टोकन से अलग होता है. इसलिए, जारी किए गए टोकन को बाद में उपयोगकर्ता की Google पहचान से लिंक नहीं किया जा सकता. इसका मतलब है कि जब उपयोगकर्ता का ट्रैफ़िक गुप्त मोड में प्रोक्सी किया जाता है, तो Google को यह पता नहीं चलता कि वह उपयोगकर्ता कौन है. भले ही, धोखाधड़ी रोकने के लिए पुष्टि करने की ज़रूरत हो. |
| आईपी पते की निजता | आईपी का इस्तेमाल करना गलत है. इन्हें कुकी की तरह ब्राउज़र से मिटाया नहीं जा सकता. साथ ही, उपयोगकर्ताओं के पास पारदर्शिता से जुड़े वे कंट्रोल नहीं होते जो कुकी के लिए होते हैं. अगर कुकी बंद हो जाती हैं, तो इंडस्ट्री एक अन्य विकल्प के तौर पर आईपी का इस्तेमाल करेगी. इसमें निजता के बजाय, खुद को सुरक्षित रखने को प्राथमिकता दी जाएगी. | Chrome एक प्लैटफ़ॉर्म है, जिसका मकसद उपयोगकर्ताओं को वेब पर ब्राउज़ करने का बेहतर अनुभव देने वाली सुविधाएं उपलब्ध कराना है. Chrome के जिन उपयोगकर्ताओं ने गुप्त मोड में ब्राउज़ करने का विकल्प चुना है उनके लिए, तीसरे पक्ष के संदर्भों में आईपी पते की जानकारी की उपलब्धता को सीमित करके, अलग-अलग साइटों पर ट्रैकिंग के ख़िलाफ़ बेहतर सुरक्षा दी जा रही है. |
| मास्क किए गए डोमेन की सूची | मास्क किए गए डोमेन की सूची (एमडीएल) में शामिल करने की शर्तें क्या हैं? | Chrome ने यह तय करने के लिए शर्तें तय की हैं कि कौनसे डोमेन एमडीएल में शामिल होने चाहिए. इसलिए, तीसरे पक्ष के संदर्भ में उन्हें मास्क किए गए आईपी पते मिलते हैं. Google ने Disconnect.me के साथ साझेदारी की है. यह इंटरनेट निजता के क्षेत्र में काम करने वाली एक प्रमुख कंपनी है. यह अन्य वेब ब्राउज़र के साथ भी काम करती है. Chrome, Disconnect.me का इस्तेमाल करके उन डोमेन की पहचान करेगा जो Chrome की तय की गई शर्तों के मुताबिक हैं. इसके अलावा, Chrome ने आम तौर पर इस्तेमाल किए जाने वाले उन JavaScript फ़ंक्शन की पहचान करने के लिए एक तरीका विकसित किया है जो स्थिर और ज़्यादा एन्ट्रापी वाले वेब एपीआई से लगातार आउटपुट देते हैं. इसलिए, इनका इस्तेमाल ज़्यादा एन्ट्रापी वाले संभावित आइडेंटिफ़ायर बनाने के लिए किया जा सकता है. इन फ़ंक्शन का पता तब चलता है, जब वे तीसरे पक्ष के संदर्भ में वेबसाइटों पर लोड किए जाते हैं. इससे, उन डोमेन की सूची बनती है जो इन विशेषताओं वाली स्क्रिप्ट दिखाते हैं. ये स्क्रिप्ट एमडीएल का हिस्सा बन जाती हैं और इसलिए, इन्हें प्रॉक्सी किया जाता है. एपीआई के गलत इस्तेमाल के इन पैटर्न का पता लगाने वाली पाइपलाइन, सभी डोमेन पर नज़र रखती है. इनमें Google के डोमेन भी शामिल हैं. |
| धोखाधड़ी की रोकथाम | संभावित तौर पर ज़ाहिर किए जाने वाले टोकन (पीआरटी) के बारे में सुझाव, जिसमें बताया गया है कि 24 घंटे के अंदर ज़ाहिर करने की प्रस्तावित देरी और ज़ाहिर करने की दरों से, रीयल-टाइम में धोखाधड़ी का पता लगाने में रुकावट आती है. कम समय (1 घंटे) की देरी और ज़्यादा किराये (कम से कम दो अंकों में) का अनुरोध करें. अन्य सुझावों में, जोखिम के सिग्नल (वीपीएन, ऑटोमेटेड ब्राउज़र) के आधार पर अलग-अलग दरें चालू करना और खास टोकन को टारगेट करके दिखाने की अनुमति देना शामिल है. | हमने जिन डेवलपर से बात की है उनमें से ज़्यादातर अपने ग्राहकों को हर घंटे रिपोर्टिंग देते हैं. साथ ही, कई डेवलपर दिन भर आईपी ब्लॉकलिस्ट अपडेट करते हैं. देरी की कम अवधि से, ज़्यादा बार अपडेट मिलते हैं. साथ ही, एक घंटे से भी कम समय में, हर घंटे के आंकड़ों में IVT मेज़रमेंट फिर से चालू हो जाता है. हालांकि, इससे उपयोगकर्ताओं की पहचान फिर से की जा सकती है. हम इकोसिस्टम की स्टडी और हिस्सेदारों के सुझाव, शिकायत या राय के आधार पर, देरी की अवधि को कम करने और प्रॉडक्ट रिलीज़ करने की दर में बदलाव करने के बारे में सोच सकते हैं. साथ ही, हम यहां और भी सुझाव, शिकायत या राय का स्वागत करते हैं. |
| मास्क किए गए डोमेन की सूची | विज्ञापन के इस्तेमाल के उदाहरण के बिना, डोमेन को एमडीएल में शामिल करने के बारे में सवाल. इस बात की चिंता है कि इससे आईपी पतों के आधार पर प्रोफ़ाइलें बनाने के लिए, "आईपी-ब्रिजिंग" की सुविधा चालू हो सकती है. | हम इस बात से सहमत हैं कि सूची के आधार पर, अपील करने की प्रक्रिया लागू करना ज़रूरी है. अपील करने से कंपनियों को यह दावा करने की अनुमति मिलती है कि एमडीएल में शामिल किया गया उनका डोमेन, शामिल किए जाने की ज़रूरी शर्तों को पूरा नहीं करता और उसे हटा दिया जाना चाहिए. इससे उस डोमेन को गुप्त मोड में, तीसरे पक्ष के संदर्भ में उपयोगकर्ताओं के ओरिजनल आईपी पते मिलते रहेंगे. हमने अपील करने की प्रोसेस शुरू कर दी है. इससे डोमेन के मालिकों को, Chrome के स्टैबल वर्शन में गुप्त मोड में आईपी प्रोटेक्शन की सुविधा लॉन्च होने से पहले, अपील करने और फ़ैसला पाने के लिए ज़रूरत के मुताबिक समय मिल पाएगा. अपील की प्रक्रिया के बारे में ज़्यादा जानकारी यहां उपलब्ध है. |
| मास्क किए गए डोमेन की सूची | पब्लिशर ने फ़ीडबैक दिया है कि वे अपने पार्टनर के एमडीएल में शामिल होने के असर की जांच कर रहे हैं. उन्हें आईपी सुरक्षा के बारे में बताने वाले लेख में, भौगोलिक आईपी पते से जुड़े प्रावधानों से भरोसा मिला. | Chrome, जगह के हिसाब से इस्तेमाल के उदाहरणों को इस्तेमाल करने की ज़रूरत को समझता है. प्रॉक्सी, ऐसे आईपी पते असाइन करेगा जिनसे उपयोगकर्ता की जगह की अनुमानित जानकारी मिलती हो. इसमें देश की जानकारी भी शामिल है. ज़्यादा जानकारी के लिए, आईपी पते से जगह की जानकारी पाने की सुविधा के बारे में जानकारी लेख पढ़ें. |
| मास्क किए गए डोमेन की सूची | एमडीएल के बारे में सवाल, क्या देश के लेवल पर टारगेटिंग की सुविधा अब भी उपलब्ध है या नहीं. | Chrome, जगह के हिसाब से इस्तेमाल के उदाहरणों को इस्तेमाल करने की ज़रूरत को समझता है. प्रॉक्सी, ऐसे आईपी पते असाइन करेगा जिनसे उपयोगकर्ता की जगह की अनुमानित जानकारी मिलती हो. इसमें देश की जानकारी भी शामिल है. ज़्यादा जानकारी के लिए, आईपी पते से जगह की जानकारी पाने की सुविधा के बारे में जानकारी लेख पढ़ें. |
| धोखाधड़ी का पता लगाने की सुविधा | धोखाधड़ी का पता लगाने वाले सिस्टम पर, आईपी प्रोटेक्शन के असर से जुड़ी चिंताएं. क्या उपयोगकर्ताओं को प्रॉक्सी आईपी या हेडर दिखेगा? क्या किसी खास इस्तेमाल के लिए, एसएसपी और डीएसपी को एक ही प्रॉक्सी आईपी पता दिखेगा? इनमें अंतर होने पर, धोखाधड़ी का पता लगाने और OpenRTB पर असर पड़ सकता है. | गुप्त मोड में ब्राउज़ करने वाले ऐसे उपयोगकर्ता जिन्होंने आईपी पते की सुरक्षा की सुविधा चालू की हुई है और जो एमडीएल में मौजूद डोमेन के लिए अनुरोध करते हैं उन्हें तय किए गए जियोफ़ीड के आधार पर एक प्रॉक्सी आईपी पता मिलेगा. संगठन, प्रॉक्सी किए गए ट्रैफ़िक पर अतिरिक्त हेडर के तौर पर पीआरटी भेजने का अनुरोध कर सकते हैं. इसमें, कुछ समय बाद ओरिजनल आईपी का एक छोटा सैंपल दिखाया जा सकता है. हमें लगता है कि कई एसएसपी, सर्वर-साइड बिड रिक्वेस्ट में अपने डिमांड पार्टनर को प्रॉक्सी आईपी पता पास करेंगे. हालांकि, यह गारंटी नहीं है कि इंप्रेशन के समय, डीएसपी को वही प्रॉक्सी आईपी पता दिखेगा. |
| धोखाधड़ी का पता लगाने की सुविधा | आईपी जियोलोकेशन फ़ाइल को अपडेट करने की फ़्रीक्वेंसी, धोखाधड़ी वाले व्यवहार और पीआरटी की शिकायत करने के लिए अपडेट करने का समय, और विज्ञापन टेक्नोलॉजी को धोखाधड़ी वाली गतिविधियों का पता कैसे लगाना चाहिए, इनके बारे में सवाल. | पीआरटी के बारे में जानकारी देने वाला पेज लाइव है. साथ ही, प्रॉक्सी आईपी पतों और उनके मैप किए गए भौगोलिक इलाकों की सूची भी लाइव है. हमारा सुझाव है कि अपडेट और बदलावों के लिए, समय-समय पर इस फ़ाइल को देखें. ऐसा इसलिए, क्योंकि समय के साथ आईपी पते बदलते रहेंगे. गलत इस्तेमाल की शिकायत करने के लिए, सार्वजनिक ईमेल पते का एलान लॉन्च से पहले किया जाएगा. |
| जगह से जुड़ी जानकारी | प्रॉक्सी के लिए इस्तेमाल किए गए आईपी पतों की सार्वजनिक सूची का अनुरोध. | आईपी पतों को जगह की अनुमानित जानकारी से मैप करने वाली फ़ाइल, आईपी सुरक्षा के लिए यहां उपलब्ध है. कृपया ध्यान दें कि इस फ़ाइल को समय-समय पर अपडेट किया जाता है. |
| एपीआई प्रयोग | यह दावा कि आईपी पते की सुरक्षा की सुविधा डिफ़ॉल्ट रूप से चालू रहती है और उपयोगकर्ताओं को ऑप्ट आउट करने का विकल्प नहीं दिया जाता. | आईपी पते की सुरक्षा की सुविधा, Android और डेस्कटॉप प्लैटफ़ॉर्म पर, Chrome के गुप्त मोड में उपयोगकर्ताओं के लिए उपलब्ध होगी. उपयोगकर्ताओं के पास आईपी पते की सुरक्षा की सुविधा को बंद करने का विकल्प होगा. Chrome के एंटरप्राइज़ वर्शन के लिए, आईपी पते की सुरक्षा की सुविधा चालू की जा सकती है. हालांकि, यह सुविधा डिफ़ॉल्ट रूप से बंद रहती है. |
| एपीआई प्रयोग | Chrome Canary और बीटा रिलीज़ में आईपी सुरक्षा की सुविधा को चालू करने और उसकी जांच करने के लिए, एक्सपेरिमेंट फ़्लैग की उपलब्धता के बारे में क्वेरी. | फ़िलहाल, हमारे पास आईपी सुरक्षा की पूरी सुविधा को टेस्ट करने के लिए, एक्सपेरिमेंट फ़्लैग उपलब्ध नहीं है. फ़ंक्शनल एक्सपेरिमेंट में, हम सिर्फ़ Google डोमेन पर जाने वाले प्रॉक्सी ट्रैफ़िक का इस्तेमाल कर रहे हैं. |
| आईपी पते की निजता | जब ब्राउज़र गुप्त मोड में चला जाता है, तो 3PC प्रॉम्प्ट सेटिंग कैसे काम करती हैं? | गुप्त मोड में, तीसरे पक्ष की कुकी डिफ़ॉल्ट रूप से ब्लॉक रहती हैं. |
| गुप्त मोड | यह जानना है कि जब उपयोगकर्ता Chrome में साइन इन नहीं करता है, तो क्या गुप्त मोड में आईपी पते की सुरक्षा की सुविधा काम करती है. | अगर उपयोगकर्ता ने गुप्त मोड चालू करने से पहले, Chrome में लॉग इन नहीं किया है, तो आईपी सुरक्षा की सुविधा चालू नहीं होती. ऐसा धोखाधड़ी और गलत इस्तेमाल को रोकने के लिए किया जाता है. जैसे, प्रॉक्सी के ऐक्सेस को सीमित करना. आईपी प्रोटेक्शन, क्लाइंट की पुष्टि करने की सुविधा का इस्तेमाल करेगा. इससे, नुकसान पहुंचाने वाले लोग या ग्रुप, एमडीएल पर मौजूद सेवाओं पर हमले बढ़ाने के लिए, प्रॉक्सी का फ़ायदा नहीं ले पाएंगे. इसलिए, आईपी सुरक्षा की सुविधा सिर्फ़ उन उपयोगकर्ताओं के लिए उपलब्ध होगी जिन्होंने गुप्त विंडो खोलने से पहले, Chrome ब्राउज़र में उस Google खाते से साइन इन किया है जिसकी पुष्टि की गई है. |
| गुप्त मोड | लॉन्च से पहले, आईपी प्रोटेक्शन के असर का आकलन करने के लिए अनुरोध. इनमें ये शामिल हैं: (1) गुप्त मोड के इस्तेमाल की संख्या का पता लगाने के लिए, ब्राउज़र स्टेटस फ़्लैग या एग्रीगेट एपीआई रिपोर्टिंग का इस्तेमाल करने का प्रस्ताव; (2) सुविधा चालू करने से पहले, कुछ समय के लिए आईपी प्रोटेक्शन हेडर भेजना; और (3) अनुमान लगाने के लिए, ट्रैफ़िक के छोटे से हिस्से पर सुविधा को शिप करना. |
हम समझते हैं कि इकोसिस्टम को आईपी प्रोटेक्शन के स्केल और असर को समझने और मेज़र करने में दिलचस्पी है. हालांकि, Chrome यह पक्का करने की कोशिश करता है कि गुप्त मोड में ब्राउज़ करने की उपयोगकर्ता की पसंद को निजी रखा जाए. Chrome, गुप्त मोड में ब्राउज़ करने वाले उपयोगकर्ताओं का पता लगाने का कोई तरीका नहीं बताता. साथ ही, उसने ऐसे अन्य सिग्नल को सीमित करने के लिए कदम उठाए हैं जिनसे उपयोगकर्ता के ब्राउज़िंग मोड का पता चल सकता है. हम इस टेस्टिंग को आसान बनाने के तरीकों पर काम कर रहे हैं. ऐसा गुप्त मोड में ब्राउज़ करने वाले उपयोगकर्ताओं की निजता पर असर डाले बिना किया जाएगा. साथ ही, हम नेटवर्क से जुड़े लोगों के सुझावों का स्वागत करते हैं. |
बाउंस ट्रैकिंग को कम करने की सुविधा
| फ़ीडबैक की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| अनुपालन | डेटा की सुरक्षा से जुड़े कानून का पालन करने वाली बाउंस ट्रैकिंग मटिगेशन (बीटीएम) तकनीक के इस्तेमाल की अनुमति देने से Google का इनकार करना, गैर-कानूनी है. इससे निजता सैंडबॉक्स की अपील की प्रक्रिया का कोई मतलब नहीं रह जाता. | जैसा कि हमने सुझाव/राय/शिकायत/राय देने वाले लोगों से जुड़ी पिछली रिपोर्ट में बताया था, नीति का पालन करने की स्थिति का, बीटीएम के लागू होने से कोई लेना-देना नहीं है. साथ ही, Google, बीटीएम को लागू करने के लिए नीति का पालन करने से जुड़ा कोई फ़ैसला नहीं लेता. Chrome की निजता को सुरक्षित रखने वाले अन्य टूल की तरह, बीटीएम का मकसद भी उपयोगकर्ताओं को यह कंट्रोल देना है कि उनका डेटा शेयर किया जाए या नहीं और अगर किया जाए, तो कैसे. सीएमए की दूसरी/तीसरी तिमाही की रिपोर्ट में बताई गई, तीसरे पक्ष की मदद से की जाने वाली अपील की प्रोसेस, खास तौर पर उन मामलों में लागू होती है जहां Google, अलग-अलग कंपनियों को सूचियों में शामिल करने या बाहर रखने के बारे में फ़ैसले ले रहा हो. |
| अनुपालन | इस बारे में चर्चा की गई है कि जीडीपीआर के संदर्भ में, ब्राउज़र कानूनी तौर पर सहमति वाली कार्रवाइयों का पालन कैसे करते हैं. इसमें उन स्थितियों को हाइलाइट किया गया है जहां ब्राउज़र, रीडायरेक्ट या कुकी सेटिंग जैसी उन कार्रवाइयों को रोक सकते हैं जिनकी उपयोगकर्ताओं ने साफ़ तौर पर सहमति दी है. इससे, कानूनी सहमति और ब्राउज़र की निजता सेटिंग के बीच विरोधाभास पैदा होता है. | ब्राउज़र को उपयोगकर्ता और वेबसाइट के बीच के संबंध की जानकारी नहीं होती. इसके अलावा, BTM के मौजूदा व्यवहार के साथ, उपयोगकर्ता के पास किसी साइट से बाउंस ट्रैकिंग के लिए साफ़ तौर पर सहमति देने के लिए, पहले से ही कुछ तरीके मौजूद हैं. नीति का पालन करने के बारे में ज़्यादा जानकारी, निजता से जुड़ी नीति का पालन करने के बारे में अक्सर पूछे जाने वाले सवाल में उपलब्ध है. |
| दो तरह के काम के लिए इस्तेमाल की जाने वाली साइटें | क्या वेबव्यू या ऐप्लिकेशन-टू-वेब (Chrome) से ट्रांज़िशन करने पर, BTM के तहत "दो तरह के इस्तेमाल की सुविधा वाली साइटों" के तौर पर माना जाएगा? | ब्राउज़र यह नहीं देख सकता कि बाउंस चेन, वेबव्यू या ऐप्लिकेशन से ट्रांज़िशन के ज़रिए शुरू हुई है या नहीं. इसलिए, BTM उन फ़्लो को कोई खास प्राथमिकता नहीं देता. इसके बजाय, यह फ़्लो को "about:blank" से शुरू होने वाले क्रॉस-साइट बाउंस के तौर पर समझता है और स्टैंडर्ड व्यवहार के साथ आगे बढ़ता है. |
अलग-अलग साइटों पर निजता की सीमाओं को बेहतर बनाना
मिलती-जुलती वेबसाइट के सेट (पहले इन्हें पहले पक्ष के सेट कहा जाता था)
| फ़ीडबैक की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| एपीआई प्रयोग | आईपी पते की सुरक्षा की सुविधा के साथ आरडब्ल्यूएस के गलत इस्तेमाल की आशंका. आरडब्ल्यूएस सेट में संगठनों को आईपी पते दिखाने से, संगठनों को कई आरडब्ल्यूएस सेट में शामिल होने का बढ़ावा मिल सकता है. इससे वे गुप्त मोड में ब्राउज़ करने वाले उपयोगकर्ताओं को ट्रैक करने के लिए, पोर्टेबल आईपी पते के डेटा का ऐक्सेस पा सकते हैं. | मिलती-जुलती साइटों, सेवा साइटों, और पूरे सेट के लिए सेट की गई ज़रूरी शर्तें, अपने-आप पुष्टि करने की सुविधा से लागू होती हैं. इससे, एक से ज़्यादा सेट में शामिल होने की कोशिश करने के किसी भी संभावित इंसेंटिव को कम किया जाता है. आईपी पतों के ज़रिए सभी सेट में उपयोगकर्ता गतिविधि को जोड़ने के लिए, सेट में एमडीएल डोमेन को शामिल करना होगा. इसके लिए, सेट के मालिक और डोमेन के मालिक के बीच समन्वय की ज़रूरत होती है. यह जोखिम, एमडीएल डोमेन के साथ काम करने वाली एकल साइटों (यानी कोई आरडब्ल्यूएस शामिल नहीं है) पर भी लागू होता है. हमने इस सवाल का जवाब यहां ज़्यादा जानकारी के साथ दिया है. |
Fenced Frames API
| फ़ीडबैक की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| नेटिव विज्ञापन | फ़ीडबैक में बताया गया है कि फ़ेंस किए गए फ़्रेम, फ़िलहाल जिस तरह से डिज़ाइन किए गए हैं वह उनके नेटिव विज्ञापन कारोबार मॉडल के साथ काम नहीं करता. इस मॉडल के लिए ज़रूरी है कि विज्ञापन, आस-पास मौजूद कॉन्टेंट के हिसाब से आसानी से बदल सकें. | हम नेटवर्क की ज़रूरतों और फ़ेंस किए गए फ़्रेम की मौजूदा सुविधा का आकलन करते रहेंगे. किसी भी मामले में, जैसा कि पहले बताया गया है, फ़ेंस किए गए फ़्रेम की ज़रूरत 2026 से पहले नहीं होगी. |
Shared Storage API
| फ़ीडबैक की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| एपीआई बग | रिपोर्ट करें कि जब Shared Storage API का बजट तय करने का तरीका, selectURL ऑपरेशन को चलने से रोकता है, तब Chrome गड़बड़ी को लॉग करता है. हालांकि, ऐसा होना ज़रूरी है. Chrome से अनुरोध करें कि वह लॉगिंग लेवल को गड़बड़ी से चेतावनी या जानकारी पर घटा दे, क्योंकि कॉल करने वाले के लिए गड़बड़ी ठीक करने की कोई कार्रवाई नहीं की जा सकती. | यह बदलाव लागू कर दिया गया है और इसे Chrome M134 में शामिल किया गया है. यह वर्शन 4 मार्च, 2025 से उपलब्ध है. |
सीएचआईपीएस
| फ़ीडबैक की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| API दस्तावेज़ | SameSite=Lax/Strict कुकी की तुलना में, Partitioned कुकी से मिलने वाली सुरक्षा के बारे में साफ़ तौर पर जानकारी चाहिए. हमारा सुझाव है कि दस्तावेज़ में साफ़ तौर पर बताया जाना चाहिए कि Partitioned कुकी, XSS और CSRF हमलों से उसी लेवल की सुरक्षा नहीं देती हैं जो SameSite=Lax/Strict कुकी देती हैं. | हम सेगमेंट वाली कुकी से मिलने वाले सेमेंटिक और सुरक्षा के बारे में साफ़ तौर पर बताने के लिए, 'एक्सप्लेनर' और 'स्पेसिफ़िकेशन' को अपडेट करेंगे. |
FedCM
| फ़ीडबैक की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| यूज़र इंटरफ़ेस (यूआई) और सुरक्षा | सुझाव/राय/शिकायत/राय देने वाले ने बताया कि FedCM का यूज़र इंटरफ़ेस (यूआई), Google के पिछले एक-टैप लॉगिन से काफ़ी मिलता-जुलता है. साथ ही, उन्होंने यह भी बताया कि पैसिव प्रज़ेंटेशन ट्रैकिंग की सुविधा न होने की वजह से, FedCM की परफ़ॉर्मेंस का आकलन करना मुश्किल है. साथ ही, उन्होंने PKCE के बारे में दस्तावेज़ की भाषा को बेहतर बनाने का सुझाव दिया है. | हम उनसे मिले सुझावों, शिकायतों या राय को ठीक करने के लिए, लगातार काम कर रहे हैं. फ़िलहाल, इन विषयों पर चर्चा की जा रही है: IdP को बेहतर मेट्रिक उपलब्ध कराने के तरीके, ताकि वे FedCM की परफ़ॉर्मेंस को ट्रैक कर सकें. साथ ही, सदस्यता के इस्तेमाल के उदाहरणों के आस-पास FedCM के नए इस्तेमाल के उदाहरणों को हल करने के लिए, संभावित सुधार. |
| एपीआई प्रयोग | जब कोई उपयोगकर्ता पेज को रीफ़्रेश करता है और लॉगिन करने के लिए navigator.credentials.get को कॉल करता है, तो एक पॉप-अप विंडो दिखती है. इसमें उपयोगकर्ता को जारी रखने के लिए क्लिक करना होता है. इससे उपयोगकर्ता अनुभव पर असर पड़ता है. क्या भरोसेमंद पक्ष (आरपी), उपयोगकर्ता अनुभव को बेहतर बनाने के लिए, navigator.credentials.get से मिले टोकन को कैश मेमोरी में सेव कर सकते हैं? | आरपी, टोकन को सेव करने के लिए अपनी कुकी का इस्तेमाल कर सकते हैं. इसके बाद, आरपी अपनी कुकी की जांच करके यह पता लगा सकते हैं कि उपयोगकर्ता ने navigator.credentials.get को कॉल करने से पहले लॉग इन किया है या नहीं. हमने इस बारे में ज़्यादा जानकारी यहां दी है. |
| एक से ज़्यादा आईडीपी चुनना | FedCM में, ब्राउज़र एक से ज़्यादा आइडेंटिटी प्रोवाइडर (आईडीपी) के लिए लॉगिन के विकल्प कैसे दिखाएगा? | डेवलपर दस्तावेज़ में, एक से ज़्यादा आईडीपी को दिखाने के तरीके के बारे में जानकारी दी गई है. Chrome://flags में जाकर, fedcm-multi-idp फ़्लैग को चालू करके, हिस्सेदार इस सुविधा को आज़मा सकते हैं. |
| ब्राउज़र और आईडीपी | क्या Chrome जैसे ब्राउज़र, खुद आईडीपी के तौर पर काम कर सकते हैं? ब्राउज़र, अपने स्टोर किए गए खाते और प्रोफ़ाइल के डेटा का इस्तेमाल, पुष्टि करने के लिए भरोसेमंद सोर्स के तौर पर कर सकते हैं. | ब्राउज़र में बदलाव किए जा सकते हैं.जैसे, एक्सटेंशन की मदद से. इसलिए, सीधे ब्राउज़र से किए गए ईमेल पते की पुष्टि के दावों पर, सर्वर से की गई पुष्टि के बिना भरोसा नहीं किया जा सकता. इसलिए, सिर्फ़ क्लाइंट पर आधारित समाधान का सुझाव नहीं दिया जाता. हमने इस समस्या के बारे में ज़्यादा जानकारी यहां दी है. |
| एपीआई स्पेसिफ़िकेशन | इस बारे में चर्चा कि IdentityCredential.disconnect() एल्गोरिदम के लिए पैरामीटर ज़रूरी है या नहीं. | अब यह समस्या ठीक कर दी गई है. इसके बारे में ज़्यादा जानकारी यहां मिल सकती है. |
| एपीआई की सुरक्षा | अगर किसी आरपी में एक्सएसएस (XSS) की समस्या है, तो FedCM लॉगिन प्रोसेस में टोकन लीक होने से जुड़ी समस्याएं. हैकर, टोकन पाने के लिए नुकसान पहुंचाने वाले कोड में navigator.credentials.get को चला सकता है. | FedCM, एक्सएसएस से जुड़े नए जोखिम नहीं पैदा करता. ये जोखिम, वेब ऐप्लिकेशन और पुष्टि करने के मौजूदा प्रोटोकॉल में पहले से मौजूद होते हैं. इन जोखिमों को कम करने के लिए, आरपी को आईडी टोकन में aud दावे की पुष्टि करनी चाहिए. साथ ही, सिर्फ़ अपने ऑरिजिन से जारी किए गए दावे स्वीकार करने चाहिए. यहां बताए गए तरीके, टोकन एक्सचेंज को सुरक्षित करने के सबसे सही तरीके हैं. ये आज भी मौजूद हैं और FedCM के साथ इस्तेमाल किए जा सकते हैं. इसके अलावा, Storage Access API का इस्तेमाल FedCM के साथ किया जा सकता है. साथ ही, FedCM कॉल होने पर Storage Access API कॉल अपने-आप मिल जाते हैं. इससे, GitHub की समस्या में बताए गए एम्बेड किए गए रीडायरेक्ट फ़्लो की सुविधा चालू हो जाएगी. |
| एपीआई स्पेसिफ़िकेशन | FedCM के लिए, कॉन्फ़िगरेशन एंडपॉइंट के जवाब में client_metadata_endpoint एक ज़रूरी फ़ील्ड है. कोई खाली ऑब्जेक्ट, मान्य रिस्पॉन्स होता है. साथ ही, Chromium 404 कोड वाले रिस्पॉन्स को अनदेखा कर देता है. इससे पता चलता है कि एंडपॉइंट को असल में वैकल्पिक माना जाता है. | हम इस बात से सहमत हैं कि इस बदलाव को दिखाने के लिए, स्पेसिफ़िकेशन में बदलाव किया जा सकता है. साथ ही, client_metadata_endpoint को वैकल्पिक फ़ील्ड बनाया जा सकता है. |
| एपीआई प्रयोग | ब्राउज़र से कंट्रोल किए जाने वाले यूज़र इंटरफ़ेस की वजह से, FedCM को लागू करने की जांच करने में आने वाली समस्याओं के बारे में चिंता. ये यूज़र इंटरफ़ेस, DOM से ऐक्सेस नहीं किए जा सकते. | हम रिग्रेशन टेस्टिंग के लिए, ब्राउज़र ऑटोमेशन एपीआई का इस्तेमाल करते हैं. इससे इन समस्याओं को हल किया जा सकता है. इन एपीआई के बारे में यहां बताया गया है. |
| एपीआई स्पेसिफ़िकेशन | login_url पैरामीटर, कॉन्फ़िगरेशन एंडपॉइंट के रिस्पॉन्स का ज़रूरी हिस्सा है. इसे स्पेसिफ़िकेशन के सेक्शन 3.2 में शामिल नहीं किया गया था. | हमने दस्तावेज़ में एक अपडेट सबमिट किया है, ताकि सेक्शन 3.2 में login_url पैरामीटर शामिल किया जा सके. |
| एपीआई स्पेसिफ़िकेशन | FedCM में संभावित ट्रैकिंग वेक्टर से जुड़ी समस्या. कोई आईडीपी, कॉन्फ़िगरेशन एंडपॉइंट रिस्पॉन्स (accounts_endpoint, client_metadata_endpoint) में बताए गए एंडपॉइंट में, पाथ पैरामीटर के तौर पर आईडी डाल सकता है. साथ ही, खाते और क्लाइंट मेटाडेटा के अनुरोधों को जोड़ने के लिए, इन आईडी का इस्तेमाल कर सकता है. | हालांकि, हमारे पास इस बात का कोई सबूत नहीं है कि आईडीपी ने इन एंडपॉइंट में आईडी डाले हैं. हम इस समस्या को हल करने के लिए, यहां बताए गए तरीकों का इस्तेमाल कर रहे हैं. |
स्पैम और धोखाधड़ी से बचना
Private State Tokens API (और अन्य एपीआई)
इस तिमाही में कोई सुझाव, राय या शिकायत नहीं मिली.