Google Play जल्द ही डेवलपर्स को एपीके के बजाय ऐप बंडल अपलोड करने के लिए मजबूर करेगा, जिससे आवश्यकता के बारे में असुविधाजनक सुरक्षा प्रश्न खड़े हो जाएंगे।
गत नवंबर, गूगल ने की घोषणा डेवलपर्स को एपीके के बजाय एंड्रॉइड ऐप बंडल (एएबी) प्रारूप का उपयोग करके प्ले स्टोर पर नए ऐप प्रकाशित करने की आवश्यकता होगी। अभी कुछ ही दिन पहले, Google ने डेवलपर्स को इस आगामी आवश्यकता की याद दिलाई, जिससे विवाद का तूफ़ान खड़ा हो गया उन उपयोगकर्ताओं से जो मानते हैं कि Google एपीके को ख़त्म कर रहा है, साइडलोडिंग को ख़त्म कर रहा है, तीसरे पक्ष के ऐप स्टोर में बाधा डाल रहा है, और क्या नहीं.
यह सच है कि एंड्रॉइड ऐप बंडल उस क्लासिक एपीके प्रारूप से बहुत बड़ा विचलन है जिसका उपयोग आप एक उपयोगकर्ता और डेवलपर दोनों के रूप में कर सकते हैं। हालाँकि ऐप बंडलों का उपयोग करने के कई फायदे हैं, लेकिन उन्हें बनाने का एक महत्वपूर्ण पहलू है जिससे कुछ डेवलपर्स और सुरक्षा विशेषज्ञ चिंतित हैं।
इस लेख में, हम एंड्रॉइड ऐप बंडलों पर स्विच करने के बारे में देखी गई आलोचनाओं के साथ-साथ कुछ प्रस्तावित समाधानों को भी कवर करेंगे, और हम इन समस्याओं के लिए Google के प्रस्तावित समाधान के बारे में भी बात करेंगे।
पृष्ठभूमि
हालाँकि ऐसा होने से पहले, हमें इस बारे में थोड़ी बात करने की ज़रूरत है कि सामान्य तौर पर एंड्रॉइड पर ऐप वितरण कैसे काम करता है। यदि आप पहले से ही जानते हैं कि ऐप साइनिंग और ऐप बंडल कैसे काम करते हैं, तो आप इस भाग को छोड़ सकते हैं।
आपके पास ऐसे APK
अधिकांश भाग के लिए, एंड्रॉइड पर ऐप्स एपीके फ़ाइलों के अंदर वितरित किए जाते हैं। एपीके में ऐप के सभी कोड और संसाधन शामिल होते हैं, साथ ही साइनिंग मेनिफेस्ट जैसी कुछ सुरक्षा सुविधाएं भी होती हैं। जब कोई एपीके इंस्टॉल किया जाता है, तो इसे मूल रूप से एक विशिष्ट फ़ोल्डर में कॉपी किया जाता है और इंस्टॉल किए गए ऐप्स के आंतरिक डेटाबेस में जोड़ा जाता है।
हस्ताक्षर
इंस्टालेशन के दौरान, यह सुनिश्चित करने के लिए कि ऐप वैध है, उस ऐप के हस्ताक्षर को भी सत्यापित किया जाता है। यदि ऐप पहले से इंस्टॉल है, तो एंड्रॉइड पहले से इंस्टॉल किए गए ऐप के विरुद्ध नए ऐप के हस्ताक्षर की जांच करता है। यदि हस्ताक्षर मान्य नहीं है या मेल नहीं खाता है, तो एंड्रॉइड ऐप इंस्टॉल करने से इंकार कर देगा।
एंड्रॉइड में हस्ताक्षर जांच सुरक्षा का एक महत्वपूर्ण हिस्सा है। यह सुनिश्चित करता है कि आप जो ऐप इंस्टॉल कर रहे हैं वह वैध है और कम से कम उसी स्रोत से है जिसे आपने पहले ही इंस्टॉल किया है। उदाहरण के लिए, यदि आप इंस्टॉल करते हैं, तो कहें, प्ले स्टोर से मेरा लॉकस्क्रीन विजेट ऐप, आप यथोचित रूप से आश्वस्त हो सकते हैं कि मैंने ही इस पर हस्ताक्षर किए हैं और यह प्रामाणिक है। यदि आप किसी संदिग्ध तृतीय-पक्ष साइट से लॉकस्क्रीन विजेट के लिए अपडेट इंस्टॉल करने का प्रयास करते हैं और यह विफल हो जाता है, तो आपको पता चल जाएगा कि किसी ने संभवतः मैलवेयर जोड़ने के लिए उस एपीके के साथ छेड़छाड़ की है।
किसी ऐप पर हस्ताक्षर करने के लिए उपयोग की जाने वाली कुंजी है (आदर्श रूप से) कभी नहीं सार्वजनिक रूप से जारी किया गया। इसे निजी कुंजी के रूप में जाना जाता है. फिर निजी कुंजी का उपयोग ऐप के हस्ताक्षर में दिखाई गई कुंजी को उत्पन्न करने के लिए किया जाता है, जिसे सार्वजनिक कुंजी के रूप में जाना जाता है। किसी ऐप की वैधता को सत्यापित करने के लिए एंड्रॉइड और ऐप स्टोर इसका उपयोग करते हैं। मैं इस बारे में नहीं बताऊंगा कि निजी कुंजी को उजागर किए बिना आप वास्तव में सार्वजनिक कुंजी कैसे उत्पन्न कर सकते हैं, क्योंकि इसमें बहुत सारे एन्क्रिप्शन गणित शामिल हैं। यदि आप अधिक विवरण चाहते हैं, तो देखें एपीके पर हस्ताक्षर करने पर Google का दस्तावेज़ या एकतरफ़ा गणित फ़ंक्शंस पर कुछ शोध करें।
ऐप हस्ताक्षरों की एक अन्य विशेषता केवल मिलान वाले हस्ताक्षर वाले ऐप्स तक ही अनुमतियों को प्रतिबंधित करने की क्षमता है। एंड्रॉइड कई कार्यों के लिए आंतरिक रूप से ऐसा करता है, जहां केवल फ्रेमवर्क के समान कुंजी से हस्ताक्षरित ऐप्स ही कुछ सुविधाओं तक पहुंच सकते हैं।
ऐप बंडल
तो अब जब हमने एपीके और हस्ताक्षरों का एक त्वरित अवलोकन दे दिया है, तो आइए ऐप बंडलों के बारे में बात करें। यहीं पर एपीके संसाधन आते हैं। संसाधन लेआउट, चित्र, ऑडियो आदि जैसी चीज़ें हैं। मूलतः, वे ऐसी कोई भी चीज़ हैं जो कोड नहीं है। विभिन्न डिस्प्ले कॉन्फ़िगरेशन और विभिन्न भाषाओं का बेहतर समर्थन करने के लिए, डेवलपर्स एक ही संसाधन के कई संस्करण बना सकते हैं जिनका उपयोग डिवाइस और भाषा के आधार पर किया जाता है।
लेकिन एपीके में, वे सभी संसाधन मौजूद हैं, इससे कोई फर्क नहीं पड़ता कि आप किसका उपयोग करते हैं। और वे जगह घेर लेते हैं. आपके ऐप की जटिलता के आधार पर, कई उपकरणों के लिए बहुत सारे अप्रयुक्त संसाधन हो सकते हैं। ऐप बंडल इसी को हल करने के लिए बनाए गए हैं। डेवलपर्स एपीके की तरह ही एक ऐप बंडल तैयार कर सकते हैं, और उस ऐप बंडल को एपीके की तरह ही प्ले स्टोर पर अपलोड किया जा सकता है।
इसके बाद Google अलग-अलग डिवाइस कॉन्फ़िगरेशन के लिए अलग-अलग APK का एक पूरा समूह तैयार करने के लिए उस ऐप बंडल का उपयोग करता है। प्रत्येक ऐप बंडल में केवल उस कॉन्फ़िगरेशन के लिए आवश्यक संसाधन होते हैं। जब कोई उपयोगकर्ता उस ऐप को डाउनलोड करने जाता है, तो उन्हें जेनरेट किया गया एपीके दिया जाता है जो उनके कॉन्फ़िगरेशन से मेल खाता है। इससे ऐप डाउनलोड और इंस्टॉल आकार दोनों को कम करने, बैंडविड्थ और स्टोरेज स्पेस बचाने में मदद मिलती है।
बेशक, आपके डिवाइस के लिए विशिष्ट एपीके इंस्टॉल करने का मतलब है कि आपके लिए इसे किसी अन्य डिवाइस पर कॉपी करना और बिना किसी समस्या के इंस्टॉल करना कठिन है। आपके दृष्टिकोण के आधार पर, यह अच्छी या बुरी चीज़ हो सकती है। एक ओर, यह पायरेसी को और अधिक कठिन बना देता है, क्योंकि उपयोगकर्ताओं के पास अब संपूर्ण ऐप नहीं है। दूसरी ओर, यह इसी कारण से वैध रूप से ऐप्स को संग्रहीत करना अधिक कठिन बना देता है।
ऐप साइनिंग
चूंकि एंड्रॉइड ऐप बंडल एपीके नहीं हैं, आप केवल एएबी फ़ाइल नहीं खोल सकते हैं और इसे सीधे डिवाइस पर इंस्टॉल नहीं कर सकते हैं। जब आप किसी को Play Store पर अपलोड करते हैं, तो Google अलग-अलग (अहस्ताक्षरित) APK फ़ाइलें बनाने के लिए बंडल का उपयोग करता है। इंस्टॉल करने से पहले उन एपीके पर हस्ताक्षर करना होगा।
डेवलपर को उन जेनरेट किए गए एपीके पर हस्ताक्षर करने और पुनः अपलोड करने के लिए कहने के बजाय, Google स्वयं हस्ताक्षर करने का प्रबंधन करता है। प्ले स्टोर या तो अपने द्वारा बनाई गई नई कुंजी का उपयोग करता है या डेवलपर से वह कुंजी मांगता है जिसका उपयोग वे हस्ताक्षर करने के लिए करते हैं APK. किसी भी विकल्प के साथ, Google डेवलपर के लिए सार्वजनिक हस्ताक्षर को संभालता है और एक अपलोड प्रदान करता है चाबी। Google आंतरिक सत्यापन के लिए अपलोड कुंजी का उपयोग करता है और सुनिश्चित करता है कि डेवलपर जो ऐप बंडल (या कुछ मामलों में एपीके) अपलोड कर रहा है वह सही है।
यदि अपलोड कुंजी से छेड़छाड़ की जाती है या खो जाती है, तो डेवलपर्स एक नई कुंजी का अनुरोध कर सकते हैं, और ऐप को वितरित करने के लिए उपयोग की जाने वाली हस्ताक्षर कुंजी अपरिवर्तित रहती है।
ऐप साइनिंग में और भी बहुत कुछ है, लेकिन इस लेख के लिए यही प्रासंगिक है। यदि आप चाहें तो ऐप बंडल और ऐप साइनिंग के बारे में अधिक पढ़ सकते हैं वोजटेक कालिसिंस्की का यह मध्यम लेख.
आलोचना
सिद्धांत और व्यवहार में, ऐप बंडल बहुत बढ़िया हैं। वे उपयोगकर्ता को कुछ भी किए बिना, डेटा उपयोग और इंस्टॉल आकार को कम करते हैं। लेकिन इसे कैसे लागू किया गया है, इसके कारण पिछले कुछ महीनों में कुछ डेवलपर्स और सुरक्षा शोधकर्ताओं ने चिंता जताई है। इससे पहले कि मैं इन चिंताओं को संक्षेप में बताऊँ, मैं यह कहने के लिए कुछ समय लेना चाहता हूँ कि नीचे जो कुछ भी लिखा गया है वह सीधे तौर पर लिखा गया है लेखों की एक श्रृंखला पर आधारित डेवलपर मार्क मर्फी द्वारा कॉमन्सवेयर। आपको उसके लेखों को अवश्य देखना चाहिए, क्योंकि वे एक डेवलपर के दृष्टिकोण से अधिक विवरण और आलोचनाएँ प्रदान करते हैं।
सुरक्षा
क्लासिक वितरण मॉडल में, एक डेवलपर एपीके पर हस्ताक्षर करने के लिए उपयोग की जाने वाली कुंजी को निजी रखता है। इसे कभी भी जनता के साथ साझा नहीं किया जाता है और केवल अधिकृत लोगों को ही इस तक पहुंच होनी चाहिए। यह सुनिश्चित करता है कि केवल वही लोग वैध एपीके उत्पन्न कर सकते हैं।
लेकिन यदि आप Play Store पर ऐप बंडल का उपयोग करते हैं, तो Google वह कुंजी प्रबंधित करता है जो उपयोगकर्ताओं को प्राप्त APKs पर हस्ताक्षर करती है। गलती करना Google Play पर अपलोड किए गए नए ऐप्स के लिए व्यवहार अगस्त 2021 से शुरू Google को अपनी स्वयं की वितरण कुंजी बनानी है जिसे वह डेवलपर से निजी रखता है।
डेवलपर्स सबमिट कर रहे हैं नए ऐप्स डिफ़ॉल्ट रूप से Google उनके लिए उनकी निजी कुंजी प्रबंधित करेगा, हालांकि डेवलपर्स अपडेट सबमिट कर रहे हैं मौजूदा ऐप्स APK का उपयोग जारी रख सकते हैं या वे Google द्वारा नए उपयोगकर्ताओं के लिए उपयोग हेतु एक नई कुंजी उत्पन्न करके AAB वितरण पर स्विच कर सकते हैं। मौजूदा ऐप्स आवश्यक नहीं हैं एपीके वितरण से एंड्रॉइड ऐप बंडलों पर स्विच करने के लिए, हालांकि यह विकल्प उनके लिए उपलब्ध है, उन्हें चुनना चाहिए। कुछ धक्का-मुक्की के बाद, Google इसे संभव भी बनाएगा नए और मौजूदा दोनों ऐप्स के लिए Google पर साइन इन करने के लिए अपनी निजी कुंजी अपलोड करें। इनमें से कोई भी स्थिति आदर्श नहीं है, चाहे कुछ भी हो, यदि आप चाहें तो Google के पास आपकी निजी कुंजी तक पहुंच होगी एंड्रॉइड ऐप बंडल का उपयोग करें (और डेवलपर्स के पास इस मामले में कोई विकल्प नहीं है कि वे अगस्त के बाद एक नया ऐप सबमिट करना चाहते हैं 2021!)
हालाँकि हमें विश्वास है कि Google सुरक्षा को बहुत गंभीरता से लेता है, लेकिन पृथ्वी पर ऐसी कोई भी कंपनी नहीं है जो डेटा उल्लंघनों से सुरक्षित हो। यदि वितरण के लिए आपके ऐप पर हस्ताक्षर करने के लिए Google जिस कुंजी का उपयोग करता है, वह उन उल्लंघनों में से एक है, तो कोई भी आपके ऐप के संस्करण पर हस्ताक्षर कर सकता है और ऐसा दिखा सकता है जैसे यह आपके द्वारा हस्ताक्षरित था। और कुछ डेवलपर्स और सुरक्षा विशेषज्ञ इस संभावना से खुश नहीं हैं। हां, यह बहुत ही कम संभावना है, लेकिन यह तथ्य कि यह एक संभावना है, इन्फोसेक समुदाय में कुछ लोगों को डराता है।
डेवलपर्स द्वारा एंड्रॉइड एपीके पर हस्ताक्षर करने का मतलब है कि कोई भी Google Play से एपीके को सत्यापित कर सकता है, अंध विश्वास की आवश्यकता नहीं है। यह एक सुंदर डिज़ाइन है जो सत्यापन योग्य सुरक्षा प्रदान करता है। ऐप बंडल इसे सिर पर रख देते हैं, और वेंडर लॉक-इन को बढ़ावा देने के लिए संरचित प्रतीत होते हैं। ऐसे कई वैकल्पिक तकनीकी दृष्टिकोण हैं जो डेवलपर्स द्वारा अभी भी हस्ताक्षरित छोटे एपीके प्रदान करेंगे, लेकिन ये प्ले को प्राथमिकता नहीं देंगे। उदाहरण के लिए, सभी एपीके वेरिएंट तैयार किए जा सकते हैं और डेवलपर द्वारा हस्ताक्षरित किए जा सकते हैं, फिर किसी भी ऐप स्टोर पर अपलोड किए जा सकते हैं।
इस बारे में निश्चित रूप से तर्क दिए जाने चाहिए कि क्या निजी कुंजी का सुरक्षित भंडारण Google या व्यक्तिगत डेवलपर्स के हाथों में छोड़ना बेहतर है। लेकिन वे डेवलपर्स (शायद) आमतौर पर अपनी चाबियों के लिए केंद्रीय भंडार का उपयोग नहीं कर रहे हैं। डेवलपर्स को प्ले ऐप साइनिंग का उपयोग करने के लिए मजबूर करके, एक दुर्भावनापूर्ण हमलावर को हजारों या लाखों चाबियाँ प्राप्त करने के लिए केवल एक बार Google की सुरक्षा में सेंध लगाने की आवश्यकता होती है।
इसके लायक क्या है, यहां बताया गया है कि Google अपने बुनियादी ढांचे पर आपकी हस्ताक्षर कुंजी की सुरक्षा कैसे करता है:
[ब्लॉककोट लेखक = "वोजटेक कालिसिंस्की, एंड्रॉइड डेवलपर एडवोकेट एट गूगल"]जब आप प्ले ऐप साइनिंग का उपयोग करते हैं, तो आपकी चाबियाँ उसी बुनियादी ढांचे पर संग्रहीत होती हैं जिसका उपयोग Google अपनी चाबियाँ संग्रहीत करने के लिए करता है।
सभी परिचालनों के लिए मुख्य पहुंच सख्त एसीएल और छेड़छाड़-स्पष्ट ऑडिट ट्रेल्स द्वारा नियंत्रित होती है।
डेवलपर की कुंजी के साथ उत्पन्न और हस्ताक्षरित सभी कलाकृतियाँ आपको निरीक्षण/सत्यापन के लिए Google Play कंसोल में उपलब्ध कराई जाती हैं।
इसके अलावा, कुंजी हानि को रोकने के लिए, हम अपने प्राथमिक भंडारण का बहुत बार बैकअप बनाते हैं। ये बैकअप दृढ़ता से एन्क्रिप्टेड हैं और हम नियमित रूप से इन बैकअप से पुनर्स्थापित करने का परीक्षण करते हैं।
यदि आप Google के तकनीकी बुनियादी ढांचे के बारे में जानना चाहते हैं, तो पढ़ें Google क्लाउड सुरक्षा श्वेतपत्र.[/ब्लॉककोट]
इतनी बढ़िया कि सभी ध्वनियाँ, हानि और चोरी अभी भी संभव हैं। और ऑडिट ट्रेल्स केवल भविष्य के हमलों को रोकने में मदद करते हैं; उन्हें टूटी हुई चाबियाँ वापस नहीं मिलेंगी।
अनधिकृत संशोधनों की संभावना
Google ने जिस तरह से ऐप बंडल स्थापित किया है, उसमें एक बड़ा मुद्दा किसी ऐप में अनधिकृत संशोधनों को जोड़े जाने की संभावना है। ऐप बंडल से एपीके निकालने की प्रक्रिया में स्वाभाविक रूप से संशोधन शामिल होते हैं, क्योंकि Google को प्रत्येक एपीके को मैन्युअल रूप से बनाना होता है। जबकि Google ने वादा किया है कि वह कोड को इंजेक्ट या संशोधित नहीं करेगा और न ही करेगा, ऐप बंडल प्रक्रिया के साथ समस्या यह है कि इसमें ऐसा करने की शक्ति है।
यहां कुछ उदाहरण दिए गए हैं कि Google जैसी स्थिति वाली कंपनी क्या करने की क्षमता रखती है:
मान लीजिए कि एक सुरक्षित मैसेजिंग ऐप है जिसका उपयोग लोग सरकारी निगरानी के जोखिम के बिना संचार करने के लिए करते हैं। यह उन लोगों के लिए एक अविश्वसनीय रूप से उपयोगी उपकरण हो सकता है जो सत्तावादी सरकार का विरोध कर रहे हैं, या यहां तक कि उन लोगों के लिए भी जो सिर्फ अपनी गोपनीयता बनाए रखना चाहते हैं। वह सरकार, यह देखने की क्षमता चाहती है कि ऐप उपयोगकर्ता क्या कह रहे हैं, वह Google को ऐप के कोड में एक निगरानी बैकडोर जोड़ने के लिए मजबूर करने का प्रयास कर सकती है।
यह उदाहरण थोड़ा अधिक हानिरहित है, लेकिन यह कुछ ऐसा भी है जो कुछ लोगों को चिंतित करता है। मान लीजिए कि एक ऐप है जिसे प्रतिदिन लाखों डाउनलोड मिलते हैं, लेकिन इसमें कोई विज्ञापन या विश्लेषण नहीं है। यह एक बहुत बड़ा डेटा स्रोत है और उस डेटा तक पहुंचने का कोई तरीका नहीं है। Google, एक विज्ञापन कंपनी होने के नाते, शायद उस डेटा तक पहुँचना चाहेगा।
ऐप वितरण के क्लासिक एपीके मॉडल में, Google हस्ताक्षर बदले बिना ऐप्स को संशोधित नहीं कर सकता है। यदि Google हस्ताक्षर बदलता है, विशेष रूप से किसी लोकप्रिय ऐप पर, तो लोग नोटिस करेंगे क्योंकि अपडेट इंस्टॉल नहीं होगा। लेकिन ऐप बंडल और ऐप साइनिंग के साथ, Google ऐप्स को वितरित करने से पहले चुपचाप अपना कोड इंजेक्ट कर सकता है। हस्ताक्षर नहीं बदलेगा क्योंकि Google के पास हस्ताक्षर कुंजी होगी।
स्पष्ट होना, इन उदाहरणों के घटित होने की अविश्वसनीय रूप से संभावना नहीं है. Google सरलता से काम करता है परेशानी वाले बाज़ारों से पूरी तरह बाहर निकलें, अनुकूलन के बजाय। लेकिन यद्यपि यह असंभावित है, फिर भी यह संभव है। सिर्फ इसलिए कि कोई कंपनी वादा करती है कि कुछ नहीं होगा, वह इसकी गारंटी नहीं देती।
कोड पारदर्शिता
Google ने इन चिंताओं को सुनते हुए, इस सप्ताह एक नया फीचर पेश किया जिसका नाम है ऐप बंडलों के लिए कोड पारदर्शिता. कोड पारदर्शिता एक डेवलपर को अनिवार्य रूप से दूसरा हस्ताक्षर बनाने की अनुमति देती है जो उपयोगकर्ताओं को ऐप के साथ भेजा जाता है। यह अतिरिक्त हस्ताक्षर एक अलग निजी कुंजी से बनाया जाना चाहिए जिस तक केवल डेवलपर की पहुंच हो। हालाँकि, इस पद्धति की कुछ सीमाएँ हैं।
कोड पारदर्शिता केवल कोड को कवर करती है। नाम को देखते हुए यह स्पष्ट प्रतीत हो सकता है, लेकिन इसका अर्थ यह भी है कि यह उपयोगकर्ताओं को संसाधनों, मेनिफेस्ट, या किसी अन्य चीज़ को सत्यापित नहीं करने देता है जो DEX फ़ाइल या मूल लाइब्रेरी नहीं है। जबकि गैर-कोड फ़ाइलों में दुर्भावनापूर्ण संशोधनों का आमतौर पर बहुत कम प्रभाव होता है, फिर भी यह ऐप की सुरक्षा में एक छेद है।
कोड पारदर्शिता के साथ एक और मुद्दा यह है कि इसमें कोई अंतर्निहित सत्यापन नहीं है। एक के लिए, यह एक वैकल्पिक सुविधा है, इसलिए डेवलपर्स को अपने द्वारा अपलोड किए जाने वाले प्रत्येक नए एपीके के लिए इसे शामिल करना याद रखना होगा। फिलहाल, इसे कमांड लाइन से और एक संस्करण के साथ किया जाना है bundletool यह एंड्रॉइड स्टूडियो के साथ नहीं आता है। यहां तक कि जब कोई डेवलपर इसे शामिल करता है, तब भी एंड्रॉइड के पास यह जांचने के लिए किसी प्रकार का सत्यापन अंतर्निहित नहीं होता है कि कोड पारदर्शिता मेनिफ़ेस्ट ऐप में कोड से मेल खाता है या नहीं।
यह अंतिम उपयोगकर्ता पर निर्भर है कि वह डेवलपर द्वारा प्रदान की जा सकने वाली सार्वजनिक कुंजी के साथ मैनिफ़ेस्ट की तुलना करके या सत्यापन के लिए डेवलपर को एपीके भेजकर स्वयं की जांच कर सके।
जबकि कोड पारदर्शिता यह पुष्टि करने की अनुमति देती है कि किसी ऐप में कोई भी कोड संशोधित नहीं किया गया है, इसमें ऐप के अन्य हिस्सों के लिए किसी भी प्रकार का सत्यापन शामिल नहीं है। इस प्रक्रिया में कोई अंतर्निहित विश्वास भी नहीं है। आप यह तर्क दे सकते हैं कि यदि आपको Google पर भरोसा नहीं है, तो संभवतः आप स्वतंत्र रूप से सत्यापन करने के कार्य के लिए तैयार हैं, लेकिन आपको ऐसा क्यों करना चाहिए?
कोड पारदर्शिता सुविधा के साथ अन्य मुद्दे भी हैं बताया मार्क मर्फी द्वारा कॉमन्सवेयर. मैं फीचर के अधिक गहन विश्लेषण के लिए उनके लेख को पढ़ने की सलाह देता हूं।
डेवलपर सुविधा और विकल्प
कुछ डेवलपर्स द्वारा ऐप बंडलों को लेकर समस्या उठाने का तीसरा (और इस लेख के लिए अंतिम) कारण कम सुविधा और विकल्प है।
यदि कोई डेवलपर Google द्वारा ऐप बंडल की आवश्यकता शुरू करने के बाद प्ले स्टोर पर एक नया ऐप बनाता है और वे चुनते हैं Google को हस्ताक्षर कुंजी प्रबंधित करने देने का डिफ़ॉल्ट विकल्प, उनके पास कभी भी उस हस्ताक्षर तक पहुंच नहीं होगी चाबी। यदि वही डेवलपर उस ऐप को किसी अन्य ऐप स्टोर पर वितरित करना चाहता है, तो उन्हें अपनी कुंजी का उपयोग करना होगा, जो Google से मेल नहीं खाएगी।
इसका मतलब है कि उपयोगकर्ताओं को या तो Google Play से या तीसरे पक्ष के स्रोतों से इंस्टॉल और अपडेट करना होगा। यदि वे स्रोत बदलना चाहते हैं, तो उन्हें ऐप को पूरी तरह से अनइंस्टॉल करना होगा, संभावित रूप से डेटा खोना होगा और पुनः इंस्टॉल करना होगा। एपीके एग्रीगेटर्स को पसंद है एपीकेमिरर फिर उसे एक ही ऐप के लिए कई आधिकारिक हस्ताक्षरों से भी निपटना होगा। (तकनीकी रूप से, उन्हें पहले से ही ऐसा करना होगा क्योंकि ऐप साइनिंग आपको नए उपयोगकर्ताओं के लिए एक नई, अधिक सुरक्षित कुंजी बनाने की सुविधा देता है, लेकिन यह उनके और अन्य साइटों के लिए और भी बुरा होगा जब हर कोई है करने के लिए।)
इस मुद्दे पर Google की प्रतिक्रिया अपलोड किए गए बंडल से परिणामी एपीके डाउनलोड करने के लिए प्ले कंसोल में ऐप बंडल एक्सप्लोरर या आर्टिफैक्ट एक्सप्लोरर का उपयोग करना है। कोड पारदर्शिता की तरह, यह पूर्ण समाधान नहीं है। प्ले कंसोल से डाउनलोड किए गए एपीके को अलग-अलग डिवाइस प्रोफाइल के लिए विभाजित किया जाएगा। जबकि प्ले कंसोल एक ऐप के एक संस्करण के लिए एकाधिक एपीके अपलोड करने का समर्थन करता है, कई अन्य वितरण चैनल ऐसा नहीं करते हैं।
इस प्रकार, जब डेवलपर्स कई स्टोर प्रबंधित कर रहे होते हैं, तो ऐप बंडलों का उपयोग करने के बहुत सारे लाभ समाप्त हो जाते हैं, जिससे वितरण अधिक कठिन हो जाता है। उस खबर के साथ विंडोज़ 11 है एंड्रॉइड ऐप समर्थन प्राप्त करना अमेज़ॅन ऐपस्टोर को धन्यवाद, कुछ लोगों का मानना है कि ऐप बंडल आवश्यकता डेवलपर्स को अमेज़ॅन पर वितरण करने से हतोत्साहित करेगी। बेशक, Google की प्राथमिक चिंता अपने स्वयं के ऐप स्टोर को लेकर है, लेकिन वास्तव में यही है उन्हें प्रतिस्पर्धियों के साथ गर्म पानी में डाल दिया उन्हें बनाने के लिए अग्रणी छोटे, समाधानकारी परिवर्तन एंड्रॉइड पर थर्ड-पार्टी ऐप स्टोर कैसे काम करते हैं।
कई स्टोरों से संबंधित कुछ मुद्दे ऐप इंटरकनेक्टिविटी और रैपिड-फायर टेस्टिंग हैं।
आइए ऐप इंटरकनेक्टिविटी से शुरुआत करें। क्या आपने कभी कोई ऐसा ऐप डाउनलोड किया है जो पेवॉल के पीछे सुविधाओं को लॉक कर देता है? लगभग निश्चित रूप से. कुछ डेवलपर सुविधाओं को इन-ऐप खरीदारी के पीछे रखते हैं, लेकिन अन्य एक अलग, सशुल्क ऐप बनाना चुन सकते हैं। जब वह ऐड-ऑन ऐप इंस्टॉल हो जाता है, तो मुख्य ऐप की सुविधाएं अनलॉक हो जाती हैं।
लेकिन किसी को पायरेटेड स्रोत से ऐड-ऑन इंस्टॉल करने से क्या रोकता है? खैर, डेवलपर्स के लिए बहुत सारे विकल्प हैं, लेकिन कम से कम एक में हस्ताक्षर-संरक्षित अनुमतियों का उपयोग करना शामिल है। मान लें कि मुख्य ऐप हस्ताक्षर-संरक्षित अनुमति की घोषणा करता है। ऐड-ऑन ऐप तब घोषणा करता है कि वह उस अनुमति का उपयोग करना चाहता है। आदर्श रूप से, ऐड-ऑन ऐप में कुछ प्रकार की लाइसेंस सत्यापन कार्यक्षमता भी होगी, जो यह सुनिश्चित करने के लिए इंटरनेट से जुड़ती है कि उपयोगकर्ता वैध है।
यदि दोनों ऐप्स के हस्ताक्षर समान हैं, तो एंड्रॉइड ऐड-ऑन ऐप को अनुमति देगा और पायरेसी सुरक्षा जांच पास हो जाएगी। यदि ऐड-ऑन ऐप में सही हस्ताक्षर नहीं है, तो अनुमति नहीं दी जाएगी और सत्यापन विफल हो जाएगा।
क्लासिक एपीके वितरण मॉडल के साथ, उपयोगकर्ता किसी भी वैध स्रोत से कोई भी ऐप प्राप्त कर सकता है और उससे काम चला सकता है। वर्तमान डिफ़ॉल्ट ऐप बंडल मॉडल के साथ, मुख्य और ऐड-ऑन ऐप्स पर हस्ताक्षर मेल नहीं खाएंगे। गूगल हर ऐप के लिए एक यूनिक कुंजी बनाने जा रहा है। डेवलपर हमेशा हस्ताक्षर-संरक्षित अनुमति को हटा सकता है और सीधे हस्ताक्षर हैश सत्यापन का उपयोग कर सकता है, लेकिन यह बहुत कम सुरक्षित है।
और फिर रैपिड-फायर परीक्षण होता है। उपयोगकर्ता डेवलपर्स को उनके ऐप्स में समस्याओं के बारे में हर समय ईमेल करते हैं। कभी-कभी वे समस्याएं सरल समाधान होती हैं: समस्या को पुन: उत्पन्न करना, समस्या का पता लगाना, उसे ठीक करना और एक नया संस्करण अपलोड करना। लेकिन कभी-कभी वे नहीं होते. कभी-कभी डेवलपर किसी समस्या को पुन: उत्पन्न नहीं कर पाते हैं. वे जो समस्या समझते हैं उसे ठीक कर सकते हैं, लेकिन फिर उपयोगकर्ता को इसका परीक्षण करना होगा। अब मान लें कि उपयोगकर्ता ने Google Play के माध्यम से ऐप इंस्टॉल किया है।
एपीके मॉडल के साथ, एक डेवलपर कुछ कोड बदल सकता है, एक नया एपीके बना और हस्ताक्षर कर सकता है, और इसे परीक्षण के लिए उपयोगकर्ता को भेज सकता है। चूंकि परीक्षण एपीके का हस्ताक्षर उपयोगकर्ता द्वारा इंस्टॉल किए गए हस्ताक्षर से मेल खाता है, इसलिए इसे अपडेट करना, परीक्षण करना और वापस रिपोर्ट करना एक सरल प्रक्रिया है। ऐप बंडलों के साथ, यह अलग हो जाता है। चूंकि Google उपयोगकर्ता द्वारा मूल रूप से इंस्टॉल किए गए एपीके पर हस्ताक्षर करता है, इसलिए यह डेवलपर द्वारा भेजे गए एपीके के हस्ताक्षर से मेल नहीं खाएगा। यदि यह ऐप ऐप बंडल की समय सीमा के बाद प्रकाशित होता है, तो डेवलपर के पास Google द्वारा उपयोग की जाने वाली कुंजी तक पहुंच भी नहीं होगी। परीक्षण करने के लिए, उपयोगकर्ता को परीक्षण संस्करण इंस्टॉल करने से पहले वर्तमान ऐप को अनइंस्टॉल करना होगा।
यहां समस्याओं का अंबार है. सबसे पहले, डेवलपर और उपयोगकर्ता दोनों तरफ से असुविधा है। किसी समाधान का परीक्षण करने के लिए ऐप को अनइंस्टॉल करना मज़ेदार नहीं है। और अगर समस्या दूर हो जाए तो क्या होगा? क्या यह डेवलपर द्वारा किए गए परिवर्तन थे, या ऐसा इसलिए था क्योंकि उपयोगकर्ता ने ऐप के डेटा को प्रभावी ढंग से साफ़ कर दिया था? प्ले स्टोर में आंतरिक परीक्षण होता है, जो डेवलपर्स को रैपिड-फायर बिल्ड और वितरण करने देता है, लेकिन इसके लिए उपयोगकर्ता को पहले रिलीज़ संस्करण को अनइंस्टॉल करना होगा। यह वास्तव में कुछ भी ठीक नहीं करता है।
यदि यह सब काल्पनिक बकवास की तरह लगता है, तो यहां एक डेवलपर का एक बहुत ही वास्तविक उदाहरण है, जिसके पास ये समस्याएं होंगी यदि वे Google को उनके लिए एक निजी कुंजी उत्पन्न करने दें: जोआओ डायस। वह ऑटोएप्स सुइट सहित प्लगइन ऐप्स के एक पूरे समूह के साथ-साथ टास्कर का डेवलपर है। नई ऐप बंडल आवश्यकता के साथ, जोआओ का विकास चक्र बहुत पेचीदा हो सकता है, कम से कम नए ऐप्स के लिए। परीक्षण संस्करण सीधे भेजना कम सुविधाजनक होगा। लाइसेंस सत्यापित करना कम प्रभावी होगा.
यह थोड़ा अजीब लग सकता है, लेकिन ऐसा नहीं है कि जोआओ कोई छोटा डेवलपर है, और यह संभव है कि वह अकेला नहीं है। प्ले स्टोर पर ऐसे कई ऐप्स हैं जो अवैध उपयोगकर्ताओं का पता लगाने के लिए हस्ताक्षर सत्यापन पर भरोसा करते हैं।
बेशक, डेवलपर्स के लिए Google पर अपनी स्वयं की हस्ताक्षर कुंजी अपलोड करने के नए विकल्प के साथ, ये समस्याएं कम से कम कुछ हद तक कम हो गई हैं। लेकिन डेवलपर्स को प्रत्येक ऐप के लिए विकल्प सक्षम करने के लिए ऑप्ट-इन करना होगा। यदि वे ऐसा नहीं करते हैं, तो इंटरकनेक्ट विफल हो जाएंगे और रैपिड-फायर समर्थन के लिए Google पर एक बंडल अपलोड करना होगा और उपयोगकर्ता को सही एपीके भेजने से पहले एपीके जेनरेट होने की प्रतीक्षा करनी होगी। साथ ही, इसका अभी भी मतलब है कि उन्हें अपनी निजी कुंजी साझा करनी होगी, जो हमें उन चिंताओं पर वापस लाती है जिन पर हमने पहले चर्चा की थी।
समाधान
यह एक पुराना मुद्दा है क्योंकि ऐप बंडल आवश्यकताओं को महीनों पहले प्रचारित किया गया था, इसलिए अंतरिम में कुछ समाधान प्रस्तावित किए गए हैं।
एक समाधान प्ले ऐप साइनिंग की आवश्यकता से बचना है। एक ऐप बंडल बनाने के बजाय जिसे Google फिर एपीके और संकेतों में संसाधित करता है, वह प्रसंस्करण एंड्रॉइड स्टूडियो द्वारा किया जा सकता है। फिर, डेवलपर्स Google द्वारा जेनरेट किए गए प्रत्येक कॉन्फ़िगरेशन के लिए स्थानीय रूप से हस्ताक्षरित एपीके से भरा ज़िप अपलोड कर सकते हैं।
उस समाधान के साथ, Google को डेवलपर्स की कुंजियों तक पहुंच की बिल्कुल भी आवश्यकता नहीं होगी। यह प्रक्रिया क्लासिक एपीके वितरण मॉडल के समान होगी, लेकिन इसमें केवल एक के बजाय कई, छोटे, एपीके शामिल होंगे।
एक अन्य समाधान यह है कि ऐप बंडलों के उपयोग की आवश्यकता न हो और डेवलपर्स को स्थानीय रूप से हस्ताक्षरित एपीके अपलोड करने की अनुमति जारी रखी जाए। जबकि ऐप बंडल हो सकते हैं कई मामलों में उपयोगकर्ता के लिए बेहतर अनुभव हो सकता है, कुछ ऐप्स को न्यूनतम आकार के साथ प्रति-कॉन्फिगरेशन में विभाजित होने से वास्तव में कोई लाभ नहीं होता है कमी।
यदि Google ने इन दोनों समाधानों को लागू किया, तो जो डेवलपर ऐप बंडल का उपयोग करना चाहता है उसे हाथ नहीं लगाना पड़ेगा Google पर हस्ताक्षर करने से अधिक, और एक डेवलपर जिसके ऐप को प्रारूप से अधिक लाभ नहीं होगा, उसे इसका उपयोग नहीं करना होगा सभी।
Google की प्रतिक्रियाएँ
स्वयं पर हस्ताक्षर
जब उनसे पहली बार डेवलपर्स को ऐप बंडलों के लिए हस्ताक्षर करने की अनुमति देने के बारे में पूछा गया, तो Google की प्रतिक्रिया बहुत ही गैर-प्रतिबद्ध थी:
[ब्लॉककोट लेखक = ""]इसलिए, मैंने अगले साल नए ऐप्स के लिए ऐप बंडलों का उपयोग करने की आवश्यकता के बारे में संक्षेप में बात की, और एक बात जो इसके साथ आती है वह यह है कि विस्तार से हमें प्ले ऐप साइनिंग की आवश्यकता होगी। इसलिए डेवलपर्स को या तो Play पर ऐप साइनिंग कुंजी जेनरेट करनी होगी या Play पर अपनी स्वयं की कुंजी अपलोड करनी होगी... क्योंकि ऐप बंडलों के लिए यह एक शर्त है। हमने डेवलपर्स से सुना है कि उनमें से कुछ ऐसा नहीं करना चाहते हैं। वे नहीं चाहते कि चाबियाँ Play द्वारा प्रबंधित हों। और यदि आप ऐप बंडल का उपयोग करना चाहते हैं तो वर्तमान में यह संभव नहीं है।
लेकिन, हमने वह प्रतिक्रिया सुनी है, और... मैं अभी किसी भी बारे में बात नहीं कर सकता, हमारे पास घोषणा करने के लिए कुछ भी नहीं है, लेकिन हम इस पर विचार कर रहे हैं कि हम इनमें से कुछ चिंताओं को कैसे कम कर सकते हैं। बंडल अपलोड करते समय यह आवश्यक नहीं है कि आपको अपनी कुंजी रखने की अनुमति दी जाए। हम विभिन्न विकल्पों पर विचार कर रहे हैं। अभी हमारे पास घोषणा करने के लिए कोई समाधान नहीं है। लेकिन, हमारे पास अभी भी आवश्यकता पड़ने तक लगभग एक वर्ष का समय है, इसलिए मुझे वास्तव में उम्मीद है कि हमारे पास डेवलपर्स के लिए इसका उत्तर होगा।[/ब्लॉककोट]
वह पिछले साल नवंबर के अंत में था, और ऐसा लगता है कि कुछ भी नहीं हुआ था। अब कुछ ही महीने बचे हैं ऐप बंडल आवश्यकता प्रभावी हो गई है, डेवलपर्स के पास अभी भी अपने स्वयं के ऐप्स पर हस्ताक्षर करने का कोई तरीका नहीं है। जबकि Google ने अब इसे संभव बना दिया है डालना नए और मौजूदा दोनों ऐप्स के लिए आपकी अपनी कुंजी, यह अभी भी हस्ताक्षर करने वाले हिस्से को डेवलपर के हाथों से छीन लेती है।
कोड परिवर्तन
जबकि Google ने विशेष रूप से वादा किया है कि Play Store ऐप कोड को संशोधित नहीं करेगा, वादा कोई गारंटी नहीं है। ऐप बंडल और ऐप साइनिंग के साथ, ऐसी कोई तकनीकी सीमा नहीं है जो Google को वितरण से पहले अपलोड किए गए ऐप्स को संशोधित करने से रोकती हो।
गूगल ने पेश किया है कोड पारदर्शिता एक वैकल्पिक सुविधा के रूप में, और हालांकि यह कुछ हद तक मदद करता है, इसमें समस्याओं का उचित हिस्सा है, जैसा कि हमने पहले चर्चा की थी।
स्व-निर्मित बंडल
जब Google से डेवलपर्स को अपने स्वयं के ऐप "बंडल" (स्प्लिट एपीके वाले ज़िप) बनाने की अनुमति देने के बारे में पूछा गया, तो प्रतिक्रिया मूल रूप से थी "हम ऐसा नहीं करने जा रहे हैं":
संभवतः ऐसा नहीं है जैसा कि प्रश्न में वर्णित है, क्योंकि इससे डेवलपर्स के लिए प्रकाशन प्रक्रिया और भी कठिन हो जाएगी, और हम वास्तव में इसे सरल और सुरक्षित बनाना चाहते हैं। हालाँकि, फिर से, हमने यह प्रतिक्रिया सुनी है, और हम इसे संभव बनाने के विकल्पों पर विचार करेंगे, हालाँकि संभवतः उस तरीके से नहीं जैसा कि यहाँ वर्णित किया गया था।
दिलचस्प बात यह है कि Google का औचित्य यह प्रतीत होता है कि इससे प्रकाशन अधिक जटिल हो जाएगा। हालाँकि, Google अभी भी एंड्रॉइड स्टूडियो में एपीके जेनरेशन डायलॉग के हिस्से के रूप में प्रक्रिया को स्वचालित बना सकता है। इसके अलावा, यदि विचाराधीन ऐप कई स्टोरों पर वितरित किया जा रहा है, तो यह वास्तव में ऐसा करेगा प्रकाशन प्रक्रिया सरल हो गई, क्योंकि डेवलपर्स को एकाधिक हस्ताक्षर कुंजियाँ और शिकायतों का प्रबंधन नहीं करना पड़ेगा उपयोगकर्ता.
और कोड पारदर्शिता की शुरूआत के साथ, ऐसा लगता है कि जटिलता वास्तव में कोई मुद्दा नहीं है। कोड पारदर्शिता के लिए, कम से कम अभी के लिए, डेवलपर को एक कमांड-लाइन टूल का उपयोग करने और उपयोगकर्ताओं को उनके द्वारा परोसे जाने वाले ऐप की वैधता को स्पष्ट रूप से सत्यापित करने की आवश्यकता होती है। यह स्वयं बंडल बनाने की प्रक्रिया से अधिक जटिल है, और यह स्पष्ट नहीं है कि Google यही समाधान क्यों पसंद करता है।
आगे जा रहा है
1 अगस्त से Google Play पर सबमिट किए गए नए ऐप्स के लिए ऐप बंडल आवश्यक वितरण प्रारूप होगा। हालाँकि Google ने डेवलपर्स और सुरक्षा विशेषज्ञों द्वारा उठाए गए अधिकांश मुद्दों को कम से कम कुछ हद तक संबोधित किया है, लेकिन प्रतिक्रियाएँ अभी भी वांछित नहीं हैं। अगली पीढ़ी के वितरण प्रारूप के रूप में ऐप बंडलों के कई स्पष्ट लाभ हैं, लेकिन ऐप साइनिंग का आंशिक या पूर्ण नियंत्रण Google को देने को लेकर हमेशा चिंता बनी रहेगी।
Google की प्रतिक्रियाओं और प्रयासों की निश्चित रूप से सराहना की जाती है, लेकिन मार्क मर्फी जैसे कुछ लोगों का मानना है कि वे बहुत आगे तक नहीं गए हैं। स्व-निर्मित बंडलों जैसे समाधानों को लागू नहीं किया जा रहा है और एंड्रॉइड ऐप बंडलों की समय सीमा तेजी से आवश्यक है निकट आते हुए, ऐसा नहीं लगता कि Google Play पर डेवलपर अधिक समय तक अपने ऐप्स पर पूर्ण नियंत्रण बनाए रख पाएंगे अब.
हम आज दोपहर बाद ट्विटर स्पेस में एंड्रॉइड ऐप बंडल आवश्यकता के निहितार्थों के बारे में बात करेंगे, इसलिए हमसे जुड़ें!