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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TABLE-01
timestamp ad_id account_id clickid
TABLE-02
account_id name dob country

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

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

TABLE-01
timestamp ad_id clickid dev_model
TABLE-02
timestamp demo account_id dev_model name

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

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

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

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

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

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

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

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

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

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

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

Kotlin

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

Java

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

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

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

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

Android 11 में मैक पते की उपलब्धता में हुए बदलाव

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

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

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

इस बदलाव से ऐप्लिकेशन पर होने वाले असर की सूची यहां दी गई है:

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

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

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

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

दायरा

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

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

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

रीसेट करने की सुविधा और स्थायी होना

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

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

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

यूनीकनेस

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

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

पूरी सुरक्षा देने की सुविधा और नॉन-रेप्यूडिएबिलिटी

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

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

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

खाते

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

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

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

यह सुझाव क्यों?

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

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

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

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

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

यह सुझाव क्यों?

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

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

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

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

यह सुझाव क्यों?

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

विज्ञापन

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

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

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

यह सुझाव क्यों?

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

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

आकलन

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

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

यह सुझाव क्यों?

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

कन्वर्ज़न

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

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

यह सुझाव क्यों?

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

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

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

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

यह सुझाव क्यों?

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

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

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

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

समस्या को हल करने के संभावित तरीके:

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

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

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

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

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

यह सुझाव क्यों?

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

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

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

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

यह सुझाव क्यों?

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

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

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

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

यह सुझाव क्यों?

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

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

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

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

यह सुझाव क्यों?

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

सुरक्षा

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

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

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

यह सुझाव क्यों?

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

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

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

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

यह सुझाव क्यों?

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

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

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

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

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

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

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

यह सुझाव क्यों?

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