Android ऐप इंस्टॉल करते समय, sideloading सहित सभी मामलों में developer verification अनिवार्य होने वाला है

• Google 2026 से केवल verified developers के apps को ही verified Android devices पर इंस्टॉल होने देने की योजना बना रहा है
• यह policy इंस्टॉल के सभी तरीकों पर लागू होगी, जिसमें Play Store के अलावा third-party app stores और APK files की direct installation भी शामिल है
• Google का कहना है कि यह कदम fake apps और malicious apps के वितरण को रोकने तथा बार-बार नुकसान पहुंचाने वाले actors को ब्लॉक करने को मजबूत करने के लिए लाया जा रहा है
• non-commercial developers (students, hobby developers) और commercial developers के लिए अलग verification process तैयार किया जाएगा
• 2026 के सितंबर से Brazil, Indonesia, Singapore, Thailand में पहले लागू किया जाएगा और 2027 में दुनिया भर में विस्तार किया जाएगा

---

Google की नई Android app developer verification policy का overview

• Google malware और financial fraud की रोकथाम के लिए 2026 से केवल verified developers द्वारा बनाए गए apps को ही verified Android devices पर इंस्टॉल करने की अनुमति देने की योजना बना रहा है
• यह policy Play Protect supported devices और उन devices पर लागू होगी जिनमें Google apps पहले से pre-installed हैं, और यह सिर्फ Play Store ही नहीं बल्कि third-party app stores और APK direct sideloading सहित सभी installation routes पर लागू होगी

Policy की विस्तृत जानकारी

• 2023 में Play Store पर इसी तरह की developer verification requirement पहले ही लागू की जा चुकी थी, लेकिन आगे चलकर यह सभी installation/distribution routes पर समान रूप से लागू होगी
• Google ने इसे “airport के identity check (ID check)” जैसा बताते हुए कहा कि वह app के content या source से अलग केवल developer की identity verify करेगा
• लक्ष्य यह है कि malicious app distributors, app हटाए जाने के तुरंत बाद नए harmful apps फिर से distribute न कर सकें, और विश्वसनीय दिखने वाले fake apps से होने वाले नुकसान को कम किया जा सके
• Google की जांच के अनुसार, इंटरनेट के जरिए sideloaded apps में malware occurrence rate Play Store की तुलना में 50 गुना से अधिक अधिक है

Users और developers पर असर

• app distribution की स्वतंत्रता बनी रहेगी, और developers अपनी पसंद के तरीके से users को app उपलब्ध करा सकेंगे
• सिर्फ Google Play के बाहर distribute करने वाले developers के लिए एक अलग Android Developer Console बनाया जाएगा, जबकि students और hobby developers को commercial developers से अलग verification flow दिया जाएगा
• Google Play के जरिए distribute करने वाले developers संभवतः Play Console में पहले ही संबंधित requirements पूरी कर चुके होंगे (organizations के लिए D-U-N-S number आवश्यक)
• कुछ developers 2024 के अक्टूबर से verification process शुरू कर सकेंगे, और 2026 के मार्च तक इसे पूरी तरह खोल दिया जाएगा

लागू होने की समय-सारिणी और देश

• सितंबर 2026 में Brazil, Indonesia, Singapore और Thailand सबसे पहले इस policy के दायरे में आएंगे
  इसकी वजह यह बताई गई है कि इन देशों में ऐसे fraud apps से नुकसान विशेष रूप से ज्यादा रहा है
• 2027 से इसे वैश्विक स्तर पर पूरी तरह लागू करने की योजना है
• संबंधित क्षेत्रों में verified Android devices पर केवल verified developers द्वारा registered apps ही इंस्टॉल किए जा सकेंगे

प्रमुख संस्थाओं और सरकारों की प्रतिक्रिया

• Indonesia के Ministry of Communication and Information Technology ने इसे “Android की openness बनाए रखते हुए user protection के साथ संतुलन” हासिल करने वाला कदम बताया
• Thailand के Ministry of Digital Economy and Society ने इसे “सकारात्मक और proactive safety measure” बताते हुए कहा कि यह देश की digital safety policy के अनुरूप है
• Brazil के banking federation (FEBRABAN) ने इसे “user protection और accountability सुनिश्चित करने की दिशा में सार्थक प्रगति” बताया

[bus710]

मैं audio share नाम का एक ऐप F-Droid से सिर्फ़ apk लेकर इस्तेमाल कर रहा हूँ, तो आगे इसका क्या होगा यह जानने की जिज्ञासा है। यही मेरा एकमात्र sideloading ऐप है...

[unsure4000]

अगर साइडलोडिंग वास्तव में लगभग बंद ही हो जाती है, तो मेरे लिए इसकी उपयोगिता iOS से कम हो जाएगी। मेरे हिसाब से दोनों लगभग समान फ़ीचर देते हैं, और UX में iOS थोड़ा बेहतर है, लेकिन मैं साइडलोडिंग को Android का बड़ा फ़ायदा मानता हूँ। Google Pixel पर GrapheneOS इंस्टॉल करके इस्तेमाल करना मेरा सपना था, लेकिन अगर Pixel source को private करने से लेकर साइडलोडिंग के व्यावहारिक अवरोध तक सब सामने आ रहा है, तो मेरे लिए Android इस्तेमाल करने की वजह नहीं बचेगी। अगर यह इसी तरह रिलीज़ हुआ, तो लगता है 2027 में फिर iOS पर लौट जाऊँगा।

[tribela]

चिंता हो रही है कि जो लोग खुद ही ऐप बनाकर इस्तेमाल करते हैं, क्या उन्हें भी developer verification लेना पड़ेगा..

[GN⁺]

Hacker News टिप्पणियाँ

• Google का Android डिवाइसों में ऐप वितरण करने वाले सभी डेवलपर्स की पहचान सत्यापित करने का फैसला पूरी तरह स्वीकार करना मुश्किल है, यह वैसा ही है जैसे Windows पर कोई प्रोग्राम चलाने के लिए Microsoft को अपनी निजी जानकारी देनी पड़े; ऐसी नीति मनचाही दिशा में नहीं जाएगी

  • मेरा अनुमान है कि Google से पहले या बाद में Microsoft भी Windows पर यही रास्ता अपनाएगा; यह malware समस्या, platform control और सरकारी regulation के संयुक्त प्रभाव वाला भविष्य है
  • मैंने कभी "फोन" प्रोग्रामिंग में बहुत गहराई से कदम नहीं रखा, लेकिन बाज़ार के स्थिर होने का इंतज़ार करते-करते हालात और खराब हो गए हैं; दुनिया भर में बहुत से लोगों के लिए फोन ही एकमात्र computing device है
  • लगता है Google पूरे ecosystem को कसकर पकड़े हुए है; हाल के वर्षों में smartphone निर्माता device unlock या modification को और कठिन बना रहे हैं, और Google व app developers ऐसी तकनीकों की ओर बढ़ रहे हैं जो hardware TPM जैसी हों और यह जाँचें कि device पर Google-स्वीकृत system है या नहीं; alternative platforms अभी भी app ecosystem में दशकों पीछे हैं, इसलिए संभव है कि Google यह नीति बस आगे बढ़ा दे
  • Microsoft Windows भी इसी दिशा में जा रहा है; Smart App Control फीचर कुछ क्षेत्रों में लागू होना शुरू हो गया है, और code-signed certificate के बिना .exe चल नहीं पाता Smart App Control विस्तार से
  • बहुत से लोग ऐसी नीति का विरोध कर सकते हैं, लेकिन व्यवहारिक रूप से विकल्प कम हैं; iOS पर जाने से भी आज़ादी नहीं मिलती, और Linux phone अभी रोज़मर्रा के उपयोग लायक नहीं हैं, तो क्या अंत में flip phone जैसे पुराने device पर लौटना पड़ेगा जहाँ ऐप इंस्टॉल करना ही मुश्किल हो, यह सवाल है

• हाल के समय में केवल दो smartphone OS होने के बीच ऐसी घटना होना बहुत गंभीर समस्या है; encryption को पूरी तरह प्रतिबंधित करने का तरीका न होने से सरकारें सुरक्षा और privacy को इस तरह की identity verification जैसी नीतियों से धीरे-धीरे काट रही हैं; Google की आधिकारिक policy page पर भी ‘official ID upload required’ है नीति मार्गदर्शिका, और मुझे लगता है कि अंततः लोगों के गुस्से के कारण Google या सरकार को यह नीति वापस लेनी पड़ सकती है; जितना संभव हो alternative mobile OS की ओर जाने की सलाह है

  • मुझे लगता है ऐसी नीति जन-आक्रोश का विषय बननी चाहिए, लेकिन वास्तव में दिलचस्पी लेने वाले लोग बहुत कम होंगे और इसे बड़ा मुद्दा बनाना कठिन होगा; अभी की app sideloading lawsuits भी इसलिए संभव हुईं क्योंकि उनका Epic जैसी बड़ी कंपनियों के हितों से सीधा संबंध था
  • Smartphone बाज़ार में सिर्फ दो major OS होना अपने आप में कोई असाधारण बात नहीं है; desktop OS बाज़ार भी लंबे समय तक ऐसा ही था, अंततः यह user expectations का सवाल है
  • मुझे समझ नहीं आता कि Play Protect certification के बिना कोई alternative OS install करने में समस्या क्या है
  • मुझे नहीं लगता कि मौजूदा authoritarian प्रवृत्ति आसानी से खत्म होगी
  • यह मानना अवास्तविक है कि जन-आक्रोश से नीति वापस हो जाएगी; चाहे वोट या किसी और तरीके से प्रभाव डालने की कोशिश की जाए, अधिकतर उम्मीदवार Google जैसी कंपनियों के प्रभाव में रहते हैं, इसलिए संरचनात्मक सीमाएँ साफ़ हैं

• पिछले 10 सालों में Android और iOS दोनों से असंतोष बढ़ता गया है; platforms उपयोगकर्ता के प्रति अधिक शत्रुतापूर्ण हो गए हैं, और app stores privacy invasion, tracking, ads और addictive तत्वों से भरे घटिया apps से भर गए हैं; शुरुआती mobile app innovation की कमी महसूस होती है और Palm Pilot के दिनों की याद आती है; सवाल है कि क्या कोई सच में इस समस्या को हल कर रहा है, क्योंकि हम निश्चित ही बेहतर digital environment बना सकते हैं

  • मेरा मानना है कि असली बदलाव तभी शुरू होगा जब app subscription के बजाय one-time purchase model पर वापसी होगी; लेकिन सभी पक्षों का लालच इतना बढ़ चुका है कि यह आसान नहीं होगा
  • व्यक्तिगत रूप से GrapheneOS और F-Droid का संयोजन इस्तेमाल करते समय मुझे वास्तव में सबसे अधिक संतोष मिलता है; जब दूसरे लोगों के smartphone इस्तेमाल करता हूँ तो हमेशा हैरानी होती है; अगर GrapheneOS अपना device निकाले तो मैं ज़रूर खरीदूँगा और सक्रिय रूप से recommend करूँगा
  • जर्मनी की Vollo एक आकर्षक device बेचती है जिसमें custom Android और Ubuntu Touch को विकल्प के रूप में चलाया जा सकता है, और Netherlands में Fairphone जैसे विकल्प भी हैं Vollo Fairphone
  • Android और iOS के पुराने ‘nostalgic days’ जैसी अनुभूति आज भी काफी हद तक ली जा सकती है; साथ ही LLM जैसी नई बदलावों की इस अवधि का थोड़ा आनंद भी लेना चाहिए
  • Smartphone platform की स्थिति सचमुच गंभीर है, और कुछ users पहले ही धीरे-धीरे smartphone से दूरी बनाने लगे हैं; हालांकि मुझे नहीं लगता कि यह mainstream होगा

• “हम developers को sideloading या किसी भी app store का विकल्प देते हैं, यही open system की परिभाषा है” जैसे नारों के विपरीत, वास्तविकता में चीज़ें बंद होती जा रही हैं; खासकर “Developer’s Alliance” जैसे संगठन भी ऐसी नीतियों का समर्थन करते दिखते हैं, जिससे यह सवाल उठता है कि क्या वे सच में developers के पक्ष में हैं; मुझे लगता है कि नीति के समर्थन में बोलने वाले कई संगठन वास्तव में बड़ी कंपनियों या सरकार से जुड़े होते हैं

  • Developer’s Alliance का पता Washington DC के एक coworking space का है, इसलिए यह policy PR के लिए एक paper organization होने की संभावना लगती है, यानी तकनीकी भाषा में astroturfing

• लेख में account approval process के बारे में लगभग कुछ नहीं था, लेकिन ऐसा लगता है कि Google के पास ऐप वितरण की मंज़ूरी मनमाने ढंग से देने या वापस लेने की शक्ति होगी; यह एक open platform पर gatekeeping की शुरुआत जैसा है; व्यक्तिगत रूप से मेरा मानना है कि unsigned apps इंस्टॉल करते समय warning dialog पर क्लिक करना या setting enable करना ही पर्याप्त है; Windows भी कुछ ऐसा ही करता है, unsigned executable पर warning दिखाता है और signed file को सीधे चलने देता है

  • थोड़ी चिंता है कि कहीं यह Steam की तरह NSFW apps पर प्रतिबंध लगाने की पहली सीढ़ी न बन जाए

• Privacy की समस्या तो है ही, लेकिन यह भी सवाल है कि क्या ऐसी नीति open source projects के local builds को लगभग असंभव बना देगी; पहले local build को developer अपनी ही key से sign करके चढ़ा देता था, लेकिन नई policy में package name identity से बंधता हुआ दिखता है, इसलिए शायद किसी दूसरे की key से sign करना संभव न रहे; अगर मेरी याद गलत है या process बदल गया है तो इस पर राय जानना चाहूँगा

  • Repository अपने आप में एक file directory है, इसलिए namespace बदला जा सकता है, लेकिन यह प्रक्रिया ही बहुत झंझट भरी है; खुद Android signing key तैयार करना और फिर अतिरिक्त रूप से identity submit करना user experience को काफ़ी खराब करता है; अंततः अगर आप 'approved person' नहीं हैं तो Google-certified device पर locally built app चलाना आसान नहीं रहेगा

• अगर यह नीति सचमुच लागू हो जाती है, तो mobile बाज़ार में न तो a) ऐसा OS बचेगा जिसमें third party से contract किए बिना app install किया जा सके, और न ही b) ऐसा OS जिसमें mainstream security-sensitive apps, खासकर banking apps, काम करें

  • आगे चलकर संभव है कि banking access desktop पर भी केवल certified OS और browser से ही मिले
  • मैं तो बस इसे disable कर दूँगा, और ऐसे apps चुनूँगा जिनका banking web पर हो सके; मेरी कई apps sideloaded हैं, Play Store पर भी बहुत कुछ है, और developers द्वारा अपनी जानकारी स्वयं जमा करना भी काफी आम है

• आधिकारिक घोषणा नीचे दिए गए links में देखी जा सकती है Google official blog policy details Google Play सहायता, लेकिन Play Store में malicious apps की भरमार को देखते हुए मौजूदा verification process का खास असर नहीं दिखता; यह नई नीति Google के लिए Revanced जैसे apps को स्थायी रूप से रोकने, यानी अपनी शक्ति बढ़ाने का साधन लगती है; “safety” को बहाना बनाया जा रहा है, जबकि वास्तव में महत्वपूर्ण internet permission settings जैसी चीज़ें users के ad blocking के कारण छिपाई जाती हैं, यह निराशाजनक है; “हम केवल यह सत्यापित करते हैं कि developer कौन है, app की सामग्री नहीं देखते” जैसी पंक्ति समझ नहीं आती, क्योंकि असली security के लिए क्या app contents को किसी स्तर पर देखना ज़रूरी नहीं है? Play Protect बंद करके bypass संभव होगा या नहीं, इसका आधिकारिक बयान में ज़िक्र नहीं है, इसलिए शायद संभव नहीं होगा; इस वजह से अब Linux और Windows ही सच्चे अर्थों में स्वतंत्र development platforms लगने लगे हैं; मैं Google account के बिना develop करना चाहता हूँ

  • व्यवहार में internet permission के बिना भी data बाहर भेजा जा सकता है; attacker अपने site पर data query भेजने वाला intent browser को भेज दे, इतना ही काफी है
  • Play Protect disable करके इस restriction को bypass किया जा सकेगा या नहीं, यह वास्तविक policy लागू होने तक पता नहीं चलेगा; अगर यह संभव हुआ, तो Play Protect शायद “allowed/notarized” apps के अलावा बाकी सबको block करने की दिशा में जाएगा; इस स्थिति में मौजूदा सभी developers को verification process से गुजरना होगा; घोषणा की मंशा भी इसी ओर इशारा करती है; हालांकि कितने users इस verification को बंद कर पाएँगे, यह अभी अज्ञात है
  • यह शक भी होता है कि मामला वास्तव में security का कम और KYC या sanctions जैसे policy controls का ज्यादा है
  • Company identity verification माँगने से बैंक जैसी spoofed apps को रोकने में कुछ लाभ हो सकता है, और package name के हिसाब से public key registration malware-injected modified versions की installation रोकने में उपयोगी है; APKMirror भी signature verification करता है, लेकिन अगर app सिर्फ अविश्वसनीय रास्तों से डाउनलोड करनी पड़े तो मूल app की पहचान के लिए ऐसा सिस्टम कुछ हद तक ज़रूरी हो सकता है; web की EV SSL certificate जैसी security व्यवस्था की तरह यह app contents को analyze किए बिना भी चल सकता है
  • Android में छिपी हुई internet access control setting से क्या मतलब है, इस पर और सुनना चाहूँगा

• अगर यह नीति Play Protect के ज़रिए लागू की जाती है, तो नीचे दिए गए command से इसे आसानी से disable किया जा सकता है

  adb shell settings put global package_verifier_user_consent -1
  

  Root permission के बिना Play Protect disable किया जा सकता है; open source app distribution के लिए मैं Google के साथ अनावश्यक व्यावसायिक संबंध नहीं रखना चाहता; अगर इसका परिणाम यह हुआ कि केवल वही users मेरी apps इंस्टॉल कर पाएँगे जिन्होंने Play Protect को globally बंद किया है, तो भी मैं इसे स्वीकार करूँगा

  • उम्मीद है कि Google जल्द ही “scammer रोकने” जैसे बहाने से इस रास्ते को भी बंद कर देगा
  • जानना चाहूँगा कि यह तरीका वास्तव में और क्या-क्या तोड़ देगा

• सवाल यह है कि हम इस स्थिति को स्वीकार करने तक पहुँचे कैसे; सच तो यह है कि countless छोटे-छोटे restrictions के साथ समझौता करते-करते हम यहाँ तक आए हैं; पहले जब आसपास ऐसे concerns उठाए जाते थे तो अक्सर लोग हँसकर कहते थे “तुम ज़रूरत से ज़्यादा संवेदनशील हो, इसमें कुछ नहीं है”, और अब वही वास्तविकता सामने है

  • eternal september जैसा कहावत-सदृश भाव, यानी बदलाव की यह धारा कभी खत्म नहीं होती
  • कुछ लोग यह कहकर अलग हो जाते हैं कि इसका उनसे संबंध नहीं, क्योंकि वे GrapheneOS या Calyx जैसे alternative OS इस्तेमाल करते हैं; लेकिन अंततः वे भी इसी broader flow के downstream में हैं; Android की असली ताकत आम users और hackers दोनों के लिए उसकी ‘interface standardization’ थी
  • हमने इस स्थिति पर कभी वास्तविक प्रभाव नहीं डाला; असली ज़िम्मेदारी Google और उसके कर्मचारियों की है, जिन्होंने मुनाफ़े और career के लिए user freedom का सौदा किया; मौजूदा स्थिति देर-कालीन पूँजीवाद की विफलताओं में से एक लगती है