Android SDK जाँचें—ऐप की अनुमति तीसरे पक्ष की सहमति नहीं है
Android SDK के डेटा संग्रह की जाँच क्रम से करें: रिलीज़ निर्भरताओं की सूची बनाएँ, मर्ज किए गए मैनिफेस्ट और आरंभिक कोड का स्थिर विश्लेषण करें, साफ इंस्टॉल पर नेटवर्क यातायात दर्ज करें, सहमति से पहले और बाद का अंतर देखें और परिणाम को Data Safety घोषणा से मिलाएँ। Google Play की SDK अपेक्षाएँ कहती हैं कि विकासकर्ता को SDK का डेटा संग्रह अपना संग्रह मानना चाहिए और उसका आरंभ उपयोगकर्ता की सहमति घटना के अनुरूप नियंत्रित करना चाहिए।
इसलिए Android की रनटाइम अनुमति को तीसरे पक्ष के लिए सहमति न मानें। अनुमति किसी संरक्षित संसाधन तक ऐप की तकनीकी पहुँच नियंत्रित करती है; किसी विज्ञापन या विश्लेषण प्रदाता को कौन-सा डेटा, किस उद्देश्य से भेजा जाएगा, यह अलग निर्णय है। लेखापरीक्षा का उपयोगी परिणाम हर SDK के लिए डेटा प्रकार, उद्देश्य, पहली सक्रियता, गंतव्य, सहमति अवस्था और संग्रह बंद करने का तरीका दर्ज करने वाली तालिका है।
1. रिलीज़ पैकेज की पूरी SDK सूची बनाएँ
केवल सीधे जोड़ी गई निर्भरताएँ पर्याप्त नहीं हैं। Gradle की निर्भरता रिपोर्ट में संक्रमणीय लाइब्रेरी, संस्करण सूची, स्थानीय AAR फ़ाइलें, प्लगइन से आए घटक और बड़े SDK के सहायक मॉड्यूल खोजें। जाँच रिलीज़ विन्यास पर करें, क्योंकि विकास और रिलीज़ बिल्ड में निर्भरताएँ तथा मान अलग हो सकते हैं।
हर प्रविष्टि में SDK और संस्करण, उसे जोड़ने वाला मॉड्यूल, व्यावसायिक उद्देश्य तथा अपेक्षित डेटा व्यवहार लिखें। डेटा को स्थान, संपर्क, उपयोगकर्ता या डिवाइस पहचानकर्ता, ऐप गतिविधि, निदान और क्रैश विवरण जैसी श्रेणियों में बाँटें। प्राप्तकर्ता को अपने सर्वर, सेवा प्रदाता या स्वतंत्र तीसरे पक्ष के रूप में चिह्नित करें।
प्रदाता की घोषणा को शुरुआती संकेत मानें, प्रमाण नहीं। आपके विन्यास, सक्षम सुविधाओं और SDK संस्करण से व्यवहार बदल सकता है। किसी ऐसे SDK का उद्देश्य स्पष्ट न हो तो नेटवर्क परीक्षण से पहले ही तय करें कि उसे रखना आवश्यक है या हटाया जा सकता है।
2. मर्ज किया गया मैनिफेस्ट और आरंभिक कोड देखें
स्रोत मैनिफेस्ट के बजाय रिलीज़ बिल्ड का मर्ज किया गया AndroidManifest जाँचें। SDK स्थान, विज्ञापन पहचानकर्ता, नेटवर्क स्थिति, ब्लूटूथ या पैकेज दृश्यता से जुड़ी अनुमति के साथ ContentProvider, Service या Receiver जोड़ सकता है। विशेष रूप से देखें कि कोई प्रदाता Application कक्षा के सामान्य आरंभ से पहले SDK को स्वतः सक्रिय तो नहीं कर रहा।
इसके बाद SDK आरंभ करने, पहचानकर्ता तय करने, स्थान सौंपने, विज्ञापन निजीकरण चालू करने और विश्लेषण घटनाएँ भेजने वाले कॉल खोजें। संसाधनों तथा विन्यास फ़ाइलों में संग्रह रोकने वाले विकल्प देखें और रिलीज़ मान सत्यापित करें। अनुमति न मिलने से कुछ पहुँच रुक सकती है, लेकिन नेटवर्क अनुरोध, ऐप गतिविधि, डिवाइस गुण या SDK से बना पहचानकर्ता संवेदनशील रनटाइम अनुमति के बिना भी भेजा जा सकता है।
स्थिर जाँच केवल क्षमता दिखाती है। कोड में किसी API या अनुमति की मौजूदगी यह नहीं बताती कि डेटा वास्तव में कब भेजा गया। हर संभावित पहुँच के सामने वह परीक्षण घटना लिखें जिससे उसे गतिशील रूप से सत्यापित किया जा सके।
3. mitmproxy से सहमति की हर अवस्था जाँचें
नियंत्रित एमुलेटर या अपने परीक्षण उपकरण, अलग खाते और कृत्रिम व्यक्तिगत डेटा का उपयोग करें। डिबग बिल्ड का HTTP और HTTPS यातायात mitmproxy से दर्ज करें तथा हर क्रम से पहले ऐप डेटा मिटाएँ। OWASP का नेटवर्क गोपनीयता परीक्षण भी अलग कार्यप्रवाहों में संवेदनशील इनपुट देकर यातायात दर्ज करने और मिले व्यक्तिगत डेटा को बाज़ार घोषणा तथा गोपनीयता नीति से मिलाने का क्रम देता है।
- साफ इंस्टॉल खोलें और किसी अनुमति या सहमति पर प्रतिक्रिया देने से पहले अनुरोध दर्ज करें।
- अनुमति और वैकल्पिक सहमति अस्वीकार करके ऐप दोबारा खोलें।
- केवल सुविधा के लिए आवश्यक Android अनुमति दें, पर तीसरे पक्ष का वैकल्पिक संग्रह अस्वीकार रखें।
- सहमति देने के तुरंत बाद, संबंधित सुविधा चलाते समय और ऐप पृष्ठभूमि में जाने पर यातायात देखें।
- सहमति वापस लेकर ऐप बंद करें, फिर खोलें और जाँचें कि अनुरोध या पुराने पहचानकर्ता लौटते तो नहीं हैं।
हर अनुरोध के लिए समय, होस्ट, पथ, भेजी गई कुंजियाँ, पहचानकर्ता, उसे शुरू करने वाली घटना और उस समय की सहमति अवस्था दर्ज करें। रिपोर्ट में वास्तविक टोकन या व्यक्तिगत मान न रखें; उन्हें संपादित या हैश करें। किसी अपरिचित डोमेन का स्वामी केवल नाम से तय न करें—DNS, प्रमाणपत्र, SDK दस्तावेज और अनुरोध की सामग्री को साथ देखकर संबंध स्थापित करें।
यदि कुछ HTTPS कनेक्शन दिखाई नहीं देते, तो परीक्षण उपकरण पर प्रॉक्सी प्रमाणपत्र का भरोसा और प्रमाणपत्र पिनिंग जाँचें। पिनिंग को केवल अपने ऐप के पृथक, अधिकृत और डिबग-विशिष्ट परीक्षण में बाइपास करें; उत्पादन विन्यास को कमजोर करना लेखापरीक्षा का हिस्सा नहीं है।
4. वैकल्पिक SDK को सहमति के बाद आरंभ करें
यदि वैकल्पिक संग्रह ऐप खुलते ही शुरू हो जाता है, तो बाद में दिखाया गया संवाद पहले भेजे जा चुके डेटा को वैध नहीं बनाता। मैनिफेस्ट प्रदाता, स्टार्टअप इनिशियलाइज़र या Application कक्षा से होने वाला स्वतः आरंभ बंद करें। SDK का इंस्टेंस तभी बनाएँ जब उपयोगकर्ता को डेटा प्रकार, उद्देश्य और तीसरे पक्ष से साझाकरण बताया जा चुका हो और उसने उसी विकल्प को स्वीकार किया हो।
सहमति को कम से कम अनिर्धारित, स्वीकृत, अस्वीकृत और वापस ली गई अवस्थाओं में संभालें। अनिर्धारित या अस्वीकृत अवस्था में SDK आरंभ न हो, घटनाएँ बाद में भेजने के लिए कतार में न लगें और वैकल्पिक पहचानकर्ता न बने। सहमति वापस लेने पर संग्रह रोकने के साथ स्थानीय पहचानकर्ता मिटाने तथा प्रदाता की विलोपन सुविधा बुलाने की जरूरत भी जाँचें।
जरूरी ऐप सुविधा और तीसरे पक्ष के वैकल्पिक उपयोग को एक स्विच में न बाँधें। उदाहरण के लिए, मानचित्र पर वर्तमान स्थिति दिखाने की Android अनुमति एक निर्णय है; वही निर्देशांक विज्ञापन प्रदाता को भेजना अलग उद्देश्य और अलग प्राप्तकर्ता है। अस्वीकार करने वाले उपयोगकर्ता के लिए SDK-विहीन या कम डेटा वाला विकल्प उपलब्ध हो तो उसे अलग परीक्षण कार्यप्रवाह बनाएँ।
5. Data Safety मिलान को रिलीज़ शर्त बनाएँ
Google Play की Data Safety आवश्यकताओं में तीसरे पक्ष की लाइब्रेरी और SDK द्वारा संभाला गया डेटा भी ऐप की घोषणा में शामिल है, और पूर्ण तथा सही विवरण की जिम्मेदारी विकासकर्ता की है। इसलिए SDK प्रदाता की तैयार जानकारी को अपने प्रपत्र में बिना वास्तविक विन्यास और यातायात से मिलाए न उतारें।
लेखापरीक्षा तालिका की हर देखी गई कुंजी को Data Safety की डेटा श्रेणी, उद्देश्य, संग्रह और साझाकरण वर्ग से जोड़ें। फिर जाँचें कि ऐप के भीतर दी गई सूचना, गोपनीयता नीति, Play Console प्रपत्र और नेटवर्क अभिलेख एक ही व्यवहार बताते हैं। अंतर मिलने पर घोषणा बदलना तभी पर्याप्त है जब संग्रह जरूरी और उचित हो; अनावश्यक संग्रह को विन्यास से बंद करें या SDK हटाएँ।
- रिलीज़ SDK सूची और मर्ज किया गया मैनिफेस्ट समीक्षा किए गए हैं।
- साफ इंस्टॉल, अस्वीकृति, स्वीकृति, सहमति वापसी और पुनः आरंभ के अभिलेख मौजूद हैं।
- हर बाहरी गंतव्य का स्वामी, डेटा प्रकार, उद्देश्य और सक्रिय करने वाली घटना पहचानी गई है।
- अनिर्धारित या अस्वीकृत अवस्था में वैकल्पिक संग्रह नहीं होता।
- वास्तविक यातायात, उपयोगकर्ता को दी गई सूचना, गोपनीयता नीति और Data Safety घोषणा परस्पर मेल खाते हैं।
यह भी पढ़ें:
हमारे न्यूज़लेटर की सदस्यता लें
Web3, AI और क्रिप्टो की नवीनतम खबरें सीधे अपने इनबॉक्स में पाएँ।