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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

इस उदाहरण में, ad_id कॉलम को दोनों टेबल में मौजूद account_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 एपीआई का संदर्भ देखें.

FID और GUID के साथ काम करना

किसी डिवाइस पर चल रहे ऐप्लिकेशन इंस्टेंस की पहचान करने का सबसे आसान तरीका, 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, उस ऐप्लिकेशन तक ही सीमित होता है जो इसे बनाता है. इससे, आइडेंटिफ़ायर का इस्तेमाल करके उपयोगकर्ताओं को अलग-अलग ऐप्लिकेशन पर ट्रैक नहीं किया जा सकता. इसे आसानी से रीसेट भी किया जा सकता है. इसके लिए, उपयोगकर्ता को ऐप्लिकेशन का डेटा मिटाना होगा या ऐप्लिकेशन को फिर से इंस्टॉल करना होगा. एफ़आईडी बनाने की प्रोसेस आसान है. इसके लिए, Firebase इंस्टॉलेशन गाइड देखें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

सुरक्षा

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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