Android के लिए प्राइवसी सैंडबॉक्स से जुड़ी प्रोग्रेस से जुड़े अपडेट

प्रोग्रेस अपडेट में, डिज़ाइन के प्रस्तावों में हुए नए बदलावों और अपडेट की खास जानकारी दी जाएगी. साथ ही, हमें मिले मुख्य सवालों और सुझावों के बारे में बताया जाएगा. इसके अलावा, डेवलपर के लिए उपलब्ध, रिलीज़ के अपडेट भी दिए जाएंगे.

रिलीज़ हुए नए गाने

डेवलपर के लिए झलक का सातवां वर्शन रिलीज़ किया गया

यह नई रिलीज़ एक अहम माइलस्टोन है. यह आने वाले समय में प्राइवसी सैंडबॉक्स के बीटा वर्शन के रिलीज़ होने की बुनियाद है. इस रिलीज़ में, Protected Audience वॉटरफ़ॉल मीडिएशन के लिए सहायता, एट्रिब्यूशन रिपोर्टिंग इवेंट रजिस्ट्रेशन डेज़ी-चेन रीडायरेक्ट, और एपीआई में किए गए अन्य बदलावों से जुड़ी अतिरिक्त सुविधाएं शामिल हैं.

आने वाले महीनों में नई सुविधाएं रिलीज़ होने पर, हम डेवलपर प्रीव्यू के रिसॉर्स को अपडेट करते रहेंगे. इस कैंपेन से जुड़े अपडेट पाने के लिए साइन अप करें.

मार्च 2023 में बीटा वर्शन रिलीज़ किया गया

इस रिलीज़ में, सार्वजनिक डिवाइसों पर Privacy Sandbox APIs की उपलब्धता के बारे में बताया गया है. यह रिलीज़, डेवलपर के लिए झलक 6 के तौर पर काम करती है. डेवलपर, एक्सटेंशन SDK टूल की मदद से, बीटा रिलीज़ में एपीआई ऐक्सेस कर सकते हैं.

डेवलपर प्रीव्यू रिलीज़ की टाइमलाइन के बारे में अपडेट

तारीखें और जानकारी कभी भी बदली जा सकती है

हर डेवलपर प्रीव्यू और बीटा रिलीज़ के साथ, रिलीज़ के बारे में ज़्यादा जानकारी देने वाले नोट और गाइड उपलब्ध होंगे. इनसे यह पता चलेगा कि हर रिलीज़ में कौनसी सुविधाएं उपलब्ध हैं और कौनसी नहीं.

अभी उपलब्ध है:

• डेवलपर के लिए सातवां रिलीज़ वर्शन - इसमें ऐसी सुविधाएं शामिल हैं जिनकी मदद से, SDK Runtime, Topics, Protected Audience, और Attribution Reporting API जैसे काम के एपीआई का इस्तेमाल करके इंटिग्रेशन डिज़ाइन किया जा सकता है
• बीटा प्रोग्राम, प्रोडक्शन टेस्टिंग के लिए सीमित तौर पर उपलब्ध है. मार्च 2023 में रिलीज़ किया गया बीटा वर्शन, सार्वजनिक डिवाइसों पर Privacy Sandbox APIs की उपलब्धता दिखाता है. साथ ही, यह वर्शन, डेवलपर के लिए उपलब्ध झलक के छठे वर्शन के तौर पर काम करता है.

साल 2023 की शुरुआत में:

• Android 13 डिवाइसों के एक छोटे से हिस्से पर, निजता बनाए रखने वाले एपीआई की पहली स्टैबल रिलीज़.

साल 2023 तक:

• डेवलपर के लिए उपलब्ध झलक और स्थिर एपीआई रिलीज़ के और वर्शन, जिनमें अतिरिक्त सुविधाएं होंगी. ज़्यादा उपयोगकर्ताओं और Android डिवाइसों के लिए उपलब्ध कराना.

रिमाइंडर: फ़रवरी में, जब हमने Android पर प्राइवसी सैंडबॉक्स के एलान किए थे, तब हमने साफ़ तौर पर बताया था कि इन नए समाधानों को डिज़ाइन, बनाए जाने, और टेस्ट किए जाने के दौरान, हम विज्ञापन प्लैटफ़ॉर्म की मौजूदा सुविधाओं को कम से कम दो साल तक उपलब्ध रखेंगे. साथ ही, आने वाले समय में होने वाले किसी भी बदलाव से पहले, हम आपको इसकी पूरी जानकारी देंगे.

डिज़ाइन के प्रस्ताव से जुड़े अपडेट

इस सेक्शन में, डिज़ाइन के प्रस्तावों से जुड़े कई खास अपडेट के बारे में बताया गया है.

Reflection API

हमारे मूल SDK टूल के रनटाइम डिज़ाइन प्रपोज़ल में, हमने रिफ़्लेक्शन के ऐक्सेस को रोकने और एपीआई को शुरू करने के अपने सुझाव पर सुझाव देने के लिए अनुरोध किया था. इसका मकसद, अन्य SDK टूल के साथ होने वाली छेड़छाड़ को रोकने में SDK टूल के डेवलपर की मदद करना था.

हमें उन इस्तेमाल के उदाहरणों के बारे में अहम सुझाव मिले हैं जिन पर इस बदलाव का असर पड़ा है. साथ ही, इस बदलाव की उपयोगिता और उससे जुड़े जोखिमों की जांच करने के बाद, हम SDK टूल के रनटाइम में रिफ़्लेक्शन और एपीआई को कॉल करने की अनुमति देंगे. साथ ही, हमने अपने डिज़ाइन के प्रस्ताव को इसी हिसाब से अपडेट कर दिया है.

हालांकि, किसी SDK टूल को रिफ़्लेक्शन का इस्तेमाल करने या रनटाइम की सुविधा वाले किसी अन्य SDK टूल पर एपीआई को कॉल करने की अनुमति नहीं होगी. इसके बजाय, SDK टूल के रनटाइम में SDK टूल से SDK टूल की जानकारी के लिए, हम SDK टूल को खोजने के लिए अलग-अलग एपीआई डिज़ाइन कर रहे हैं. आने वाले समय में होने वाले अपडेट में, इस बारे में ज़्यादा जानकारी दी जाएगी.

हम लगातार ऐसे तरीकों की जांच कर रहे हैं जिनसे अन्य SDK टूल के गलत इस्तेमाल के जोखिम को कम किया जा सके. इसलिए, हमारा सुझाव है कि SDK टूल के रनटाइम में JNI कोड का इस्तेमाल न किया जाए. साथ ही, हम अन्य एपीआई पर भी विचार कर रहे हैं. हम आने वाले समय में, पाबंदी वाले एपीआई के बारे में पूरी जानकारी शेयर करेंगे.

Attribution Reporting API

• सुझावों के आधार पर, हमने एक उदाहरण जोड़ा है. इसमें दिखाया गया है कि व्यू, क्लिक, और कन्वर्ज़न इवेंट, शामिल होने वाले कई पक्षों की ओर से कैसे रजिस्टर किए जा सकते हैं. हमने आने वाले समय में ध्यान में रखने वाली बातें और खुले सवाल जोड़े हैं. इनके बारे में हमें सुझाव/राय चाहिए.

Topics API

• Topics API, ज़्यादा से ज़्यादा तीन विषयों की सूची दिखाता है. इसमें, पिछले तीन समयावधि (उदाहरण के लिए, पिछले तीन हफ़्तों) में से हर एक के लिए एक विषय होता है. हमने Topics API के तकनीकी प्रस्ताव को अपडेट किया है. इससे यह साफ़ तौर पर पता चलता है कि दिखाए गए विषय, उपयोगकर्ता की दिलचस्पी के बारे में बताते हैं. साथ ही, दिखाए गए किसी भी या सभी विषयों का इस्तेमाल, उपयोगकर्ता के हिसाब से विज्ञापन दिखाने के लिए किया जा सकता है.

हमें मिले अन्य सवालों और सुझाव/राय/शिकायत की खास जानकारी

इस सेक्शन में, हमें मिले कुछ सवालों और सुझावों के साथ-साथ, उनका जवाब भी दिया गया है.

सामान्य सवाल

क्या Android पर प्राइवसी सैंडबॉक्स, कनेक्टेड टीवी डिवाइसों पर लागू होगा?

हमारे मौजूदा डिज़ाइन के प्रस्ताव, मोबाइल डिवाइसों और ऐप्लिकेशन के इस्तेमाल के उदाहरणों पर आधारित हैं. हम आने वाले समय में, Android के अन्य नाप या आकार के बारे में और जानकारी शेयर करेंगे.

Android पर Privacy Sandbox को बीटा वर्शन के लिए, डिवाइसों पर कैसे रोल आउट किया जाएगा?

उपयोगकर्ताओं को समय-समय पर अपडेट आसानी से उपलब्ध कराने के लिए, मुख्य कॉम्पोनेंट को, काम करने वाले Android मोबाइल डिवाइसों पर मुख्य मॉड्यूल के तौर पर डिस्ट्रिब्यूट किया जाएगा. इससे, हम Android प्लैटफ़ॉर्म के सामान्य रिलीज़ साइकल के अलावा, उन डिवाइसों पर आसानी से सुधार कर पाएंगे जिन पर यह सुविधा काम करती है.

Kotlin के लिए सहायता देने का आपका प्लान क्या है?

हम Privacy Sandbox API के डिज़ाइन को बेहतर बनाने पर काम कर रहे हैं. साथ ही, हम डेवलपर को Kotlin में आसानी से कोड लिखने की सुविधा देना चाहते हैं. डेवलपर से जुड़े संसाधन, जैसे कि डेवलपर की झलक में मौजूद सैंपल ऐप्लिकेशन, Java के साथ-साथ Kotlin में भी उपलब्ध हैं.

प्राइवसी सैंडबॉक्स के लिए, उपयोगकर्ता-लेवल पर कौनसे कंट्रोल उपलब्ध हैं और इन कंट्रोल को रोल आउट करने में कितनी समय लगेगा?

फ़ाइनल डिज़ाइन अभी तक तैयार नहीं किए गए हैं. हालांकि, बीटा वर्शन के दौरान हम डिवाइस की सेटिंग में उपयोगकर्ता कंट्रोल उपलब्ध कराने जा रहे हैं, ताकि:

1. Privacy Sandbox के समाधानों को छोड़ना या उनमें फिर से शामिल होना
2. Topics API से अनुमानित कुछ विषयों को हटाना

क्या Google Play के अलावा, अन्य ऐप्लिकेशन स्टोर नेटवर्क भी Privacy Sandbox के समाधानों का इस्तेमाल कर सकते हैं?

Privacy Sandbox के सभी समाधान, Android Open Source Project (AOSP) का हिस्सा हैं. इसलिए, अगर कोई ऐप्लिकेशन स्टोर चाहे, तो इनका इस्तेमाल कर सकता है. उन ऐप स्टोर से संपर्क करें जिनके साथ आपका काम होता है, ताकि उनके प्लान को बेहतर तरीके से समझा जा सके.

SDK टूल का रनटाइम

इन प्रस्तावों के तहत, SDK टूल के वर्शन कैसे मैनेज किए जाएंगे? अगर वेंडर अपने SDK टूल को स्वतंत्र रूप से अपडेट कर सकते हैं, तो क्या ऐप्लिकेशन, SDK टूल के वर्शन की डिपेंडेंसी को कंट्रोल कर पाएंगे?

फ़िलहाल, इसे डिज़ाइन किया जा रहा है. एक तरीका यह है कि SDK टूल के डेवलपर, SDK टूल के जिस वर्शन को SDK टूल के रनटाइम के साथ काम करने वाले ऐप्लिकेशन स्टोर के ज़रिए डिस्ट्रिब्यूट करना चाहते हैं उसके major.minor.patch वर्शन की जानकारी दें.

इसके बाद, ऐप्लिकेशन डेवलपर अपने ऐप्लिकेशन मेनिफ़ेस्ट में इसकी जानकारी देकर, major.minor के उस वर्शन को चुन सकते हैं जिस पर वे निर्भर रहना चाहते हैं. उस major.minor वर्शन के लिए, सबसे हाल ही में रिलीज़ किया गया पैच तब तक इंस्टॉल रहेगा, जब तक अगला पैच रिलीज़ नहीं हो जाता. अगला पैच अपने-आप इंस्टॉल हो जाएगा. इसके अलावा, पैच तब तक इंस्टॉल रहेगा, जब तक ऐप्लिकेशन डेवलपर अपने ऐप्लिकेशन को फिर से न बनाए और उसमें major.minor के किसी दूसरे वर्शन की डिपेंडेंसी न बताए.

SDK टूल के रनटाइम का इस्तेमाल किस तरह के SDK टूल के लिए किया जाता है?

SDK टूल के रनटाइम के शुरुआती वर्शन को, विज्ञापन से जुड़े SDK टूल के इस्तेमाल के उदाहरणों के साथ काम करने के लिए डिज़ाइन किया जा रहा है. इनमें विज्ञापन दिखाने, विज्ञापन मेज़रमेंट, विज्ञापन धोखाधड़ी, और गलत इस्तेमाल का पता लगाने की सुविधा देने वाले SDK टूल शामिल हैं.

हालांकि, शुरुआत में विज्ञापन से जुड़े SDK टूल पर फ़ोकस किया जा रहा है, लेकिन जिन डेवलपर के पास विज्ञापन से जुड़े SDK टूल नहीं हैं और जो निजता को प्राथमिकता देते हैं और ऊपर बताई गई शर्तों के तहत काम कर सकते हैं वे SDK टूल के रनटाइम में चल रहे अपने SDK टूल के बारे में सुझाव/राय/शिकायत शेयर कर सकते हैं.

फ़िलहाल, हम डेटा इस्तेमाल करने के उदाहरणों के लिए, प्रपोज़ल में बताई गई अनुमतियों के अलावा अन्य अनुमतियों का इस्तेमाल करते हैं. क्या हम और अनुमतियों का अनुरोध कर सकते हैं?

हम विज्ञापन से जुड़े ऐसे इस्तेमाल के मामलों को समझने में माहिर हैं जिनके लिए ऐक्सेस की खास अनुमतियों की ज़रूरत होती है. ये अनुमतियां, हमारे शुरुआती डिज़ाइन प्रपोज़ल में दी गई अनुमतियों के दायरे में नहीं आतीं.

क्या SDK टूल को SDK रनटाइम प्रोसेस में ले जाने से, डाउनलोड साइज़ या स्टोरेज में बचत होगी?

अगर कई ऐप्लिकेशन को एक ही वर्शन वाले, रनटाइम के साथ काम करने वाले अलग-अलग SDK टूल के साथ इंटिग्रेट किया जाता है, तो इससे डाउनलोड साइज़ और डिस्क में ज़्यादा जगह बचेगी.

क्या AAID (AD_ID) को ऐक्सेस करने के लिए, SDK टूल को दी गई अनुमति, ऐप्लिकेशन की अनुमतियों पर निर्भर करती है?

AAID को ऐक्सेस करने की RE SDK टूल की क्षमता, ऐप्लिकेशन और SDK टूल, दोनों पर निर्भर करती है. इसके लिए, ज़रूरी है कि ऐप्लिकेशन और SDK टूल, अपने ऐप्लिकेशन के मेनिफ़ेस्ट में अनुमति का एलान करें. आने वाले समय में, हम एपीआई के बारे में जानकारी देंगे. SDK टूल, इस एपीआई का इस्तेमाल करके AAID हासिल कर पाएंगे. हालांकि, इसके लिए ज़रूरी है कि उनके पास अनुमति हो.

आईपी पते, ओएस वर्शन, और अन्य डेटा: क्या ये विज्ञापन से जुड़े SDK टूल के लिए उपलब्ध होंगे?

फ़िलहाल, हम उन सिस्टम प्रॉपर्टी पर काम कर रहे हैं जिनका ऐक्सेस, विज्ञापन से जुड़े SDK टूल के पास होगा. इस बारे में, डिज़ाइन के प्रस्ताव के अगले अपडेट में बताया जाएगा. हमने इन प्रॉपर्टी के इस्तेमाल के लिए कोई नीति पब्लिश नहीं की है.

क्या हमारा SDK टूल, एक से ज़्यादा ऐप्लिकेशन के लिए एक ही ऐप्लिकेशन सेट आईडी इकट्ठा करता है. भले ही, वे ऐप्लिकेशन अलग-अलग Google Play डेवलपर खातों से जुड़े हों? हम AAID के बिना, कई ऐप्लिकेशन पर धोखाधड़ी करने वाले लोगों को कैसे ब्लॉक कर सकते हैं?

किसी ऐप्लिकेशन या उसके किसी भी SDK टूल के पास, होस्ट ऐप्लिकेशन के Google Play डेवलपर खाते से जुड़े ऐप्लिकेशन सेट आईडी की वैल्यू का ही ऐक्सेस हो सकता है. Android पर मौजूद प्राइवसी सैंडबॉक्स, धोखाधड़ी के मकसद से क्रॉस-पब्लिशर आइडेंटिफ़ायर नहीं देगा. फ़िलहाल, डेवलपर आईपी का इस्तेमाल थोड़ा कम मिलता-जुलता विकल्प के तौर पर कर सकते हैं.

विषय

क्या मुझे उन सभी संभावित विषयों की सूची दिखेगी जो एपीआई से मिल सकती हैं?

जांच करने के लिए, डेवलपर प्रीव्यू 1 में इस टैक्सोनॉमी के विषयों का इस्तेमाल किया जाता है. इसमें बदलाव हो सकता है. हमें उम्मीद है कि समय के साथ, हम इसे बेहतर बना पाएंगे. इसके लिए, हम नेटवर्क से मिलने वाले सुझावों का इस्तेमाल करेंगे.

अगर विषयों के टैक्सोनॉमी में बदलाव हो सकता है, तो डाउनस्ट्रीम बाय-साइड मॉडल पर इन बदलावों का हिसाब कैसे लगाया जा सकता है?

Topics API के जवाब में, क्लासिफ़ायर और टैक्सोनॉमी के लिए वर्शन नंबर शामिल होगा.

Android पर Protected Audience

क्या एक्सक्लूज़न टारगेटिंग, Protected Audience के साथ काम करेगी?

मौजूदा डिज़ाइन के प्रस्ताव में, Protected Audience में मौजूद कस्टम ऑडियंस के आधार पर नेगेटिव टारगेटिंग की सुविधा काम नहीं करती.

ऐप्लिकेशन इंस्टॉल कैंपेन के लिए, हम विज्ञापन टेक्नोलॉजी की सेवा देने वाली कंपनियों को विज्ञापन फ़िल्टर करने की सुविधा उपलब्ध कराएंगे, ताकि वे पहले से इंस्टॉल किए गए ऐप्लिकेशन को फ़िल्टर कर सकें. हम यह भी पता लगा रहे हैं कि फ़्रीक्वेंसी कैपिंग पर आधारित कैंपेन के नेगेटिव फ़िल्टर की ज़रूरतों को कैसे पूरा किया जा सकता है. डिज़ाइन के प्रस्ताव के बारे में आने वाले अपडेट में ज़्यादा जानकारी दी जाएगी.

क्या सेलर के विज्ञापन नेटवर्क, कस्टम ऑडियंस बना सकते हैं? या क्या ये सिर्फ़ खरीदार के विज्ञापन नेटवर्क तक सीमित हैं?

कस्टम ऑडियंस के लिए हमारा मौजूदा प्रस्ताव, बिडिंग के लिए उपयोग के उदाहरण पर फ़ोकस करता है. ऐसा इसलिए है, क्योंकि इनका मकसद रीमार्केटिंग के लिए, निजता बनाए रखते हुए बिडिंग के लिए उपयोग के उदाहरण बनाने में मदद करना है.

एट्रिब्यूशन रिपोर्टिंग

क्या वेब-टू-ऐप्लिकेशन और ऐप्लिकेशन-टू-वेब के इस्तेमाल के उदाहरणों के लिए, Privacy Sandbox API एक साथ काम करेंगे?

हम इस्तेमाल के उदाहरणों को एक्सप्लोर कर रहे हैं. इनमें, मोबाइल ब्राउज़र ऐप्लिकेशन, Android Attribution Reporting API को कॉल करता है, ताकि एक ही डिवाइस पर ऐप्लिकेशन और वेब पर एट्रिब्यूशन चालू किया जा सके. ऐप्लिकेशन-टू-वेब को चालू करने पर, Android एपीआई के लिए प्राइवसी सैंडबॉक्स के एपीआई, स्टोरेज और एट्रिब्यूशन के लिए इस्तेमाल किए जाएंगे. साथ ही, यह ऐप्लिकेशन और वेब पर एट्रिब्यूशन की डुप्लीकेट जानकारी इकट्ठा करेगा. हालांकि, आपको एपीआई से ऐप्लिकेशन और वेब के लिए अलग-अलग रिपोर्ट मिल सकती हैं. इन्हें जोड़ना ज़रूरी है.

क्या एपीआई, लास्ट क्लिक के अलावा दूसरे एट्रिब्यूशन मॉडल के साथ काम करता है?

एपीआई, सोर्स को प्राथमिकता देने वाले लास्ट टच एट्रिब्यूशन मॉडल के साथ काम करता है. यह प्रस्ताव, पोस्ट-इंस्टॉल कन्वर्ज़न के लिए वैकल्पिक एट्रिब्यूशन लॉजिक का समर्थन करता है, ताकि इसे इंस्टॉल करने वाले क्लिक या व्यू को एट्रिब्यूट किया जा सके.

क्या Privacy Sandbox का असर Play Install Referrer पर पड़ेगा?

मौजूदा डिज़ाइन और प्लान के आधार पर, Privacy Sandbox API का इस्तेमाल करने से, Play Install Referrer की सुविधा पर कोई असर नहीं पड़ेगा.

कुछ डेवलपर ने ऐसे विज्ञापन फ़ॉर्मैट की पहचान की है जिनमें क्लिक के बाद होने वाले खास इवेंट को पूरा करने पर, उपयोगकर्ताओं को "इनाम" दिया जा सकता है. उपयोगकर्ता लेवल के एट्रिब्यूशन के बिना, मौजूदा प्रस्तावों के तहत यह एक चुनौती होगी.

इस समस्या की जांच की जा रही है, ताकि इसके संभावित समाधानों का पता लगाया जा सके. हम चाहते हैं कि आप इस इस्तेमाल के उदाहरण और इस्तेमाल के ऐसे अन्य मामलों के बारे में अतिरिक्त सुझाव, शिकायत या राय भेजें जो पहले से मौजूद हो सकते हैं.

हर विज्ञापन टेक्नोलॉजी प्लैटफ़ॉर्म के लिए, एट्रिब्यूशन अलग-अलग क्यों होता है?

आज, विज्ञापन देने वाले कई लोगों का मानना है कि सभी नेटवर्क पर अपने कन्वर्ज़न इवेंट का डुप्लीकेट व्यू पाना ज़रूरी है. साथ ही, मोबाइल मेज़रमेंट पार्टनर (एमएमपी) का इस्तेमाल करना आम बात है. नए एपीआई की मदद से, ऐसा करना आसान बना रहेगा. साथ ही, अगर किसी टेक्नोलॉजी प्लैटफ़ॉर्म या विज्ञापन देने वाले को सीधे तौर पर मेज़र करना है, तो वह भी ऐसा आसानी से कर सकता है.

रीडायरेक्ट का इस्तेमाल करने का मतलब है कि आपको हर ऐप्लिकेशन में SDK टूल की ज़रूरत नहीं है. हालांकि, रीडायरेक्ट की प्रोसेस में शामिल होने के लिए, आपको विज्ञापन टेक्नोलॉजी के SDK टूल के साथ जुड़ना होगा.

इस तरीके का एक मुख्य फ़ायदा यह है कि हर व्यक्ति के पास अपने कारोबार के लॉजिक के लिए, अपना मेटा-डेटा और एग्रीगेशन कुंजियां हो सकती हैं. साथ ही, अपनी प्राथमिकता भी तय की जा सकती है.

क्या Play Store से इंस्टॉल किए गए ऐप्लिकेशन की पुष्टि की जाती है?

पुष्टि किए गए इंस्टॉल का इस्तेमाल सिर्फ़ पोस्ट-इंस्टॉल कन्वर्ज़न एट्रिब्यूशन लॉजिक के वैकल्पिक होने के लिए किया जाता है. पुष्टि किए गए इन इंस्टॉल की जानकारी, एपीआई से नहीं भेजी जाएगी. एपीआई सिर्फ़ रजिस्टर किए गए कन्वर्ज़न के आधार पर रिपोर्ट भेजेगा और यह कोई सिग्नल नहीं दिखाएगा कि उपयोगकर्ता ने पहले ऐप्लिकेशन इंस्टॉल किया है या नहीं.

क्या क्लिक या व्यू की पुष्टि की जा रही है? क्या व्यू की पुष्टि करने के लिए, वीडियो की अवधि कम से कम कितनी होनी चाहिए?

एपीआई के मौजूदा प्रस्ताव में, InputEvent की मदद से क्लिक की बुनियादी पुष्टि की सुविधा काम करती है. हम क्लिक की पुष्टि करने और व्यू की पुष्टि करने के ज़्यादा बेहतर तरीकों के बारे में जानना चाहते हैं. हम इन इस्तेमाल के उदाहरणों के लिए ज़्यादा सुझाव, राय या शिकायत भेजने का सुझाव देते हैं. खास तौर पर, इस बारे में कि किस तरह की व्यू डेफ़िनिशन, नेटवर्क के लिए मददगार होंगी.