5 पॉइंट द्वारा GN⁺ 2025-08-28 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Google द्वारा 2026 से लागू किया जाने वाला Android डेवलपर वेरिफिकेशन प्रोग्राम सभी app developers से अपनी पहचान सत्यापित करने की मांग करता है, जिससे privacy और security के बीच संतुलन पर बहस छिड़ गई है
  • ICEBlock मामले से पता चलता है कि जिन डेवलपर्स को anonymity की जरूरत होती है, उनके लिए पहचान उजागर होना व्यक्तिगत और पेशेवर नुकसान का कारण बन सकता है
  • Google की privacy policy में कहा गया है कि डेवलपर जानकारी को बिना स्पष्ट सीमा के third parties के साथ साझा किया जा सकता है, जिससे भरोसेमंदी और transparency को लेकर चिंता बढ़ती है
  • 2027 के बाद यदि debug keystore और duplicate package names के उपयोग पर रोक लगती है, तो शैक्षणिक माहौल में app development और testing कठिन हो सकती है
  • इस प्रोग्राम का लक्ष्य malicious apps को रोकना है, लेकिन anonymity, शैक्षणिक accessibility, और नागरिक समाज संगठनों के साथ सहयोग की कमी पर चर्चा जरूरी है

पृष्ठभूमि और उठते सवाल

  • Google 2026 से सभी Android app developers के लिए identity verification पूरा करना अनिवार्य करेगा, और इसके तहत केवल verified developers के apps ही install किए जा सकेंगे
    • यह policy Google Play के बाहर वितरित apps (sideloading) पर भी लागू होगी
    • 2025 के अक्टूबर में early access शुरू, 2026 के मार्च में सभी developers के लिए खुला, और 2026 के सितंबर में ब्राज़ील, इंडोनेशिया, सिंगापुर, और थाईलैंड में लागू
  • ICEBlock app का मामला anonymity के महत्व को रेखांकित करता है
    • ICEBlock एक ऐसा platform है जहाँ users गुमनाम रूप से ICE (Immigration and Customs Enforcement) की गतिविधियों की रिपोर्ट कर सकते हैं, और डेवलपर द्वारा पहचान सार्वजनिक किए जाने के बाद उन्हें कानूनी धमकियों तथा उनके जीवनसाथी की नौकरी जाने जैसी हानि झेलनी पड़ी
    • Android version के एक समान app (अस्थायी नाम “ICE Scream”) के डेवलपर को पहचान उजागर होने पर ऐसे ही जोखिमों का सामना करना पड़ सकता है

सवाल 1: anonymity पर विचार

  • यह स्पष्ट नहीं है कि Google वैध कारणों से anonymity बनाए रखने की जरूरत वाले डेवलपर्स का समर्थन कैसे करेगा
    • ICE Scream जैसे app के डेवलपर्स पहचान उजागर होने के कारण सुरक्षा जोखिम या कानूनी प्रतिशोध से डर सकते हैं
    • Google ने ऐसे परिदृश्यों के लिए कोई ठोस उपाय या exception policy सार्वजनिक नहीं की है

सवाल 2: नागरिक समाज संगठनों के साथ सहयोग

  • यह पुष्टि नहीं है कि Google ने EFF या AccessNow जैसे नागरिक समाज संगठनों के साथ मिलकर इस verification program में privacy और security के संतुलन पर चर्चा की है या नहीं
    • ऐसे संगठनों के पास privacy और security के संतुलन से जुड़े मुद्दों पर लंबा अनुभव है
    • Google ने उनकी विशेषज्ञता का उपयोग किया या नहीं, और उसका परिणाम क्या रहा, इस पर जानकारी की कमी है

सवाल 3: privacy policy की अस्पष्टता

  • Google की privacy policy कहती है कि डेवलपर की personal information को “trusted companies or individuals” के साथ साझा किया जा सकता है
    • “trusted” का मानदंड क्या है, या साझा की गई जानकारी के उपयोग पर क्या सीमाएँ हैं, इसका कोई स्पष्ट विवरण नहीं है
    • इससे ICE Scream जैसे apps के डेवलपर्स के लिए Google की information handling पर भरोसा करना कठिन हो जाता है

सवाल 4: debug keystore और development environment

  • Android app development में debug keystore का उपयोग होता है, जो अस्थायी होता है और अक्सर बदला जाता है
    • 2027 के बाद, यदि debug keystore verification program में शामिल नहीं हुआ, तो Google-verified hardware पर app testing असंभव हो सकती है
    • शैक्षणिक environment (जैसे classroom, CI server) में keystore registration की मांग सीखने की बाधा बढ़ा सकती है

सवाल 5: duplicate package names की समस्या

  • शैक्षणिक environment में Google के sample projects की तरह duplicate package names का उपयोग आम है
    • verification program duplicate package names पर रोक लगाता है, जिससे नए डेवलपर्स sample code चला नहीं पाएंगे
    • उदाहरण: Android app development की किताबों के लेखक को चिंता है कि उनके पाठक samples चला नहीं सकेंगे
    • Google ने इस समस्या के समाधान के लिए कोई रास्ता नहीं बताया है

अतिरिक्त चर्चा और feedback

  • डेवलपर feedback लेने के लिए Google ने एक online form दिया है, जहाँ सवाल और चिंताएँ भेजी जा सकती हैं
  • नागरिक समाज संगठन या इच्छुक लोग dev.verification@commonsware.com पर संपर्क कर सकते हैं
  • यदि Google स्वयं भी चर्चा करना चाहे, तो did.you.really.need.a.written.invitation@commonsware.com पर संपर्क कर सकता है

निहितार्थ

  • Android डेवलपर verification program का उद्देश्य user security को मजबूत करना है, लेकिन anonymity पर लगने वाली सीमाओं का डेवलपर्स पर क्या असर पड़ेगा, इस पर पर्याप्त विचार नहीं दिखता
  • यह शैक्षणिक accessibility और privacy protection को कमजोर कर सकता है, इसलिए Google की ओर से policy की पारदर्शी व्याख्या और नागरिक समाज संगठनों के साथ सहयोग जरूरी है
  • यह policy malicious apps की रोकथाम और open ecosystem को बनाए रखने के बीच संतुलन की चुनौती पेश करती है, और डेवलपर कम्युनिटी के साथ संवाद अहम है

2 टिप्पणियां

 
ndrgrd 2025-08-28

अगर यह ऐसा app है जिसमें developer खुद apk distribute करता है, तो जहाँ तक संभव हो Obtainium से install करें। Github, Gitlab जैसे प्रसिद्ध distribution platform हों, तो एक-दो आसान steps में install किया जा सकता है और auto update भी मिलती है।
Google से जुड़ा code भी शामिल नहीं होता और हर मायने में बेहतर है।

अगर आप developer पर भरोसा नहीं कर सकते, तो वैसे भी आपको वह app install नहीं करना चाहिए।

 
GN⁺ 2025-08-28
Hacker News राय
  • यह सिर्फ सवाल उठाने भर की बात नहीं है, बल्कि पूरी तरह विरोध का रुख दिखाना चाहिए
    ज़रा-सी भी रियायत दी तो पलक झपकते ही सारे अधिकार छिन सकते हैं
    Stallman की 1997 की The Right to Read में की गई यह चेतावनी बार-बार याद आती है: “2047 में debugger नंबर देकर सिर्फ आधिकारिक रूप से प्रमाणित programmers को ही वितरित किए जाएंगे”

  • समझ नहीं आता कि एक ठीक-ठाक open source mobile OS रखना इतना जटिल क्यों है
    मैं निजी और काम दोनों के लिए सिर्फ Linux PC (laptop, server) इस्तेमाल करता हूँ
    काम के लिए MS365, Google Workspace, Zoom वगैरह चाहिए होते हैं, लेकिन कम-से-कम browser से access किया जा सकता है, इसलिए बंद ecosystem से कुछ हद तक बचाव हो जाता है
    mobile पक्ष में PostmarketOS, Phosh, Ubuntu Touch हैं, लेकिन मैंने इन्हें रोज़मर्रा के जीवन में कभी इस्तेमाल नहीं किया
    कभी-कभी लगता है क्या यह मेरी ही ज़िम्मेदारी है, लेकिन हमारी सरकार भी पहचान सत्यापन ऐप सिर्फ iOS/Android पर ही सपोर्ट करती है
    सही तो यही है कि web पर ही टिके रहें, लेकिन सुविधा के कारण मैं भी आखिर ऐप इस्तेमाल करने लगता हूँ, और खुद को कमज़ोर महसूस करता हूँ
    अगर Ubuntu Touch और iPad जैसा सेटअप हो तो शायद कम-से-कम ऐसा device होगा जिस पर मेरी निजी जानकारी मेरे नियंत्रण में रहे
    आखिरकार ज़रूरत एक ऐसे असली ‘personal computing platform’ की है जिसे बैग के बिना साथ लेकर चला जा सके
    यह बात दुख देती है कि GrapheneOS का भविष्य भी आखिर उस बड़े प्रतिद्वंद्वी के हाथ में है, जो user control को पसंद नहीं करता

  • उम्मीद है कि निकट भविष्य में बंद smartphone और tablet सामान्य desktop/laptop से भी ज़्यादा हो जाएंगे
    ज़्यादातर लोगों को तो पूरी तरह खुले device रखने का मौका भी नहीं मिलेगा
    और यह भी हो सकता है कि laptop भी बंद होते जाएं

  • अभी आप पूरी तरह खुले RISC-V chip खरीद सकते हैं और मनचाहे तरीके से debug कर सकते हैं
    x86 भी लगभग पूरी तरह खुला है (XBox, PS5 आदि में ही अपवादस्वरूप बंद करने की कोशिश होती है)
    इसलिए मुझे लगता है कि Stallman की “right to read” वाली बात अभी कुछ जल्दी की गई अतिशयोक्ति है

  • Stallman की दलील में जो बात छूटती है, वह यह है कि उसमें मान लिया जाता है कि सारे system परफेक्ट हैं, कभी टूटते नहीं, और लोगों को software तथा system की पूरी समझ है—चाहे वे चाहें या नहीं
    अगर debugger पर रोक लगाई गई, तो लोग आखिर pirated debugger ही चलाएंगे
    ज़्यादातर लोगों (99.9%) को OSS में कोई दिलचस्पी नहीं है
    लोगों को बस इतना चाहिए कि वे अपने phone को malware/junkware/adware के बिना अपनी पसंद के अनुसार इस्तेमाल कर सकें
    और publishing तथा development दो अलग-अलग गतिविधियाँ हैं

  • किसी भी ऐप को sideload करते समय verification अनिवार्य करना फासीवादी नियंत्रण है
    Google और Apple पर शर्म आई; बहुत पहले से यही उनका अंतिम लक्ष्य था
    अगला कदम यह होगा कि वे अपनी नापसंद ऐप्स को मनमाने ढंग से delete करने लगेंगे, और हम उन्हें रोक नहीं पाएंगे
    Stallman की चेतावनी सही थी

  • PC खुले इसलिए हैं क्योंकि IBM ने भविष्य का अंदाज़ा नहीं लगाया था
    जब IBM ने नियंत्रण करने की कोशिश की, तब तक बहुत देर हो चुकी थी

  • मुझे लगता है कि “sideload” शब्द ही अपने-आप में समस्या है
    “program चलाना” कहने के बजाय “sideload” क्यों कहा जाता है?
    ऐसा OS जो मुझे अपनी पसंद का program चलाने न दे, बेतुका है

  • मैंने LLM से पूछा था कि “Stallman was right” का मतलब क्या है, इसलिए मोटे तौर पर समझ गया हूँ, लेकिन अगर कोई सीधे समझा दे तो अच्छा होगा
    ऐसी बातों को समझते समय सिर्फ LLM का जवाब सुनना थोड़ा असहज लगता है, इसलिए सीधे पूछना चाहता हूँ

  • मैं ऐसे कदमों का सख्ती से विरोध करता हूँ, और इसी कारण मैं जीवनभर Apple products का वैचारिक बहिष्कार करता आया हूँ
    लेकिन हर चीज़ को “फासीवादी” कहना शब्द का दुरुपयोग है
    उम्मीद है कि इस कदम से Google को भारी backlash मिलेगा, और LineageOS जैसे ROM फिर से अपनी पुरानी लोकप्रियता हासिल करेंगे
    यह भी अच्छा होगा कि root detection bypass तकनीकें और बेहतर हों ताकि banking apps वगैरह rooted phone पर भी बस चल जाएँ
    developer certification जैसी जटिल ID मांगें Apple जितनी ही बुरी हैं
    इसी वजह से Apple products इस्तेमाल करने वाले developers कभी गंभीर नहीं लगे

  • यह बिल्कुल स्वीकार्य नहीं है
    अगर device आपका है, तो आपको उस पर अपनी पसंद की कोई भी चीज़ चलाने की आज़ादी होनी चाहिए
    पैसे देकर खरीदे गए product पर access सीमित करना या lock करना असली ownership नहीं है
    यह device किराए पर लेने से अलग नहीं है
    कल्पना करने की भी ज़रूरत नहीं कि अगर कोई car maker कुछ इलाकों में गाड़ी चलाने पर रोक लगा दे तो लोग उसे स्वीकार करेंगे या नहीं

  • दूसरी ओर, VW वास्तव में सालाना subscription बंद होने पर horsepower limit कर चुका है
    कंपनियों के लालच और users की अनभिज्ञता के कारण ऐसी चीज़ें पहले से ही वास्तविक दुनिया में हो रही हैं

  • आप Steam पर video game license खरीदते हैं और स्वतंत्र रूप से mod install कर सकते हैं
    यह किराया-आधारित model पहले से कई जगहों पर छिपे रूप में मौजूद है

  • पहले मैं phone पर Hail (ऐप pause tool) इस्तेमाल करने के लिए Shizuku का उपयोग करता था
    लेकिन मेरे credit card bank ने हाल ही में USB debugging की मौजूदगी जांचनी शुरू कर दी, इसलिए मुझे इसे छोड़ना पड़ा (3DS OTP भी अब SMS से लेना पड़ता है)
    फिलहाल Thailand में शायद दो ही bank हैं जो यह जांच नहीं करते, लेकिन लगता है जल्द ही सब बंद कर देंगे
    आखिरकार मैं Dhizuku पर चला गया; setup थोड़ा जटिल था, लेकिन एक बार हो जाने के बाद हर बार Shizuku को जटिल तरीके से चलाने की ज़रूरत नहीं पड़ती, इसलिए यह लगभग पूरी तरह untethered jailbreak जैसा लगता है
    Dhizuku मूल रूप से company phone की तरह काम करता है, फर्क सिर्फ इतना है कि उसका मालिक मैं खुद हूँ
    “main profile management” के लिए Android account system के सारे account हटाने पड़ते हैं और एक लंबा ADB command डालना पड़ता है, इसलिए इसका दुरुपयोग करना आसान नहीं है
    आगे चलकर F-Droid इस्तेमाल करने के लिए शायद engineers के बीच ऐसा तरीका standard बन सकता है

  • मैं यह सुझाव देना चाहूँगा कि banking website का इस्तेमाल करना कैसा रहेगा
    मैं phone पर banking app install नहीं करता, और जब भी transfer करना होता है, computer पर बैठकर करता हूँ

  • यह device निश्चित रूप से मेरा है, और मुझे इसे अपनी मर्ज़ी से इस्तेमाल करना चाहिए
    लेकिन यह भी ध्यान में रखना होगा कि ऐसे tools (Shizuku, Dhizuku) का उपयोग वास्तव में device security को प्रभावित कर सकता है और हमले आसान बना सकता है
    जिसमें DeviceOwner permission को अस्थायी रूप से किसी दूसरे ऐप को देना भी शामिल है, मुझे लगता है कि permission का दुरुपयोग खतरनाक है
    और अगर GrapheneOS जैसे security system भी ऐसी setting को रोकने लगें, तो समस्या और बड़ी हो जाएगी
    root detection, call stack inspection वगैरह भी व्यवहार में आसानी से bypass किए जा सकते हैं, इसलिए इनकी प्रभावशीलता सीमित है

  • जिन लोगों से राय लेनी है, उनके लिए feedback form उपलब्ध है
    Google feedback form लिंक
    संबंधित चर्चा

  • मुझे लगता है कि यह policy Chinese OEM पर लागू नहीं होगी
    Chinese devices आमतौर पर Google Mobile Services के डिफ़ॉल्ट रूप से disabled होने के साथ ship होते हैं, और उनमें users के लिए Play Store app भी नहीं होता
    internal app development के लिए Google approval माँगना बेतुका होगा
    हर OEM को अपना अलग debugging license service बनानी पड़ेगी, और Google-आधारित ऐप debugging उतनी ही कठिन हो जाएगी

  • कई Chinese OEM वैसे भी मूल रूप से Google certification नहीं लेते, इसलिए मुझे सच में लगता है कि यह policy उन पर लागू नहीं होगी
    कुछ (Huawei) के पास पहले से अपने app store और Google services के विकल्प मौजूद हैं
    वे व्यवहार में de-googled device हैं, लेकिन अफसोस यह है कि अक्सर उनकी जगह दूसरे खेमे का spyware शामिल होता है

  • ऐप install करने (sideloading) की अनुमति देना या न देना तय करने का अधिकार device owner का होना चाहिए
    जैसे phone में bootloader unlock setting उपलब्ध हो सकती है, वैसे ही ऐसे महत्वपूर्ण feature भी user-configurable होने चाहिए
    यह एक बुनियादी सिद्धांत है, इससे कम कुछ नहीं

  • कुछ सवाल असुविधाजनक हो सकते हैं, लेकिन यह सोचना कि ऐसे सवाल Google को असहज कर देंगे, बहुत आशावादी है
    Google को इन मुद्दों की बिल्कुल परवाह नहीं है

  • PR विभाग का काम ही ऐसे असुविधाजनक सवालों से चालाकी से बच निकलना है
    उल्टा, इस तरह का communication Google के लिए “हम सहयोग कर रहे हैं” जैसी छवि बनाने में इस्तेमाल होता है

  • इसकी वजह से वह मुख्य कारण खत्म होता जा रहा है, जिसके चलते मैं iPhone की जगह Android इस्तेमाल करता आया हूँ

  • बल्कि मुझे लगता है कि यह Apple की policy से भी बदतर है
    iPhone users third-party app install न कर पाने को ही एक feature मानते हैं
    मैं इससे सहमत नहीं हूँ, लेकिन Apple ने शुरू से ईमानदारी से बता दिया था कि users अपने device को नियंत्रित नहीं कर पाएंगे
    मेरे लिए यह अनुभव अप्रिय है, लेकिन कम-से-कम ईमानदार तो है
    इसके विपरीत, Google खुले platform का दावा करके users को आकर्षित करता है और फिर धोखा देता है—एक तरह का bait-and-switch

  • शुरुआती दिनों में जब Android और iPhone प्रतिस्पर्धा कर रहे थे, तब Android की सबसे बड़ी ताकत यही थी कि आप Google की अनुमति के बिना अपनी पसंद का कोई भी app install कर सकते थे

  • शायद यह सब (Google की policy का बंद होना) आखिर Google के लिए ही मुश्किल पैदा करेगा
    अगर Android भी iOS की तरह बंद और कड़े नियंत्रण वाला हो गया, तो फिर Android इस्तेमाल करने की वजह ही क्या बचेगी

  • मैं सोच रहा हूँ कि क्या यह कदम Epic जैसी कंपनी को Google के खिलाफ मुकदमे का आधार दे सकता है
    संबंधित मामले का विवरण
    अगर Google verification प्रक्रिया पर एकाधिकार कर लेता है, तो Epic Store से वितरित Android ऐप्स की वितरण शक्ति Epic के बजाय Google के हाथ में होगी

  • इसलिए मुझे लगता है कि अमेरिका (और अन्य कारणों से EU) में Google वास्तव में यह policy लागू नहीं कर पाएगा
    सच कहूँ तो मैंने कभी सोचा भी नहीं था कि वे ऐसा करने की कोशिश करेंगे, लेकिन अब तो लगता है कुछ भी संभव है, इसलिए कोई अनुमान लगाना मुश्किल है