साल 2022 की तीसरी तिमाही की तिमाही रिपोर्ट, जिसमें प्राइवसी सैंडबॉक्स के प्रपोज़ल और Chrome से मिले जवाब के बारे में नेटवर्क से मिले सुझावों की खास जानकारी दी गई है.
सीएमए को लेकर अपनी जवाबदेही के तहत, Google ने प्राइवसी सैंडबॉक्स के प्रपोज़ल के लिए, पार्टनर के जुड़ाव की प्रोसेस की तीन महीने में तीन रिपोर्ट सार्वजनिक तौर पर उपलब्ध कराने की सहमति दी है. कमीमेंट के पैराग्राफ़ 12 और 17(c)(ii) देखें. प्राइवसी सैंडबॉक्स से जुड़ी फ़ीडबैक की खास जानकारी वाली ये रिपोर्ट, अलग-अलग सोर्स से मिले सुझावों को इकट्ठा करके जनरेट की जाती हैं. इन सोर्स की जानकारी फ़ीडबैक खास जानकारी में दी गई है. इसमें इनके अलावा, और भी चीज़ें शामिल हो सकती हैं: GitHub समस्याएं, privacysandbox.com पर उपलब्ध कराए गए सुझाव फ़ॉर्म. Chrome, नेटवर्क से मिले सुझाव, शिकायत या राय का स्वागत करता है. साथ ही, वह डिज़ाइन से जुड़े फ़ैसलों में सीखने के तरीकों को शामिल करने के तरीके खोज रहा है.
सुझाव, शिकायत या राय की थीम, हर एपीआई की संख्या के हिसाब से रैंक की जाती हैं. इसके लिए, Chrome टीम को मिले सुझाव, शिकायत या राय को किसी तय थीम के आधार पर इकट्ठा करके और उन्हें घटते हुए क्रम में व्यवस्थित किया जाता है. फ़ीडबैक से जुड़ी सामान्य थीम की पहचान करने के लिए, हमने सार्वजनिक मीटिंग (W3C, PatCG, IETF), सीधे तौर पर सुझाव/शिकायत/राय, GitHub पर चर्चा के विषयों और Google की इंटरनल टीम और पब्लिक फ़ॉर्म की मदद से अक्सर पूछे जाने वाले सवालों की समीक्षा की.
खास तौर पर, वेब स्टैंडर्ड बॉडी मीटिंग के लिए तय किए गए समय की समीक्षा की गई और सीधे सुझाव के लिए, Google के 1:1 हिस्सेदारों की मीटिंग के रिकॉर्ड, अलग-अलग इंजीनियर को मिले ईमेल, एपीआई ईमेल पाने वाले लोगों की सूची, और लोगों के सुझाव देने वाले फ़ॉर्म पर विचार किया गया. इसके बाद, Google ने टीम के बीच इन अलग-अलग आउटरीच गतिविधियों को शामिल किया, ताकि यह पता लगाया जा सके कि हर एपीआई के बारे में उभर रही थीम की लोकप्रियता कितनी है.
फ़ीडबैक पर Chrome ने क्या जवाब दिए, यह जानने के लिए अक्सर पूछे जाने वाले सवालों, हिस्सेदारों की ओर से उठाए गए मुद्दों पर असल जवाब, और खास तौर पर सार्वजनिक रिपोर्टिंग की प्रोसेस के लिए एक स्थिति तय की गई है. डेवलपमेंट और टेस्टिंग के मौजूदा फ़ोकस को दिखाते हुए, हमें खास तौर पर Topics, फ़्लैज, और एट्रिब्यूशन रिपोर्टिंग एपीआई के बारे में सवाल और सुझाव मिले.
हो सकता है कि मौजूदा रिपोर्टिंग अवधि के खत्म होने के बाद मिलने वाले फ़ीडबैक को अभी तक Chrome के जवाब के तौर पर न माना जाए.
संक्षिप्त नाम की शब्दावली
- सीएचआईपीएस
- कुकी, इंडिपेंडेंट पार्टिशन्ड स्टेट है
- डीएसपी
- डिमांड-साइड प्लैटफ़ॉर्म
- FedCM
- फ़ेडरेटेड क्रेडेंशियल मैनेजमेंट
- FPS (फ़्रेम प्रति सेकंड)
- पहले पक्ष के सेट
- IAB
- इंटरैक्टिव विज्ञापन ब्यूरो
- आईडीपी
- पहचान देने वाली कंपनी
- आईईटीएफ़
- इंटरनेट इंजीनियरिंग टास्क फ़ोर्स
- IP
- इंटरनेट प्रोटोकॉल पता
- openRTB
- रीयल-टाइम बिडिंग
- OT
- ऑरिजिन ट्रायल
- PatCG
- प्राइवेट ऐडवर्टाइज़िंग टेक्नोलॉजी कम्यूनिटी ग्रुप
- RP
- भरोसेमंद पार्टी
- एसएसपी
- सप्लाई-साइड प्लैटफ़ॉर्म
- TEE
- भरोसेमंद तरीके से एक्ज़ीक्यूशन एनवायरमेंट
- UA
- उपयोगकर्ता एजेंट स्ट्रिंग
- UA-CH
- उपयोगकर्ता-एजेंट क्लाइंट हिंट
- W3C
- वर्ल्ड वाइड वेब कंसोर्टियम
- डब्ल्यूआईपीबी
- विलफ़ुल आईपी ब्लाइंडनेस
सामान्य सुझाव, किसी खास एपीआई/टेक्नोलॉजी के आधार पर नहीं
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
| (दूसरी तिमाही में इसकी रिपोर्ट भी की गई)
अलग-अलग तरह के हिस्सेदारों के लिए उपयोगिता |
यह चिंता की बात है कि प्राइवसी सैंडबॉक्स टेक्नोलॉजी, बड़े डेवलपर को पसंद आती है. साथ ही, सामान्य (बड़ी) साइटों के मुकाबले, खास (छोटी) साइटों का योगदान ज़्यादा होता है. | तीसरी तिमाही का अपडेट:
Google, सीएमए के लिए प्रतिबद्ध है कि वह प्राइवसी सैंडबॉक्स के प्रपोज़ल को इस तरह से डिज़ाइन और लागू करे कि Google के कारोबार को प्राथमिकता देकर, प्रतिस्पर्धा को खराब न करे. साथ ही, डिजिटल विज्ञापन में, पब्लिशर और विज्ञापन देने वालों पर पड़ने वाले असर को ध्यान में रखा जाए, चाहे उनका साइज़ कुछ भी हो. हम यह पक्का करने के लिए सीएमए के साथ मिलकर काम करते रहते हैं कि हमारा काम इन प्रतिबद्धताओं का पालन करे. प्राइवसी सैंडबॉक्स की टेस्टिंग के दौरान, हम इस अहम सवाल का आकलन करेंगे कि अलग-अलग तरह के हिस्सेदारों के लिए नई टेक्नोलॉजी कैसा परफ़ॉर्म कर रही है. इस मामले में सुझाव, राय या शिकायत बहुत अहम है. खास तौर पर, सटीक और कार्रवाई करने लायक सुझाव, शिकायत या राय की मदद से हम तकनीकी डिज़ाइन को और बेहतर बना सकते हैं. हमने संख्यात्मक परीक्षण के लिए अपने तरीके को विकसित करने के लिए सीएमए के साथ काम किया है. साथ ही, हम प्रयोग के डिज़ाइन पर नोट पब्लिश करने में सीएमए की सहायता करते हैं, ताकि बाज़ार में हिस्सा लेने वालों को ज़्यादा जानकारी दी जा सके और सुझाए गए तरीकों पर टिप्पणी करने का मौका दिया जा सके. |
| (दूसरी तिमाही में इसकी रिपोर्ट भी की गई)
दस्तावेज़ के अनुरोध |
टेस्टिंग, विश्लेषण, और लागू करने की प्रोसेस को मैनेज करने के तरीके की जानकारी देने वाले ज़्यादा संसाधनों के अनुरोध | तीसरी तिमाही का अपडेट:
हम इस बात की सराहना करते हैं कि डेवलपर को हमारा मौजूदा कॉन्टेंट मददगार लगा. हम आने वाले हफ़्तों और महीनों में ज़्यादा से ज़्यादा कॉन्टेंट उपलब्ध कराने के लिए प्रतिबद्ध हैं, ताकि डेवलपर को लगातार यह समझने में मदद मिले कि नई टेक्नोलॉजी उनके लिए किस तरह काम कर सकती है. हमने डेवलपर के लिए ऑफ़िस में कामकाज के घंटे के दौरान, सार्वजनिक तौर पर उपलब्ध सेशन आयोजित किए हैं. इन सेशन में, प्रॉडक्ट के इस्तेमाल से जुड़े सबसे सही तरीके और डेमो शेयर किए जाएंगे. साथ ही, प्रॉडक्ट और इंजीनियरिंग लीड के साथ सवाल-जवाब के सेशन भी आयोजित किए गए, ताकि लोग चर्चा या सवालों के जवाब दे सकें. |
| क्रॉस-ब्राउज़र सहायता | प्राइवसी सैंडबॉक्स एपीआई का इस्तेमाल करने वाले अन्य ब्राउज़र वेंडर. | Apple, Mozilla, और Microsoft जैसे ब्राउज़र की सेवा देने वाले अन्य लोग, सार्वजनिक फ़ोरम पर सक्रिय रहते हैं. यहां निजता से जुड़े सिद्धांतों और ब्राउज़र पर आधारित तरीकों पर चर्चा की जा रही है. हाल ही में हुई W3C की सालाना TPAC मीटिंग और अभी चल रहे W3C PATCG फ़ोरम जैसे फ़ोरम में, साथ मिलकर काम करने से हमें खुशी हो रही है. इन फ़ोरम में कई तरह की सहमति है. |
| प्लैटफ़ॉर्म में अंतर | ट्रांज़िशन के लिए ज़रूरी संसाधनों को कम करने के लिए, वेब और Android पर सुविधाओं के सेट को ज़्यादा से ज़्यादा अलाइन करने का अनुरोध करें. | हम Chrome और Android पर हर तरह के काम करने के लिए कड़ी मेहनत कर रहे हैं, ताकि पूरी इंडस्ट्री में भ्रम की स्थिति पैदा न हो. हमारे इस तरीके में कोई भी अंतर मुख्य रूप से वेब और मोबाइल ऐप्लिकेशन प्लैटफ़ॉर्म के बीच ज़रूरी तकनीकी अंतर की वजह से होगा, जिन्हें डेवलपर पहले से ही ध्यान में रखेंगे. |
| प्राइवसी सैंडबॉक्स एपीआई की जांच करने के लिए संसाधन | काफ़ी जगह असाइन करने में दिक्कतें
में मौजूद संसाधनों को एक्सप्लोर कर रहा है. |
Google, टेस्टर के लिए उपलब्ध दस्तावेज़ और सहायता में लगातार सुधार कर रहा है, ताकि एपीआई को इस्तेमाल करने में आसानी हो और उसे अपनाने में मदद मिल सके. इन कोशिशों में शामिल हैं: एपीआई से जुड़ी, ईमेल पाने वाले लोगों की सूचियां, ऑफ़िस में कामकाज के घंटे, और developers.chrome.com पर लगातार होने वाले अपडेट. |
| Sandbox API ऑप्ट-आउट सिग्नल | 'उपयोगकर्ता ने सैंडबॉक्स एपीआई सिग्नल से ऑप्ट आउट किया है' सिग्नल देने का अनुरोध करें. विज्ञापन टेक्नोलॉजी और वेबसाइटें, इस सिग्नल का इस्तेमाल कर सकती हैं. | हमने ऐसे कई पुराने मामले देखे हैं जहां वेबसाइटें, उपयोगकर्ता की पसंद को ध्यान में रखकर प्रतिक्रिया देती हैं, जैसे कि "तीसरे पक्ष की कुकी बंद करना". ऐसा तब होता है, जब उपयोगकर्ता पर अपनी सेटिंग बदलने के लिए कहा जाता है. कभी-कभी इसमें वेबसाइट के ऐक्सेस को ब्लॉक करना भी शामिल है, बशर्ते वे ऐसा न करें. फ़िंगरप्रिंट की सुविधा के लिए, ऑप्ट-आउट सिग्नल का इस्तेमाल एक अन्य सिग्नल के तौर पर भी किया जा सकता है. इस समय, Google का इरादा ऑप्ट-आउट सिग्नल देने का नहीं है |
| (दूसरी तिमाही में इसकी रिपोर्ट भी की गई)
समयावधि के बारे में साफ़ तौर पर जानकारी पाएं |
साफ़ और ज़्यादा जानकारी के साथ रिलीज़ करने के शेड्यूल | तीसरी तिमाही का अपडेट:
जैसा कि नीचे दिए गए सुझाव, शिकायत या राय वाले सेक्शन में किए गए बदलावों के बारे में बताया गया है. Google ने जुलाई में प्राइवसी सैंडबॉक्स की टाइमलाइन को अपडेट किया, ताकि बाज़ार को शुरुआती टेस्टिंग और सुझाव, शिकायत या राय के लिए ज़्यादा समय मिल सके. साथ ही, तीसरे पक्ष की कुकी के बंद होने से पहले, प्राइवसी सैंडबॉक्स एपीआई के पूरी तरह लॉन्च होने के बाद, टेस्ट के लिए ज़्यादा समय मिल सके. |
| (दूसरी तिमाही में इसकी रिपोर्ट भी की गई)
तीसरे पक्ष की कुकी के बंद होने की टाइमलाइन |
तीसरे पक्ष की कुकी के इस्तेमाल को रोकने के अनुरोध | तीसरी तिमाही का अपडेट:
जुलाई में, Chrome ने तीसरे पक्ष की कुकी के इस्तेमाल को बंद करने के लिए, अपडेट की गई टाइमलाइन का एलान किया था. इससे, टेक्नोलॉजी की जटिलता और नेटवर्क में उनकी अहमियत को ध्यान में रखते हुए ज़िम्मेदारी के साथ काम करने की हमारी प्रतिबद्धता दिखाई गई थी. इस बदलाव से पहले, संबंधित रेगुलेटर और इंडस्ट्री के सुझावों को ध्यान में रखा गया था. हम सभी हिस्सेदारों के साथ मिलकर काम कर रहे हैं. |
| पहले-पक्ष की कुकी | क्या पहले-पक्ष की कुकी पर भी पाबंदियों का सुझाव दिया जा रहा है? अगर ऐसा है, तो लंबे समय तक स्थिरता की चिंता, ब्राउज़र में होने वाले संभावित बदलावों से जोखिम हो सकता है और इस वजह से इंजीनियरिंग में काम करने में लगने वाला समय बर्बाद हो सकता है. | हमने पहले-पक्ष की कुकी से जुड़ी किसी पाबंदी पर कोई विचार नहीं किया है. प्राइवसी सैंडबॉक्स, तीसरे पक्ष की कुकी का इस्तेमाल रोकने पर फ़ोकस करता है. |
काम का कॉन्टेंट और विज्ञापन दिखाएं
विषय
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
| (दूसरी तिमाही में इसकी रिपोर्ट भी की गई)
अलग-अलग तरह के हिस्सेदारों के लिए उपयोगिता |
साइटों के लिए कितने काम के हैं, इस बात को लेकर चिंता बढ़ गई है. यह इस बात पर निर्भर करता है कि साइट के ट्रैफ़िक का लेवल क्या है या उनका कॉन्टेंट कितना खास है. | तीसरी तिमाही का अपडेट:
टेस्टिंग के ज़रिए यह पता लगाया जाएगा कि यह एपीआई काम का है या नहीं. प्रतिबद्धता के अनुच्छेद 17.c.ii के मुताबिक, Google इस तरह के टेस्ट के नतीजों को CMA के साथ शेयर करेगा. Chrome को उम्मीद है कि जांच के नतीजों के आधार पर अलग-अलग कैटगरी और अन्य पैरामीटर में बदलाव होगा. कैटगरी या पैरामीटर के क्रमिक विकास के लिए, हो सकता है कि पुराने सिस्टम के साथ काम न करने वाले बदलावों की ज़रूरत न पड़े. इसके अलावा, Chrome को उम्मीद है कि तीसरे पक्ष की कुकी के बंद होने के बाद भी, Topics API के डेवलपमेंट पर असर पड़ता रहेगा. |
| निजता/नीति | हर कॉलर के लिए विषय को फ़िल्टर करने की ज़रूरी शर्त को हटाने का अनुरोध करें. | निजता केओएफ़, निजता के वकील, सुरक्षा विशेषज्ञों, डिजिटल अधिकारों के लिए बने ग्रुप, और नेटवर्क के अन्य लोगों से मिले सुझावों के आधार पर, Chrome ने इस डिज़ाइन को चुना. यह डिज़ाइन ऐसे लोगों को जानकारी का ऐक्सेस देने के लिए चुना गया जिनके पास ऐसा ऐक्सेस था. इसकी वजहों में, क्रॉस-साइड डेटा लीक होने की बढ़ती हुई संख्या को सीमित करना, पारदर्शिता और जानकारी देने वाला तरीका पक्का करना, लागू करने और ब्यौरा देने वाला आसान तरीका अपनाना, और फ़िंगरप्रिंट की सुविधा के जोखिम को सीमित करना शामिल हैं. हालांकि, यह इन ही वजहों में शामिल है. Topics पाने वाले पब्लिशर और तीसरे पक्ष, खुद यह तय कर सकते हैं कि वे अपनी साइट पर मौजूद पक्षों के साथ किस तरह की जानकारी शेयर करेंगे. अगर तीसरे पक्ष यह जानकारी शेयर करते हैं, तो Chrome उन्हें इस तरह की जानकारी शेयर करने के बारे में उपयोगकर्ताओं के साथ पारदर्शिता बनाए रखने के लिए बढ़ावा देता है. साथ ही, इस तरह की जानकारी को कंट्रोल करने की सुविधा भी देता है. |
| गलत कैटगरी में रखी गई साइटें | साइटों की कैटगरी गलत विषय के हिसाब से लगाई गई है. इस वजह से, विज्ञापनों के लिए टारगेटिंग गलत हो सकती है. | साइटों को, मैन्युअल तौर पर चुनी गई ओवरराइड लिस्ट के ज़रिए अलग-अलग कैटगरी में बांटा जाता है. इनमें सबसे लोकप्रिय साइटें और उपयोगकर्ता के डिवाइस पर मौजूद एमएल मॉडल शामिल होते हैं. Chrome, विषयों की कैटगरी तय करने में योगदान देने वाली साइटों के विकल्पों का आकलन करता रहता है. बिजली, पानी जैसी सुविधाओं में किए गए किसी भी तरह के सुधार, निजता और इसके गलत इस्तेमाल को ध्यान में रखकर किए जाने चाहिए. उदाहरण के लिए, ये कुछ जोखिम हो सकते हैं:
chrome://topics-internals या इस colab के ज़रिए उपलब्ध टूल की मदद से, लोग इन कॉम्पोनेंट की जांच कर सकते हैं. टेस्टिंग के ज़रिए, हम समय के साथ वर्गीकरण में सुधार होने की उम्मीद करते हैं. साथ ही, हम गलत कैटगरी वाली साइटों के उदाहरणों के सुझाव का स्वागत करते हैं. |
| ऐक्सेस की ज़रूरी शर्तें | स्क्रिप्ट या iframe के तौर पर पेज पर मौजूद DOM इकाई के लिए मौजूदा विषयों से जुड़ी ज़रूरी शर्ताें की वजह से, विज्ञापन नेटवर्क में खिलाड़ियों को कुछ अनचाहे व्यवहार दिख सकते हैं. | हमने GitHub के बारे में जानकारी देने वाले टूल में बदलाव को मर्ज कर दिया है. हम एचटीटीपी हेडर में विषयों का इस्तेमाल करना चाहते हैं. |
| विषयों की अलग-अलग कैटगरी, ज़रूरत के मुताबिक नहीं हैं | मौजूदा विषयों की कैटगरी काफ़ी बड़ी है. इसमें ज़्यादा जानकारी देने वाले विषय शामिल नहीं किए गए हैं, जैसे कि क्षेत्रीय विषय. | टेक्सॉनमी में सुधार करने के लिए, हम लगातार कोशिश कर रहे हैं. हमें उम्मीद है कि नेटवर्क की टेस्टिंग और इनपुट के हिसाब से, टेक्सॉनमी इस कैटगरी में बेहतर होगी.
हम ऐसी कैटगरी पर सुझाव/राय देने या शिकायत करने के लिए लगातार काम कर रहे हैं जो नेटवर्क के लिए सबसे ज़्यादा काम की होगी. विषयों की संख्या बढ़ाने या ज़्यादा जानकारी देने वाले विषयों को शामिल करने का आकलन करते समय, कुछ बातों का ध्यान रखा जाता है. इनमें, 1) निजता से जुड़ी समस्याएं शामिल हो सकती हैं (जैसे, ज़्यादा विषयों पर फ़िंगरप्रिंट का जोखिम हो सकता है) और 2) पहले देखे जा चुके विषयों को फिर से पाने की क्षमता (जैसे, ज़्यादा विषयों के साथ, विज्ञापन टेक्नोलॉजी से जुड़ी इन चीज़ों के चुने गए विषय को पहले देखने की संभावना कम है). Google, #2 पर जाकर कोशिश कर रहा है कि उपयोगकर्ताओं को फ़िल्टर करने की मौजूदा ज़रूरी शर्तों को पूरा करते हुए पहले देखे गए विषयों की जानकारी मिल सके. इसका मकसद, कॉल करने वाले लोगों की सुविधा और निजता, दोनों को बढ़ाना है. |
| विषयों की सीमा | हर वेबसाइट के तीन विषयों में, विज्ञापन देने वाले लोगों या कंपनियों के लिए बहुत कम जानकारी उपलब्ध कराते हैं. | नेटवर्क से मिले सुझाव, खास तौर पर, ऑरिजिन ट्रायल से मिले नतीजों की जांच करके, एपीआई को बेहतर बनाने पर असर डालते रहेंगे. यह ध्यान रखना ज़रूरी है कि Topics से मिलता-जुलता अन्य सिग्नल, कॉन्टेक्स्ट के हिसाब से मददगार साबित होता है. इससे, वेबसाइट पर आने वाले लोगों के लिए सही विज्ञापन ढूंढने में मदद मिलती है. इसलिए, विज्ञापन देने वाले के लिए विषयों के अलावा और भी जानकारी उपलब्ध हो सकती है. |
| (दूसरी तिमाही में इसकी रिपोर्ट भी की गई)
उपयोगकर्ता के कंट्रोल और सुरक्षा |
कुछ विषय, संवेदनशील ग्रुप के लिए प्रॉक्सी हो सकते हैं. इसलिए, नेगेटिव नतीजों को रोकने के लिए, लोगों को ज़्यादा कंट्रोल की ज़रूरत होती है. | तीसरी तिमाही का अपडेट:
विषय, उपयोगकर्ता के कंट्रोल और पारदर्शिता बनाए रखने की दिशा में किए जा रहे अहम कदम को दिखाते हैं. उपयोगकर्ता, विषयों से ऑप्ट आउट कर सकते हैं. साथ ही, उन्हें असाइन किए गए विषयों की समीक्षा कर सकते हैं और विषयों को हटा सकते हैं. साथ ही, यह भी समझ सकते हैं कि दिए गए पेज पर उनके विषयों के साथ कौनसी कंपनियां इंटरैक्ट कर रही हैं. इसके अलावा, उपयोगकर्ता अपने विषयों से जुड़े ब्राउज़िंग इतिहास को मिटाकर भी अपने विषयों को मिटा सकते हैं. ये कंट्रोल, फ़िलहाल Chrome ब्राउज़र पर डिवाइस के लेवल पर लागू किए गए हैं. डेवलपर के सुझाए गए कंट्रोल जैसे बेहतर उपयोगकर्ता कंट्रोल के बारे में लगातार होने वाली चर्चा का हम स्वागत करते हैं. हालांकि, हमें यह पक्का करना होगा कि जोड़ी गई नई सुविधाओं को, बताई गई समस्याओं को ध्यान में रखते हुए बेहतर तरीके से तैयार किया गया हो और इनसे छोटे-छोटे बदलाव न हों. |
| एसईओ पर असर | Topics को बेहतर तरीके से दिखाने के लिए, पब्लिशर अपनी वेबसाइट के होस्टनेम में बदलाव करते हैं. इससे एसईओ पर बुरा असर पड़ सकता है. | हम सिर्फ़ Topics के मकसद से, साइटों को अपने होस्टनेम न बदलने पर चेतावनी देते हैं. यह बात सही है कि कोई साइट इस तरीके से, अपने असाइन किए गए विषयों में बदलाव कर सकती है. हालांकि, ऐसा करने से पब्लिशर को मिलने वाले फ़ायदों के बारे में साफ़ तौर पर जानकारी नहीं दी गई है. साथ ही, अगर साइटें, कैटगरी तय करने के मॉडल से "छेड़छाड़" करने की कोशिश करती हैं, तो इससे पूरे नेटवर्क के लिए Topics की अहमियत कम हो जाएगी. विषय के असाइनमेंट भी ठीक नहीं किए जाते. हमें उम्मीद है कि टेस्टिंग और इनपुट की मदद से, कैटगरी बेहतर होती रहेगी. इस जांच के लिए, हम गलत कैटगरी वाली साइटों के सभी उदाहरणों के साथ-साथ सुझाव/राय देने या शिकायत करने का सुझाव देते हैं. |
| धोखाधड़ी और गलत इस्तेमाल | खरीदारी करने वाले पक्ष के लिए, यह पुष्टि करने का तरीका होना चाहिए कि उन्हें जो विषय दिख रहा है वह असल में ब्राउज़र से जनरेट हुआ है या नहीं. | हम विज्ञापन टेक्नोलॉजी के खरीदारों के लिए, प्रोग्रैम्ड तरीके से विज्ञापन की नीलामियों में पास किए गए विषयों की पुष्टि करने के तरीके को बढ़ावा देने के सुझाव की सराहना करते हैं. हम यहां होने वाली चर्चा में शामिल होने के लिए, नेटवर्क को बढ़ावा देते हैं. फ़िलहाल, हम ज़्यादा प्राथमिकता वाले कुछ अन्य सुधारों पर काम कर रहे हैं. हालांकि, हमें लगता है कि आने वाले समय में यह डिज़ाइन और भी बेहतर होगा. |
| धोखाधड़ी और गलत इस्तेमाल | उन पक्षों की सार्वजनिक समीक्षा की अनुमति दें जो Topics डेटा के सही उपयोगकर्ता हैं. यह उसी तरह की सार्वजनिक पोस्ट और समीक्षा के ज़रिए किया जाता है जो पहले-पक्ष के सेट पर लागू होती है. | हम सुझाव की सराहना करते हैं और इस बात से सहमत हैं कि प्राइवसी सैंडबॉक्स के लक्ष्यों को हासिल करने के लिए, सार्वजनिक जवाबदेही एक अहम टूल है. Topics API कॉल स्वाभाविक रूप से सार्वजनिक होते हैं, क्योंकि कोई भी व्यक्ति किसी साइट पर जा सकता है और JavaScript API को किए गए डोमेन के कॉल पर नज़र रख सकता है. इसलिए, लोग और संगठन उस गतिविधि को देख सकते हैं. साथ ही, यह आकलन कर सकते हैं कि कौनसी साइटें Topics का इस्तेमाल कर रही हैं और कैसे. हमारा मानना है कि साइट की "वैधता" का आकलन करने के बजाय, Topics API के काम करने का यह तरीका बेहतर है. |
| पहले पक्ष के सिग्नल पर असर | टॉपिक के सिग्नल काफ़ी अहम हो सकते हैं. इसकी वजह से, पहले पक्ष की दिलचस्पी के हिसाब से मिलने वाले अन्य सिग्नल की वैल्यू कम हो जाती है. | हमारा मानना है कि वेब के लिए, दिलचस्पी के हिसाब से विज्ञापन दिखाना, इस्तेमाल का एक अहम उदाहरण है. साथ ही, Topics को इस्तेमाल के उदाहरण के हिसाब से डिज़ाइन किया गया है. जैसा कि ऊपर बताया गया है, नेटवर्क के अन्य हिस्सेदारों ने इस बात की चिंता जताई है कि Topics, शायद फ़ायदेमंद न हो. इन सभी मामलों में, टेक्सॉनमी में सुधार करने की कोशिश लगातार जारी है. हमें उम्मीद है कि नेटवर्क की अलग-अलग टेस्टिंग और इनपुट के हिसाब से, टेक्सॉनॉमी में सुधार किए जाएंगे. |
फ़्लेज
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
| FLEDGE नीलामी | FLEDGE नीलामी में बिड करने के लिए, Google Ads को भेजे गए डेटा को SSP किस तरह फ़ॉर्मैट कर सकता है. | टेस्टिंग में हिस्सा लेने वाली कंपनियों को, टेस्टिंग प्लान के बारे में दस्तावेज़ पब्लिश करने और जहां ज़रूरी हो वहां साथ मिलकर काम करने के लिए प्रोत्साहित किया जाता है.
हमने संख्यात्मक परीक्षण के लिए अपने दृष्टिकोण को विकसित करने के लिए CMA के साथ काम किया है और CMA को प्रयोग के डिज़ाइन पर नोट पब्लिश करने में मदद करते हैं, ताकि बाज़ार में हिस्सा लेने वाले उन लोगों को ज़्यादा जानकारी दी जा सके जो ट्रायल के साथ जुड़ने और सुझाए गए तरीकों पर टिप्पणी करने का मौका देना चाहते हैं. Ad Manager की टीम ने उन सेलर के लिए दस्तावेज़ पोस्ट किए हैं जो यहां ऐसे पब्लिशर के साथ FLEDGE की टेस्टिंग करना चाहते हैं जो Ad Manager का इस्तेमाल अपने विज्ञापन सर्वर के तौर पर करते हैं. इसके बारे में ज़्यादा तकनीकी जानकारी यहां दी गई है. |
| नेस्ट किए गए फ़ेंस किए गए फ़्रेम में FLEDGE | फ़ेंस किए गए फ़्रेम, कम पाबंदी वाले फ़्रेम की जांच करते हैं, जबकि आने वाले समय में ज़्यादा समय के लिए पाबंदी लगाते हैं. यह अज्ञात टाइमलाइन, नेटवर्क के लिए एक चुनौती पेश करती है. | फ़िलहाल, कंपनियां फ़ेंस किए गए फ़्रेम के साथ FLEDGE को टेस्ट कर सकती हैं. शामिल होने का आसान विकल्प देने के लिए, कंपनियां पहले FLEDGE को लागू कर सकती हैं. FLEDGE का इस्तेमाल करने के बाद, वे FLEDGE डिज़ाइन के साथ फ़ेंस किए गए फ़्रेम को टेस्ट कर सकते हैं. |
| डेटा के रखरखाव से जुड़ी नीति | इंटरेस्ट ग्रुप / FLEDGE के लिए डेटा मैनेज करने की नीति क्या है? | FLEDGE डिज़ाइन में, इंटरेस्ट ग्रुप में सेव किया गया सारा डेटा या लोगों की दिलचस्पी वाले ग्रुप में सेव किया गया सारा डेटा, डिवाइस पर ही रहता है. इसमें से कोई भी डेटा Google सर्वर पर नहीं भेजा जाता.
Chrome, FLEDGE के लिए कुछ निजता सुरक्षा सुविधाएं खरीदने की योजना बना रहा है. इनमें, Google के चलाए गए k-ऐनिमिटी सर्वर के साथ इंटरैक्शन शामिल है. इस इंटरैक्शन को सोच-समझकर डिज़ाइन किया जा रहा है, ताकि उपयोगकर्ताओं के बारे में जानकारी शेयर न की जा सके. साथ ही, इसे भरोसेमंद एक्ज़ीक्यूशन एनवायरमेंट (टीईई) पर चलाया जा सके. इससे यह पक्का किया जाता है कि सभी विज्ञापन नेटवर्क में एक जैसी जानकारी हो. \ Google, प्राइवसी सैंडबॉक्स के प्रपोज़ल को इस तरह डिज़ाइन और लागू करने के लिए प्रतिबद्ध है कि वह Google के कारोबार को खुद प्राथमिकता देकर प्रतिस्पर्धा न करे. साथ ही, डिजिटल विज्ञापन के साथ-साथ पब्लिशर और विज्ञापन देने वालों पर पड़ने वाले असर को भी ध्यान में रखे. हम यह पक्का करने के लिए सीएमए के साथ मिलकर काम करते रहते हैं कि हमारा काम इन प्रतिबद्धताओं का पालन करे. |
| उम्र से जुड़ी नीतियां | Chrome यह कैसे पक्का करता है कि FLEDGE की बनाई गई ऑडियंस, उम्र से जुड़ी पाबंदियों के मुताबिक हैं? | पब्लिशर और विज्ञापन देने वाले, यह आकलन कर सकते हैं कि FLEDGE का इस्तेमाल करके बनाई गई ऑडियंस, लागू कानून का पालन करती है या नहीं. उपयोगकर्ताओं को ज़्यादा सुरक्षित रखने के लिए, Chrome में साइन इन करने वाले किसी भी उपयोगकर्ता के लिए, प्राइवसी सैंडबॉक्स एपीआई चालू नहीं होगा. ऐसा, जांच के दौरान भी 18 साल से कम उम्र के उपयोगकर्ताओं के लिए किया जाएगा. साइन आउट कर चुके उपयोगकर्ताओं के लिए, Chrome प्रोफ़ाइल सिग्नल इकट्ठा नहीं करता. इससे ब्राउज़र, उपयोगकर्ता की उम्र का पता लगा पाता है. |
| FLEDGE कुंजी/वैल्यू सेवाएं | इससे साफ़ तौर पर पता चलता है कि FLEDGE कुंजी/वैल्यू सेवा, किस तरह की कुंजियों की अनुमति देगी. जैसे, कुंजियों की संख्या और उन्हें कितनी बार अपडेट किया जा सकता है. | FLEDGE का इस्तेमाल करने वाली कंपनियों के पास, रैम में फ़िट होने के लिए ज़्यादा से ज़्यादा कुंजियां हो सकती हैं. ज़्यादा जानकारी के लिए, कृपया यहां पर जानकारी देखें.
हम डेटा में बदलाव करने की प्रोसेस को तेज़ करने और किसी भी ज़रूरी शर्त के लिए मिलने वाले सुझावों को बेहतर बनाने की कोशिश कर रहे हैं. |
| टेस्ट करना | Google Ads के साथ FLEDGE को टेस्ट करना मुश्किल है | ऑरिजिन ट्रायल में बेहतर तरीके से हिस्सा लेने और टेस्ट करने का तरीका जानने के लिए, Google Ads के शामिल होने से जुड़ा दस्तावेज़ देखें. |
| बिडिंग और नीलामी सेवाओं का एपीआई | बिडिंग और नीलामी सेवाओं के एपीआई के लिए Google का निर्देश क्या है? क्या इसे डिवाइस की नीलामियों में Chrome ब्राउज़र FLEDGE से ऊपर या नीचे प्राथमिकता दी जाएगी? | हम मौजूदा FLEDGE ऑन-डिवाइस बिडिंग डिज़ाइन के लिए प्रतिबद्ध हैं. बिडिंग और नीलामी सेवाओं का सुझाव, इस्तेमाल के ऐसे सबसेट की मदद के लिए संभावित समाधान खोजने का है जहां डिवाइस की कंप्यूटेशनल पावर या नेटवर्क स्पीड सीमित हो सकती है. |
| एग्रीगेट रिपोर्टिंग | जनरेट करने के लिए उपलब्ध सभी सिग्नल के आधार पर, एग्रीगेट रिपोर्ट को सपोर्ट करने का अनुरोध. | हम इस बारे में ज़्यादा जानकारी सार्वजनिक तौर पर जल्द ही शेयर करेंगे. |
| काम के विज्ञापन | FLEDGE की मदद से काम के विज्ञापन दिखाना. | हमने इस विकल्प पर विचार किया है. इसकी वजहें चर्चा में बताई गई हैं. इसलिए, फ़िलहाल हमारा सुझाव है कि आप काम के विज्ञापनों के लिए, FLEDGE का इस्तेमाल न करें. |
| असल दुनिया में टेस्टिंग | इस बारे में दिशा-निर्देश कि असल दुनिया में जांच के लिए, FLEDGE को तीसरे पक्ष की कुकी से कैसे अलग किया जाए. | हम ऐसे तरीकों की जांच कर रहे हैं जिनसे टेस्ट किए गए लोगों की संख्या पता की जा सके.
हमने संख्यात्मक परीक्षण के लिए अपने दृष्टिकोण को विकसित करने के लिए CMA के साथ काम किया है और हम प्रयोग के डिज़ाइन पर नोट प्रकाशित करने में CMA की सहायता करते हैं, ताकि बाज़ार में हिस्सा लेने वालों को ज़्यादा जानकारी दी जा सके और सुझाए गए तरीकों पर टिप्पणी करने का अवसर दिया जा सके. |
| FLEDGE और Attribution Reporting API की टेस्टिंग | FLEDGE के साथ Attribution Reporting API को लागू करने का सबसे अच्छा तरीका क्या है? क्या FLEDGE और एट्रिब्यूशन को अलग करना या साथ मिलकर टेस्ट करना सही है? | आने वाले समय में, हम एक ही प्लैटफ़ॉर्म पर FLEDGE और Attribution Reporting API की टेस्टिंग को सपोर्ट करेंगे. हालांकि, हमारी सलाह है कि हम पहले, एट्रिब्यूशन रिपोर्टिंग एपीआई को अलग से टेस्ट करें. इसके बाद, इंटिग्रेशन पूरा होने के बाद, FLEDGE की मदद लें. |
| बिड की कीमत किसको दिखे | बोली की कीमतों को अस्पष्ट बनाने का अनुरोध. | DevTools से बिड वैल्यू को ऐक्सेस करने के लिए, `generatebid()` या `scoreAd()` में ब्रेकपॉइंट सेट किए जा सकते हैं. Chrome टीम ने FLEDGE पर की गई इस राय में इकट्ठा किए गए नैरो अटैक वेक्टर को ध्यान में रखा है. हालांकि, Chrome के सुरक्षा और निजता मॉडल यह मानते हैं कि उपयोगकर्ता अपने डिवाइस पर मौजूद जानकारी के साथ जो चाहें वह करते हैं. इसलिए, अनुरोध के मुताबिक बिड डेटा को छिपाने का कोई संभव तरीका नहीं है. |
| दस्तावेज़ के अनुरोध | लाइव नेटवर्क में जांच करने से जुड़े दस्तावेज़ और उदाहरण. | हम इस बात की सराहना करते हैं कि डेवलपर को हमारा मौजूदा कॉन्टेंट मददगार लगा. हम आने वाले हफ़्तों और महीनों में ज़्यादा से ज़्यादा कॉन्टेंट उपलब्ध कराने के लिए प्रतिबद्ध हैं, ताकि डेवलपर को लगातार यह समझने में मदद मिले कि नई टेक्नोलॉजी उनके लिए किस तरह काम कर सकती है.
हमने प्रॉडक्ट और इंजीनियरिंग लीड के साथ सवाल-जवाब के सेशन शेयर करने के साथ-साथ, सबसे सही तरीके और डेमो शेयर करने के लिए, सार्वजनिक तौर पर बाहरी डेवलपर को ऑफ़िस में कामकाज के घंटे के दौरान आयोजित किया है. इसका मकसद, लाइव चर्चा/सवालों का जवाब देना है. |
| निजी एग्रीगेशन एपीआई | क्या आपको Private एग्रीगेशन API के बारे में ज़्यादा जानकारी चाहिए? | सार्वजनिक तौर पर जानकारी देने वाला टूल, इस समय शेयर की जा सकने वाली नई जानकारी के साथ उपलब्ध है. इस एपीआई के डेवलप होने और इस्तेमाल के उदाहरण तय किए जाने पर, ज़्यादा दस्तावेज़ दिए जाएंगे. |
| डेटा के इंतज़ार का समय | क्या FLEDGE की/वैल्यू सर्वर डेटा वापस पाया जा सकेगा? | क्वेरी के लिए सर्वर की ओर से अपडेट किया गया डेटा दिखाने से पहले, अपडेट किए गए डेटा को दिखाने से पहले, मिनट के हिसाब से थोड़ी पुरानी जानकारी दिखना, जिसकी जानकारी घंटों में नहीं होती. इसके बारे में GitHub की खुली हुई समस्या में जानकारी दी गई है. हम डेवलपर के सुझाव भी चाहते हैं. |
| बिडिंग और नीलामी से जुड़ी सेवाएं | क्या बिडिंग और नीलामी (B&A) सेवाओं का इस्तेमाल करने पर, बिड की कीमतें उपयोगकर्ता को नहीं दिखेंगी? | B&A सर्वर साइड के मामले में, उपयोगकर्ता को व्यक्तिगत बिड की कीमत नहीं दिखती, क्योंकि बिड रिक्वेस्ट SSP नीलामी सेवा से सीधे DSP नीलामी सेवा को दी जाती है और इसलिए यह ब्राउज़र में अब उपलब्ध नहीं है.
हालांकि, जीतने वाली बिड की कीमत अब भी ब्राउज़र पर दिखेगी. बिड की कीमतों को अस्पष्ट बनाने के अनुरोधों के बारे में, ऊपर ज़्यादा जानकारी के साथ चर्चा की गई है. |
| बिडिंग और नीलामी से जुड़ी सेवाएं | बैलेंस बिडिंग और नीलामी सेवाओं को कैसे लोड किया जा सकता है? | फ़िलहाल, हमारे पास लोड बैलेंस करने के लिए कोई दिशा-निर्देश नहीं है. हालांकि, परफ़ॉर्मेंस और निजता, दोनों के हिसाब से यह एक अहम समस्या है. आने वाले समय में, हम इस बारे में ज़्यादा जानकारी देंगे. |
| FLEDGE की सीमाएं | जुड़ाव AdInterestGroup की अवधि की सीमा को 30 दिन से बढ़ाकर 90 दिन करने का अनुरोध करें. | हमें लगता है कि 30 दिन तक डेटा के रखरखाव की समयसीमा, Privacy Sandbox के अन्य विज्ञापन एपीआई के मुताबिक है. जैसे, एट्रिब्यूशन रिपोर्टिंग में 30 दिनों की सीमा और Topics में 3 हफ़्ते की लुक. यह समयसीमा, विज्ञापन टेक्नोलॉजी से जुड़ी ज़रूरतों और उपयोगकर्ताओं की निजता से जुड़ी ज़रूरतों को पूरा करती है.
हालांकि, हम इस समस्या पर यहां चर्चा कर रहे हैं और इस बारे में हम आपको और सुझाव या राय दे सकते हैं. |
| FLEDGE में शेयर किया गया स्टोरेज | क्या FLEDGE में Shared Storage API इस्तेमाल किया जा सकता है? | हम आने वाले समय में, FLEDGE में Shared Storage API की सुविधा उपलब्ध कराना चाहते हैं. साथ ही, आने वाले ऑरिजिन ट्रायल में इसे उपलब्ध कराने पर काम कर रहे हैं. |
| क्लिक के आधार पर फ़्रीक्वेंसी कंट्रोल | क्या FLEDGE में, क्लिक (जीत नहीं) के हिसाब से फ़्रीक्वेंसी कैपिंग की जा सकती है? | FLEDGE यह तय करता है कि फ़ेंस किए गए फ़्रेम की मदद से, navgator.leaveAdInterestGroup() (बिना पैरामीटर के) को कॉल किया जा सकता है. इससे उस इंटरेस्ट ग्रुप को छोड़ा जा सकता है जिसकी वजह से विज्ञापन दिखाया गया था. यह कॉल, फ़्रीक्वेंसी कैपिंग के तौर पर, आने वाले समय में बिडिंग को रोकने के लिए, क्लिक मिलने पर पहली बार किया जा सकता है. फ़िलहाल, यह तरीका एक से ज़्यादा क्लिक के बाद कैपिंग के लिए काम नहीं करेगा. |
| नेस्ट किए गए फ़ेंस किए गए फ़्रेम में FLEDGE. | फ़ेंस किए गए फ़्रेम वाले विज्ञापनों की रिपोर्टिंग से, ऐसे क्लिक की रिपोर्ट नहीं की जा सकती जो नेस्ट किए गए फ़ेंस किए गए फ़्रेम पर होते हैं. | हमने इस समस्या को ठीक करने के लिए यहां एक प्रस्ताव पब्लिश किया है. |
| मापें | FLEDGE नीलामी में बिड करने वाले लोगों के लिए, इंतज़ार के समय से जुड़ा डेटा इकट्ठा करने के तरीके के बारे में दिशा-निर्देश की ज़रूरत है. | हम परफ़ॉर्मेंस मेज़रमेंट का दस्तावेज़ जल्द ही पब्लिश करने पर काम कर रहे हैं. |
| रिपोर्टिंग | FLEDGE रिपोर्टिंग को कैसे मैनेज किया जाएगा? | जीत, नीलामी के नतीजे, इवेंट जैसे क्लिक पर FLEDGE की रिपोर्टिंग, रिपोर्ट रिज़ल्ट() जैसे FLEDGE एपीआई के ज़रिए उपलब्ध होगी. विज्ञापन कन्वर्ज़न के साथ रिपोर्टिंग करने पर, Attribution Reporting API के साथ इंटिग्रेशन, FLEDGE से अलग होगा. हालांकि, नेटवर्क को लेकर इन तरीकों को लेकर बातचीत जारी है.
निजी एग्रीगेशन एपीआई का इस्तेमाल, काम करने की अलग-अलग जगहों पर नीलामी के नतीजों की रिपोर्ट करने के लिए भी किया जा सकता है. जानकारी देने वाला दस्तावेज़ यहां देखें. |
| एक जैसी दिलचस्पी वाले ग्रुप का साइज़ | क्या विज्ञापन टेक्नोलॉजी के लिए, इंटरेस्ट ग्रुप के साइज़ (ग्रुप में उपयोगकर्ताओं की संख्या) की जांच करने का कोई तरीका है? | दिलचस्पी वाले ग्रुप की सदस्यता को ब्राउज़र, उपयोगकर्ता के डिवाइस पर सेव करता है. इसे ब्राउज़र के वेंडर या किसी और के साथ शेयर नहीं किया जाता.
हालांकि, एक इंटरेस्ट ग्रुप का मालिक सैद्धांतिक तौर पर, navgator.joininterestgroup(...) पर किए जाने वाले हर कॉल को ट्रैक कर सकता है. इस कॉल को ट्रैक करने से, IG के सटीक साइज़ की गारंटी नहीं मिलती (क्योंकि उपयोगकर्ता किसी भी समय ग्रुप छोड़ सकते हैं), लेकिन इससे मालिक को ज़्यादा जानकारी मिलती है. साथ ही, यह अंदाज़ा भी लग जाता है कि साइज़ कितना हो सकता है. |
| परफ़ॉर्मेंस | क्या हर नीलामी में बिडिंग करने वाला JS/WebAssembly कोड इकट्ठा किया जाता है? | हर नीलामी के दौरान, बिडिंग JS/WebAssembly कोड को एक बार कंपाइल किया जाता है. |
| परफ़ॉर्मेंस | बिडिंग DurationMsec का स्कोप क्या है? | Bidding DurationMsec में कंपाइलिंग स्क्रिप्ट का समय शामिल होता है. इसमें डाउनलोड का समय, Wasm कंपाइलेशन समय, नेटवर्क का समय, मुख्य वैल्यू सर्वर से या JS कंपाइल करने से पहले मौजूद किसी भी चीज़ से डेटा फ़ेच करने में लगने वाला समय शामिल नहीं होता. |
| पसंद के मुताबिक बनाएं | क्या विज्ञापन कॉम्पोनेंट को अपडेट किया जा सकता है, ताकि इसे उपयोगकर्ता के हिसाब से बनाया जा सके? | विज्ञापन कॉम्पोनेंट को तब अपडेट किया जा सकता है, जब पसंद के ग्रुप को कॉल करने वाले (कॉलर) से अपडेट किया जाता है. ऐसा तब होता है जब कॉल करने वाला इंटरेस्ट ग्रुप को कॉल करता है. इसके अलावा, जब Chrome DailyUpdateURL को कॉल करता है, तो adcomponents को अपडेट किया जा सकता है. इसकी मदद से, कॉलर, मौजूदा साइट से उपयोगकर्ता की जानकारी के आधार पर या के-अनाम जानकारी के आधार पर विज्ञापन कॉम्पोनेंट को अपडेट कर सकता है. प्रॉडक्ट-लेवल पर टर्टलडोव का मूल प्रस्ताव यहां देखा जा सकता है. इसमें आरटीबी हाउस की ओर से सुझाव के इस्तेमाल के उदाहरण के लिए कोर मेट्रिक पर असर के बारे में कुछ विश्लेषण शामिल हैं. |
| एक जैसी दिलचस्पी वाला ग्रुप | क्या इंटरेस्ट ग्रुप के मालिक, कुछ उपयोगकर्ताओं को शर्तों के साथ हटा सकते हैं? | एक जैसी दिलचस्पी वाले ग्रुप की सदस्यता को सिर्फ़ उपयोगकर्ता के ब्राउज़र पर सेव किया जाता है. इसे सिर्फ़ उपयोगकर्ता (उदाहरण के लिए, साइट का डेटा मिटाकर) हटाया जा सकता है.
हालांकि, अगर उपयोगकर्ता किसी ऐसे पेज पर वापस आता है जो इंटरेस्ट ग्रुप के मालिक के कंट्रोल में है, तो इंटरेस्ट ग्रुप के मालिक के लिए navgator.leaveAdInterestGroup() (इसके साथ कुछ शर्तों के साथ) को कॉल करना संभव है. |
| परफ़ॉर्मेंस | जनरेट करने वाली बिड की परफ़ॉर्मेंस को कैसे मेज़र करें? | कंपाइल करने और एक्ज़ीक्यूट करने के समय को बिडिंग की अवधि Msec से मापा जा सकता है. डाउनलोड के समय को chrome://net-export से मापा जा सकता है. Chrome के हाल ही के वर्शन में, डेटा को कंपाइल और एक्ज़ीक्यूट करने में लगा समय, DevTools के परफ़ॉर्मेंस टैब में दिखेगा. |
| इंटरेस्ट ग्रुप के अपडेट की फ़्रीक्वेंसी | ब्राउज़र से इंटरेस्ट ग्रुप अपडेट होने की फ़्रीक्वेंसी क्या होगी? | जिन इंटरेस्ट ग्रुप को पिछले 24 घंटों में अपडेट नहीं किया गया है, Chrome उन्हें navgator.updateAdInterestGroups() को कॉल करने या किसी नीलामी में हिस्सा लेने का मौका मिलने पर अपडेट करने की कोशिश करता है. ज़्यादा जानकारी के लिए, यहां जाएं. |
| एग्रीगेशन की सेवा देने वाली कंपनियां | एग्रीगेशन सेवा पर दूसरी क्लाउड सेवाएं कब काम करेंगी? | फ़िलहाल, हमारे पास किसी खास समय के लिए कोई अपडेट नहीं है. हालांकि, एक बार और अपडेट करने पर हम आपको जानकारी देंगे. फ़िलहाल, सिर्फ़ AWS, एग्रीगेशन सेवा की सुरक्षा से जुड़ी ज़रूरी शर्तों को पूरा करती है. |
| FLEDGE की टेस्टिंग टाइमलाइन | BYOS में FLEDGE की टेस्टिंग कब तक की जाएगी? क्या BYOS मॉडल से TEE-आधारित मॉडल पर स्विच करने के लिए, काफ़ी समय उपलब्ध होगा? | यह पक्का करने के लिए कि नेटवर्क के पास जांच करने के लिए काफ़ी समय हो, हम तीसरे पक्ष की कुकी के बंद होने के कुछ समय बाद तक, TEE का इस्तेमाल करने की ज़रूरत नहीं रखते. इस बदलाव के लागू होने से पहले, हम डेवलपर को इसकी टेस्टिंग और इस्तेमाल शुरू करने के लिए ज़रूरी सूचना देंगे. फ़िलहाल, हमारे पास कोई और अपडेट नहीं है. हालांकि, अपडेट मिलते ही हम आपको और जानकारी देंगे. कृपया नई जानकारी यहां पाएं. |
| डेटा आकार की सीमा | बिडिंग फ़ंक्शन में, Wasm के लिए डेटा साइज़ की सीमा क्या है. | एक ज़रूरी शर्त यह है कि इंटरेस्ट ग्रुप के अपडेट की वजह से, कोई ऐसा इंटरेस्ट ग्रुप न हो जो 50 केबी से ज़्यादा का हो, जैसा कि यहां बताया गया है. हालांकि, Wasm के लिए डेटा साइज़ की सीमा अभी तक तय नहीं की गई है. इसलिए, हम चाहते हैं कि आप इस विषय पर राय दें. |
| नीलामी के सिग्नल | क्या नीलामीसिग्नल के लिए एक स्टैंडर्ड डेटा स्ट्रक्चर मौजूद होगा? | इसके बारे में अभी तक तय नहीं किया गया है. हालांकि, हम इसके बारे में सुझाव, शिकायत या राय दे सकते हैं. |
| विज्ञापन टेक्नोलॉजी सर्वर की क्वेरी करना | क्या विज्ञापन टेक्नोलॉजी सर्वर के डेटा से रीयल टाइम में, K/V सर्वर से क्वेरी की जा सकती है? | नहीं, K/V सर्वर एक ट्रस्ट मॉडल में चलता है, जो उपयोगकर्ता का डेटा लीक होने से बचाने के लिए "कोई नेटवर्क, डिस्क ऐक्सेस, टाइमर या लॉगिंग नहीं" लागू करता है. ज़्यादा जानकारी के लिए, कृपया ट्रस्ट मॉडल के बारे में जानकारी देने वाली जानकारी यहां देखें. |
| विज्ञापन कॉम्पोनेंट को अपडेट करने की फ़्रीक्वेंसी | फ़िलहाल, उपयोगकर्ता के ब्राउज़िंग इतिहास के हिसाब से, adcomponents फ़ील्ड (फ़िलहाल, सिर्फ़ IG सेटिंग में) को अपडेट नहीं किया जा सकता | प्राइवसी सैंडबॉक्स का लक्ष्य, क्रॉस-साइट ट्रैकिंग के बिना, वेब नेटवर्क की ज़रूरतों को पूरा करना है. इसका मतलब है कि ब्राउज़िंग इतिहास के ऐक्सेस को रोका जा सकता है. हमारा सुझाव है कि आप 'विषय' जैसे विकल्पों का इस्तेमाल करें. |
| नीलामी के नतीजे | क्या विज्ञापन टेक्नोलॉजी के लिए, नीलामी जीतने की दरों के बारे में जानने का कोई तरीका है? | नीलामी के नतीजे को, विक्रेता और जीतने वाले खरीदार से मिले नीलामी कोड में, Reportनतीजे() और रिपोर्टWin() फ़ंक्शन को कॉल करके रिपोर्ट किया जाता है. इसलिए, हर एक के पास नीलामी के नतीजे को लॉग करने और रिपोर्ट करने का मौका होता है. |
| (दूसरी तिमाही में इसकी रिपोर्ट भी की गई)
नेगेटिव इंटरेस्ट ग्रुप के हिसाब से टारगेटिंग के लिए सहायता |
नेगेटिव इंटरेस्ट ग्रुप टारगेटिंग के साथ काम करने वाला एपीआई: विज्ञापनों को सिर्फ़ तब दिखाना, जब कोई उपयोगकर्ता किसी इंटरेस्ट ग्रुप से जुड़ा न हो. | तीसरी तिमाही का अपडेट:
हमने एक नया प्रस्ताव शेयर किया है और हम सुझाव चाहते हैं. |
डिजिटल विज्ञापनों का आकलन करना
एट्रिब्यूशन रिपोर्टिंग (और दूसरे एपीआई)
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
| ओटी से जुड़ी ज़रूरी शर्तें | सिर्फ़ ओटी के लिए / के दौरान अनुमति-नीति से जुड़ी पाबंदियां हटाएं. | कृपया टेस्टिंग के दौरान अनुमतियों से जुड़ी नीति में हमारे एलान किए गए बदलाव देखें. इस बदलाव से, हिस्सेदार की मुख्य चिंता का पता चला है. इसकी वजह से, डीएसपी को ज़्यादा संख्या में क्रॉस-ऑरिजिन iframe पर एपीआई की जांच करने की अनुमति मिल रही है. दरअसल, डीएसपी को पब्लिशर/एसएसपी के साथ मिलकर काम करना पड़ता था, ताकि यह पक्का किया जा सके कि क्रॉस-ऑरिजिन iframe पर एपीआई की जांच करने के लिए, अनुमति की सही नीति सेट की गई है. हालांकि, इस बदलाव के बाद डीएसपी, डिफ़ॉल्ट रूप से एपीआई को कॉल कर पाएंगे. साथ ही, ऑरिजिन ट्रायल के दौरान ज़रूरत पड़ने पर, SSP/पब्लिशर इस एपीआई को बंद कर सकते हैं. |
| आवाज़ | सुझाव दें कि गै़र-ज़रूरी डेटा का लेवल बहुत ज़्यादा है और इसकी वजह से रिपोर्टिंग की अहमियत पर असर पड़ रहा है. | हम शोर के बारे में सुझाव/राय देने या शिकायत करने का स्वागत करते हैं. हम इसका इस्तेमाल करके, शोर से जुड़े कुछ पैरामीटर सेट करने का तरीका तय करेंगे. हम जांच करने वाले लोगों की मदद करने के लिए, ज़्यादा संसाधन, टूल, और अन्य दस्तावेज़ भी पब्लिश करना चाहते हैं. |
| क्रॉस-डोमेन कन्वर्ज़न | क्रॉस-डोमेन वाले कन्वर्ज़न, जैसे कि दो या उससे ज़्यादा डेस्टिनेशन वाले कन्वर्ज़न को कैसे ट्रैक करें? | फ़िलहाल, हम इस सवाल पर बात कर रहे हैं और सुझाव मांग रहे हैं. |
| डीबग करने की ज़रूरी शर्तें | क्या आपको खास जानकारी वाली रिपोर्ट को डिप्लॉय / टेस्ट करते समय, निजता से जुड़े बाकी बजट को देखने की अनुमति देने का अनुरोध करना है? | सुविधा के अनुरोध को यहां ट्रैक किया जा सकता है. |
| एपीआई के इस्तेमाल से जुड़ी नीतियां | फ़िंगरप्रिंट की सुविधा जैसी चीज़ों से जुड़ी पाबंदियों के आधार पर, फ़ीडबैक में नीतियों के सुझाव दिए जाते हैं. ये सुझाव इस बात के लिए दिए जाते हैं कि एपीआई का इस्तेमाल कौन कर सकता है | यह एक बहुत ही दिलचस्प विचार है और हमें ब्राउज़र की सेवा देने वाली दूसरी कंपनियों और पूरे वेब नेटवर्क, दोनों के साथ काम करने में खुशी होगी. |
| कन्वर्ज़न रिपोर्ट में समयसीमा खत्म होने की सेटिंग | रिपोर्ट फ़िल्टर / समयसीमा खत्म होने की तारीख 24 घंटे से कम समय में इस्तेमाल करने की सुविधा देने का अनुरोध करें. | घंटे के हिसाब से डेटा खत्म होने की सुविधा, निजता के लिए चिंता का विषय होती है. इससे विज्ञापन टेक्नोलॉजी को यह पता चल जाता है कि उपयोगकर्ता, विज्ञापन देने वाली कंपनी की साइट पर कितने घंटे में आता है. दिन के लेवल की समयसीमा खत्म होने की वजह से, विज्ञापन टेक्नोलॉजी अमान्य इंप्रेशन को फ़िल्टर कर सकती है. इसके लिए, यह तय नहीं किया जा सकता कि उपयोगकर्ता ने साइट पर किस समय विज़िट किया. |
| ओटी टोकन के खत्म होने की तारीख | ऑपरेशनल ओवरहेड को कम करने के लिए मौजूदा ओटी टोकन की वैधता बढ़ाने का अनुरोध करें. | हमारा मानना है कि टोकन रिन्यू करना ज़रूरी है. साथ ही, हम डेवलपर के लिए इसे आसान बनाने और ज़्यादा सूचना देने के लिए काम कर रहे हैं. |
| क्षेत्रीय सहायता | फ़िलहाल, एग्रीगेशन सेवा सभी इलाकों में काम नहीं करती. | फ़िलहाल, यह बीटा वर्शन पर लागू है. उम्मीद है कि जैसे-जैसे टेस्टिंग आगे होगी, हम अन्य इलाकों में भी इसे शामिल करेंगे. हालांकि, अभी तक इसकी समयावधि के बारे में साफ़ तौर पर नहीं बताया गया है. |
| इवेंट लेवल की रिपोर्टिंग में देरी | इस्तेमाल के कुछ मामलों के लिए, इवेंट लेवल की रिपोर्टिंग में 2 से 30 दिन ज़्यादा लग सकते हैं. | हमने यहां एक प्रस्ताव शेयर किया है, जिसमें विज्ञापन टेक्नोलॉजी को यह कंट्रोल करने की अनुमति दी जाएगी कि इवेंट लेवल की रिपोर्ट कब भेजी जाएं. डिफ़ॉल्ट अवधि 30 दिन है, लेकिन इसे इससे कम समय के लिए सेट किया जा सकता है. |
| (दूसरी तिमाही में इसकी रिपोर्ट भी की गई)
मल्टी-टच एट्रिब्यूशन |
क्रॉस डिवाइस या क्रॉस ऐप्लिकेशन जैसे मल्टी-टच एट्रिब्यूशन को अनुमति दें. | तीसरी तिमाही का अपडेट:
मल्टी-टच एट्रिब्यूशन के मौजूदा तरीकों के लिए, अलग-अलग वेबसाइटों पर उपयोगकर्ता के इंप्रेशन (इस वजह से, उनकी पहचान) को सीमित तौर पर एक साथ जोड़ना ज़रूरी है. इसलिए, मौजूदा फ़ॉर्म में यह सुविधा प्राइवसी सैंडबॉक्स के लक्ष्यों से मेल नहीं खाती. सैंडबॉक्स का मकसद, क्रॉस-साइट ट्रैकिंग के बिना, विज्ञापनों के इस्तेमाल के उदाहरणों को बेहतर बनाने में मदद करना है. |
| FLEDGE और एट्रिब्यूशन रिपोर्टिंग इंटिग्रेशन की टाइमलाइन | FLEDGE और एट्रिब्यूशन रिपोर्टिंग एपीआई के इंटिग्रेशन की टाइमलाइन क्या है? | फ़िलहाल, हमारे पास शेयर करने के लिए कोई अपडेट नहीं है. हालांकि, तय समयावधि में जानकारी मिलने के बाद हम सार्वजनिक तौर पर ज़्यादा जानकारी उपलब्ध कराएंगे. |
| एक से ज़्यादा ट्रिगर टाइप | ट्रिगर के रजिस्ट्रेशन में ज़्यादा सुविधा पाने के लिए अनुरोध करें. | हमने एग्रीगेट एपीआई के लिए, डुप्लीकेट कॉपी हटाने का एक सिस्टम सुझाया है. इससे, विज्ञापन टेक्नोलॉजी को बेहतर तरीके से इवेंट-लेवल और एग्रीगेट की जा सकने वाली रिपोर्ट को कंट्रोल करने में मदद मिलेगी. |
| मापें | इन्वेंट्री अच्छा परफ़ॉर्म कर रही है या नहीं, इससे जुड़ा मेज़रमेंट डेटा पाने का अनुरोध करें. | हम आपके सुझाव, शिकायत या राय की सराहना करते हैं. साथ ही, हम इस अनुरोध के इस्तेमाल के उदाहरणों के बारे में ज़्यादा जानकारी चाहते हैं. |
| कन्वर्ज़न की समयसीमा खत्म होने की तारीख | सिर्फ़ सोर्स टैग के बजाय, ट्रिगर टैग पर कन्वर्ज़न की समयसीमा सेट करने का अनुरोध करें. | हम आपके सुझाव, शिकायत या राय की सराहना करते हैं. साथ ही, हम इस अनुरोध के इस्तेमाल के उदाहरणों के बारे में ज़्यादा जानकारी चाहते हैं. |
| बैच रिपोर्टिंग | बैच रिपोर्टिंग में अतिरिक्त मेज़रमेंट का अनुरोध करें. | हम एग्रीगेशन सेवा पर होने वाले असर के बारे में सोचते रहने के लिए, इस सुझाव, शिकायत या राय की सराहना करते हैं. हम जानना चाहते हैं कि विज्ञापन टेक्नोलॉजी, एक साथ कई रिपोर्ट भेजने और उनकी उम्मीद की फ़्रीक्वेंसी के बारे में किस तरह सोच रही है. साथ ही, हम इस बारे में भी जानना चाहते हैं कि साल भर में बैच बनाने की रणनीति किस तरह बदलती है. |
| Epsilon | एप्सिलॉन की वैल्यू कब तय की जाएगी? | हम एपिसोड की वैल्यू को तय करने और GA में इसे लागू करने के तरीके को पूरा करने के लिए, नेटवर्क की जांच करने वाले लोगों के साथ लगातार काम कर रहे हैं. वैल्यू सार्वजनिक रूप से दिखेगी. साथ ही, उस चर्चा के साथ-साथ वैल्यू के बारे में फ़ैसला लिया जाएगा. अगर आपका कोई सुझाव/शिकायत/राय है, तो कृपया उसे इस जीएच समस्या में पोस्ट करें. |
कवर ट्रैकिंग को सीमित करें
उपयोगकर्ता एजेंट को कम करने की प्रोसेस
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
| डिप्लॉयमेंट डिपेंडेंसी | स्ट्रक्चर्ड यूज़र एजेंट (एसयूए) डिप्लॉयमेंट डिपेंडेंसी को ठीक करना. | हमने Chrome के 101 और उसके बाद के वर्शन का इस्तेमाल करने वाले सभी उपयोगकर्ताओं के लिए, "चौथा फ़ेज़" यानी माइनर वर्शन को रोल आउट कर दिया है. इसे माइनर वर्शन कहते हैं. अपडेट यहां देखें. |
| टेस्ट करना | उपयोगकर्ता-एजेंट रिडक्शन ऑरिजिन ट्रायल की अवधि बढ़ाने का अनुरोध, Meta से करना. | हमने ऑरिजिन ट्रायल की सुविधा की अवधि बढ़ाई और बड़ी साइटों के लिए ट्रैफ़िक की सीमा हटाने के लिए अनुमति मिल गई. ट्रैफ़िक की आरामदेह सीमा हर साइट पर लागू होती है, फिर चाहे वह बड़ी हो या छोटी. |
उपयोगकर्ता एजेंट क्लाइंट हिंट
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
| (दूसरी तिमाही में इसकी रिपोर्ट भी की गई)
धोखाधड़ी-विरोधी / गलत इस्तेमाल-विरोधी समस्याएं |
UA-CH के ज़रिए मिलने वाली कुछ सुविधाएं: क्लिक रीडायरेक्ट ट्रैकर और धोखाधड़ी वाले क्लिक. | तीसरी तिमाही का अपडेट:
हमें उन कंपनियों से अच्छे सुझाव मिले हैं जिनमें कहा गया है कि उन्हें धोखाधड़ी रोकने वाली पाइपलाइन पर कोई बुरा असर नहीं दिखा. नतीजे यहां और यहां दिए गए हैं. टीम धोखाधड़ी रोकने और मेज़रमेंट पार्टनर के साथ, इन संभावित समस्याओं की लगातार जांच कर रही है. |
| अनुमति से जुड़ी नीति | क्या अनुमति-नीति को कैश मेमोरी में सेव किया गया है? | अनुमति से जुड़ी नीति को कैश मेमोरी में सेव नहीं किया जाता, जैसा कि GitHub से जुड़ी इस समस्या में बताया गया है. |
नैटकैचर (काम जारी है)
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
| जियोलोकेशन के इस्तेमाल के उदाहरण | Gnatcatcher भविष्य में किसी भौगोलिक स्थान के इस्तेमाल के मामलों को सही तरीके से काम करने से रोक सकता है, जैसे कि भौगोलिक स्थान के आधार पर कॉन्टेंट को मनमुताबिक बनाना. | हम यह पक्का करने के लिए हिस्सेदारों के साथ काम कर रहे हैं कि Chrome, आईपी पतों के इस्तेमाल के मामलों में भी सही तरीके से काम करता रहे. |
क्रॉस-साइट निजता की सीमाओं को मज़बूत बनाएं
पहले पक्ष के सेट
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
| नीति | चिंता का विषय, "लागू डेटा सुरक्षा कानून" से जुड़े, सीएमए के वादों के प्रावधानों का पालन न करने पर, इस आधार पर कि जीडीपीआर किसी सेट में साइटों की संख्या पर सीमा लागू नहीं करता, जबकि FPS की सीमा तीन होती है. | Google, सीएमए के लिए प्रतिबद्ध है कि वह प्राइवसी सैंडबॉक्स के प्रपोज़ल को इस तरह डिज़ाइन और लागू करे कि Google के कारोबार को प्राथमिकता देकर, प्रतिस्पर्धा में किसी तरह की गड़बड़ी न हो. साथ ही, डिजिटल विज्ञापन, पब्लिशर, और विज्ञापन देने वाले लोगों या कंपनियों में प्रतिस्पर्धा पर पड़ने वाले असर को ध्यान में रखा जाए. साथ ही, लागू डेटा सुरक्षा कानून के तहत, निजता से जुड़े नतीजों और डेटा की सुरक्षा के सिद्धांतों के पालन पर असर को भी ध्यान में रखा जाए. ज़ाहिर की गई चिंता में, जीडीपीआर के साथ किसी भी तरह की गड़बड़ी ज़ाहिर नहीं की गई है. हम यह पक्का करने के लिए सीएमए के साथ मिलकर काम करते रहते हैं कि हमारा काम इन प्रतिबद्धताओं का पालन करे. नीचे "सुझाव के जवाब में होने वाले बदलाव" सेक्शन में ज़्यादा जानकारी दी गई है. |
| दस्तावेज़ | ज़्यादा उदाहरण के लिए अनुरोध करें और जानकारी देने वाले मौजूदा लेखों को अपडेट करें. | हमारे एक्सप्लेनर वीडियो में दिए गए उदाहरणों की समीक्षा की जा रही है. ज़रूरत पड़ने पर, इनमें साफ़ तौर पर जानकारी दी जाएगी या इन्हें हटा दिया जाएगा. |
| पसंदीदा सेटिंग शेयर करना | एक ही पार्टी के सेट के लिए प्राथमिकताएं तय करने का प्रस्ताव. | हम आपके सुझाव, शिकायत या राय का स्वागत करते हैं और हम यहां इस आइडिया पर लगातार चर्चा कर रहे हैं. |
| नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) | नीति उल्लंघन ठीक करने के पारदर्शी तरीकों के तहत, बुरे मकसद से काम करने वाले लोग या ग्रुप, इनका गलत इस्तेमाल कर सकते हैं. | आपके सुझाव, शिकायत या राय की हम सराहना करते हैं. हम इस समस्या में बताई गई बातों को ध्यान में रखते हुए, GitHub के हिस्सेदारों के साथ लगातार बातचीत कर रहे हैं. हम इस समस्या से जुड़े सुझावों को भी ध्यान में रखते हुए काम कर रहे हैं. साथ ही, हम दूसरे फ़ोरम में भी इस सुझाव को शामिल करना चाहते हैं, ताकि इस जोखिम का आकलन किया जा सके और संभावित खतरों की पहचान की जा सके. |
| मालिकाना हक | मालिकाना हक के बारे में बताने के लिए, मशीन से पढ़ा जा सकने वाला एलान का प्रस्ताव. | हमारे प्रस्ताव पर इनपुट का स्वागत किया जाता है और इसे इस्तेमाल करने का सुझाव दिया जाता है. |
| सबडोमेन के मालिकाना हक | क्या अलग-अलग डेटा कंट्रोलर, अलग-अलग निजता नीतियों या अलग-अलग इकाइयां ऑपरेट किए जाने वाले अलग-अलग सबडोमेन एक ही पहले पक्ष के सेट का हिस्सा होने चाहिए? | आपसे मिले सुझावों के आधार पर, हम eTLD के इस्तेमाल के उदाहरण को हटाने की योजना बना रहे हैं. |
| गलत इस्तेमाल को कम करना | गलत इस्तेमाल को कम करने के तरीकों के बारे में ज़्यादा जानकारी के लिए अनुरोध करें. | इस प्रोसेस के मैनेजमेंट पर विचार किया जा रहा है. आने वाले महीनों में, इस बारे में ज़्यादा जानकारी शेयर की जाएगी. |
| संभावित अटैक वेक्टर | आसानी से खोजे जा सकने वाले पेजों के लिए, 'धोखाधड़ी वाले सेट' का इस्तेमाल, ऐसे दूसरे पेजों पर ट्रैफ़िक लाने के लिए किया जा सकता है जिन्हें धोखे से अलग तरीके के तौर पर पेश किया गया हो. | हम लगातार लोगों से जानकारी इकट्ठा कर रहे हैं और इस समस्या को हल करने के संभावित तरीकों का पता लगा रहे हैं. |
| पुष्टि करने की सुविधा सेट करें | सहमति वाली सामान्य नीतियों के ज़रिए सेट की पुष्टि करना. | वेब स्टैंडर्ड से जुड़ी कम्यूनिटी और बड़े नेटवर्क के कई सदस्यों ने बताया है कि ऐसा करना मुमकिन नहीं है. |
| डोमेन की सीमा | जुड़े हुए डोमेन की संख्या बढ़ाने का अनुरोध. | हम FPS में डोमेन की सीमा को लेकर बातचीत कर रहे हैं. साथ ही, अगर समुदाय के सुझाव, शिकायत या राय को इस बारे में बताना चाहते हैं कि इस्तेमाल के उदाहरणों के लिए, डोमेन के कितने हिस्सों की ज़रूरत है, तो हम इस बारे में बात करेंगे. |
| सेवा इंटरैक्शन का सबसेट | सेवा और उससे जुड़े सबसेट इंटरैक्शन से जुड़ी समस्या. | हमें आपके सुझाव, शिकायत या राय का इंतज़ार है. हम आने वाले समय में, इसे और बेहतर बनाने पर काम करेंगे. |
| (दूसरी तिमाही में इसकी रिपोर्ट भी की गई)
निजता को बेहतर बनाना |
एक ही सेट में बहुत ज़्यादा साइटों का इस्तेमाल करने पर, तीसरे पक्ष की कुकी की तरह नतीजे मिल सकते हैं. | तीसरी तिमाही का अपडेट:
नए प्रस्ताव में, "जुड़े हुए" सबसेट के लिए तीन डोमेन की सीमा का सुझाव दिया गया है. हालांकि, इनमें ccTLD और सेवा डोमेन शामिल नहीं हैं. यह सीमा सही है या नहीं, यह तय करने के लिए Chrome, नेटवर्क के साथ मिलकर काम कर रहा है. |
| (दूसरी तिमाही में इसकी रिपोर्ट भी की गई)
निजता नीति से जुड़ी सामान्य शर्तें |
एक ही सेट का हिस्सा बनने वाले सभी प्रॉडक्ट और अधिकार क्षेत्रों के लिए, एक जैसी निजता नीति बनाए रखना संभव नहीं होता. | तीसरी तिमाही का अपडेट:
एक ही सेट का हिस्सा होने के लिए, अब सामान्य निजता नीति का होना ज़रूरी नहीं है. |
फ़ेंस किए गए फ़्रेम का एपीआई
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
| iframes पर विशेषताओं के बजाय नया तत्व क्यों? | मौजूदा iframe प्रपोज़ल के बजाय, प्रपोज़ल फ़्रैंडेंस फ़्रेम के बारे में सवाल. | हम आपके सुझाव, शिकायत या राय का स्वागत करते हैं. साथ ही, मौजूदा स्थिति के बारे में यहां बताए गए तरीके से बातचीत करने के लिए हम तैयार हैं. |
| फ़ेंस्ड फ़्रेम में इंटरसेक्शन ऑब्ज़र्वर | फ़ेंस किए गए फ़्रेम में मौजूद जानकारी के दिखने से जुड़े सवाल. | इस दस्तावेज़ में और GitHub पर, इस बारे में चर्चा चल रही है. साथ ही, टिप्पणी करने की अवधि में भी इस बारे में बातचीत चल रही है. हम पार्टनर का स्वागत करते हैं, ताकि वे अपने साथ काम के उदाहरण शेयर कर सकें. इससे हमें यह समझने में मदद मिलेगी कि उनकी मदद कैसे की जाती है. |
| सहायता वीडियो और नेटिव इन्वेंट्री | क्या फ़ेंस किए गए फ़्रेम, वीडियो और नेटिव इन्वेंट्री के साथ काम करते हैं? | वीडियो चलाने की क्षमताओं की बात करें, तो फ़ेंस किए गए फ़्रेम, iframe से अलग नहीं होते हैं. इसलिए, किसी भी सार्वजनिक दस्तावेज़ में इसे साफ़ तौर पर शामिल नहीं किया जाता है. अगर वीडियो विज्ञापनों में कोई समस्या दिखती है, तो सुझाव/राय दें या शिकायत करें, ताकि हम उसकी जांच कर सकें. |
| वेब बंडल | क्या आने वाले समय में, फ़ेंस किए गए फ़्रेम x FLEDGE की मदद से, वेब बंडल की मदद से विज्ञापन दिखाने / रेंडरिंग की ज़रूरत होगी? | लंबे समय का लक्ष्य, फ़ेंस किए गए फ़्रेम में विज्ञापन कॉन्टेंट को रेंडर करने के लिए, वेब बंडल की सुविधा देना है. हालांकि, मौजूदा समय में FLEDGE को लागू करना, इसके साथ काम नहीं करता. इसके लिए, रेंडर करने के यूआरएल से मिले एचटीएमएल रिसॉर्स को रेंडर करना ज़रूरी होता है. |
| एसेट डाइमेंशन | स्लॉट की ऊंचाई और चौड़ाई के लिए मैक्रो को सपोर्ट करने के लिए रेंडर_url का अनुरोध करें, ताकि हम सही साइज़ के क्रिएटिव के साथ जवाब दे सकें | इस पर यहां चर्चा की जा रही है. |
शेयर किया गया स्टोरेज एपीआई
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
| FLEDGE इंटिग्रेशन | शेयर किए गए स्टोरेज और FLEDGE को इंटिग्रेट कैसे किया जाएगा? | हालांकि, हम इस पर काम नहीं कर रहे हैं, लेकिन हम इस आइडिया पर काम करना चाहते हैं, ताकि निजता की सुरक्षा पक्की की जा सके. हम इस बात में दिलचस्पी रखने वाले पक्षों को सलाह देते हैं कि इस्तेमाल के संभावित मामलों में, शेयर किए गए स्टोरेज के GitHub रिपॉज़िटरी या FLEDGE GitHub रिपॉज़िटरी में यह सुझाव दिया जा सके. . |
| डेटा का रखरखाव | शेयर किए गए स्टोरेज को खाली करने से, उसका इस्तेमाल कम हो जाता है. क्या डेटा के रखरखाव की समयसीमा के एक्सटेंशन या अलग-अलग कुंजी/वैल्यू को मिटाने की सुविधा को विकल्प के तौर पर लिया गया है? | हम हमेशा उपयोगकर्ताओं की निजता और बिजली, पानी जैसी सुविधाओं के बीच संतुलन बनाने की कोशिश करते हैं. हम बदलावों के बारे में सुझाव/राय देने या शिकायत करने के लिए तैयार हैं. हम पार्टनर को इस बात की सलाह देते हैं कि वे शेयर किए गए स्टोरेज को टेस्ट करने के दौरान, ज़्यादा सुझाव और जानकारी दें. |
| नेगेटिव सिग्नल | शेयर किए गए स्टोरेज के प्रस्ताव के बारे में Mozilla के नेगेटिव सिग्नल. | हमारे प्रस्ताव की सावधानी से समीक्षा करने के लिए हम Mozilla को धन्यवाद देते हैं. हम आने वाले समय में उनके सुझावों का जवाब देने की योजना बना रहे हैं. |
सीएचआईपीएस
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
| डेटा सोर्स बांटा गया | पहले पक्ष की कुकी पर, "सेगमेंट में बांटी गई" एट्रिब्यूट के लिए, व्यवहार से जुड़ी ज़रूरी शर्त जोड़ें. | हमने PrivacyCG कॉल पर इस बारे में बात की है. साथ ही, GitHub से जुड़ी समस्या के बारे में नोट के साथ बात की है. हम ब्राउज़र, डेवलपर, और निजता समुदाय के साथ लगातार काम कर रहे हैं, ताकि हम ऐसा व्यवहार कर सकें और उसके बारे में बता सकें. |
| पुष्टि किए गए एम्बेड | सीएचआईपीएस, एसएसओ (SSO) के मौजूदा साइन इन फ़्लो पर असर डाल सकता है. इसकी वजह यह है कि अलग-अलग पार्टिशन की वजह से, पुष्टि किए गए एम्बेड पर असर पड़ता है. | हमें पुष्टि किए गए एम्बेड के इस्तेमाल के उदाहरण के बारे में पता है और हम समाधान ढूंढने के लिए काम कर रहे हैं. |
| कुकी विभाजन सीमा | चिंता करें कि इस्तेमाल के कुछ मामलों में, हो सकता है कि 10 कुकी की मौजूदा सीमा काफ़ी न हो. | हम कुकी की संख्या की सीमा से 12 केबी की मेमोरी सीमा पार कर रहे हैं. ऐसा करने से, हमें कुकी की सीमा से जुड़ी समस्याओं को हल करने में मदद मिलती है. साथ ही, यह पक्का करने में भी मदद मिलती है कि परफ़ॉर्मेंस और ब्राउज़र की मेमोरी फ़ुटप्रिंट पर बुरा असर न पड़े. |
| ऑरिजिन ट्रायल की टाइमलाइन | होस्टनेम की सीमा से जुड़ी ज़रूरी शर्त को हटाने के बाद, ओटी को बढ़ाएं. | नेटवर्क से मिले सुझावों के बाद, हमने ऑरिजिन ट्रायल की समयसीमा बढ़ा दी है. |
| Chrome में सीमाओं की जांच करना | Chrome की मौजूदा सीमा की वजह से, Firefox में सीएचआईपीएस को टेस्ट करने की संभावना. | Firefox को लागू करने का तरीका करीब-करीब अलग है, Chrome में कुकी की सीमा कम होती है, और CHIPS एक ऑप्ट-इन तकनीक है. हालांकि, Firefox को डिफ़ॉल्ट रूप से अलग-अलग हिस्सों में बांटा जाता है. |
| (दूसरी तिमाही में इसकी रिपोर्ट भी की गई)
पुष्टि किए गए एम्बेड |
क्या साइन-ऑन स्थिति सीएचआईपीएस के साथ सुरक्षित रहती है? | तीसरी तिमाही का अपडेट:
'साइन इन की गई' स्थिति को फ़िलहाल सेव नहीं किया गया है, लेकिन यह सीएचआईपीएस के इस्तेमाल के लिए सही नहीं है. हमें पुष्टि किए गए एम्बेड के इस्तेमाल के उदाहरण के बारे में पता है और हम समाधान ढूंढने के लिए काम कर रहे हैं. |
FedCM
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
| (दूसरी तिमाही में इसकी रिपोर्ट भी की गई)
संभावित अटैक वेक्टर |
लिंक डेकोरेशन और टाइमिंग अटैक के ज़रिए, संभावित अटैक वेक्टर. | तीसरी तिमाही का अपडेट:
हमने Mozilla के साथ मिलकर यह समझने के लिए काम किया है कि टाइमिंग हमले की समस्या को कैसे हल किया जाए. साथ ही, ज़्यादा जानकारी यहां दी गई है. अब हम वास्तुकला में हुए इस बदलाव का प्रोटोटाइप बना रहे हैं और हमें उम्मीद है कि अगली कुछ तिमाहियों में हम इसके प्रयोग करेंगे. |
| पहचान देने वाली सेवा | खाता चुनने की सुविधा: सिंगल आइडेंटिटी प्रोवाइडर. एक से ज़्यादा आइडेंटिटी प्रोवाइडर को अनुमति देने का अनुरोध करें. | हमने ब्राउज़र वेंडर और FedID CG के साथ मिलकर यह पता लगाया है कि आइडेंटिटी प्रोवाइडर की अलग-अलग सुविधाओं की अनुमति कैसे दी जाए. इसके लिए, हमने एक ऐसा तरीका तैयार किया है जो काम का लगता है. प्रस्ताव की जानकारी यहां दी गई है. हम अगली कुछ तिमाहियों में इसके प्रोटोटाइप बनाने और एक्सपेरिमेंट चलाने की उम्मीद करते हैं. |
| फ़ेडरेशन की पहले से मालूम समस्याएं | ऐसे मामलों की गिनती करने का अनुरोध करें जहां फ़ेडरेशन में तीसरे पक्ष की कुकी को रोकने में समस्या आ सकती है. | FedID CG में एक वर्क आइटम मौजूद है, जिसमें यहां और यहां फ़ेडरेशन के ब्रेक लेने के तरीकों के बारे में बताया गया है. वे यहां Web Platform API के ब्रेकेज को मैप करने के लिए, डिसिज़न मैट्रिक्स भी बना रहे हैं. |
| Nउंस पैरामीटर | क्या NROWS पैरामीटर से साइन इन फ़्लो पर असर पड़ सकता है? | इसे क्रॉस-साइट ट्रैकिंग माना जा सकता है, लेकिन हम अब भी इनपुट इकट्ठा कर रहे हैं और विश्लेषण कर रहे हैं कि ऐसे मामलों को कैसे ठीक किया जाए. |
| उपयोगकर्ता की सहमति | हर ऑरिजिन के लिए, अलग-अलग भरोसेमंद पक्षों (आरपी) और उपयोगकर्ता की सहमति को लिंक करना. | यह खास जानकारी यह कंट्रोल नहीं कर सकती कि एक ही डोमेन के ऑरिजिन, कुकी को कैसे शेयर करें. इस शर्त के मुताबिक, आईडीपी ऑरिजिन से आरपी ऑरिजिन तक आईडी टोकन की अनुमति दी जाती है. हालांकि, यह आरपी पर निर्भर करता है कि उपयोगकर्ता के साइन इन की स्थिति को उसी ऑरिजिन में लॉक की गई कुकी में सेव किया जाए या उसी डोमेन में मौजूद ऑरिजिन के साथ शेयर की गई कुकी में. |
| आईडीपी खाता
पोर्टेबिलिटी |
उपयोगकर्ता, दो आईडीपी के बीच ट्रांसफ़र करते समय आईडीपी को माइग्रेट करने का विकल्प चुन सकते हैं. | ऐसा लगता है कि उपयोगकर्ता को सीधे अपनी पसंद के नए आईडीपी के साइन अप पेज पर ऐसा करना होगा, न कि FedCM API के ज़रिए. |
| खाता मिटाना | आईडीपी के साथ खाता मिटाने के लिए आईडीपी रद्द करने का हिसाब. | सुविधा के इस अनुरोध का जवाब दिया जा सकता है और इसकी जांच की जा रही है. |
| यूज़र इंटरफ़ेस (यूआई) दावा | ब्राउज़र के हिसाब से इंटरफ़ेस के पहलुओं के बारे में दावे. | इस समस्या को हल करने के लिए, पुल अनुरोध देखें. |
| आईडीपी रेफ़रल की जांच | आईडीपी, आरपी के रेफ़रर की जांच करता है. | खास जानकारी में, आईडीपी (IdP) के रेफ़रर की ज़रूरी जांच जोड़ी गई. पुल अनुरोध देखें. |
| साइन इन फ़्लो | आरपी की प्राथमिकताओं के आधार पर, साइन इन करने के फ़्लो को पसंद के मुताबिक बनाने का अनुरोध करें. | हम इस आइडिया का स्वागत करते हैं और इस पर लगातार चर्चा कर रहे हैं. |
स्पैम और धोखाधड़ी को रोकना
Trust Tokens API
| फ़ीडबैक थीम | खास जानकारी | Chrome रिस्पॉन्स |
| धोखाधड़ी और गलत इस्तेमाल | ऐसे टूल जो यह पक्का करते हैं कि बॉट, किसी जारी करने वाले के साथ धोखे से कोई टोकन न ले ले, साथ ही बॉट ने असली उपयोगकर्ता को जारी किए गए टोकन पर कब्ज़ा नहीं किया है और बॉट को नुकसान पहुंचाने वाले टोकन देने से रोकने के लिए क्या किया है? | हालांकि, बॉट को जारी करने वाले से टोकन मिल सकते हैं, लेकिन जारी करने वालों को यह सलाह दी जाती है कि वे कितनी बार टोकन जारी करते हैं, और टोकन जारी करने के मज़बूत तरीके क्या होते हैं. जिन कंपनियों के पास टोकन देने के लिए ज़रूरी जानकारी नहीं होती उनके नेटवर्क पर, भरोसा होने की संभावना कम हो जाती है. ऐसा इसलिए होता है, क्योंकि वेबसाइटें ज़्यादा मज़बूत जारी करने वालों पर निर्भर करती हैं. |
| धोखाधड़ी और गलत इस्तेमाल | क्या ऐसा कोई तरीका है जिससे ट्रस्ट टोकन रिडीम करने वाला यह बता सके कि वह सिर्फ़ कुछ खास इकाइयों से मिले ट्रस्ट टोकन स्वीकार करेगा? | हां, ऐसा किया जा सकता है. जानकारी देने वाले सेक्शन में, ट्रस्ट टोकन रिडीम करने के सेक्शन में बताया गया है कि यह सुविधा कैसे काम करती है. |
| धोखाधड़ी और गलत इस्तेमाल | क्या ट्रस्ट टोकन जारी करने वाला कोई ऐसा तरीका है जिससे वह रिडीम करने वालों की सूची बना सके और किसी और को टोकन रिडीम करने की अनुमति न दे? | फ़िलहाल, ऐसी कोई जानकारी नहीं है. हालांकि, हमारी टीम इस्तेमाल के इस उदाहरण की जांच कर रही है. |
| टाइमलाइन | Trust Token API आम तौर पर कब उपलब्ध होगा? | जैसे ही हम किसी टाइमलाइन पर कार्रवाई करेंगे, हम ज़्यादा जानकारी को सार्वजनिक रूप से शेयर करेंगे. |
| (दूसरी तिमाही में इसकी रिपोर्ट भी की गई)
मेंटेनेंस ओवरहेड |
यह साफ़ नहीं है कि कितने समय तक प्रोटोकॉल वर्शन काम करेंगे. | तीसरी तिमाही का अपडेट:
एक से ज़्यादा वर्शन के साथ काम करने वाले एपीआई में अतिरिक्त सहायता जोड़ी जा रही है, ताकि वर्शन के बीच बेहतर ट्रांज़िशन किया जा सके. हालांकि, सहायता / बंद करने की समयसीमा पर अब भी काम किया जा रहा है. |