Android डेवलपर सत्यापन: सुरक्षा के रूप में छिपा हुआ ख़तरा

Google के Android Developer Verification (ADV) का दायरा

• ADV को Play Services / Play Protect के एक ऐसे घटक के रूप में वर्णित किया गया है जिसमें सिस्टम-स्तरीय विशेषाधिकार हैं और जो ऐप्स और डेवलपर्स को “verified” या नहीं के रूप में वर्गीकृत करेगा।
• सत्यापित डेवलपर्स को सरकारी ID, व्यक्तिगत विवरण प्रदान करने होंगे, और साइनिंग keys पंजीकृत करनी होंगी; ToS Google को पहुँच समाप्त करने और ऐप्स को सटीक परिभाषा के बिना “malware or harmful” के रूप में लेबल करने की अनुमति देती है।
• कुछ लोगों का कहना है कि ADV केवल install flow बदलता है (warnings + 24h “advanced flow” और असत्यापित ऐप्स के लिए developer mode) और मौजूदा ऐप्स को नहीं हटाता या sideloading को पूरी तरह नहीं रोकता।
• दूसरों को डर है कि यह भविष्य में F-Droid, ad-blockers, और राजनीतिक रूप से नापसंद ऐप्स को ब्लॉक करने के लिए एक तकनीकी और कानूनी आधार है।

Malware बनाम Security बनाम Lock-in

• एक पक्ष ADV को “malware” या “trojan” कहता है क्योंकि यह unremovable है, गहराई से privileged है, और मुख्यतः उपयोगकर्ता सुरक्षा के बजाय Google के नियंत्रण हितों की सेवा करता है।
• दूसरा पक्ष इस भाषा का विरोध करता है, इसे भ्रामक fear-mongering बताता है, और तर्क देता है कि यह बड़े पैमाने पर phishing और banking malware अभियानों के प्रति एक (दोषपूर्ण लेकिन वास्तविक) प्रतिक्रिया है।
• slippery-slope पर बहस: कुछ लोग कहते हैं कि इतिहास दिखाता है कि गंभीर भविष्यवाणियाँ अक्सर “तल” तक नहीं पहुँचतीं; दूसरे जवाब देते हैं कि हाल के कई “security” कदमों ने स्वतंत्रता घटाई है (जैसे Chrome extension बदलाव, Play Integrity)।

EU कानून, Antitrust, और Apple से तुलना

• कई टिप्पणियाँ EU Digital Markets Act और Digital Services Act के साथ संगतता पर सवाल उठाती हैं; कुछ ने पहले ही DMA शिकायतें दर्ज की हैं या regulators से संपर्क किया है।
• दूसरों का तर्क है कि DMA Article 6(4) ऐसे उपायों की अनुमति देता है यदि वे “strictly necessary” हों और user-controllable हों, और ADV आंशिक रूप से openness पर EU फैसलों का पालन करने के लिए है।
• Apple का उल्लेख दोनों तरह से किया गया है: एक precedent के रूप में (“Google बस Apple के walled garden की बराबरी कर रहा है”) और एक contrast के रूप में (“Google एक ऐसे platform को retroactively lock down कर रहा है जिसे open के रूप में बेचा गया था”).

उपयोगकर्ताओं, डेवलपर्स, और विकल्पों पर प्रभाव

• power users जोर देते हैं कि Android की अपील स्वतंत्रता थी: sideloading, F-Droid, custom ROMs, personal APKs। यदि यह कमज़ोर होती है, तो बहुत से लोग Apple के अधिक polished लेकिन साफ़-साफ़ closed ecosystem को स्वीकार करना चाहेंगे।
• centralization risk को लेकर गंभीर चिंता: एक Google account ban email, documents, payments, devices सब कुछ मिटा सकता है; ADV डेवलपर्स पर उस leverage को बढ़ाता है।
• F-Droid की inflammatory tone के लिए आलोचना भी की जाती है, लेकिन यह भी बचाव किया जाता है कि वह सही ढंग से इस बात को उजागर कर रहा है कि “harmful” क्या है, यह केवल Google तय करेगा।
• विकल्पों में गहरी रुचि:
  • GrapheneOS (अभी Pixel-only, आने वाले समय में Motorola support के साथ) सबसे सुरक्षित de-Googled Android माना जाता है; इसके सख्त hardware/security requirements पर बहस होती है।
  • LineageOS, /e/OS, और अन्य AOSP forks पर चर्चा होती है, लेकिन कई लोग outdated kernels, firmware, और banking / government ID apps की समस्याओं का उल्लेख करते हैं जिन्हें Play Integrity की आवश्यकता होती है।
  • non-Android Linux phones (Sailfish, Ubuntu Touch, postmarketOS, PureOS, Mobian) का भी उल्लेख है, लेकिन अधिकांश सहमत हैं कि वे immature हैं, app-incompatible हैं, और आधुनिक Android/iOS की तुलना में कहीं कम secure हैं।

प्रस्तावित प्रतिक्रियाएँ

• व्यावहारिक सुझावों में शामिल हैं:
  • जहाँ संभव हो, GrapheneOS या अन्य de-Googled ROMs पर जाना।
  • ADB installs का उपयोग करना और जहाँ संभव हो Play Services से बचना।
  • petitions (जैसे keepandroidopen.org) का समर्थन करना और regulatory complaints दर्ज करना, खासकर EU में।
  • बैंकों और governments पर दबाव डालना कि वे App-Store-locked ID apps के बजाय web-based और hardware-token authentication को सपोर्ट करें।