साल 2024 की चौथी तिमाही की तिमाही रिपोर्ट, जिसमें Privacy Sandbox के प्रस्तावों और Chrome के जवाब पर, नेटवर्क से मिले सुझाव/राय या शिकायतों की खास जानकारी दी गई है.
सीएमए के साथ किए गए अपने वादे के तहत, Google ने प्राइवसी सैंडबॉक्स के प्रपोज़ल के लिए, हिस्सेदारों के साथ जुड़ने की प्रोसेस के बारे में हर तीन महीने में सार्वजनिक तौर पर रिपोर्ट देने का वादा किया है. समझौते के पैराग्राफ़ 12 और 17(c)(ii) देखें. Privacy Sandbox के सुझाव/राय/शिकायत/राय देने वाले फ़ॉर्म की खास जानकारी वाली ये रिपोर्ट, अलग-अलग सोर्स से मिले सुझाव/राय/शिकायत/राय को इकट्ठा करके जनरेट की जाती हैं. इन सोर्स के बारे में सुझाव/राय/शिकायत/राय की खास जानकारी में बताया गया है. इनमें ये सोर्स शामिल हैं, लेकिन इन तक ही सीमित नहीं हैं: GitHub पर मौजूद समस्याएं, privacysandbox.com पर उपलब्ध सुझाव/राय/शिकायत/राय देने वाला फ़ॉर्म, इंडस्ट्री के हिस्सेदारों के साथ हुई मीटिंग, और वेब स्टैंडर्ड फ़ोरम. Chrome, नेटवर्क से मिले सुझावों और राय का स्वागत करता है. साथ ही, डिज़ाइन से जुड़े फ़ैसलों में, इन सुझावों और राय को शामिल करने के तरीकों को लगातार एक्सप्लोर कर रहा है.
सुझाव/राय/शिकायत की थीम को हर एपीआई के हिसाब से, उनकी संख्या के आधार पर रैंक दी जाती है. ऐसा करने के लिए, Chrome की टीम को किसी खास थीम के बारे में मिले सुझाव, शिकायत या राय को इकट्ठा किया जाता है. इसके बाद, उन्हें संख्या के हिसाब से कम से ज़्यादा के क्रम में लगाया जाता है. आम तौर पर मिलने वाले सुझाव, शिकायत या राय के विषयों की पहचान करने के लिए, सार्वजनिक मीटिंग (W3C, PatCG, IETF), सीधे तौर पर मिलने वाले सुझाव, शिकायत या राय, GitHub, और Google की इंटरनल टीमों और सार्वजनिक फ़ॉर्म से पूछे जाने वाले सामान्य सवालों के विषयों की समीक्षा की गई.
खास तौर पर, वेब स्टैंडर्ड बॉडी की मीटिंग के मिनट की समीक्षा की गई. साथ ही, सीधे फ़ीडबैक के लिए, Google के 1:1 हिस्सेदारों की मीटिंग के रिकॉर्ड, अलग-अलग इंजीनियरों को मिले ईमेल, एपीआई की मेलिंग सूची, और सार्वजनिक फ़ीडबैक फ़ॉर्म को ध्यान में रखा गया. इसके बाद, Google ने अलग-अलग आउटरीच गतिविधियों में शामिल टीमों के बीच समन्वय किया, ताकि यह पता लगाया जा सके कि हर एपीआई के लिए, कौनसी थीम सबसे ज़्यादा लोकप्रिय हैं.
Chrome पर मिले फ़ीडबैक के जवाबों की जानकारी, पब्लिश किए गए अक्सर पूछे जाने वाले सवालों, हिस्सेदारों की ओर से उठाई गई समस्याओं के जवाबों, और सार्वजनिक तौर पर रिपोर्ट करने के लिए खास तौर पर तय की गई स्थिति के आधार पर तैयार की गई है. डेवलपमेंट और टेस्टिंग के मौजूदा फ़ोकस को ध्यान में रखते हुए, हमें Topics, PA API, एट्रिब्यूशन रिपोर्टिंग एपीआई, और टेक्नोलॉजी के बारे में खास तौर पर सवाल और सुझाव मिले.
हो सकता है कि हाल ही में मिले सुझाव, शिकायत या राय पर Chrome ने अब तक कोई कार्रवाई न की हो.
शॉर्ट फ़ॉर्म की ग्लॉसरी
- 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 का जवाब |
|---|---|---|
| ज़िम्मेदारियां | Privacy Sandbox को कामयाब बनाने के लिए, प्रतिबद्धताओं का सेक्शन G ज़रूरी है. इस बात की कोई गारंटी नहीं है कि Google का विज्ञापन कारोबार, सिर्फ़ Sandbox टेक्नोलॉजी पर काम करेगा. इसलिए, इस टेक्नोलॉजी के इस्तेमाल में लगातार गिरावट आने का खतरा बढ़ जाता है. साथ ही, Google के इस टेक्नोलॉजी को बेचने की संभावना भी बढ़ जाती है. इस तरह की बिक्री या उपयोगिता में कमी, ओपन वेब पर निजता को ध्यान में रखकर बनाए गए पते के अस्तित्व के लिए खतरा हो सकती है. | इन प्रतिबद्धताओं से यह गारंटी नहीं मिलती कि Google का विज्ञापन कारोबार, सिर्फ़ Privacy Sandbox की टेक्नोलॉजी पर काम करेगा. Google, पते की जानकारी पाने के लिए पोर्टफ़ोलियो के तरीके का इस्तेमाल करना चाहता है. इसमें Privacy Sandbox की टेक्नोलॉजी शामिल होंगी. तीसरे पक्ष भी इनका इस्तेमाल कर सकते हैं और कर रहे हैं. हम जानते हैं कि विज्ञापन नेटवर्क में पोर्टफ़ोलियो का तरीका आम तौर पर इस्तेमाल किया जाता है. हमारा मानना है कि डेवलपर के लिए, निजता बनाए रखने वाले टूल और टेक्नोलॉजी का होना ज़रूरी है. हम Privacy Sandbox API को उपलब्ध कराते रहेंगे. साथ ही, निजता और उपयोगिता को बेहतर बनाने के लिए, इन पर काम करते रहेंगे. |
| मैनेज करना | सुझाए गए गवर्नेंस मॉडल में, आधिकारिक सलाह या अपील की प्रोसेस में जवाबदेही के लिए कोई खास तरीका शामिल नहीं है. | यह सही नहीं है. (i) फ़ैसला लेने वाला सिस्टम और उससे जुड़े पब्लिकेशन और (ii) अपील की प्रोसेस, दोनों ही जवाबदेही के लिए खास तरीके उपलब्ध कराते हैं. इसके अलावा, मॉनिटरिंग ट्रस्टी उनकी गतिविधियों पर बारीकी से नज़र रखेगा. |
| मैनेज करना | फ़ीडबैक में बताया गया है कि मॉडल में, क्रॉस-प्लैटफ़ॉर्म स्टैंडर्ड बनाने और उसे मैनेज करने के लिए कोई प्रावधान नहीं है. | कोई भी मैनेजमेंट मॉडल, दूसरे पक्षों को किसी स्टैंडर्ड को अपनाने के लिए मजबूर नहीं कर सकता. इस मामले में, ब्राउज़र को. इसलिए, हमने ऐसा मॉडल नहीं सुझाया है जिसमें सभी प्लैटफ़ॉर्म पर एक जैसे स्टैंडर्ड अपनाने की ज़रूरत हो. Google, स्टैंडर्ड फ़ोरम में हिस्सा लेना जारी रखेगा. इन फ़ोरम में, प्रस्ताव बनाना और उन्हें लागू करने का अनुभव शेयर करना आम बात है. |
| मैनेज करना | हमारा सुझाव है कि आप सलाह लेने की अवधि को कम से कम दो महीने तक बढ़ाएं. सुझाए गए गवर्नेेंस मॉडल में, सुझाए गए बदलावों के असर का विश्लेषण करने के लिए, नेटवर्क को ज़रूरत के मुताबिक समय नहीं मिलता. | किसी बदलाव के लिए, तीन हफ़्ते की अवधि ही सुझाव, राय या शिकायत देने की पूरी अवधि नहीं होती. इस दौरान, सुझाव, राय या शिकायत देने के लिए मौजूदा साइकल (जो काफ़ी लंबे होते हैं) जारी रहेंगे. इसके बजाय, रणनीतिक फ़ैसले लेने के लिए, मौजूदा प्रोसेस में सुझाव/राय देने के लिए एक नई और आधिकारिक विंडो उपलब्ध कराई गई है. इसलिए, सुविधा के डेवलपमेंट के दौरान, तीसरे पक्ष अलग-अलग फ़ोरम (इनमें GitHub, W3C, और IAB Tech Lab जैसे विज्ञापन मानकों के लिए काम करने वाली संस्थाएं शामिल हैं) के ज़रिए इनपुट दे पाएंगे. सुझाव/राय देने के लिए इस तरह के साइकल बनाने से, इकोसिस्टम को सुझाए गए बदलाव का विश्लेषण करने और उस पर अपने विचार शेयर करने का मौका मिलता है. इससे, डेवलपमेंट प्रोसेस में कोई खास देरी नहीं होती. |
| मैनेज करना | आने वाले समय में, कॉन्टेंट मैनेज करने के प्लान के बारे में जानकारी का अनुरोध करें. | सुझाए गए गवर्नेेंस मॉडल की खास जानकारी, सीएमए की 2024 की दूसरी/तीसरी तिमाही की रिपोर्ट में दी गई है. यह जानकारी यहां पेज 3 से 5 पर दी गई है. |
| अपवाद का अनुरोध | सहमति देने वाले उपयोगकर्ताओं के लिए, तीसरे पक्ष की कुकी (3PC) ऐक्सेस करने के लिए अपवाद का अनुरोध करें. | डेटा प्रोसेस करने के खास मकसदों के लिए, डिवाइस को ऐक्सेस करने और उसमें डेटा सेव करने की अनुमति देने का मतलब यह नहीं है कि उपयोगकर्ता Chrome में 3PC सेटिंग को बदलना चाहता है. किसी उपयोगकर्ता की 3PC सेटिंग को साइट-लेवल पर बदलने की अनुमति देने से, गलत इस्तेमाल की संभावना बढ़ जाती है. साथ ही, Chrome के लिए उन सभी साइटों के व्यवहार का ऑडिट करना असंभव होगा जिनकी वजह से अपवाद का अनुरोध किया जा सकता है. |
| Privacy Sandbox | Privacy Sandbox API के लिए ऑप्ट-इन रेट का अनुरोध करें. | हमारा यह डेटा, किसी दूसरे प्लैटफ़ॉर्म के साथ शेयर नहीं किया जाएगा. डेवलपर, Privacy Sandbox APIs की उपलब्धता का अनुमान लगाने के लिए, आज उन एपीआई को कॉल कर सकते हैं जहां उनका कोड डिप्लॉय किया गया है. |
| ऑरिजिन ट्रायल | क्या ऑरिजिन ट्रायल की अवधि बढ़ाने का कोई प्लान है? | ऑरिजिन ट्रायल की अवधि 14 अप्रैल, 2025 तक बढ़ा दी गई है. |
| Privacy Sandbox | प्राइवसी सैंडबॉक्स के बारे में कम शब्दों में और तकनीकी जानकारी के बिना बताने का अनुरोध करें. इससे, इसकी कारोबारी वैल्यू हाइलाइट होती है और एग्ज़ीक्यूटिव का भरोसा भी बढ़ता है. | हमने हाल ही में privacysandbox.com पर यहां कारोबार से जुड़े संसाधनों का एक सेक्शन जोड़ा है. इसमें इस बारे में जानकारी दी गई है. |
| मोड B | जब कोई ब्राउज़र "Mode B" में हो, तो क्या मौजूदा कुकी जर्स (1PC, 3PC, लोकल स्टोरेज) सेव रहेगा या मिट जाएगा? | मौजूदा कुकी जर्स को मिटाया नहीं जाएगा. 3PC, पहले पक्ष (ग्राहक) के संदर्भ में ऐक्सेस किए जा सकेंगे. |
| Chrome पर तीन पीसी के लिए अपडेट किया गया तरीका | क्या आने वाले समय में, Chrome से 3PCs को पूरी तरह हटा दिया जाएगा? | हम एक अपडेट किया गया तरीका सुझा रहे हैं, जो उपयोगकर्ता की पसंद को बढ़ावा देता है. यहां बताए गए तरीके के मुताबिक, हम 3PCs को बंद करने के बजाय, Chrome में एक नया वर्शन लॉन्च करेंगे. इससे, लोग अपने वेब ब्राउज़िंग पर लागू होने वाली कोई ऐसी सुविधा चुन पाएंगे जिसके बारे में उन्हें पता हो. साथ ही, वे इस सुविधा में किसी भी समय बदलाव कर पाएंगे. हम इस नए तरीके के बारे में, रेगुलेटर के साथ बातचीत कर रहे हैं. साथ ही, इसे लॉन्च करने से पहले, हम इंडस्ट्री के साथ भी बातचीत करेंगे. |
| Chrome टेस्टिंग | Chrome की मदद से होने वाले टेस्टिंग लेबल की उपलब्धता को जारी रखने का अनुरोध करें. | Privacy Sandbox की टीम को पता है कि कंपनियां कुकी के बंद होने के लेबल का इस्तेमाल करना जारी रखना चाहेंगी. लेबल की उपलब्धता बढ़ाने की प्रोसेस, ऑरिजिन ट्रायल की अवधि बढ़ाने की प्रोसेस जैसी ही है. इस प्रोसेस के तहत, एक्सपेरिमेंट को एक बार में सिर्फ़ तीन Chrome माइलस्टोन के लिए बढ़ाया जा सकता है. उदाहरण के लिए, कुकी के बंद होने की जानकारी देने वाले लेबल के लिए, Chrome के सबसे नए एक्सपेरिमेंट को एक्सटेंड़ करने का इंटेंट (I2EE) Chrome M130-M132 के लिए भी एक्सटेंड़ किया गया था. इससे, फ़रवरी की शुरुआत में रिलीज़ होने वाले M133 के स्टेबल वर्शन तक, लेबल के साथ काम करने की सुविधा चालू रहेगी. अन्य एक्सटेंशन भी इसी प्रोसेस के तहत चलेंगे. इसलिए, अपडेट के लिए blink-dev ईमेल ग्रुप को फ़ॉलो करने का सुझाव दिया जाता है. |
रजिस्टर करना और पुष्टि करना
इस तिमाही में कोई सुझाव, राय या शिकायत नहीं मिली.
काम का कॉन्टेंट और विज्ञापन दिखाना
विषय
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| खास जानकारी | क्या क्लासिफ़ायर मॉडल को Android (ऐप्लिकेशन के नाम के हिसाब से) और Chrome (होस्ट के नाम के हिसाब से) के बीच शेयर किया जाता है? | नहीं, ये अलग-अलग मॉडल हैं, क्योंकि इनकी टैक्सोनॉमी अलग-अलग हैं. |
| विषयों की टैक्सोनॉमी के बारे में ज़्यादा जानकारी | पहले पक्ष की जानकारी के साथ इस्तेमाल करने पर, विषय बहुत सामान्य हो जाते हैं और काम के नहीं रह जाते. | Topics टैक्सोनॉमी का मकसद, उपयोगिता और निजता के बीच संतुलन बनाना है. हमने Topics को ज़्यादा सटीक बनाने के लिए, संभावित तरीकों का आकलन किया है. हालांकि, हमने सुरक्षा और निजता के साथ-साथ अन्य बातों को ध्यान में रखते हुए, ऐसा करने का फ़ैसला नहीं लिया है. विज्ञापन टेक्नोलॉजी, सभी उपलब्ध टूल को जोड़कर सबसे अच्छे नतीजे हासिल कर सकती हैं. जैसे, मशीन लर्निंग और निजता बनाए रखने वाले एपीआई से मिले निजता को सुरक्षित रखने वाले सिग्नल. साथ ही, संदर्भ के हिसाब से डेटा, क्रिएटिव डेटा, और पहले पक्ष (ग्राहक) का डेटा. इस बारे में ज़्यादा जानकारी यहां उपलब्ध है. |
| एपीआई प्रयोग | Topics API की कवरेज कम है. | कवरेज कम होने की सामान्य वजहें: - उपयोगकर्ता कंट्रोल/ऑप्ट-आउट - पब्लिशर कंट्रोल/ऑप्ट-आउट - साइट की ज़रूरी शर्तें (इन साइटों को विषयों से मैच करने की अनुमति नहीं है: असुरक्षित साइटें; वेबव्यू; iOS पर Chrome, और गुप्त मोड) - उपयोगकर्ता से जुड़ी सीमाएं (18 साल से कम उम्र के Chrome उपयोगकर्ताओं या गुप्त मोड का इस्तेमाल करने वाले उपयोगकर्ताओं को निगरानी में नहीं रखा जा सकता और उन्हें विषय नहीं असाइन किए जा सकते) - सेलर को निगरानी करने की ज़रूरी शर्त (कॉल करने वाले को, ज़रूरी शर्तें पूरी करने वाले विषय से जुड़ी साइट पर उपयोगकर्ता को पहले देखना होगा) - हाल ही में लागू किया गया (कॉल करने वाले को निगरानी करने की सुविधा को बढ़ाने के लिए, चार हफ़्ते का समय लगता है) |
| एपीआई प्रयोग | Topics API के इस्तेमाल के बारे में जानकारी का अनुरोध करें, क्योंकि नेटवर्किंग टैब से पता चलता है कि एक कॉल भेजा गया और उसे कैप्चर किया गया है. हालांकि, chrome://topics-internals/ पर, ऑब्ज़र्वर को रिकॉर्ड नहीं किया गया है. | Topics API के साथ इंटरैक्ट करने के लिए एचटीटीपी हेडर का इस्तेमाल करने पर, विषयों को Sec-Browsing-Topics अनुरोध हेडर में भेजा जाता है. हालांकि, इन विषयों को सिर्फ़ तब देखा जाता है, जब सर्वर Observe-Browsing-Topics: ?1 रिस्पॉन्स हेडर के साथ जवाब देता है. इस बारे में ज़्यादा जानकारी यहां दी गई है. |
| Chromium की भूमिका | क्या डेस्कटॉप के लिए, Chrome, Chromium पर आधारित अन्य ब्राउज़र के साथ एक ही तरह के अवलोकन और रैंकिंग के संदर्भ शेयर करेगा? क्या मोबाइल के लिए, Android Chrome, Chromium / इन-ऐप्लिकेशन Chromium पर आधारित अन्य Android ब्राउज़र के साथ एक ही नतीजा और रैंकिंग का कॉन्टेक्स्ट शेयर करेगा? |
Chrome, डिवाइस पर मौजूद दूसरे ब्राउज़र के साथ Topics का डेटा शेयर नहीं करता. |
| खास जानकारी | Topics API यह कैसे तय करता है कि किसी उपयोगकर्ता के पेज व्यू को 'विषय के इतिहास की एंट्री' माना जाए या नहीं? | हर हफ़्ते के विषयों का हिसाब लगाने के लिए, पेज पर आने वाले हर व्यक्ति के लिए 'निगरानी करें' कॉल होना ज़रूरी है. यह कॉल किसी भी व्यक्ति से किया जा सकता है. 'निगरानी करें' कॉल के बिना, विज़िट को विषय के इतिहास में शामिल नहीं किया जाएगा. |
| सुरक्षा | Topics API, किसी कॉलर को दूसरे कॉलर के निगरानी में रखे गए विषयों को देखने से कैसे रोकता है? | हमने इस बारे में यहां जानकारी दी है. |
| टैक्सनॉमी | हर एपिसोड में, Topics API में मौजूद ट्री स्ट्रक्चर टैक्सोनॉमी का इस्तेमाल, निगरानी में कैसे किया जाता है? | टॉप पांच विषयों का हिसाब लगाते समय, सिर्फ़ क्लासिफ़ायर से मिले मूल विषयों को ध्यान में रखा जाता है. रैंकिंग तय करने के लिए, (i) पेज पर आने वाले लोगों की संख्या और (ii) प्राथमिकता वाले स्कोर (जानकारी देखें) का इस्तेमाल किया जाता है. टॉप पांच विषयों में से हर विषय के लिए, 'कॉल करने वाले लोगों ने देखे' का हिसाब लगाते समय, उन कॉल करने वालों को शामिल किया जाता है जिन्होंने मुख्य विषय या उसके किसी भी डेसेंटेंट विषय को देखा हो. |
| खास जानकारी | जवाब में 5% ग़ैर-ज़रूरी आवाज़ों के बारे में ज़्यादा जानकारी का अनुरोध. | हर समयावधि के लिए, हमेशा पांच सबसे ज़्यादा ब्राउज़ किए गए विषय होते हैं. अगर ब्राउज़िंग इतिहास में पांच विषय नहीं हैं, तो पांच विषयों तक विषयों को रैंडम तौर पर चुना जाता है. हम इन्हें पैड किए गए विषय कहते हैं. कॉल करने वाले लोगों को इनमें से कोई भी विषय तब तक नहीं दिखेगा, जब तक कि उपयोगकर्ता ने पिछले कुछ हफ़्तों में उस विषय से जुड़ी साइट पर विज़िट नहीं की है. एपीआई को कॉल करने पर, हर उपयोगकर्ता, हर साइट, और हर युग के लिए हैश का हिसाब लगाया जाता है. अगर वह हैश, ग़ैर-ज़रूरी विषय दिखाने की संभावना से कम है, तो हर उपयोगकर्ता, हर साइट, और हर युग के लिए कोई विषय चुना जाता है. हालांकि, ग़ैर-ज़रूरी शब्दों को हटाने के बाद का विषय सिर्फ़ तब दिखाया जाता है, जब कॉलर ने उस उपयोगकर्ता/साइट/एपिक के लिए, ग़ैर-ज़रूरी शब्दों को हटाने से पहले का विषय देखा हो. एक्सप्लेनर देखें. इस फ़िल्टरिंग से यह पक्का होता है कि कॉल करने वाले व्यक्ति के लिए, ग़ैर-ज़रूरी शब्दों को हटाने के बाद भी 5% समय तक विषयों को दिखाया जाए. भले ही, उस व्यक्ति के बारे में ज़्यादा जानकारी हो या नहीं. |
| खास जानकारी | एक हफ़्ते से दूसरे हफ़्ते डुप्लीकेट विषयों की जानकारी कैसे मिलती है? क्या एपीआई, हफ़्तों के बीच अपने-आप चुनकर उन्हें मर्ज कर रहा है? | हर हफ़्ते (एपॉच) के विषयों का हिसाब अलग-अलग लगाया जाता है. हर epoch से दिखाने के लिए चुना गया विषय, उस साइट पर निर्भर करता है जिस पर कॉलर मौजूद है. हम इस बात का ध्यान नहीं रखते कि किसी कॉलर के लिए, हर एपिसोड में एक ही विषय दोहराया जा सकता है. इसलिए, हमें लगता है कि कॉलर को कोई दूसरा विषय चुनना चाहिए. हालांकि, इस समस्या के बारे में ज़्यादा सुझाव/राय देने के लिए, यहां क्लिक करें. |
Protected Audience API
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| A/B टेस्टिंग | यहां बताए गए शेयर किए गए स्टोरेज के समाधान में इंतज़ार का समय बढ़ जाता है और गड़बड़ी की दर ज़्यादा होती है. इसका मतलब है कि ट्रैफ़िक का एक बड़ा हिस्सा, पॉप्युलेशन आईडी के बिना ही खत्म हो जाता है. कम एन्ट्रापी वाला आईडी (उदाहरण के लिए, 3 बिट) का इस्तेमाल किया जा सकता है. इससे निजता पर काफ़ी असर पड़े बिना, असरदार A/B टेस्टिंग की जा सकती है. | हमारा मानना है कि शेयर किए गए स्टोरेज का विकल्प अब भी एक सही तरीका है. हालांकि, हम इस अनुरोध पर विचार कर रहे हैं. अगर यह सुविधा आपकी प्राथमिकता है, तो हमारे साथ ज़्यादा सुझाव/राय/शिकायत शेयर करें. |
| रिपोर्टिंग | reportWin() में अतिरिक्त बिट का अनुरोध करें. ऐसा इसलिए, क्योंकि PA API में नई क्लिक और डिसप्ले रिपोर्टिंग में 6 से 8 बिट का इस्तेमाल होगा. इससे PA API की अन्य रिपोर्टिंग के लिए उपलब्ध बिट की संख्या कम हो जाएगी. |
निजता से जुड़ी चिंताओं की वजह से, हम modelingSignals के बिट को मौजूदा 12 बिट से ज़्यादा नहीं बढ़ा रहे हैं. हमने निजी मॉडल ट्रेनिंग के प्रस्ताव पर सुझाव, राय या टिप्पणी देने के लिए, नेटवर्क के सभी सदस्यों को न्योता दिया है. इसका मकसद, सुरक्षित माहौल में एमएल ट्रेनिंग की ज़रूरतों को पूरा करना है. इसमें, Privacy Sandbox की वजह से बिट पर लगाई गई सीमा को हटाना भी शामिल है. |
| एक जैसी दिलचस्पी वाले ग्रुप | दिलचस्पी के ग्रुप (आईजी) के लिए 90 दिनों के लाइफ़ साइकल का अनुरोध किया जा रहा है, क्योंकि 30 दिन की अवधि काफ़ी नहीं है. | जैसा कि हमने अपनी ब्लॉग पोस्ट में बताया है, हम इंस्टाग्राम पर पोस्ट की लाइफ़ को 90 दिनों तक बढ़ाने जा रहे हैं. इस बारे में ज़्यादा जानकारी के लिए, यहां क्लिक करें. फ़िलहाल, हम इस सुविधा को लागू करने पर काम कर रहे हैं. लॉन्च की समयावधि उपलब्ध होने पर, हम इसकी जानकारी शेयर करेंगे. |
| एक जैसी दिलचस्पी वाले ग्रुप | आईजी खाते को किसी दूसरे को सौंपने के लिए, डाइनैमिक अपडेट का अनुरोध करना. | हमें कई हिस्सेदारों से इस अनुरोध के बारे में पता है. हम इस समस्या को हल करने के लिए काम कर रहे हैं. इस सुविधा के बारे में अपडेट, हम GitHub पर शेयर करेंगे. साथ ही, हम इस बारे में सुझाव, राय या शिकायतें भी स्वीकार करते हैं. |
| उपयोगकर्ता के डिवाइस पर | डिवाइस पर मौजूद PA API के समाधानों में निवेश जारी रखने के लिए, ईकोसिस्टम के लिए ज़्यादा वैल्यू दिखाएं. | Privacy Sandbox की टीम, निजता को बेहतर बनाने वाली टेक्नोलॉजी (पीईटी) पर आधारित एपीआई को डेवलप करना जारी रखती है. इनमें PA API भी शामिल है. इससे डेवलपर को ब्राउज़र में, निजता बनाए रखने के ज़्यादा विकल्प मिलते हैं. ये टेक्नोलॉजी, अब बड़े पैमाने पर Chrome के सभी ब्राउज़र पर उपलब्ध हैं. कुछ डेवलपर ने गलतफ़हमी में यह समझा है कि ये टेक्नोलॉजी सिर्फ़ 1% ब्राउज़र पर उपलब्ध हैं. उपयोगकर्ता चाहे 3PC चालू करें या नहीं, डेवलपर अपने प्रॉडक्ट में पीईटी (प्राइवेट एन्क्रिप्शन टेक्नोलॉजी) पर आधारित समाधान शामिल कर सकते हैं. ठीक उसी तरह जैसे कई कंपनियां, ब्राउज़र के बाहर पीईटी पर आधारित अन्य समाधानों को अपना रही हैं. कई डेवलपर को, ऑन-डिवाइस PA API के समाधानों में निवेश करने से पहले ही फ़ायदा मिल चुका है. ऐसा, सभी साइटों पर बेहतर पहुंच के लिए, पहले पक्ष (ग्राहक) के डेटासिग्नल को बढ़ाकर किया गया है. हम समझते हैं कि कुछ डेवलपर, Privacy Sandbox API या पीईटी पर आधारित अन्य समाधानों का इस्तेमाल सिर्फ़ तब करेंगे, जब ज़्यादा तीसरे पक्ष की कुकी बंद कर दी जाएंगी. ये डेवलपर, इस जानकारी का इंतज़ार कर रहे हैं जिससे वे अनुमान लगा सकें कि कितने ब्राउज़र तीसरे पक्ष की कुकी बनाए रखेंगे. हम जानते हैं कि डेवलपर तब तक इंतज़ार करेंगे, जब तक उन्हें प्रॉडक्ट से जुड़े फ़ैसले लेने के लिए ज़रूरी जानकारी नहीं मिल जाती. |
| एक जैसी दिलचस्पी वाले ग्रुप | एसएसपी को आईजी बनाने और उससे जुड़ी भूमिकाओं में हिस्सा लेने की अनुमति दें. एसएसपी, इसे अपनी वैल्यू ऐड के अहम हिस्से के तौर पर देखते हैं. साथ ही, वे पब्लिशर को अपने एसएसपी के ज़रिए इंप्रेशन फ़्रेम बेचने में मदद करना चाहते हैं. | हमें कई हिस्सेदारों से, आईजी के ज़्यादा बेहतर प्रतिनिधिमंडल की मदद करने का अनुरोध मिला है. साथ ही, हमें लगता है कि एसएसपी इस प्रोसेस में अहम योगदान दे सकते हैं. हम सबसे अच्छा समाधान ढूंढने के लिए रिसर्च कर रहे हैं, ताकि अलग-अलग पक्ष ऑडियंस एक्सटेंशन की प्रोसेस में हिस्सा ले सकें. इस सुविधा के बारे में अपडेट, हम GitHub पर शेयर करेंगे. साथ ही, हम इस नेटवर्क से जुड़े लोगों के सुझाव, राय या शिकायतों का स्वागत करते हैं. |
| रिपोर्टिंग | forDebuggingOnly और Private Aggregation API के बीच, "बिड नॉन-ज़ीरो" की रिपोर्ट की संख्या में अंतर. | हमें लगता है कि इस अंतर की दो वजहें हैं: पहली वजह, निजी एग्रीगेशन एपीआई का डीबग मोड सिर्फ़ तब उपलब्ध होता है, जब डिवाइस पर तीन पीसी की अनुमति हो. वहीं, forDebuggingOnly एपीआई हमेशा बिना सैंपल के उपलब्ध होता है. हालांकि, यहां बताए गए तरीके से, आखिर में यह व्यवहार बदल जाएगा. दूसरी बात, Private Aggregation API में योगदान की सीमाएं होती हैं, जबकि forDebuggingOnly में नहीं. हालांकि, इस सुझाव से पता चलता है कि इस गड़बड़ी की वजह कुछ और हो सकती है. हम इस समस्या को हल करने के लिए, तीसरे पक्ष के हिस्सेदार के साथ काम कर रहे हैं. |
| क्लिक करने की संभावना | क्लिक मिलने की संभावना के सिग्नल के लिए अपडेट किए गए प्रस्ताव में बताया गया है कि "attributionsrc" एट्रिब्यूट से शुरू किए गए अनुरोधों के लिए, नया एचटीटीपी रिस्पॉन्स हेडर दिखाकर व्यू और क्लिक रजिस्टर किए जाएंगे. यह ज़रूरी है कि ये अनुरोध ज़रूरी शर्तें पूरी करते हों. साथ ही, इस रिस्पॉन्स हेडर में ऑरिजिन की एक सूची शामिल होगी. इसका इस्तेमाल यह बताने के लिए किया जा सकता है कि कौनसी अन्य पार्टियां, इन व्यू और क्लिक को अपनी कुल संख्या में शामिल कर सकती हैं. क्या इसका मतलब है कि विज्ञापन टेक्नोलॉजी, ऑरिजिन को मनमुताबिक सेट कर सकती है? | क्लिक मिलने की संभावना के बारे में जानकारी में बताया गया है कि एग्रीगेट किए गए व्यू और क्लिक की संख्या में योगदान देने वाले विज्ञापन टेक्नोलॉजी ("ओरिजिन उपलब्ध कराना") में, रिस्पॉन्स हेडर के साथ एक वैकल्पिक पैरामीटर शामिल किया जा सकता है. इससे, "एक या उससे ज़्यादा ऐसे IG मालिक के ओरिजिन की जानकारी दी जा सकती है जिनके लिए इस इवेंट को कैलकुलेट किए गए व्यू और क्लिक की संख्या में शामिल किया जा सकता है. यह जानकारी, सुरक्षित ऑडियंस नीलामियों में उनके generateBid() इनवोकेशन को दी जाएगी" ("ज़रूरी शर्तें पूरी करने वाले ओरिजिन").हालांकि, ये व्यू और क्लिक, व्यू और क्लिक की संख्या में अपने-आप शामिल नहीं होते. इसके बजाय, हर विज्ञापन टेक्नोलॉजी कंपनी को अपने आईजी में, "ओरिजिन की जानकारी देने वाली कंपनियों" का वह सेट बताना होगा जिनसे व्यू और क्लिक इवेंट शामिल किए जाने चाहिए. साथ ही, सिर्फ़ इन ओरिजिन की जानकारी देने वाली कंपनियों का डेटा, उस विज्ञापन टेक्नोलॉजी कंपनी के generateBid() कॉल में दिखाए गए व्यू और क्लिक की संख्या में शामिल होता है.इस प्रोसेस के लिए, दोनों पक्षों के बीच कानूनी समझौता होना ज़रूरी है. इससे, नुकसान पहुंचाने वाले खिलाड़ियों को अन्य विज्ञापन टेक्नोलॉजी के लिए व्यू और क्लिक की संख्या पर असर डालने से रोका जा सकता है. इसका यह भी मतलब है कि "ज़रूरी शर्तें पूरी करने वाले ऑरिजिन" को मनमुताबिक सेट करने वाले "विज्ञापन टेक्नोलॉजी" का, ज़रूरी शर्तें पूरी करने वाले ऑरिजिन के व्यू और क्लिक की संख्या पर तब तक कोई असर नहीं पड़ेगा, जब तक कि ज़रूरी शर्तें पूरी करने वाले ऑरिजिन, अपने आईजी में साफ़ तौर पर और जान-बूझकर उस विज्ञापन टेक्नोलॉजी को शामिल न करें. |
| निजी मॉडल ट्रेनिंग | कुछ मामलों में, DP-SGD (अलग-अलग निजता - स्टोकेस्टिक ग्रेडिएंट डिसेंट) की वजह से, ट्रेनिंग की प्रोसेस काफ़ी धीमी हो जाती है. ऐसा इसलिए होता है, क्योंकि यह बैकप्रॉप के दौरान कैलकुलेट किए गए ग्रेडिएंट की स्पार्सिटी को खत्म कर देता है. क्या इस समस्या को हल करने के लिए कोई तकनीक आज़माने पर विचार किया जा रहा है या इस बारे में कोई सुझाव है? | हम डीपी-एसजीडी में स्पार्सिटी को बनाए रखने के लिए, कुछ तकनीकों के बारे में जानते हैं.जैसे, यह. हम निजी मॉडल को ट्रेनिंग देने वाले इन्फ़्रास्ट्रक्चर में, इस तरह की तकनीकों का इस्तेमाल करने की संभावनाएं तलाश रहे हैं. इस बारे में अपडेट मिलने पर, हम उन्हें शेयर करेंगे. साथ ही, हम यहां आपके सुझाव, राय या शिकायतों का स्वागत करते हैं. |
| नेगेटिव टारगेटिंग | यहां बताई गई, इंस्टाग्राम पर नकारात्मक फ़िल्टर की सुविधा को रोल आउट करने के बारे में अपडेट पाने का अनुरोध करें. | यहां दिए गए जवाब के मुताबिक, हमारा प्लान है कि हम PA API बिड में नेगेटिव आईजी का इस्तेमाल करें. लॉन्च की टाइमलाइन उपलब्ध होने पर, हम उसे शेयर करेंगे. साथ ही, यहां अपने सुझाव, राय या शिकायत भेजें. |
| बिडिंग | क्या बिडिंग करते समय, एक से ज़्यादा आईजी को जोड़ा जा सकता है? | फ़िलहाल, PA API की मदद से ऐसा नहीं किया जा सकता. PA API इस डिज़ाइन पर आधारित है कि आईजी, उपयोगकर्ता के बारे में उस जानकारी से जुड़ा है जो किसी एक साइट को पता है. यह जानकारी, पूरे नेटवर्क के साथ की जाने वाली चर्चाओं का मुख्य हिस्सा रही है. इस तरीके से, विज्ञापन टेक्नोलॉजी कंपनियां कई तरह के समाधान बना सकती हैं. इनसे विज्ञापन देने वालों को, वेब पर अपनी 1P ऑडियंस को बढ़ाने में मदद मिलती है. हमें पता है कि Microsoft के Ads Selection API के प्रस्ताव में, एक अलग डिज़ाइन का सुझाव दिया गया है. इसमें ऑडियंस, सभी साइटों की जानकारी पर आधारित होती हैं. हम इस तरीके पर नज़र बनाए रखेंगे. हालांकि, हम Chrome में इसी तरह के बदलाव करने से पहले, इस बारे में नेटवर्क और निजता कम्यूनिटी से ज़्यादा चर्चा करना चाहेंगे. |
| नेटिव विज्ञापन | PA API, नेटिव विज्ञापनों के अलग-अलग फ़ॉर्मैट और रेंडरिंग की ज़रूरी शर्तों के साथ काम कर सकता है या नहीं. साथ ही, PA API, असरदार नेटिव विज्ञापन के लिए ज़रूरी क्रिएटिव में बदलाव करने और ऑप्टिमाइज़ करने की सुविधा देता है या नहीं. | हम नेटिव विज्ञापनों के लिए ज़्यादा सहायता देने पर काम कर रहे हैं. साथ ही, हम नेटिव विज्ञापनों के लिए, नेटवर्क से जुड़े लोगों के सुझावों और राय का स्वागत करते हैं. |
| रिपोर्टिंग | रिपोर्टिंग स्क्रिप्ट को बेहतर बनाने का अनुरोध, जो बिडिंग स्क्रिप्ट के साथ संसाधनों के लिए प्रतिस्पर्धा करती हैं और हो सकता है कि चल रही नीलामी फ़्रेम से नेविगेट करने पर वे खो जाएं. | हमें उम्मीद है कि हम जल्द ही GitHub पर इस बारे में जवाब पोस्ट करेंगे. हालांकि, हमें नहीं लगता कि इन समस्याओं से, सही रिपोर्टिंग पर कोई असर पड़ेगा |
| मैक्रो बदलना | नीलामी कॉन्फ़िगरेशन में पास किए गए मैक्रो रिप्लेसमेंट, कुछ तीसरे पक्ष के कॉन्फ़िगरेशन के साथ काम नहीं कर रहे हैं. | इसकी मुख्य वजह यह थी कि A/B मोड के लेबल वाले सभी ट्रैफ़िक में यह सुविधा चालू नहीं थी. हमने हाल ही में, A/B मोड वाले सभी ट्रैफ़िक पर इस सुविधा को चालू करने का फ़ैसला लिया है. साथ ही, इस तरह की अन्य सुविधाओं को भी चालू किया जाएगा. हम साल 2025 की पहली तिमाही में यह बदलाव करेंगे. अगर आपके पास कोई और सुझाव, शिकायत या राय है, तो यहां हमें बताएं. |
| दस्तावेज़ | generateBid() में मौजूद browserSignals ऑब्जेक्ट में, हाल ही में विज़िट करने की वैल्यू के लिए मेज़रमेंट की इकाई के बारे में दस्तावेज़ में अंतर दिख रहा है. इसलिए, इस बारे में साफ़ तौर पर बताने का अनुरोध है. |
हमने इस बारे में ज़्यादा जानकारी यहां दी है. साथ ही, अपने दस्तावेज़ को भी अपडेट कर दिया है. सही जवाब है कि समय की इकाई, मिलीसेकंड है. |
| रिपोर्टिंग | तीसरे पक्ष की रिपोर्टिंग का अनुरोध करना. डीएसपी और एसएसपी को Chrome से इंप्रेशन की सूचनाएं मिलती हैं, लेकिन मिडल लेयर की तकनीकी सेवा देने वाली कंपनियों को डिफ़ॉल्ट रूप से सूचनाएं नहीं मिलती हैं. | फ़िलहाल, हम इस सुविधा के अनुरोध पर यहां चर्चा कर रहे हैं. साथ ही, हमें इस बारे में और सुझाव, शिकायत या राय मिलती रहे, तो हमें खुशी होगी. |
| एक जैसी दिलचस्पी वाले ग्रुप | पैरलल आईजी नीलामी वर्कफ़्लो का इस्तेमाल करते समय, interestGroupBuyers को डाइनैमिक तौर पर बाहर रखने के तरीके के बारे में दिशा-निर्देश पाने का अनुरोध. | हमने इस बारे में यहां दिशा-निर्देश दिए हैं. |
| नेटिव विज्ञापन | किसी पेज लोड के लिए, अलग-अलग PA API नीलामियां, एक ही पेज पर विज्ञापन फ़िल्टर करने से रोकती हैं. | नेटिव विज्ञापनों के लिए, "नेटिव" के तौर पर जाने जाने वाले सुझाव विजेट और एक यूनिट में कई विज्ञापनों के साथ काम करने की सुविधा, फ़िलहाल रिसर्च के दायरे में है. हम मानते हैं कि हो सकता है कि मौजूदा डिज़ाइन, एक ही पेज पर विज्ञापन फ़िल्टर करने की सुविधा के साथ काम न करे. साथ ही, फ़ेंस किए गए फ़्रेम जैसी अन्य सुरक्षा भी इस सुविधा को आगे बढ़ने से रोक सकती है. |
| नेटिव विज्ञापन | क्रिएटिव स्कैनिंग, रिपोर्टिंग वगैरह जैसी PA API की मौजूदा सुविधाओं को, यूआरएल पर आधारित सिग्नल पर भरोसा करने की ज़रूरत पड़ सकती है. ऐसा, नेटिव विज्ञापन क्रिएटिव में इस्तेमाल किए गए JSON ऑब्जेक्ट को हैंडल करने के लिए किया जा सकता है. | नेटिव विज्ञापनों के लिए सहायता, रिसर्च का एक ज़रूरी हिस्सा है. हम नेटिव विज्ञापन रेंडर करने में मदद करने के लिए, PA API को अपनाने की संभावना का आकलन कर रहे हैं. |
| विज्ञापन की पुष्टि करना | perBuyerSignals की देरी और कैश मेमोरी से जुड़ी सीमाओं की वजह से, PA API में तीसरे पक्ष के ब्रैंड की सुरक्षा पर असर पड़ता है. यह डाइनैमिक कॉन्टेंट के लिए समस्या पैदा करता है. | हम जानते हैं कि एसएसपी और डीएसपी को कैश मेमोरी के लिए सबसे सही टीटीएल तय करना होगा. इससे ट्रैफ़िक को कंट्रोल करने के लक्ष्यों और ब्रैंड सुरक्षा के लिए तय किए गए ज़्यादा से ज़्यादा टीटीएल के बीच संतुलन बना रहता है. इससे यह पक्का होता है कि कैश मेमोरी में सेव किया गया डेटा, ब्रैंड सुरक्षा के लिए काम का बना रहे. हम इस समस्या की जांच कर रहे हैं. इस बारे में कोई अपडेट मिलने पर, हम आपको इसकी जानकारी देंगे. |
| विज्ञापन की पुष्टि करना | बिड के बाद ब्रैंड सुरक्षा मेज़रमेंट करने के लिए, एसएसपी के ज़रिए FullpageURL मैक्रो को बदलना ज़रूरी है. | deprecatedReplaceInURN, एसएसपी के लिए इस सिग्नल को उपलब्ध कराने का मौजूदा सुझाव है. |
| विज्ञापन की पुष्टि करना | बिड के बाद की पुष्टि के लिए एसएसपी के इस्तेमाल किए जाने वाले मैक्रो फ़ॉर्मैट में स्टैंडर्डाइज़ेशन की कमी की वजह से, डेटा प्रोसेसिंग और विश्लेषण में गड़बड़ियां और अंतर हो सकते हैं. | एसएसपी और विज्ञापन की पुष्टि करने वाली कंपनियों को, मैक्रो के इस्तेमाल के लिए साफ़ दिशा-निर्देश और खास जानकारी तय करने के लिए सीधे तौर पर मिलकर काम करना चाहिए. इससे, सभी एसएसपी के लिए मैक्रो फ़ॉर्मैट को स्टैंडर्ड बनाने में मदद मिलेगी. इससे डेटा प्रोसेसिंग और विश्लेषण में एक जैसी परफ़ॉर्मेंस मिलती है और गड़बड़ियों से बचा जा सकता है. यह ऐसी गतिविधि है जिसके लिए IAB Tech Lab जैसे विज्ञापन मानक संगठन सबसे सही हैं. |
| विज्ञापन की पुष्टि करना | विज्ञापन देने वालों और विज्ञापन की पुष्टि करने वाले लोगों या कंपनियों को, डीबग करने और समस्या हल करने के लिए, एक ही पब्लिशर कॉन्टेक्स्ट के लिए बिड से पहले और बिड के बाद की जांच को लिंक करने की सुविधा चाहिए. | बिडिंग के बाद पुष्टि करने का एक विकल्प, इवेंट-लेवल की रिपोर्टिंग में शामिल किए गए नीलामी और कैंपेन-आधारित सिग्नल के ज़रिए है. इससे, बिड से पहले लिए गए फ़ैसले के लॉग के साथ जॉइन की सुविधा चालू हो सकती है. हम इस सुविधा को उपलब्ध कराने के लिए, संभावित पैटर्न एक्सप्लोर कर रहे हैं. इस सुविधा के उपलब्ध होने पर, हम आपको अपडेट देंगे. |
| विज्ञापन की पुष्टि करना | बिडिंग से पहले, भरोसेमंद की-वैल्यू (टीकेवी) सर्वर के समाधानों (डीएसपी के मालिकाना हक वाले और विज्ञापन की पुष्टि करने वाले टूल के मालिकाना हक वाले) को एक्सप्लोर करने और बिडिंग के बाद, फ़ेंस किए गए फ़्रेम की सीमाओं को हल करने का अनुरोध. | हम इस अनुरोध का आकलन कर रहे हैं. साथ ही, यहां इकोसिस्टम से ज़्यादा सुझाव, शिकायत या राय देने का न्योता देते हैं. इससे हमें ऐसा समाधान ढूंढने में मदद मिलेगी जो बिड करने से पहले ब्रैंड सुरक्षा को बेहतर बना सके और दोनों पक्षों के बीच समन्वय की ज़रूरी शर्तों को आसान बना सके. |
| नेटिव विज्ञापन | नेटिव विज्ञापनों के लिए, बिड के बाद सेल-साइड रेंडरिंग ऑडिट का अनुरोध. | नेटिव विज्ञापनों के लिए सहायता उपलब्ध कराने के लिए, हम लगातार काम कर रहे हैं. साथ ही, हम नेटिव विज्ञापनों को रेंडर करने में मदद करने के लिए, इस तरह की मौजूदा सुविधाओं को अपनाने पर विचार कर रहे हैं. |
सुरक्षित नीलामी (B&A Services)
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| इंतज़ार का समय | इंतज़ार के समय को कम करने के लिए ज़रूरी कदम नहीं उठाए गए हैं. हालांकि, B&A Services की मदद से, लंबे समय में इस समस्या को कम किया जा सकता है. हालांकि, Google ने Chrome पर 3PCs में बदलाव करने से पहले, इसकी व्यापक उपलब्धता के लिए कोई वादा नहीं किया है. | हमने पिछले कुछ क्वार्टर में, डिवाइस पर इंतज़ार के समय को कम करने के लिए कई सुधार किए हैं. हम ज़रूरत के हिसाब से, बिक्री और सहायता से जुड़ी सेवाओं को भी बना रहे हैं और उन्हें बढ़ा रहे हैं. हमने हाल ही में, देरी से जुड़े सबसे सही तरीकों की गाइड को अपडेट किया है. इसमें इन सुविधाओं का फ़ायदा पाने के तरीके के बारे में ज़्यादा जानकारी दी गई है. हम इंतज़ार के समय को कम करने के लिए नए तरीके भी बना रहे हैं. इनमें से कुछ तरीकों के बारे में यहां बताया गया है. |
| (पिछली तिमाहियों में भी इसकी शिकायत की गई थी) ऑक्शन सिक्योरिटी |
डिवाइस पर होने वाली नीलामी में छेड़छाड़ करने की कोशिशों को रोकने/कम करने के तरीकों के बारे में ज़्यादा जानकारी का अनुरोध. उदाहरण के लिए, Google इसे एक गंभीर जोखिम मानता है या नहीं. | हमारी पिछली तिमाहियों की तुलना में, हमारा जवाब अब भी वही है: "PA API विज्ञापनों के रिपोर्टिंग सिस्टम में, आज भी वह जानकारी सेव रहती है जिसका इस्तेमाल, लोगों को बॉट ट्रैफ़िक से अलग करने के लिए किया जाता है. इसके अलावा, डोमेन को शामिल करने या बाहर रखने के लिए, डोमेन पर आधारित मौजूदा तकनीकों का इस्तेमाल PA API में किया जा सकता है. इस बारे में ज़्यादा जानकारी, Privacy Sandbox के बारे में IAB Tech Lab की रिपोर्ट के जवाब में दी गई है." |
| ऑन-प्राइमिस सलूशन | प्राइवेट क्लाउड के लिए सहायता उपलब्ध न होने और इसे इस्तेमाल करने के लिए लंबे और अस्पष्ट रोडमैप की वजह से, बड़े सप्लायर Privacy Sandbox या B&A को कैसे अपना सकते हैं, इस बारे में चिंता. | हम उन इन्फ़्रास्ट्रक्चर का दायरा बढ़ाने के लिए प्रतिबद्ध हैं जिन पर Privacy Sandbox की सेवाएं काम करती हैं. हमने हाल ही में Azure क्लाउड के लिए सहायता का एलान किया है. साथ ही, निजी क्लाउड के लिए निजता और सुरक्षा से जुड़ी ऐसी ही सुरक्षा देने के लिए, संभावित समाधानों की जांच जारी है. अक्टूबर में आपसे बातचीत करने के बाद, हमने इस मामले में आगे बढ़ने के लिए काम किया है. हम ऑन-प्राइमिस ट्रस्टेड एक्सीक्यूशन एनवायरमेंट (टीईई) में, Chrome के उपयोगकर्ताओं की निजता को सुरक्षित रखने के संभावित तरीकों पर लगातार रिसर्च कर रहे हैं. हम अब अपनी रिसर्च में उस मुकाम पर हैं जहां हमें पारिस्थितिकी तंत्र के हिस्सेदारों के साथ अलग-अलग तरीकों की पुष्टि करनी है. हमारा प्लान है कि हम पहली तिमाही में इनपुट इकट्ठा करना शुरू करें. नेटवर्क से मिले सुझावों और सहयोग से, किसी भी संभावित समाधान को बेहतर बनाने में मदद मिलेगी. |
| टेस्ट करना | क्या PA API के रिपोर्टिंग समाधानों (रीयल टाइम रिपोर्टिंग और निजी एग्रीगेशन) की जांच करने के लिए, टीईई बनाए जा सकते हैं? | एग्रीगेशन सेवा की जांच के लिए, विज्ञापन टेक्नोलॉजी विशेषज्ञ, फ़ंक्शनल टेस्टिंग की खास जानकारी वाली रिपोर्ट जनरेट करने के लिए, टेस्ट डेटा और लोकल टेस्टिंग टूल का इस्तेमाल कर सकते हैं. कृपया स्थानीय टेस्टिंग कोडलैब यहां देखें. टीईई में एग्रीगेशन की जांच करने के लिए, विज्ञापन टेक्नोलॉजी विशेषज्ञों को रजिस्टर करने की प्रक्रिया पूरी करनी होगी. इस बारे में ऊपर, कोडलैब की ज़रूरी शर्तों में बताया गया है. इस अनुरोध के बारे में ज़्यादा सुझाव, शिकायत या राय देने के लिए, यहां क्लिक करें. |
| डील के लिए K/V इंटिग्रेशन | कारोबार के इस्तेमाल के उदाहरणों के लिए, KV से डील पर आधारित जानकारी खींचने की सुविधा का अनुरोध करें. | हम इस सुविधा के अनुरोध का आकलन कर रहे हैं. हम GitHub पर इस बारे में अपडेट देंगे. |
| No-win Deal Measure |
सिग्नल का अनुरोध करना या यह समझने की सुविधा कि कोई एसएसपी कब और क्यों नहीं जीता. | हम इस अनुरोध की समीक्षा कर रहे हैं. हम GitHub पर इस बारे में अपडेट देंगे. |
| सुविधा का अनुरोध | प्राइवसी सैंडबॉक्स से डिक्शनरी स्ट्रक्चर उपलब्ध कराने का अनुरोध करें, ताकि विज्ञापनों के ग्रुप को डील आईडी के संबंधित सेट से मैच करने में मदद मिल सके. | हम इस अनुरोध का आकलन कर रहे हैं. साथ ही, डील आईडी को स्टोर करने के लिए, आईजी के साइज़ को कम करने के अन्य तरीकों का भी आकलन कर रहे हैं. हम GitHub पर इस बारे में अपडेट देंगे. |
| परफ़ॉर्मेंस | बिडिंग स्क्रिप्ट के साइज़ की वजह से, विज्ञापन नीलामी के छूटे हुए अवसरों को मेज़र करने के लिए समाधान. | हम इस अनुरोध की समीक्षा कर रहे हैं. अगर आपके पास कोई और सुझाव/राय/शिकायत है, तो यहां भेजें. |
| खास जानकारी | फ़िलहाल, B&A, स्पेसिफ़िकेशन में prevWins की जगह prevWinMs फ़ील्ड को बदलने के बजाय, सिर्फ़ prevWins फ़ील्ड को पढ़ता है. | यह सही है कि B&A, prevWins में मिलीसेकंड में अवधि को generatebid() को पास नहीं करता. Chrome, अवधि को सेकंड में भेजता है, ताकि पेलोड पर कम ओवरहेड हो. यहां B&A को सेकंड को मिलीसेकंड में बदलना होगा. B&A, browserSignals में prevWins और prevWinsMs, दोनों वैल्यू उपलब्ध कराएगा, ताकि इसे डिवाइस पर होने वाली नीलामियों के साथ काम किया जा सके.ध्यान दें, वेब के लिए ऑन-डिवाइस नीलामियों के लिए भी, prevWins और prevWinsMs एक ही वैल्यू के होते हैं. साथ ही, prevWinsMs = prevWins * 1,000 होता है. हम इस समस्या को ठीक करने पर काम कर रहे हैं. |
| दस्तावेज़ | दस्तावेज़ में, सेलर फ़्रंट एंड (एसएफ़ई) की जांच करने का तरीका साफ़ तौर पर नहीं बताया गया है. डिप्लॉयमेंट पूरा करने के तुरंत बाद, जांच करने के लिए अतिरिक्त दिशा-निर्देश और बिल्ड के लिए Bazel का इस्तेमाल करने का तरीका जानना मददगार होगा. | इस कोडलैब को गाइड के तौर पर पब्लिश किया गया है, ताकि इकोसिस्टम के ज़्यादा से ज़्यादा लोग अपने SFE की जांच आसानी से कर सकें. |
| डिप्लॉयमेंट | क्या B&A के लिए, पहले से बने बाइनरी उपलब्ध कराने का कोई प्लान है? | हम B&A के लिए, पहले से बनी बाइनरी उपलब्ध कराने पर विचार कर रहे हैं. हालांकि, हमारे पास इसके लिए कोई तय समयसीमा नहीं है. तब तक, विज्ञापन टेक्नोलॉजी कंपनियां खुद ही बाइनरी बना सकती हैं और दिए गए हैश का इस्तेमाल करके पुष्टि कर सकती हैं. |
| डिप्लॉयमेंट | क्या सभी तरह के ऑर्केस्ट्रेशन (सर्वर, क्लाइंट, मिक्स) काम करने चाहिए या किसी एक को दूसरों के मुकाबले प्राथमिकता दी जानी चाहिए? | हमारे पास यह सुझाव देने के लिए कोई खास जानकारी नहीं है कि विज्ञापन टेक्नोलॉजी किन मोड को लागू करती है. यह कई बातों पर निर्भर करता है, लेकिन आखिर में यह इस बात पर निर्भर करता है कि आपके ग्राहकों के लिए क्या सबसे सही है. |
| टेस्ट करना | B&A बिल्ड के दौरान, टेस्ट पास न होने के बारे में जानकारी चाहिए. | ऐसा, गड़बड़ी वाली जांच की वजह से हो सकता है. हमने विज्ञापन टेक्नोलॉजी को सभी build_and_test_all_in_docker बिल्ड कमांड के लिए --no-tests फ़्लैग का इस्तेमाल करने का सुझाव दिया है, ताकि टेस्ट न चलाए जा सकें. |
| लॉग | यह जानना है कि टेस्ट मोड में, GCP पर लॉग एक्सप्लोरर में मौजूद लॉग, SFE चलाने वाले VM इंस्टेंस पर टैग क्यों होते हैं, लेकिन प्रोडक्शन मोड में लॉग, VM इंस्टेंस पर टैग क्यों नहीं होते. | इस बारे में कोई सामान्य बात नहीं कही जा सकती, क्योंकि यह इस बात पर निर्भर करता है कि वास्तव में क्या देखा गया था. हालांकि, आम तौर पर: - non_prod से मिले लॉग, शायद क्लाउड सेवा देने वाली कंपनी (इस मामले में, GCP) ने रीडायरेक्ट किए गए stderr लॉग हैं और GCP ने टैग जोड़ा है. - आम तौर पर, वीएम से जनरेट होने वाले लॉग को वीएम इंस्टेंस के साथ टैग किया जाता है. वहीं, बाइनरी से जनरेट होने वाले लॉग को GCP टैग नहीं करता. - प्रोडक्शन से मिले लॉग, टीईई में Open Telemetry की मदद से एक्सपोर्ट किए जाते हैं. इनमें अलग-अलग टैग होते हैं. यहां बताया गया है कि non_prod और prod में क्या-क्या उपलब्ध है. |
| B&A | OTEL लॉगिंग बंद होने पर, पासकोड मौजूद न होने पर 403 कोड वाली गड़बड़ी. | 4.1 वर्शन के अपडेट के बाद, इस समस्या को ठीक कर दिया गया है. साथ ही, दस्तावेज़ में भी इसके हिसाब से बदलाव किया गया है. |
| B&A | GCP terraform कॉन्फ़िगरेशन के लिए outputs.tf फ़ाइल मौजूद न होने पर गड़बड़ी होती है. | अब यह समस्या ठीक कर दी गई है. |
| टेस्ट करना | टेस्ट मोड में निजी कुंजी फ़ेच करते समय गड़बड़ी हुई. | ऐसे मामलों में, कृपया पक्का करें कि सर्वर, TEST_MODE=true के साथ चल रहे हों. एक्सप्लेनर यहां देखें. |
| रोडमैप | क्या getInterestGroupAdAuctionData को एक से ज़्यादा सेलर ऑरिजिन स्वीकार करने और B&A पेलोड के सिफरटेक्स्ट में सेलर ऑरिजिन का मैप दिखाने के लिए बनाया गया है? | हां, navigator.getInterestGroupAdAuctionData() को एक से ज़्यादा सेलर को स्वीकार करने की अनुमति देने के लिए, सहायता जोड़ी जा रही है. |
| केवी की खास जानकारी | क्या KV यूआरएल (trustedScoringSignalsURL) को प्रॉमिस के तौर पर डिलीवर किया जा सकता है? | यहां दी गई जानकारी देखें. |
| B&A | नए प्लैटफ़ॉर्म हेडर बनाने का अनुरोध, ताकि B&A सेलर साइड को यह बताया जा सके कि निजी नीलामी के लिए क्लाइंट (ब्राउज़र) को किन सुविधाओं की ज़रूरत है. | फ़िलहाल, हम इस सुविधा के अनुरोध पर यहां चर्चा कर रहे हैं. साथ ही, हमें इस बारे में और सुझाव, शिकायत या राय मिलती रहे, तो हमें खुशी होगी. |
| ट्रैफ़िक शेपिंग | खास तौर पर डीएसपी के लिए, बीए सर्वर को होस्ट करने से जुड़ी बढ़ी हुई लागत को कम करने का प्रस्ताव. | फ़िलहाल, हम इस प्रस्ताव पर यहां चर्चा कर रहे हैं. साथ ही, हम आपके सुझाव, राय या शिकायतों का स्वागत करते हैं. |
| Bring-Your- Own-Binary |
'एक्सप्लेनर' को अपडेट करके, साफ़ तौर पर बताएं कि सभी बाइनरी काम करती हैं. | इसे अब अपडेट कर दिया गया है. इस बारे में ज़्यादा जानने के लिए, यहां जाएं. |
| केवी कॉल | क्या generateBid() सभी की-वैल्यू (KV) स्टोर कॉल के पूरा होने का इंतज़ार करता है या अलग से चलता है? KV बॅचिंग से, इसके समय पर क्या असर पड़ता है? |
यहां दी गई जानकारी देखें. |
| परफ़ॉर्मेंस | बिडिंग स्क्रिप्ट का फिर से इस्तेमाल करने के बारे में ज़्यादा दस्तावेज़ों का अनुरोध करना और स्क्रिप्ट पर कैश मेमोरी कंट्रोल हेडर सेट करने का सुझाव देना. | दस्तावेज़ यहां जोड़े गए हैं. |
| परफ़ॉर्मेंस | डिवाइस पर होने वाली नीलामी में लगने वाले समय को कम करने के लिए, रिसॉर्स (उदाहरण के लिए, बिडिंग स्क्रिप्ट) को अलग-अलग समय पर लोड करने की सुविधा को ध्यान में रखने और एक्सप्लोर करने का अनुरोध. | फ़िलहाल, हम इस सुविधा के अनुरोध पर यहां चर्चा कर रहे हैं. साथ ही, हमें इस बारे में और सुझाव, शिकायत या राय मिलती रहे, तो हमें खुशी होगी. |
| सहमति लॉग करना | CONSENTED_DEBUG_TOKEN सेट करके, सहमति लॉगिंग का इस्तेमाल करने के दौरान दिखने वाली गड़बड़ी के बारे में जानकारी चाहिए. | इन मामलों में, देखें कि सीक्रेट मैनेजर में CONSENTED_DEBUG_TOKEN मौजूद है या नहीं, ENABLE_OTEL_BASED_LOGGING को true पर सेट किया गया है या नहीं, और TELEMETRY_CONFIG को mode: PROD पर सेट किया गया है या नहीं. एक्सप्लेनर यहां देखें, जो सोर्स के बारे में यहां बताता है. |
| लॉग | क्या सिर्फ़ डीबग करने के लिए उपलब्ध इवेंट, B&A के ज़रिए उपलब्ध हैं? | बिडिंग और ऑप्टिमाइज़ेशन के लिए, forDebuggingOnly पैरामीटर अप्रैल 2024 से सिंगल सेलर की नीलामियों के लिए उपलब्ध है. हमारा प्लान है कि हम जल्द ही, एक से ज़्यादा सेलर वाली नीलामियों के लिए भी यह सुविधा चालू करें. |
| वर्कलेट लॉग | ChromeDriver के साथ काम करने वाले वर्कलेट को लॉग करने का अनुरोध. | हम इस अनुरोध की समीक्षा कर रहे हैं. अगर आपके पास कोई और सुझाव/राय/शिकायत है, तो यहां भेजें. |
डिजिटल विज्ञापनों की परफ़ॉर्मेंस का आकलन करना
एट्रिब्यूशन रिपोर्टिंग (और अन्य एपीआई)
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| डीबग रिपोर्ट | Chrome पर तीसरे पक्ष की कुकी के अपडेट किए गए तरीके के बाद, विज्ञापन टेक्नोलॉजी के लिए ARA डीबग रिपोर्ट कैसे उपलब्ध होंगी? क्या विज्ञापन टेक्नोलॉजी कंपनियों के पास अब भी उन उपयोगकर्ताओं के लिए ARA डीबग रिपोर्ट का ऐक्सेस होना चाहिए जिनके पास 3PCs हैं और जिन्होंने Privacy Sandbox API चालू किए हैं? |
विज्ञापन टेक्नोलॉजी के पास, कुकी पर आधारित और कुकी के बिना डीबग करने के समाधानों का ऐक्सेस होगा. यह ऐक्सेस, उन उपयोगकर्ताओं के लिए होगा जिनके डिवाइसों पर 3PC और ARA, दोनों चालू हैं. कुकी बंद होने पर, उनके पास सिर्फ़ एग्रीगेट डीबग सलूशन का ऐक्सेस होगा. डीबग करने के तरीकों के बारे में ज़्यादा जानकारी यहां और यहां उपलब्ध है. |
| फ़ीचर का पता लगाना | सर्वर-साइड पर ARA के लिए, सुविधा की पहचान करने का तरीका जानने के लिए अनुरोध करें. | फ़िलहाल, उपयोगकर्ता एजेंट स्ट्रिंग में दिखने वाले Chrome वर्शन के आधार पर, यह पता लगाया जा सकता है कि ARA की सुविधा काम कर रही है या नहीं. इस बारे में, हमें नेटवर्क से जुड़े सुझाव, शिकायत या राय भेजें. |
| सुविधा का अनुरोध | ARA के एग्रीगेट किए गए shared_info में इस्तेमाल किए गए source_registration_time के लिए, ज़्यादा जानकारी देने का अनुरोध.उदाहरण के लिए, एक दिन के बजाय एक घंटे या एक मिनट के हिसाब से राउंड किया गया. साथ ही, टाइमज़ोन को ध्यान में रखने के लिए कॉन्फ़िगर किया जा सकता है (फ़िलहाल, सिर्फ़ यूटीसी). | source_registration_time फ़ील्ड को राउंड करने का मतलब है कि उसे सबसे नज़दीकी दिन पर सेट करना. यह निजता से जुड़ा एक तरीका है. इसका इस्तेमाल, विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली कंपनी को किसी उपयोगकर्ता को किसी खास सोर्स रजिस्ट्रेशन से जोड़ने से रोकने के लिए किया जाता है. फ़िलहाल, source_registration_time यूटीसी पर आधारित है. विज्ञापन टेक्नोलॉजी की मदद से, इसकी वजह से होने वाली गड़बड़ी को ठीक करने के लिए, विज्ञापन रिपोर्ट में बदलाव किया जा सकता है. हम इस अनुरोध के बारे में, इकोसिस्टम से जुड़े अन्य सुझाव, शिकायत या राय का स्वागत करते हैं. इसके लिए, यहां क्लिक करें. |
| खास जानकारी | "trigger_data" और "priority" की खास जानकारी देने का अनुरोध, खास तौर पर तब जब इनका इस्तेमाल ऐरे वैल्यू के साथ किया जाता है. | इन फ़ील्ड में ऐरे वैल्यू नहीं डाली जा सकतीं. एक्सप्लेनर में स्क्वेयर ब्रैकेट, किसी ऐरे को नहीं दिखाते. इसके बजाय, इससे पता चलता है कि टेक्स्ट, वैल्यू का उदाहरण नहीं है, बल्कि जानकारी वाला प्लेसहोल्डर है. जैसा कि स्क्वेयर ब्रैकेट में मौजूद टेक्स्ट से पता चलता है: - trigger_data एक int-64 है - priority एक signed int-64 है इनमें से कोई भी फ़ील्ड, ऐरे वैल्यू स्वीकार नहीं करता. ARA के लिए हेडर की पुष्टि करने वाले टूल का इस्तेमाल करना भी फ़ायदेमंद होता है. इससे, अलग-अलग वैल्यू आज़माने में मदद मिलती है. साथ ही, दस्तावेज़ में गड़बड़ियों का पता चलता है. |
| Accelerated Mobile Pages (एएमपी) विज्ञापनों के लिए सहायता | क्या ARA, एएमपी विज्ञापनों के साथ काम करता है? | AMP के साथ काम करने के तरीके के बारे में हमारा प्रस्ताव यहां उपलब्ध है. साथ ही, हम आपके सुझाव, राय या शिकायतों का स्वागत करते हैं. |
| खास जानकारी | ARA के लिए, मल्टी-लेयर एम्बेड किए गए विज्ञापनों के लिए किस यूआरएल को "सोर्स-साइट" माना जाएगा? | टॉप लेवल साइट का यूआरएल. |
| (पिछली तिमाहियों में भी इसकी शिकायत की गई थी) सुविधा का अनुरोध |
event_report_window की कम से कम वैल्यू को 3600 सेकंड (एक घंटा) से घटाकर 1800 सेकंड (30 मिनट) करने का अनुरोध. | रिपोर्टिंग विंडो की कम से कम अवधि तय करने के लिए, उपयोगिता और निजता के पहलुओं को ध्यान में रखना ज़रूरी है. निजता बनाए रखने और इतिहास को फिर से बनाने से जुड़े कुछ तरह के हमलों को कम करने के लिए, इवेंट-लेवल की रिपोर्ट के लिए कम से कम एक घंटे की रिपोर्टिंग विंडो ज़रूरी है. इस अनुरोध के बारे में ज़्यादा सुझाव, शिकायत या राय देने के लिए, यहां क्लिक करें. |
| शोर | ARA इवेंट-लेवल की रिपोर्ट में, ग़ैर-ज़रूरी डेटा को हटाने के तरीके के बारे में ज़्यादा जानकारी चाहिए, ताकि डेटा का सटीक तरीके से विश्लेषण किया जा सके और उसका इस्तेमाल किया जा सके. | ज़्यादा जानकारी यहां और यहां उपलब्ध है. |
| रिपोर्टिंग | अब एग्रीगेट रिपोर्ट की shared_info में, डिफ़ॉल्ट रूप से source_registration_time शामिल नहीं होता. | ऐसा एपीआई में हुए बदलावों की वजह से हुआ है. इस बारे में ज़्यादा जानकारी यहां दी गई है. |
| रिपोर्टिंग | filtering_id, chrome://attribution-internals/ यूज़र इंटरफ़ेस के "एग्रीगेट की जा सकने वाली रिपोर्ट" टैब में मौजूद नहीं है. |
फ़िलहाल, किसी लाइन पर क्लिक करने पर, "ट्रिगर रजिस्ट्रेशन" टैब की जानकारी में filtering_id दिखता है. इससे, इसकी पुष्टि की जा सकती है. हम "एग्रीगेट की जा सकने वाली रिपोर्ट" टैब में इसे दिखाने की अहमियत समझते हैं. हमने इस बारे में यहां बताया है. |
| एट्रिब्यूशन का सोर्स | एट्रिब्यूशन सोर्स के काम करने के तरीके के बारे में जानकारी का अनुरोध. | इस बारे में ज़्यादा जानकारी यहां दी गई है. |
| ऐप्लिकेशन से वेब पर ट्रांज़िशन का एट्रिब्यूशन | ऐसे अनुरोध जिनमें यह तय नहीं है कि सोर्स ओएस या वेब में से किस तरह के होंगे. | इसके बारे में ज़्यादा जानकारी यहां दी गई है. |
एग्रीगेशन सेवा
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| सुविधा का अनुरोध | AgS के लिए, कॉन्फ़िगर किए जा सकने वाले टाइम आउट और/या लंबे समय तक चलने वाले जॉब की स्थिति को ज़्यादा से ज़्यादा लोगों को दिखाने का अनुरोध करें. | हम लंबे समय तक चलने वाले जॉब को मॉनिटर करने की सुविधाएं उपलब्ध कराने पर विचार कर रहे हैं. इस बारे में, हमें नेटवर्क से जुड़े सुझाव, शिकायत या राय भेजें. |
| Terraform | Terraform, service_account_token_creator_list सेट न होने पर भी खाते की IAM नीति में बदलाव करने की कोशिश कर रहा है. | डेवलपर, जोड़ी गई अनुमतियों को अपने लोकल मॉड्यूल/adtech_setup/main.tf फ़ाइल में जोड़ सकते हैं. |
| दस्तावेज़ का अनुरोध | एग्रीगेशन सेवा की परफ़ॉर्मेंस पर नज़र रखने का तरीका बताने वाले दस्तावेज़ या कोडलैब का अनुरोध करना. | coordinator-services-and-shared-libraries रिपॉज़िटरी में, ऑपरेटर की terraform फ़ाइलों (alarms.tf और monitoring.tf) में, सेवा और जॉब की परफ़ॉर्मेंस पर नज़र रखने के लिए इस्तेमाल किए जा सकने वाले मौजूदा अलार्म की जानकारी मिल सकती है. एग्रीगेशन सेवा जॉब को मॉनिटर करने के तरीके के बारे में, हम ज़्यादा दस्तावेज़ और दिशा-निर्देश पब्लिश करेंगे. |
| स्केलिंग: | स्केलिंग से जुड़ी समस्याओं को कैसे मॉनिटर करें? | हमने इस दिशा-निर्देश का अपडेट किया गया वर्शन पब्लिश किया है. इसमें एग्रीगेशन सेवा के बड़े पैमाने पर इस्तेमाल के बारे में बताया गया है. फ़िलहाल, कोई सीधा सिग्नल नहीं है जिससे यह पता चलता हो कि मशीन, जॉब के स्केल के साथ काम नहीं कर रही है. इनडायरेक्ट सिग्नल में ये शामिल हैं: गड़बड़ी से पहले 90% मेमोरी खर्च होना, बार-बार गड़बड़ी होना. हम ऐसे सिग्नल की ज़रूरत के बारे में, नेटवर्क से जुड़े अन्य लोगों के सुझाव, राय या शिकायतें सुनने के लिए तैयार हैं. |
| खास जानकारी | AgS रिपोर्ट के बैच का सामान्य रन टाइम क्या होता है? | कृपया यहां दिए गए दिशा-निर्देश देखें. |
Private Aggregation API
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| सुविधा का अनुरोध | फ़्लोट वैल्यू (इनमें नेगेटिव वैल्यू भी शामिल हैं) को contributeToHistogramOnEvent में शामिल करने की अनुमति देने का अनुरोध, 2^16 की संवेदनशीलता के साथ | फ़िलहाल, हम इस प्रस्ताव पर यहां चर्चा कर रहे हैं. साथ ही, हम आपके सुझाव, राय या शिकायतों का स्वागत करते हैं. |
गुप्त ट्रैकिंग को सीमित करना
यूज़र-एजेंट रिडक्शन/यूज़र-एजेंट क्लाइंट हिंट
इस तिमाही में कोई सुझाव, राय या शिकायत नहीं मिली.
आईपी पते की सुरक्षा (पहले इसे Gnatcatcher कहा जाता था)
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| जगह से जुड़ी जानकारी | आईपी पते की सुरक्षा से जुड़ी जगह की जानकारी वाली फ़ाइल का अनुरोध करना. | आईपी की सुरक्षा के लिए, आईपी को जगह की अनुमानित जानकारी से मैप करने वाली फ़ाइल यहां उपलब्ध है. कृपया ध्यान दें कि इस फ़ाइल को समय-समय पर अपडेट किया जाता है. |
बाउंस ट्रैकिंग को कम करने की सुविधा
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| अनुमति वाली सूची | अपडेट की गई स्थिति में, अनुमति वाली सूची या मिलते-जुलते ऐसे तरीकों के बारे में नहीं बताया गया है जो Google की फ़ैसला लेने की प्रोसेस से अलग हों. | Google, बाउंस ट्रैकिंग कम करने (बीटीएम) से जुड़ी अनुमति वाली कोई सूची नहीं बनाएगा. सुरक्षा के ये उपाय सभी डोमेन पर एक जैसे लागू होते हैं. |
| अनुपालन | आईसीओ के पास निजता से जुड़ी शर्तों का पालन करने की अनुमति होनी चाहिए. | नीति का पालन करने की स्थिति का, बीटीएम के लागू होने से कोई लेना-देना नहीं है. साथ ही, Google, बीटीएम को लागू करने के लिए नीति का पालन करने से जुड़ा कोई फ़ैसला नहीं लेता. |
| प्रतिस्पर्धा | ऐसा लगता है कि Google को बीटीएम (या अन्य तरीकों) का इस्तेमाल करके, पीईटी के प्रतिस्पर्धियों को फ़ोरक्लोज़ करने की अनुमति मिल सकती है. इसके बाद, वह यह तय कर सकता है कि उन्हें फिर से बाज़ार में आने की अनुमति देनी है या नहीं. अपील की मौजूदा प्रोसेस की वजह से, पीईटी के प्रतिस्पर्धी कुछ समय के लिए बीटीएम या मिलते-जुलते तरीकों का इस्तेमाल नहीं कर पाएंगे. | मौजूदा बीटीएम प्रोसेस का मकसद, बाउंस ट्रैकिंग को एक तकनीक के तौर पर इस्तेमाल करना है. Google का मकसद, ऐसे कुछ इस्तेमाल के उदाहरणों को रोकना है जिनमें मिलती-जुलती तकनीकें शामिल हो सकती हैं. हालांकि, Google के पास किसी को भी बीटीएम से छूट देने का कोई प्लान नहीं है. इसलिए, Google के पास यह तय करने का विकल्प नहीं है कि प्रतिस्पर्धियों को दिखाना है या नहीं. |
अलग-अलग साइटों पर निजता की सीमाओं को बेहतर बनाना
मिलती-जुलती वेबसाइट के सेट (पहले इन्हें फ़र्स्ट-पार्टी सेट कहा जाता था)
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| (पिछली तिमाहियों में भी रिपोर्ट की गई) मिलती-जुलती वेबसाइट के सेट (आरडब्ल्यूएस) के लिए डोमेन की सीमा |
क्रॉस-साइट मेज़रमेंट के इस्तेमाल के उदाहरणों को पूरा करने के लिए, पांच असोसिएटेड डोमेन की मौजूदा सीमा काफ़ी नहीं है. | हमारा जवाब पिछली तिमाहियों के जवाब से मिलता-जुलता है: फ़िलहाल, हमें संख्या की सीमा बढ़ाने की उम्मीद नहीं है. यह सीमा, उपयोगकर्ता की निजता को ध्यान में रखते हुए तय की गई है. साथ ही, W3C के नेटवर्क के हिस्सेदारों से मिले सुझावों और अन्य ब्राउज़र में लागू किए गए इसी तरह के फ़ंक्शन के आधार पर भी यह सीमा तय की गई है. ज़्यादा जानकारी के लिए, कृपया हमारी ब्लॉग पोस्ट (1, 2) देखें. हमारा सुझाव है कि आप उन इस्तेमाल के उदाहरणों की जांच करें जिनमें संख्या की सीमा से ज़्यादा क्रॉस-साइट कुकी ऐक्सेस की ज़रूरत होती है. साथ ही, पहचान के इस्तेमाल के उदाहरणों, पुष्टि किए गए एम्बेड, और विज्ञापन के इस्तेमाल के उदाहरणों के लिए हमारे दिशा-निर्देशों का इस्तेमाल करें. इस समस्या के बारे में ज़्यादा सुझाव/राय/शिकायत देने के लिए, यहां क्लिक करें. |
Fenced Frames API
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| नेटिव विज्ञापन | फ़ेंस किए गए फ़्रेम में नेटिव विज्ञापन रेंडर करने में समस्याएं आती हैं. इसकी वजह यह है कि iframe और पब्लिशर के पेज के बीच कम्यूनिकेशन की सीमाओं की वजह से, पब्लिशर की स्टाइल को इनहेरिट करना सीमित है. | फ़ेंस किए गए फ़्रेम लागू करने के बाद, नेटिव विज्ञापनों के लिए ज़्यादा सहायता उपलब्ध कराना, रिसर्च का एक ज़रूरी हिस्सा है. इस समस्या के बारे में ज़्यादा सुझाव/राय/शिकायत देने के लिए, यहां क्लिक करें. |
Shared Storage API
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| एपीआई प्रयोग | जब Privacy Sandbox के अन्य एपीआई काम कर रहे हों, तो कुछ डिवाइसों पर Shared Storage API उपलब्ध नहीं होता. | ऐसा हो सकता है कि शेयर किए गए स्टोरेज को रोकने के प्रयोग में शामिल उपयोगकर्ताओं के एक छोटे से सबसेट (लगभग 1%) के लिए, यह सुविधा उपलब्ध न हो. इस एक्सपेरिमेंटल सेटअप का इस्तेमाल, अलग-अलग स्थितियों में एपीआई की परफ़ॉर्मेंस और उन्हें अपनाने का आकलन करने के लिए किया जाता है. |
| एपीआई प्रयोग | क्या Shared Storage में डेटा पब्लिशर ऑरिजिन या बिडिंग स्क्रिप्ट ऑरिजिन के तहत लिखा जाता है? शुरुआती जांच में पता चला कि पब्लिशर का ऑरिजिन, स्क्रिप्ट के ऑरिजिन से अलग होने पर, कोई डेटा नहीं लिखा गया. | इस समस्या को ठीक कर दिया गया है. हालांकि, अगर डेवलपर टूल में कोई गड़बड़ी है, तो यह समस्या बनी रहेगी. ज़्यादा जानकारी यहां उपलब्ध है. शेयर किया गया स्टोरेज, generateBid कॉल के बिडिंग कॉन्टेक्स्ट में खरीदार के ऑरिजिन में लिखता है. लिखने की सुविधा, पब्लिशर के ऑरिजिन से जुड़ी नहीं होती. भले ही, पब्लिशर पेज किसी दूसरे डोमेन पर हो. |
| एपीआई प्रयोग | शेयर किए गए स्टोरेज की रिपोर्ट को कोई नुकसान पहुंचाने वाला व्यक्ति न पढ़ पाए, इसके लिए क्या सुरक्षा व्यवस्थाएं हैं? | शेयर किए गए स्टोरेज को ऑरिजिन को कॉल करके बांटा जाता है, ताकि कोई बुरा व्यक्ति या विज्ञापन टेक्नोलॉजी, किसी दूसरे विज्ञापन टेक्नोलॉजी से शेयर किए गए स्टोरेज का डेटा न पढ़ सके. निजी एग्रीगेशन रिपोर्ट को सीधे उसी ऑरिजिन पर TLS के ज़रिए भेजा जाता है, ताकि उन्हें इंटरसेप्ट न किया जा सके. |
सीएचआईपीएस
| सुझाव, राय या शिकायत की थीम | खास जानकारी | Chrome का जवाब |
|---|---|---|
| पार्टिशन की गई कुकी | Chrome और Firefox में, अलग-अलग localhost पोर्ट पर कुकी को अलग-अलग तरीके से मैनेज किया जाता है. खास तौर पर, Partitioned एट्रिब्यूट का इस्तेमाल करने पर ऐसा होता है. | Firefox, अलग-अलग पोर्ट वाले localhost को अलग-अलग पार्टीशन कुंजियों के तौर पर इस्तेमाल करता है. हालांकि, यह व्यवहार सुरक्षा के सिद्धांतों के मुताबिक है, लेकिन यह खास बातों और Chrome के तरीके से अलग है. हम उम्मीद करते हैं कि हम एचटीएमएल स्पेसिफ़िकेशन की चर्चा में, अन्य ब्राउज़र के साथ इस बारे में बातचीत करेंगे. अगर इससे CHIPS पार्टीशन की कुंजी में कोई बदलाव होता है, तो हम इकोसिस्टम को इसकी सूचना देंगे. इस समस्या के बारे में ज़्यादा सुझाव/राय/शिकायत देने के लिए, यहां क्लिक करें. |
| पार्टिशन की गई कुकी | 'साइट डेटा मिटाएं' ड्राफ़्ट में, गलत तरीके से उत्सर्जन करने वाली साइट के पार्टीशन के अलावा, अन्य पार्टीशन से भी डेटा मिटाने की अनुमति दी गई है. यह यहां दी गई पिछली चर्चाओं के उलट है. | यह स्टैंडर्ड स्पेसिफ़िकेशन दस्तावेज़ में मौजूद एक बग है. हम इसे जल्द ही ठीक कर देंगे. सही तरीके के बारे में, एक्सप्लेनेटर के इस सेक्शन में बताया गया है. यह स्टोरेज पार्टिशनिंग एक्सप्लेनेटर रिपॉज़िटरी पर मौजूद, दूसरे ब्राउज़र के व्यवहार से मेल खाता है. Chrome पर, यह सुविधा पहले से ही सही तरीके से काम कर रही है. |
FedCM
इस तिमाही में कोई सुझाव, राय या शिकायत नहीं मिली.
स्पैम और धोखाधड़ी से निपटना
Private State Token API (और अन्य एपीआई)
इस तिमाही में कोई सुझाव, राय या शिकायत नहीं मिली.