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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ध्यान रखें कि विज्ञापन देने वाले का आईडी और व्यक्तिगत पहचान से जुड़ी जानकारी के बीच के लिंक हमेशा इतने ��ाफ़ नहीं होते. ऐसा हो सकता है कि "कुछ हद तक आइडेंटिफ़ायर", PII और Ad ID कीवर्ड वाली टेबल, दोनों में दिखें. इससे भी समस्याएं आती हैं. उदाहरण के लिए, मान लें कि हम 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 इंस्टॉलेशन आईडी (एफ़आईडी) का इस्तेमाल करना है. विज्ञापनों के अलावा, ज़्यादातर इस्तेमाल के उदाहरणों में, यही तरीका अपनाने का सुझाव दिया जाता है. सिर्फ़ वह ऐप्लिकेशन इंस्टेंस इस आइडेंटिफ़ायर को ऐक्सेस कर सकता है जिसके लिए इसे प्रोविज़न किया गया था. साथ ही, इसे आसानी से रीसेट किया जा सकता है, क्योंकि यह सिर्फ़ तब तक मौजूद रहता है, जब तक ऐप्लिकेशन इंस्टॉल होता है.

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

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

Kotlin

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

Java

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

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

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

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

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

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

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

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

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

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

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

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

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

दायरा

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

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

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

रीसेट करने की सुविधा और डेटा सेव होना

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

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

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

यूनीक होने की वजह

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

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

पूरी सुरक्षा देने की सुविधा और अस्वीकार न किए जाने की सुविधा

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

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

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

खाते

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

विज्ञापन

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

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

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

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

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

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

आकलन

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

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

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

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

कन्वर्ज़न

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

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

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

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

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

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

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

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

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

ऐप एनालिटिक्स

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अलग-अलग डिवाइसों पर इंस्टॉल करना

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

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

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

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

सुरक्षा

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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