- Google ने हाल ही में Android app sideloading restriction policy लागू की है, जिससे यूज़र की digital autonomy और mobile ecosystem की openness पर बहस तेज हो गई है
- Singapore के पायलट प्रोग्राम में web·messenger·file manager से मिले apps में से sensitive permissions (SMS, accessibility आदि) मांगने वाले apps की installation ब्लॉक करने जैसी सख्ती बढ़ाई गई
- Play Integrity API के आने से developers sideloaded apps की कुछ features सीमित कर सकते हैं, जिससे Google Play Store-केंद्रित बंद distribution ढांचे को और मजबूती मिलती है
- आलोचकों का कहना है कि ये कदम security बेहतर कर सकते हैं, लेकिन innovation और competition को कमजोर करते हैं और Android की openness घटाते हैं
- Purism ने PureOS और Librem 5 जैसे open source·privacy-केंद्रित mobile विकल्प पेश किए हैं, जो यूज़र की data sovereignty और app installation की आज़ादी सुनिश्चित करते हैं
Google द्वारा Android sideloading प्रतिबंध लागू
- Google ने हाल ही में security concerns का हवाला देते हुए Android में sideloaded apps पर नए प्रतिबंध लागू करने शुरू किए हैं
- Singapore में पायलट नीति cybersecurity agency के साथ मिलकर शुरू की गई, और इसमें खास तौर पर SMS access permission या accessibility services जैसी sensitive permissions मांगने वाले apps की installation को web browser, messaging apps और file manager के जरिए सीमित किया जाता है
- इस कदम का उद्देश्य fraud और malware के जरिए होने वाले अपराधों को रोकना है
Play Integrity API और app store पर निर्भरता
- Play Integrity API के जरिए Google ने app developers को यह सुविधा दी है कि अगर app sideload किया गया हो तो वे उसकी कुछ features सीमित कर सकें
- ऐसी नीतियां यूज़र्स पर दबाव डालती हैं कि वे apps सिर्फ Google Play Store के आधिकारिक रास्ते से ही install करें
- ऊपर से यह security strengthening के लिए दिखता है, लेकिन व्यवहार में यह Android ecosystem पर Google का नियंत्रण और मजबूत करता है
- इसके चलते digital autonomy, innovation और user rights को लेकर चिंताएं फिर उभर रही हैं
आलोचना और असर
- आलोचकों का कहना है कि यह नीति malicious apps को रोकने में मदद कर सकती है, लेकिन साथ ही competition सीमित करती है और user choice घटाती है
- Android की पहचान रही platform openness और sideloading freedom कमजोर पड़ती है, और अंततः यह Apple iOS जैसे बंद ecosystem की दिशा में बदलाव का संकेत देती है
- यह रुझान आगे चलकर innovation को नुकसान और app distribution monopoly को बढ़ावा दे सकता है
Purism का विकल्प: PureOS और Librem Phone
- Purism बढ़ती surveillance और corporate control के जवाब में privacy-केंद्रित समाधान पेश करता है
- PureOS Debian-आधारित Linux operating system है, जो Librem 5 और Liberty Phones में चलता है और यूज़र को पूरी autonomy और data sovereignty देने का दावा करता है
- इस environment में सिर्फ open source security apps को समर्थन मिलता है, जो targeted ads, data mining, addictive algorithms, behavioral manipulation का इस्तेमाल नहीं करते
- यूज़र को corporate app stores या intrusive APIs पर निर्भर नहीं रहना पड़ता, जिससे उन्हें ज्यादा transparent और secure computing experience मिलता है
निष्कर्ष: खुले विकल्पों का महत्व
- जब Google Android ecosystem को और ज्यादा closed बना रहा है, तब Purism ethical, secure और open mobile computing environment की दिशा में खुद को एक विकल्प के रूप में पेश करता है
- user sovereignty और privacy पर केंद्रित ऐसे विकल्प tech industry और developers के लिए महत्वपूर्ण पसंद बनकर उभर रहे हैं
3 टिप्पणियां
असल में sideloading में अगर सिर्फ़ "trusted signer scheme" जोड़ा जाए और इसे DigiCert जैसे third-party certifiers के लिए खोल दिया जाए, तो कम से कम यह जांचना संभव है कि APK भरोसेमंद है या नहीं। समस्या यह है कि Google ने इसे Play Store पर छोड़ देने वाले तरीके से बनाया है। लेकिन अगर यह पूछा जाए कि Google Play Store malicious apps को अच्छी तरह पकड़ता है या नहीं, तो कहना मुश्किल है, और जो apps Google Play policy के खिलाफ़ हैं, वे.......
लेख की मंशा पर शक होता है, लेकिन असल इस्तेमाल में यह धीरे-धीरे ज्यादा झंझट वाला होता जा रहा है, यह भी सच है.
पहले से ही Galaxy डिवाइसों में संदिग्ध malicious apps को block करने जैसी सुविधाएँ बंद भी न की जा सकें, ऐसा बना दिया गया है. उनसे बचने के तरीके हैं, लेकिन इस तरह के नियम-कायदे लगातार बढ़ाए जा रहे हैं.
हल्के उपयोगकर्ता side-loading का लगभग इस्तेमाल नहीं करते और malicious code के execution को रोका जा सकता है, इसलिए यह उनके लिए अच्छा feature हो सकता है, लेकिन कम-से-कम इसे बंद करने का विकल्प तो होना चाहिए, है न?
मैं Pixel के आधिकारिक लॉन्च का इंतज़ार कर रहा था, लेकिन अगर Google भी ऐसा ही करता है तो...
Hacker News राय
इस समय ऐसे ब्लॉग पोस्ट का आना बहुत अजीब टाइमिंग लगती है; क्या यह लेख कुछ महीने पहले तैयार किया गया था और अब जाकर प्रकाशित किया गया? यह भी साझा किया गया कि यह pilot program 1 साल 4 महीने पहले Singapore में घोषित किया गया था। यह केवल Singapore तक सीमित है और उन apps पर लागू होता है जिन्हें खास permissions चाहिए, जैसे RECEIVE_SMS, READ_SMS, BIND_NOTIFICATIONS, accessibility permission। यह केवल उन apps पर लागू है जो app store के बाहर से सीधे download किए गए हों; F-Droid या adb से install करना ठीक रहने की बात भी बताई गई। Play Protect feature बंद करके bypass की कोशिश की जा सकती है, लेकिन Singapore में यह वास्तव में संभव है या नहीं, इस पर लेखक भी निश्चित नहीं है। दिलचस्प बात यह है कि Google ने call के दौरान Play Protect बंद करने से रोक दिया है, और इसे समझदारी भरा फैसला बताया गया। Singapore police के बयान का हवाला भी दिया गया, जिसमें कहा गया कि यह तरीका व्यावहारिक रूप से बहुत असरदार साबित नहीं हुआ; पीड़ितों को APK file install करने से पहले Google Play Protect बंद करने को कहा जाता है, और VPN app तक install करवाया जाता है ताकि scammers banking सुरक्षा तकनीकों को bypass कर सकें (https://police.gov.sg/media-room/news/…)
Singapore के लोग scams के प्रति खास तौर पर अधिक vulnerable हैं, ऐसा data का उल्लेख किया गया। पिछले साल दसियों हज़ार लोग प्रभावित हुए और कुल 1.1 billion Singapore dollars का नुकसान हुआ, जो पिछले साल की तुलना में 70% अधिक है। Global Anti-Scam Alliance के आँकड़ों के अनुसार, वास्तविक नुकसान reported मामलों से भी अधिक हो सकता है, ऐसा अनुभव साझा किया गया। Singapore के target बनने के पीछे उसकी संपन्नता, digitalization, और नियमों का पालन करने वाली संस्कृति को कारण बताया गया (https://archive.is/fCmW1)
Purism का ब्लॉग पोस्ट अभी क्यों आया, यह स्पष्ट नहीं है; इसे सिर्फ marketing के लिए FUD (डर, अनिश्चितता, संदेह) फैलाना माना गया। PureOS-आधारित Librem 5 और Liberty Phones का सीधे उल्लेख करते हुए पूछा गया कि क्या वे APK चला भी सकते हैं। यह भी जोड़ा गया कि केवल Sailfish ऐसी सुविधा देता है, लेकिन licensing issues के कारण वह अपवाद है। Purism द्वारा Phosh जैसे touch-based Linux development में काफी निवेश करने की बात स्वीकार की गई, लेकिन Linux touch environment अभी भी बहुत कमजोर है, यह ज़ोर देकर कहा गया। यह भी राय दी गई कि यह लेख ऐसे मामले पर है जो उन्हें सीधे प्रभावित नहीं करता, फिर भी mainstream alternatives को बुरा दिखाकर अपने products की marketing करने की कोशिश है
यह राय दी गई कि Google को App Store से जुड़े मुकदमे में प्रतिकूल फैसला मिलने से पहले और बाद की timing में फर्क महत्वपूर्ण है। users को सुरक्षा भी मिले और स्वतंत्रता भी, यह संतुलन बनाना कठिन है। यह भी कहा गया कि जब users सुरक्षा warnings के आदी हो जाते हैं, तो अंततः उन्हें नज़रअंदाज़ करने लगते हैं। Play Store को भी पूरी तरह सुरक्षित नहीं माना जा सकता; यहाँ तक कि सार्वजनिक Android user GPS data भी official apps के malicious behavior को दिखाता है, ऐसा दावा किया गया। अंततः vulnerable users के लिए कोई समझदार और भरोसेमंद third party device administrator authority रखे, यही बेहतर विकल्प हो सकता है
राय यह भी रही कि यह लेख ठोस सामग्री से अधिक Purism के विज्ञापन जैसा लगता है
जैसे ही यह समझ आया कि यह विज्ञापन है, पूरी बात अर्थहीन लगने लगी; बेहतर link की मांग की गई
upvote count देखकर लगा कि बहुत से लोग Android की दिशा को लेकर चिंतित हैं और alternatives में रुचि रखते हैं
सवाल उठाया गया कि क्या यह मुद्दा 2024 का नहीं था? (https://techcrunch.com/2024/02/…)
Singapore में पहले शुरू किए गए pilot program के बारे में बताया गया कि block केवल उन्हीं apps पर लागू है जो खास permissions (SMS, accessibility) मांगते हैं और जिन्हें web browser, messenger, या file manager के ज़रिए install किया जाता है। इतने सारे specific conditions होने के कारण advanced users अभी भी अपनी मनचाही apps install कर सकेंगे, ऐसा दृष्टिकोण रखा गया। विश्लेषण यह था कि औसत users के लिए SMS/accessibility permission वाले खतरनाक sideloading को आसान न रहने देना ही इस कदम का मकसद है। यह भी ज़ोर दिया गया कि यह Singapore Cyber Security Agency के सहयोग से scams और malware रोकने के लिए चलाया जा रहा है, इसलिए इसका Singapore-सीमित होना समझ में आता है
यह भी बताया गया कि ऐसी पाबंदियाँ mass market में वास्तव में anti-competitive तरीके से काम कर सकती हैं। तकनीकी समझ रखने वाले कुछ लोग install कर पाएँगे, लेकिन अधिकांश लोग Google के नियंत्रित “बाड़े” के भीतर ही रहेंगे। यह भी कहा गया कि Google और Apple third-party apps के बारे में users को डराने वाली भाषा तक इस्तेमाल करते हैं, यानी ऐसी psychological tactics से भी barriers बनाए जाते हैं। इसे regulation के जरिए हटाया जाना चाहिए, ऐसा “mind control” कहा गया
इस बात पर ज़ोर दिया गया कि “केवल Singapore” होना कोई आश्वासन देने वाली वजह नहीं है। browser और file manager तो सामान्य file transfer के साधन हैं, इसलिए यह शर्त भी ज्यादा भरोसेमंद नहीं लगती
यह विश्लेषण भी सामने आया कि जब तक ADB को भी block नहीं किया जाता, तब तक “sideloading block” कहना पूरी तरह सही नहीं है। आखिरकार malware से users की रक्षा और अपनी पसंद की apps install करने की स्वतंत्रता—इन दोनों के बीच संतुलन ज़रूरी है
Singapore के clients के साथ काम करते समय SingPass (राष्ट्रीय digital identity authentication system) integration की मांग किए जाने की याद साझा की गई; अब वे ग्राहक नहीं रहे, लेकिन codebase में वह कहीं न कहीं अब भी मौजूद है
राय यह भी थी कि region जोड़ना कभी भी संभव है, इसलिए Singapore-सीमित होने से निश्चिंत नहीं होना चाहिए। इसके बजाय Google को apps को “fake permissions” देने जैसी तकनीक की ओर जाना चाहिए, वरना अपराधी किसी और रास्ते से bypass कर लेंगे
comments में चर्चित “sideloading की समस्या GrapheneOS install करके हल हो जाती है” वाले दावे का उल्लेख करते हुए कहा गया कि यह जवाब अधिकांश आम users की वास्तविकता से कटा हुआ है। HN users hardware debugging तक कर सकते हैं, लेकिन सामान्य लोग ऐसे system-level settings संभाल ही नहीं सकते
Linux forums में कभी complex CLI को सामान्य मान लेने वाले जवाब देखकर हैरानी हुई थी; simple और आसान solution चाहने वाले beginners के लिए experts की यह पक्षपाती नज़र adoption और फैलाव में बाधा बन सकती है
यह आकलन किया गया कि अधिकांश लोग “औसत” अनुभव को ठीक से जानते ही नहीं; expert communities में यह विकृति और बढ़ जाती है, जिससे वास्तविक बहुसंख्यक users की स्थिति से दूर राय सामने आती है
यह विश्लेषण भी था कि आम लोग सामान्यतः sideloading करते ही नहीं; वे एक बार ज़रूरी app install करके उसी का लगातार उपयोग करते रहते हैं
यह भी कहा गया कि आम लोग SMS या accessibility permission माँगने वाले sideloaded apps की प्रामाणिकता पहचान नहीं सकते; इसलिए ऐसी functionality को block करने का मूल उद्देश्य “आम लोगों द्वारा गलत उपयोग रोकना” ही है
चिंता जताई गई कि Google यदि DRM technology और APIs जोड़ता रहा, तो आगे चलकर GrapheneOS install करना भी व्यावहारिक विकल्प नहीं रहेगा; तब alternative OS का उपयोग करने के लिए Android ecosystem ही छोड़ना पड़ेगा
एक व्यक्ति ने माना कि वह पहले “फोन मेरा है, मैं जो चाहूँ करूँ” वाली सोच रखता था, लेकिन DJI drones और Air Units के लिए जबरन app sideloading करवाए जाने की बात ने उसे झटका दिया। यह जानकारी भी दी गई कि DJI का app Play Store पर इसलिए नहीं है क्योंकि app अपना code self-modify कर सकता है। चेतावनी दी गई कि राजनीतिक टकराव की स्थिति में state-controlled malware ड्रोन को मनमर्जी से नियंत्रित कर सकता है, जो खतरनाक है। यह भी ज़ोर दिया गया कि लाखों लोगों ने स्थिति को ठीक से समझे बिना app install कर लिया
तर्क दिया गया कि इस समस्या का हल Google की malware scanning का दिखावा नहीं, बल्कि DJI app वास्तव में क्या permissions और capabilities इस्तेमाल कर सकता है, इस पर अधिक मजबूत नियंत्रण है। Google की असली प्रेरणा security नहीं बल्कि control बढ़ाना है, ऐसा दृष्टिकोण रखा गया
इसी संदर्भ में यह विश्वास जताया गया कि “मैं अपनी मर्जी से करना चाहता हूँ” वाली वास्तविक स्वतंत्रता software पर भी लागू होनी चाहिए। Richard Stallman ने 1988 में जो “source लेकर खुद बदल सकने की स्वतंत्रता” की बात कही थी, उसे आज भी प्रासंगिक बताया गया। अफसोस जताया गया कि वास्तविकता उलटी दिशा में जा रही है, जहाँ software ही users को नियंत्रित कर रहा है। यह भी कहा गया कि यदि nation-state software code पर नियंत्रण कर लें, तो यह सिर्फ consumer rights का नहीं बल्कि उससे भी अधिक गंभीर खतरे का मामला है
यह विश्लेषण भी दिया गया कि अलग-अलग देशों की governments यह functionality OEMs के माध्यम से पहले से ही डलवा रही हैं। sideloading block होने पर hackers सिर्फ इन built-in malware को disable होने से रोकने में और सक्षम हो जाएँगे
यह कहा गया कि app का self-modify करना इतना बड़ा मुद्दा नहीं है; अगर कोई app अपने भीतर V8 engine embed कर ले, तो code behavior कभी भी बदला जा सकता है। फिर भी Google इसे समस्या नहीं मानता—इस विडंबना की ओर इशारा किया गया
यह भी सवाल उठाया गया कि DJI drone app के खतरे पर सावधानी जताने वाली मूल comment को downvote क्यों किया गया। हाल में Chinese solar panels में वास्तविक kill switch मिलने के उदाहरण का हवाला देते हुए कहा गया कि सरकार से करीबी रखने वाली Chinese कंपनियाँ अपने hardware/software में संदिग्ध functionality जोड़ सकती हैं (https://reuters.com/sustainability/climate-energy/…, https://rickscott.senate.gov/2025/6/…)
कहा गया कि GrapheneOS install करके sideloading restriction को पार किया जा सकता है, लेकिन आजकल Google Play Integrity API के माध्यम से app functionality को ही Play Store installation तक सीमित करने की प्रवृत्ति बढ़ा रहा है। यह भी बताया गया कि GrapheneOS में bootloader lock करके Play Store उपयोग करने पर भी Google hardware attestation API के उपयोग को रोक देता है, जिससे banking apps, Google Wallet जैसी सुविधाएँ बंद हो जाती हैं। आलोचना की गई कि security updates में देरी करने वाले खराब vendors को तो Google स्वीकार करता है, लेकिन बेहतरीन सुरक्षा वाले open source OS को बाहर कर देता है। Singapore Cyber Security Agency के साथ काम किए जाने को सिर्फ एक प्रकार का justification माना गया। यह भी पूछा गया कि Facebook/Instagram apps जैसी चीज़ें block list में क्यों नहीं जोड़ी जातीं (https://localmess.github.io, https://grapheneos.social/@GrapheneOS/112878070618462132)
राय यह थी कि Google third parties की ढीली सुरक्षा प्रथाओं को तो बर्दाश्त करता है, इसलिए उसका असली लक्ष्य safety नहीं बल्कि control ही है
GrapheneOS की सबसे बड़ी समस्या यह बताई गई कि उसके supported devices बहुत कम हैं; ऐसा alternative चाहिए जो किसी खास hardware से बंधा न हो और फिर भी कुछ हद तक security बनाए रख सके
Android key attestation API GrapheneOS पर भी supported है, और developers इसे integrate कर सकते हैं (https://grapheneos.org/articles/attestation-compatibility-guide)
“GrapheneOS install कर लो” वाले दावे का सीधा जवाब पहले ही दिया जा चुका है, यह कहते हुए reference link साझा किया गया (https://news.ycombinator.com/item?id=32496220)
चिंता जताई गई कि यह कदम visually impaired community पर गंभीर असर डाल सकता है। उन देशों में जहाँ Android लोकप्रिय है और iPhone महँगा है, Commentary (Jieshuo) screen reader, TalkBack से बेहतर विकल्प माना जाता है, लेकिन यह किसी Chinese independent developer का app है और Play Store पर उपलब्ध नहीं है। ऐसे apps को पूरी screen पढ़ने और system UI नियंत्रित करने के लिए बहुत व्यापक permissions चाहिए। अगर sensitive apps तक उनकी पहुँच block हो जाए, तो screen reader होने का मूल उद्देश्य ही खत्म हो जाता है। यह भी आलोचना की गई कि Google के कर्मचारी शायद Webaim stats में कम usage देखकर इसे समस्या न मानें, लेकिन Webaim का sample मुख्यतः उच्च-आय वाले English-speaking users का है, इसलिए वह global usage pattern का प्रतिनिधित्व नहीं करता (https://webaim.org/projects/screenreadersurvey10/)
एक राय यह भी थी कि इस design का इरादा वास्तव में उचित और सामान्य समझ के अनुरूप है। ADB के जरिए malware install करना अभी भी संभव है, लेकिन barrier बढ़ जाने से आम users के लिए यह speed bump जैसा काम करता है। यह भी कहा गया कि उन्हें कोई ऐसा sideloading app नहीं दिखता जिसके साथ स्पष्ट अन्याय हो रहा हो
मूल रूप से यह समझाया गया कि privacy-related permissions (SMS, accessibility आदि) माँगने वाले apps को block करना क्यों महत्वपूर्ण है। सिर्फ SMS permission होने से OTP सहित लगभग सभी service login जानकारी चुराई जा सकती है, और accessibility permission से banking apps जैसी critical functionality तक नियंत्रित की जा सकती है। Singapore में identity information की खरीद-फरोख्त इतनी गंभीर समस्या है कि वहाँ “अगर कोई अनजान व्यक्ति आपका phone number जैसी identity info खरीदना चाहे, तो 5 साल की सज़ा हो सकती है” जैसी चेतावनियाँ तक दी जाती हैं। bank account, credit card आदि के मामले भी ऐसे ही हैं। अंततः अपराध में दुरुपयोग होने वाली identity info व्यक्ति से जुड़ी होती है, इसलिए सहयोग करने पर कड़ी सज़ा का आधार बनता है