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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

विज्ञापन आईडी के इस्तेमाल से जुड़े, निजता या सुरक्षा से जुड़ी नीतियों के बारे में जानें. ये नीतियां, आपके इस्तेमाल किए गए एसडीके से जुड़ी हो सकती हैं. उदाहरण के लिए, अगर 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 एपीआई रेफ़रंस देखें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• NetworkInterface.getHardwareAddress() हर इंटरफ़ेस के लिए शून्य दिखाता है.
• ऐप्लिकेशन, 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, IMSI, और Line1

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

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

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

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

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

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

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

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

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

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

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

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

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

विज्ञापन

सही दर्शकों को टारगेट करना

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

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

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

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

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

आकलन

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

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

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

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

कन्वर्ज़न

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

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

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

यह विज्ञापन से जुड़ा इस्तेमाल का उदाहरण है. इसके लिए, ऐसे आईडी की ज़रूरत पड़ सकती है जो आपकी कंपनी के अलग-अलग ऐप्लिकेशन में उपलब्ध हो. इसलिए, विज्ञापन आईडी का इस्तेमाल करना सबसे सही तरीका है. 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

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

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