यूनीक आइडेंटिफ़ायर के लिए सबसे सही तरीके

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

Android की अनुमतियों के बारे में सामान्य जानकारी के लिए, अनुमतियों की खास जानकारी देखें. Android की अनुमतियों के साथ काम करने के सबसे सही तरीकों के बारे में जानने के लिए, ऐप्लिकेशन की अनुमतियों के सबसे सही तरीके देखें.

Android आइडेंटिफ़ायर के साथ काम करने के सबसे सही तरीके

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

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

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

   Android 10 (एपीआई लेवल 29) में, रीसेट न किए जा सकने वाले आइडेंटिफ़ायर के इस्तेमाल पर पाबंदियां लगाई गई हैं. इनमें आईएमईआई और सीरियल नंबर, दोनों शामिल हैं. इन आइडेंटिफ़ायर को ऐक्सेस करने के लिए, आपका ऐप्लिकेशन डिवाइस या प्रोफ़ाइल के मालिक का ऐप्लिकेशन होना चाहिए. इसके अलावा, उसके पास कैरियर की खास अनुमतियां होनी चाहिए या उसके पास READ_PRIVILEGED_PHONE_STATE खास अनुमति होनी चाहिए.

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

4. विज्ञापन आईडी रीसेट करने की प्रोसेस को ब्रिज न करें.

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

6. निजता के जोखिम को कम करने के लिए, ऐसे एपीआई का इस्तेमाल करें जो आपके इस्तेमाल के उदाहरण के लिए सही हों. ज़्यादा अहमियत वाले कॉन्टेंट की सुरक्षा के लिए, DRM API का इस्तेमाल करें. साथ ही, गलत इस्तेमाल से सुरक्षा के लिए Play Integrity API का इस्तेमाल करें. Play Integrity API, यह पता लगाने का सबसे आसान तरीका है कि कोई डिवाइस असली है या नहीं. इससे निजता से जुड़ा कोई जोखिम भी नहीं होता.

इस गाइड के बाकी सेक्शन में, Android ऐप्लिकेशन डेवलप करने के संदर्भ में इन नियमों के बारे में बताया गया है.

विज्ञापन आईडी के साथ काम करना

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

विज्ञापन आईडी को रीसेट करने के लिए, हमेशा उपयोगकर्ता की मंशा का सम्मान करें. उपयोगकर्ता की सहमति के बिना, विज्ञापन आईडी को एक-दूसरे से लिंक करने के लिए, किसी अन्य आइडेंटिफ़ायर या फ़िंगरप्रिंट का इस्तेमाल करके, उपयोगकर्ता के रीसेट किए गए डेटा को न जोड़ें. Google Play Developer Program की कॉन्टेंट से जुड़ी नीति में यह बताया गया है:

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

हमेशा, लोगों की दिलचस्पी के हिसाब से दिखाए जाने वाले विज्ञापनों से जुड़े फ़्लैग का पालन करें. विज्ञापन आईडी को कॉन्फ़िगर किया जा सकता है. इससे उपयोगकर्ता, आईडी से जुड़ी ट्रैकिंग की सीमा तय कर सकते हैं. हमेशा AdvertisingIdClient.Info.isLimitAdTrackingEnabled() तरीके का इस्तेमाल करें, ताकि यह पक्का किया जा सके कि आप उपयोगकर्ताओं की इच्छाओं को दरकिनार नहीं कर रहे हैं. Google Play Developer Program की कॉन्टेंट से जुड़ी नीति में यह बताया गया है:

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

विज्ञापन आईडी का इस्तेमाल करने वाले एसडीके से जुड़ी निजता या सुरक्षा नीतियों के बारे में जानें. उदाहरण के लिए, अगर Google Analytics SDK टूल से true को enableAdvertisingIdCollection() तरीके में पास किया जाता है, तो पक्का करें कि Analytics SDK टूल की सभी लागू होने वाली नीतियों की समीक्षा की गई हो और उनका पालन किया गया हो.

यह भी ध्यान रखें कि Google Play डेवलपर कॉन्टेंट से जुड़ी नीति के मुताबिक, यह ज़रूरी है कि विज्ञापन आईडी "व्यक्तिगत पहचान से जुड़ी जानकारी से कनेक्ट न हो या किसी भी डिवाइस का खास आइडेंटिफ़ायर (उदाहरण के लिए: SSAID, MAC पता, IMEI वगैरह) से न जुड़ा हो."

उदाहरण के लिए, मान लें कि आपको डेटाबेस टेबल में जानकारी इकट्ठा करनी है. इसके लिए, आपको इन कॉलम की ज़रूरत होगी:

इस उदाहरण में, दोनों टेबल में मौजूद account_id कॉलम के ज़रिए ad_id कॉलम को पीआईआई से जोड़ा जा सकता है. अगर आपने उपयोगकर्ताओं से साफ़ तौर पर अनुमति नहीं ली है, तो यह Google Play डेवलपर कॉन्टेंट से जुड़ी नीति का उल्लंघन होगा.

ध्यान रखें कि विज्ञापन देने वाले के आईडी और व्यक्तिगत पहचान से जुड़ी जानकारी के बीच लिंक हमेशा इस तरह से साफ़ तौर पर नहीं दिखते. ऐसा हो सकता है कि "क्वासी-आइडेंटिफ़ायर" दोनों में दिखें. जैसे, व्यक्तिगत पहचान से जुड़ी जानकारी (पीआईआई) और विज्ञापन आईडी के हिसाब से कुंजी वाली टेबल. इससे भी समस्याएं होती हैं. उदाहरण के लिए, मान लें कि हम TABLE-01 और TABLE-02 में इस तरह बदलाव करते हैं:

इस मामले में, क्लिक इवेंट के बहुत कम होने पर भी, विज्ञापन देने वाले का आईडी TABLE-01 और TABLE-02 में मौजूद व्यक्तिगत पहचान से जुड़ी जानकारी को जोड़ा जा सकता है. इसके लिए, इवेंट के टाइमस्‍टैंप और डिवाइस मॉडल का इस्तेमाल किया जाता है.

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

अन्य समाधानों में ये शामिल हैं:

• ऐसी टेबल डिज़ाइन न करना जिनमें व्यक्तिगत पहचान से जुड़ी जानकारी को विज्ञापन आईडी से साफ़ तौर पर लिंक किया गया हो. ऊपर दिए गए पहले उदाहरण में, इसका मतलब है कि TABLE-01 में account_id कॉलम को शामिल नहीं किया जाएगा.

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

  1. विज्ञापन देने वाले व्यक्ति या कंपनी के आईडी से जुड़े डेटा और निजी पहचान से जुड़ी जानकारी (पीआईआई) के लिए, ऐक्सेस कंट्रोल लिस्ट (एसीएल) को अलग-अलग रखें. इससे, उन लोगों या भूमिकाओं की संख्या कम हो जाएगी जो दोनों एसीएल में शामिल हैं.
  2. ऐक्सेस लॉगिंग और ऑडिटिंग लागू करें, ताकि इस नियम के किसी भी अपवाद का पता लगाया जा सके और उसे मैनेज किया जा सके.

विज्ञापन आईडी का ज़िम्मेदारी से इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, AdvertisingIdClient एपीआई का संदर्भ देखें.

एफ़आईडी और GUID के साथ काम करना

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

इस वजह से, डिवाइस के स्कोप वाले ऐसे हार्डवेयर आईडी की तुलना में, FIDs बेहतर निजता प्रॉपर्टी देते हैं जिन्हें रीसेट नहीं किया जा सकता. ज़्यादा जानकारी के लिए, firebase.installations एपीआई का संदर्भ देखें.

अगर किसी मामले में FID का इस्तेमाल नहीं किया जा सकता, तो ऐप्लिकेशन के किसी इंस्टेंस की खास तौर पर पहचान करने के लिए, कस्टम ग्लोबल यूनीक आईडी (जीयूआईडी) का भी इस्तेमाल किया जा सकता है. इसके लिए, सबसे आसान तरीका यह है कि आप इस कोड का इस्तेमाल करके, अपना GUID जनरेट करें:

var uniqueID = UUID.randomUUID().toString()

String uniqueID = UUID.randomUUID().toString();

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

एमएसी पतों के साथ काम नहीं करता

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

Android 11 में, एमएसी पते की उपलब्धता में बदलाव

Android 11 और इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन पर, Passpoint नेटवर्क के लिए MAC रैंडमाइज़ेशन, हर Passpoint प्रोफ़ाइल के हिसाब से होता है. इससे, यहां दिए गए फ़ील्ड के आधार पर एक यूनीक MAC पता जनरेट होता है:

• पूरी तरह क्वालिफ़ाइड डोमेन नेम (एफ़क्यूडीएन)
• Realm
• क्रेडेंशियल, Passpoint प्रोफ़ाइल में इस्तेमाल किए गए क्रेडेंशियल पर आधारित होता है:
  • उपयोगकर्ता क्रेडेंशियल: उपयोगकर्ता का नाम
  • सर्टिफ़िकेट क्रेडेंशियल: सर्टिफ़िकेट और सर्टिफ़िकेट का टाइप
  • सिम क्रेडेंशियल: EAP टाइप और IMSI

इसके अलावा, बिना खास अधिकारों वाले ऐप्लिकेशन, डिवाइस के एमएसी पते को ऐक्सेस नहीं कर सकते. सिर्फ़ आईपी पते वाले नेटवर्क इंटरफ़ेस दिखते हैं. इससे getifaddrs() और NetworkInterface.getHardwareAddress() तरीकों के साथ-साथ, RTM_GETLINK Netlink मैसेज भेजने पर भी असर पड़ता है.

यहां बताया गया है कि इस बदलाव से ऐप्लिकेशन पर किस तरह असर पड़ता है:

• NetworkInterface.getHardwareAddress() हर इंटरफ़ेस के लिए null दिखाता है.
• ऐप्लिकेशन, NETLINK_ROUTE सॉकेट पर bind() फ़ंक्शन का इस्तेमाल नहीं कर सकते.
• ip कमांड, इंटरफ़ेस के बारे में जानकारी नहीं देती है.
• ऐप्लिकेशन, RTM_GETLINK मैसेज नहीं भेज सकते.

ध्यान दें कि ज़्यादातर डेवलपर को ConnectivityManager के हायर-लेवल एपीआई का इस्तेमाल करना चाहिए. इसके बजाय, उन्हें NetworkInterface, getifaddrs() या Netlink सॉकेट जैसे लोअर-लेवल एपीआई का इस्तेमाल नहीं करना चाहिए. उदाहरण के लिए, किसी ऐप्लिकेशन को मौजूदा रास्तों के बारे में अप-टू-डेट जानकारी चाहिए. इसके लिए, वह ConnectivityManager.registerNetworkCallback() का इस्तेमाल करके नेटवर्क में होने वाले बदलावों को सुन सकता है. साथ ही, नेटवर्क से जुड़े LinkProperties.getRoutes() को कॉल करके यह जानकारी पा सकता है.

आइडेंटिफ़ायर की विशेषताएं

Android OS, कई तरह के आईडी उपलब्ध कराता है. इनमें अलग-अलग तरह की विशेषताएं होती हैं. आपको कौनसे आईडी का इस्तेमाल करना चाहिए, यह इस बात पर निर्भर करता है कि आपके इस्तेमाल के उदाहरण के हिसाब से, यहां दी गई विशेषताएं कैसे काम करती हैं. इन विशेषताओं से निजता पर भी असर पड़ता है. हालांकि, यह समझना ज़रूरी है कि ये विशेषताएं एक-दूसरे के साथ कैसे इंटरैक्ट करती हैं.

दायरा

आइडेंटिफ़ायर के स्कोप से पता चलता है कि कौनसे सिस्टम आइडेंटिफ़ायर को ऐक्सेस कर सकते हैं. Android आइडेंटिफ़ायर का स्कोप आम तौर पर तीन तरह का होता है:

• सिंगल ऐप्लिकेशन: यह आईडी, ऐप्लिकेशन के लिए इंटरनल होता है और इसे अन्य ऐप्लिकेशन ऐक्सेस नहीं कर सकते.
• ऐप्लिकेशन का ग्रुप: आईडी को पहले से तय किए गए, मिलते-जुलते ऐप्लिकेशन के ग्रुप से ऐक्सेस किया जा सकता है.
• डिवाइस: इस आईडी को डिवाइस पर इंस्टॉल किए गए सभी ऐप्लिकेशन ऐक्सेस कर सकते हैं.

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

रीसेट करने की सुविधा और डेटा को बनाए रखना

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

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

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

खासियत

यूनीकनेस से यह पता चलता है कि टकराव की कितनी संभावना है. इसका मतलब है कि एक जैसे आइडेंटिफ़ायर, उससे जुड़े स्कोप में मौजूद हैं. सबसे ऊंचे लेवल पर, ग्लोबल यूनीक आइडेंटिफ़ायर कभी भी टकराता नहीं है. भले ही, यह अन्य डिवाइसों या ऐप्लिकेशन पर हो. इसके अलावा, यूनीक होने का लेवल, आइडेंटिफ़ायर की एंट्रॉपी और इसे बनाने के लिए इस्तेमाल किए गए रैंडमनेस के सोर्स पर निर्भर करता है. उदाहरण के लिए, इंस्टॉल करने की तारीख के हिसाब से बनाए गए रैंडम आइडेंटिफ़ायर (जैसे, 2019-03-01) के लिए, टकराव की संभावना, इंस्टॉल करने के Unix टाइमस्टैंप के हिसाब से बनाए गए आइडेंटिफ़ायर (जैसे, 1551414181) की तुलना में बहुत ज़्यादा होती है.

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

अपने-आप पूरी सुरक्षा देने की सुविधा और जवाबदेही

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

इस्तेमाल के सामान्य उदाहरण और इस्तेमाल करने के लिए सही आइडेंटिफ़ायर

इस सेक्शन में, हार्डवेयर आईडी (जैसे, IMEI) का इस्तेमाल करने के विकल्पों के बारे में बताया गया है. हार्डवेयर आईडी का इस्तेमाल करने का सुझाव नहीं दिया जाता, क्योंकि उपयोगकर्ता इन्हें रीसेट नहीं कर सकता. साथ ही, ये डिवाइस के स्कोप में होते हैं. कई मामलों में, ऐप्लिकेशन के स्कोप वाला आइडेंटिफ़ायर काफ़ी होता है.

खाते

मोबाइल और इंटरनेट सेवा देने वाली कंपनी का स्टेटस

इस मामले में, आपका ऐप्लिकेशन, मोबाइल और इंटरनेट सेवा देने वाली कंपनी के खाते का इस्तेमाल करके, डिवाइस के फ़ोन और मैसेज भेजने की सुविधा के साथ इंटरैक्ट करता है.

इस्तेमाल करने के लिए सुझाया गया आइडेंटिफ़ायर: IMEI, IMSI, और Line1

यह सुझाव क्यों दिया गया है?

अगर कैरियर से जुड़ी सुविधाओं के लिए हार्डवेयर आइडेंटिफ़ायर का इस्तेमाल करना ज़रूरी है, तो ऐसा किया जा सकता है. उदाहरण के लिए, इन आइडेंटिफ़ायर का इस्तेमाल करके, मोबाइल और इंटरनेट सेवा देने वाली कंपनियों या सिम स्लॉट के बीच स्विच किया जा सकता है. इसके अलावा, इनका इस्तेमाल आईपी पर एसएमएस मैसेज (Line1 के लिए) डिलीवर करने के लिए भी किया जा सकता है. ये मैसेज, सिम पर आधारित उपयोगकर्ता खातों के लिए होते हैं. हालांकि, कम सुविधाओं वाले ऐप्लिकेशन के लिए हमारा सुझाव है कि उपयोगकर्ता के डिवाइस की जानकारी को सर्वर-साइड पर वापस पाने के लिए, खाते में साइन इन करने की सुविधा का इस्तेमाल करें. इसकी एक वजह यह है कि Android 6.0 (एपीआई लेवल 23) और इसके बाद के वर्शन में, इन आइडेंटिफ़ायर का इस्तेमाल सिर्फ़ रनटाइम की अनुमति के ज़रिए किया जा सकता है. ऐसा हो सकता है कि उपयोगकर्ता इस अनुमति को बंद कर दें. इसलिए, आपके ऐप्लिकेशन को इन अपवादों को आसानी से हैंडल करना चाहिए.

मोबाइल सदस्यता की स्थिति

इस मामले में, आपको ऐप्लिकेशन की सुविधाओं को डिवाइस पर मौजूद मोबाइल सेवा की कुछ सदस्यताओं से जोड़ना होगा. उदाहरण के लिए, आपको SIM कार्ड के ज़रिए डिवाइस की मोबाइल सदस्यता के आधार पर, प्रीमियम ऐप्लिकेशन की कुछ सुविधाओं के ऐक्सेस की पुष्टि करने की ज़रूरत पड़ सकती है.

इस्तेमाल करने के लिए सुझाया गया आइडेंटिफ़ायर: डिवाइस पर इस्तेमाल किए गए सिम की पहचान करने के लिए, Subscription ID API का इस्तेमाल करें.

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

यह सुझाव क्यों दिया गया है?

फ़िलहाल, कुछ ऐप्लिकेशन इस मकसद के लिए ICCID का इस्तेमाल कर सकते हैं. आईसीसी आईडी दुनिया भर में यूनीक होता है और इसे रीसेट नहीं किया जा सकता. इसलिए, Android 10 से, READ_PRIVILEGED_PHONE_STATEअनुमति वाले ऐप्लिकेशन के लिए ही इसे ऐक्सेस करने की सुविधा उपलब्ध है. Android 11 से, Android ने getIccId() एपीआई के ज़रिए ICCID के ऐक्सेस को और सीमित कर दिया है. इससे कोई फ़र्क़ नहीं पड़ता कि ऐप्लिकेशन का टारगेट एपीआई लेवल क्या है. जिन ऐप्लिकेशन पर इसका असर पड़ा है उन्हें सदस्यता आईडी का इस्तेमाल करने के लिए माइग्रेट करना चाहिए.

सिंगल साइन-ऑन

इस मामले में, आपका ऐप्लिकेशन सिंगल साइन-ऑन की सुविधा देता है. इससे उपयोगकर्ता, किसी मौजूदा खाते को आपके संगठन से जोड़ सकते हैं.

इस्तेमाल करने के लिए सुझाया गया आइडेंटिफ़ायर: खाता मैनेजर के साथ काम करने वाले खाते, जैसे कि Google खाते को किसी दूसरे खाते से लिंक करने की सुविधा

यह सुझाव क्यों दिया गया है?

Google खाते को लिंक करने की सुविधा की मदद से, उपयोगकर्ता अपने मौजूदा Google खाते को आपके ऐप्लिकेशन से जोड़ सकते हैं. इससे उन्हें आपके संगठन के प्रॉडक्ट और सेवाओं को आसानी से और ज़्यादा सुरक्षित तरीके से ऐक्सेस करने की सुविधा मिलती है. इसके अलावा, सिर्फ़ ज़रूरी डेटा शेयर करने के लिए, OAuth के कस्टम स्कोप तय किए जा सकते हैं. इससे उपयोगकर्ताओं का भरोसा बढ़ता है, क्योंकि उन्हें साफ़ तौर पर यह पता चलता है कि उनके डेटा का इस्तेमाल कैसे किया जाता है.

विज्ञापन

टारगेटिंग (विज्ञापन के लिए सही ऑडियंस चुनना)

इस मामले में, आपका ऐप्लिकेशन किसी उपयोगकर्ता की दिलचस्पी के हिसाब से प्रोफ़ाइल बनाता है, ताकि उसे ज़्यादा काम के विज्ञापन दिखाए जा सकें.

इस्तेमाल करने के लिए सुझाया गया आइडेंटिफ़ायर: अगर आपका ऐप्लिकेशन, विज्ञापनों के लिए किसी आईडी का इस्तेमाल करता है और उसे Google Play पर अपलोड या पब्लिश करता है, तो वह आईडी विज्ञापन आईडी होना चाहिए.

यह सुझाव क्यों दिया गया है?

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

अगर आपका ऐप्लिकेशन, विज्ञापन दिखाने के मकसद से उपयोगकर्ता का डेटा इकट्ठा और इस्तेमाल करता है, तो आपको Play Console में ऐप्लिकेशन कॉन्टेंट पेज के डेटा की सुरक्षा वाले सेक्शन में, विज्ञापन दिखाने के मकसद के बारे में बताना होगा. भले ही, आपका ऐप्लिकेशन उपयोगकर्ता का डेटा शेयर करता हो या नहीं.

आकलन

इस मामले में, आपका ऐप्लिकेशन एक ही डिवाइस पर आपके संगठन के सभी ऐप्लिकेशन में उपयोगकर्ता के व्यवहार के आधार पर उसकी प्रोफ़ाइल बनाता है.

इस्तेमाल करने के लिए सुझाया गया आइडेंटिफ़ायर: विज्ञापन आईडी या Play Install Referrer API

यह सुझाव क्यों दिया गया है?

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

कन्वर्ज़न

इस मामले में, कन्वर्ज़न ट्रैक किए जा रहे हैं, ताकि यह पता लगाया जा सके कि आपकी मार्केटिंग रणनीति सफल है या नहीं.

इस्तेमाल करने के लिए सुझाया गया आइडेंटिफ़ायर: विज्ञापन आईडी या Play Install Referrer API

यह सुझाव क्यों दिया गया है?

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

रीमार्केटिंग करना

इस मामले में, आपका ऐप्लिकेशन किसी व्यक्ति की पिछली दिलचस्पी के आधार पर विज्ञापन दिखाता है.

इस्तेमाल करने के लिए सुझाया गया आइडेंटिफ़ायर: विज्ञापन आईडी

यह सुझाव क्यों दिया गया है?

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

ऐप्लिकेशन के आंकड़े

इस मामले में, आपका ऐप्लिकेशन किसी उपयोगकर्ता के व्यवहार का आकलन करता है, ताकि आपको इन बातों का पता चल सके:

• आपके संगठन के अन्य प्रॉडक्ट या ऐप्लिकेशन में से कौनसे प्रॉडक्ट या ऐप्लिकेशन, उपयोगकर्ता के लिए सही हो सकते हैं.
• उपयोगकर्ताओं को अपने ऐप्लिकेशन का इस्तेमाल करने के लिए कैसे प्रेरित करें.
• साइन आउट किए गए या पहचान छिपाने वाले उपयोगकर्ताओं के लिए, इस्तेमाल के आंकड़े और विश्लेषण मेज़र करें.

समस्या हल करने के लिए ये तरीके अपनाए जा सकते हैं:

• ऐप्लिकेशन सेट आईडी: ऐप्लिकेशन सेट आईडी की मदद से, आपके संगठन के मालिकाना हक वाले कई ऐप्लिकेशन पर उपयोगकर्ता के व्यवहार का विश्लेषण किया जा सकता है. हालांकि, इसके लिए आपको विज्ञापन दिखाने के मकसद से उपयोगकर्ता के डेटा का इस्तेमाल नहीं करना होगा. अगर आपको Google Play services की सुविधा वाले डिवाइसों को टारगेट करना है, तो हमारा सुझाव है कि ऐप्लिकेशन सेट आईडी का इस्तेमाल करें.
• Firebase ID (FID): FID, उस ऐप्लिकेशन के स्कोप में होता है जो इसे बनाता है. इससे आइडेंटिफ़ायर का इस्तेमाल, अलग-अलग ऐप्लिकेशन पर उपयोगकर्ताओं को ट्रैक करने के लिए नहीं किया जा सकता. इसे आसानी से रीसेट भी किया जा सकता है, क्योंकि उपयोगकर्ता ऐप्लिकेशन का डेटा मिटा सकता है या ऐप्लिकेशन को फिर से इंस्टॉल कर सकता है. एफआईडी बनाने की प्रोसेस आसान है. इसके बारे में जानने के लिए, Firebase इंस्टॉलेशन गाइड देखें.

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

क्रैश रिपोर्ट

इस मामले में, आपका ऐप्लिकेशन यह डेटा इकट्ठा करता है कि किसी व्यक्ति के डिवाइसों पर ऐप्लिकेशन कब और क्यों क्रैश होता है.

इस्तेमाल करने के लिए सुझाया गया आइडेंटिफ़ायर: FID या ऐप्लिकेशन सेट आईडी

यह सुझाव क्यों दिया गया है?

FID को उस ऐप्लिकेशन के स्कोप में रखा जाता है जो इसे बनाता है. इससे आइडेंटिफ़ायर का इस्तेमाल, अलग-अलग ऐप्लिकेशन पर उपयोगकर्ताओं को ट्रैक करने के लिए नहीं किया जा सकता. इसे आसानी से रीसेट भी किया जा सकता है, क्योंकि उपयोगकर्ता ऐप्लिकेशन का डेटा मिटा सकता है या ऐप्लिकेशन को फिर से इंस्टॉल कर सकता है. FID बनाने की प्रोसेस आसान है. इसके बारे में जानने के लिए, Firebase इंस्टॉलेशन गाइड देखें. ऐप्लिकेशन सेट आईडी की मदद से, आपके संगठन के मालिकाना हक वाले कई ऐप्लिकेशन पर उपयोगकर्ता के व्यवहार का विश्लेषण किया जा सकता है. हालांकि, इसके लिए यह ज़रूरी है कि विज्ञापन दिखाने के मकसद से उपयोगकर्ता के डेटा का इस्तेमाल न किया जाए.

परफ़ॉर्मेंस की रिपोर्टिंग

इस मामले में, आपका ऐप्लिकेशन परफ़ॉर्मेंस मेट्रिक इकट्ठा करता है. जैसे, लोड होने में लगने वाला समय और बैटरी खर्च. इससे आपके ऐप्लिकेशन की क्वालिटी को बेहतर बनाने में मदद मिलती है.

इस्तेमाल करने के लिए सुझाया गया आइडेंटिफ़ायर: Firebase Performance Monitoring

यह सुझाव क्यों दिया गया है?

Firebase Performance Monitoring की मदद से, उन मेट्रिक पर फ़ोकस किया जा सकता है जो आपके लिए सबसे ज़्यादा मायने रखती हैं. साथ ही, अपने ऐप्लिकेशन में हाल ही में हुए बदलाव के असर को टेस्ट किया जा सकता है.

ऐप्लिकेशन की टेस्टिंग

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

इस्तेमाल करने के लिए सुझाया गया आइडेंटिफ़ायर: FID या ऐप्लिकेशन सेट आईडी

यह सुझाव क्यों दिया गया है?

FID को उस ऐप्लिकेशन के स्कोप में रखा जाता है जो इसे बनाता है. इससे आइडेंटिफ़ायर का इस्तेमाल, अलग-अलग ऐप्लिकेशन पर उपयोगकर्ताओं को ट्रैक करने के लिए नहीं किया जा सकता. इसे आसानी से रीसेट भी किया जा सकता है, क्योंकि उपयोगकर्ता ऐप्लिकेशन का डेटा मिटा सकता है या ऐप्लिकेशन को फिर से इंस्टॉल कर सकता है. FID बनाने की प्रोसेस आसान है. इसके बारे में जानने के लिए, Firebase इंस्टॉलेशन गाइड देखें. ऐप्लिकेशन सेट आईडी की मदद से, आपके संगठन के मालिकाना हक वाले कई ऐप्लिकेशन पर उपयोगकर्ता के व्यवहार का विश्लेषण किया जा सकता है. हालांकि, इसके लिए यह ज़रूरी है कि विज्ञापन दिखाने के मकसद से उपयोगकर्ता के डेटा का इस्तेमाल न किया जाए.

क्रॉस-डिवाइस इंस्टॉलेशन

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

इस्तेमाल करने के लिए सुझाया गया आइडेंटिफ़ायर: FID या GUID

यह सुझाव क्यों दिया गया है?

एफ़आईडी को खास तौर पर इसी मकसद के लिए बनाया गया है. इसका दायरा सिर्फ़ ऐप्लिकेशन तक सीमित होता है, ताकि इसका इस्तेमाल अलग-अलग ऐप्लिकेशन पर उपयोगकर्ताओं को ट्रैक करने के लिए न किया जा सके. साथ ही, ऐप्लिकेशन को फिर से इंस्टॉल करने पर यह रीसेट हो जाता है. अगर कुछ मामलों में FID काफ़ी नहीं है, तो GUID का इस्तेमाल भी किया जा सकता है.

सुरक्षा

गलत इस्तेमाल का पता लगाना

इस मामले में, आपको ऐसे कई फ़र्ज़ी डिवाइसों का पता लगाना है जो आपकी बैकएंड सेवाओं पर हमला कर रहे हैं.

इस्तेमाल करने के लिए सुझाया गया आइडेंटिफ़ायर: Google Play Integrity API का इंटिग्रिटी टोकन

यह सुझाव क्यों दिया गया है?

यह पुष्टि करने के लिए कि अनुरोध किसी असल Android डिवाइस से किया गया है, न कि किसी एम्युलेटर या किसी ऐसे कोड से जो किसी दूसरे डिवाइस को स्पूफ़ कर रहा है, Google Play Integrity API का इस्तेमाल करें.

विज्ञापन से होने वाली धोखाधड़ी

इस मामले में, आपका ऐप्लिकेशन यह जांच करता है कि आपके ऐप्लिकेशन में उपयोगकर्ता के इंप्रेशन और कार्रवाइयां असली हैं और उनकी पुष्टि की जा सकती है.

इस्तेमाल करने के लिए सुझाया गया आइडेंटिफ़ायर: विज्ञापन आईडी

यह सुझाव क्यों दिया गया है?

विज्ञापन दिखाने के लिए, विज्ञापन आईडी का इस्तेमाल करना ज़रूरी है. ऐसा Google Play Developer Content Policy के मुताबिक है. इसकी वजह यह है कि उपयोगकर्ता इसे रीसेट कर सकता है.

डिजिटल राइट मैनेजमेंट (डीआरएम)

इस मामले में, आपका ऐप्लिकेशन बौद्धिक संपत्ति या पैसे चुकाकर खरीदे गए कॉन्टेंट को धोखाधड़ी से ऐक्सेस करने से रोकना चाहता है.

इस्तेमाल करने के लिए सुझाया गया आइडेंटिफ़ायर: FID या GUID का इस्तेमाल करने पर, उपयोगकर्ता को कॉन्टेंट की सीमाओं को दरकिनार करने के लिए ऐप्लिकेशन को फिर से इंस्टॉल करना पड़ता है. यह एक मुश्किल काम है, इसलिए ज़्यादातर लोग ऐसा नहीं करते. अगर यह सुरक्षा काफ़ी नहीं है, तो Android एक DRM API उपलब्ध कराता है. इसका इस्तेमाल, कॉन्टेंट के ऐक्सेस को सीमित करने के लिए किया जा सकता है. इसमें हर APK के लिए एक आइडेंटिफ़ायर शामिल होता है, जिसे Widevine ID कहते हैं.

उपयोगकर्ता प्राथमिकताएं

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

इस्तेमाल करने के लिए सुझाया गया आइडेंटिफ़ायर: FID या GUID

यह सुझाव क्यों दिया गया है?

ऐप्लिकेशन को फिर से इंस्टॉल करने पर भी जानकारी को सेव रखने का सुझाव नहीं दिया जाता. ऐसा इसलिए, क्योंकि उपयोगकर्ता ऐप्लिकेशन को फिर से इंस्टॉल करके अपनी प्राथमिकताओं को रीसेट करना चाहें.