Android डेवलपर वेरिफिकेशन: सुरक्षा के भेष में खतरा

 (f-droid.org)
2 पॉइंट द्वारा GN⁺ 22 시간 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • F-Droid ने आलोचना की है कि Android Developer Verification (ADV) Android 8 और उससे ऊपर के डिवाइसों पर पहले ही रोल आउट हो चुका है, और यह ऐसा केंद्रीय नियंत्रण तंत्र बन सकता है जो Google द्वारा अनुमोदित न किए गए डेवलपर्स के ऐप चलने से रोकता है
  • Google इसे malware के प्रसार को रोकने के उपाय के रूप में पेश करता है, लेकिन F-Droid के अनुसार ADV शुरुआती वितरण को रोकने के बजाय बार-बार उल्लंघन करने वाले डेवलपर्स के लिए फिर से रजिस्टर करने की लागत बढ़ाने तक सीमित है
  • डेवलपर रजिस्ट्रेशन के लिए अकाउंट बनाना, शुल्क देना, निजी जानकारी और सरकार द्वारा जारी पहचान-पत्र जमा करना, ऐप identifiers और signing keys रजिस्टर करना, और Android Developer Console Terms से सहमत होना आवश्यक है
  • मुख्य चिंता यह है कि यदि terms में malware की स्पष्ट परिभाषा नहीं होगी, तो Google व्यावसायिक कारणों या सरकारी दबाव के आधार पर ब्लॉक किए जाने वाले दायरे को बढ़ा सकता है
  • यह 30 सितंबर 2026 से Brazil, Indonesia, Singapore, Thailand में लागू होगा, और F-Droid ऐप, इंस्टॉल किए गए ऐप्स, ऐप डेटा तथा Google verification telemetry पर इसका वास्तविक प्रभाव अभी अनिश्चित है

F-Droid ने ADV की तुलना malware से क्यों की

  • F-Droid का मानना है कि Android 8 और उससे ऊपर के डिवाइसों पर Android Developer Verifier (ADV) इंस्टॉल है और वह remote activation का इंतज़ार कर रहा है
  • अनुमान दिया गया है कि ADV पहले ही 4 अरब तक Android फोन और टैबलेट्स पर डिप्लॉय हो चुका है, और दुनिया की लगभग आधी आबादी इससे प्रभावित हो सकती है
  • यह system service बैकग्राउंड में चलती है, और F-Droid का कहना है कि वह इसे ब्लॉक, disable या remove नहीं कर सकता
  • Play Protect Android Certified डिवाइसों पर सामान्य malware का पता लगाने और प्रतिक्रिया देने वाली service है, लेकिन F-Droid आलोचना करता है कि ADV Play Protect के जरिए फैलाया और इंस्टॉल किया जाता है
  • सक्रिय होने के बाद ADV का लक्ष्य, F-Droid के अनुसार, उन डेवलपर्स के software को चलने से रोकना है जिन्हें Google ने केंद्रीय रूप से मंज़ूरी नहीं दी है

malware रोकथाम के तर्क पर प्रतिवाद

  • F-Droid ने सितंबर 2025 में F-Droid and Google’s Developer Registration Decree में पहली बार Android Developer Verification को लेकर चिंता जताई थी
  • Google की केंद्रीय developer registration requirement को malware के प्रसार की रोकथाम के उपाय के रूप में पेश किया जाता है, लेकिन F-Droid का मानना है कि यह व्यवस्था दुर्भावनापूर्ण actors के शुरुआती वितरण को नहीं रोक पाती
  • वास्तविक असर अधिकतर इतना ही है कि पहले से पहचाने गए repeat violators अगर नई signing key से malware बांटना जारी रखना चाहें, तो उन्हें नया account बनाना या खरीदना पड़ेगा, जिससे उनकी गतिविधि धीमी हो जाएगी
  • कम जबरन विकल्प भी संभव बताए गए हैं
    • Play Protect ऊंची permissions वाले नए install apps या संदिग्ध रास्तों से मिले apps की अधिक बारीकी से जांच कर सकता है
    • DCM: A Developers Certification Model for Mobile Ecosystems की तरह federated verifier model भी संभव है, जिसमें उपयोगकर्ता खुद चुनते हैं कि किस verifier और authority पर भरोसा करना है
  • F-Droid की आलोचना है कि Google एक संकरे threat vector के आधार पर Android ecosystem को redesign कर रहा है और यह तय करने वाला अकेला gatekeeper बनना चाहता है कि कौन से apps मौजूद हो सकते हैं

developer registration प्रक्रिया और terms का जोखिम

  • F-Droid की सिफारिश के विपरीत, अगर कोई developer Google के साथ “verified” developer के रूप में रजिस्टर करता है, तो उसे ये प्रक्रियाएं पूरी करनी होंगी
    • account बनाना और fee चुकाना
    • विस्तृत निजी जानकारी जमा करना
    • सरकार द्वारा जारी ID अपलोड करना
    • वर्तमान और भविष्य में वितरित किए जाने वाले apps के identifiers और signing keys रजिस्टर करना
  • सबसे बड़ा मुद्दा यह है कि Android Developer Console Terms of Service से जबरन सहमत होना पड़ता है
  • terms की धारा 6.5 कहती है कि यदि कोई developer terms का उल्लंघन करता है या malware या harmful application वितरित करता है, तो Google ADC access समाप्त कर सकता है
  • F-Droid इंगित करता है कि इस दस्तावेज़ में कहीं भी “malware” की आधिकारिक परिभाषा, मानदंड या guidelines नहीं हैं
  • यदि परिभाषा खाली है, तो “malware” वही software बन जाता है जिसे Google ऐसा कहे, और उसका दायरा व्यावसायिक प्रेरणाओं या शक्तिशाली सरकारी दबाव के आधार पर बदल सकता है

ad blocker उदाहरण से दिखती blocking scope की समस्या

  • F-Droid चेतावनी देता है कि विवादित शब्दों की परिभाषा उन पक्षों पर छोड़ना खतरनाक है जिनके हित अलग-अलग हैं
  • प्रमुख उदाहरण के रूप में वह निजी content filtering tools, यानी ad blockers, का उल्लेख करता है
  • F-Droid को चिंता है कि Google सभी ad-blocking software को malware घोषित कर सकता है, दुनिया भर के Android Certified डिवाइसों पर उनकी installation रोक सकता है, और संबंधित developers को malware creators के रूप में classify कर सकता है
  • F-Droid के अनुसार ऐसी संभावना Google के advertising technology business incentives और Android Developer Console terms की भाषा से मेल खाती है

acceptance rate के दावे और विरोध की गतिविधि

  • Google ने हाल ही में कहा कि Play developers के apps में से 99% से अधिक registered हैं, लेकिन F-Droid ने इसका प्रतिवाद करते हुए कहा कि इसे ADV की व्यापक स्वीकृति का प्रमाण नहीं माना जा सकता
  • F-Droid के अनुसार, ये developers पहले से Play Store contracts से बंधे हुए थे, इसलिए पर्याप्त prior consent के बिना वे automatic रूप से शामिल हो गए
  • ADV के विरोध की गतिविधियां भी जारी हैं
    • ADV विरोधी petition पर लाखों लोगों ने हस्ताक्षर किए हैं
    • keepandroidopen.org के Open Letter पर EFF, FSF, FSFE, ACLU, Forbrukerrådet सहित दुनिया भर के 70 से अधिक संगठनों ने हस्ताक्षर किए हैं
    • program का बचाव करने की कोशिश करने वाले developer roundtable video के बारे में बताया गया कि 90% viewers ने dislike दर्ज किया
  • F-Droid कहता है कि lawmakers और regulators ने अब तक विरोध पर प्रतिक्रिया नहीं दी है
  • F-Droid का मानना है कि open-source transparency पर आधारित उसका security model closed commercial app stores के trust model से मूल रूप से टकराता है

30 सितंबर को लागू होने से पहले बाकी अनिश्चितताएं

  • ADV activation 30 सितंबर 2026 को किस failure mode के रूप में सामने आएगा, यह अभी ठीक-ठीक पता नहीं है
  • Google के public schedule के अनुसार, पहले लागू होने वाले देश Brazil, Indonesia, Singapore, Thailand हैं
  • बताया गया है कि इन चार देशों में 58 करोड़ लोग रहते हैं
  • global rollout “2027 और उसके बाद” के लिए निर्धारित है
  • लागू क्षेत्रों के users के सामने अभी भी ऐसे सवाल हैं जिनके जवाब चाहिए
    • F-Droid app install या run करने की कोशिश करने पर क्या होगा, यह पता नहीं है
    • F-Droid के जरिए install किए गए apps disable या delete होंगे या नहीं, यह अनिश्चित है
    • जिस app पर users निर्भर थे अगर वह अचानक गायब हो जाए, तो क्या उसके अंदर का data वे continue access कर पाएंगे, यह पता नहीं है
    • जब सभी software installation और execution Google verification के लिए report होंगे, तो कौन-सी telemetry information शामिल होगी, यह पता नहीं है
  • F-Droid ने संबंधित inquiries भेजी हैं, और कहा है कि lock लागू होने से पहले आने वाले हफ्तों और महीनों में प्रभावित users को अतिरिक्त guidance और support देगा

संबंधित पढ़ाई

2 टिप्पणियां

 
ndrgrd 5 시간 전

असल में यह कहना कि वैकल्पिक OS मौजूद है इसलिए सब ठीक है, कोई मायने नहीं रखता.. अभी Galaxy पर कोई दूसरा OS इंस्टॉल करना हो तो हार्डवेयर security chip को निष्क्रिय करना पड़ेगा, और ऐसा करने पर शायद Pay या banking apps वगैरह इस्तेमाल नहीं कर पाएंगे।
 
GN⁺ 22 시간 전
Hacker News की रायें

  • यह अभी की समस्या हल नहीं करता, लेकिन अगर इस रुझान को रोका न जा सके तो यह जानना उपयोगी है कि असल में मोबाइल के लिए कई Linux OS मौजूद हैं
    SailfishOS Linux-आधारित है और लगता है कि इसकी community भी काफी खुली है, लेकिन UI stack closed source है। यह एकमात्र विकल्प है जो Android apps को emulation के जरिए आधिकारिक रूप से चला सकता है, पुराना है, हल्का है, और इस सूची में सबसे स्थिर और कम bug वाला लगता है
    Ubuntu Touch पूरी तरह open source और community-driven है, security के लिए snap packages इस्तेमाल करता है और Android apps भी चला पाने की संभावना है। आखिरी बार जब मैंने इसे इस्तेमाल किया था, तब भी यह काफी स्थिर था
    PureOS पूरी तरह open source है और privacy-focused है। मेरी जानकारी में Librem 5 के साथ आए विकल्पों में यह अकेला है जिसमें hardware integration के लिए proprietary binary blobs से बचा जा सकता है। SailfishOS या Ubuntu Touch की तुलना में कम स्थिर दिखता है, और इसे इस्तेमाल करने के लिए काफी महंगा लेकिन पुराना Librem 5 खरीदना पड़ता है
    PostmarketOS पूरी तरह open source है और हल्का होने तथा पुराने phones को फिर से उपयोगी बनाने पर केंद्रित है; इसके tested devices बहुत ज्यादा हैं और यह Alpine-based है
    Mobian Debian का mobile version है, और इस सूची में अपेक्षाकृत नया है। इनके अलावा भी mobile Linux OS हैं, लेकिन मेरी जानकारी में मुख्य विकल्प यही हैं; इनमें से कुछ को मैंने काफी पहले test किया था इसलिए जानकारी गलत हो सकती है, और आखिरी दो को मैंने वास्तव में कभी इस्तेमाल नहीं किया

    • ये OS उन ज्यादातर apps और services के साथ compatible नहीं हैं जिन्हें लोग इस्तेमाल करना चाहते हैं, और आगे यह स्थिति और खराब हो सकती है। इनमें से कुछ जो compatibility layer देते हैं, वे Android security model और app sandbox को बंद करने की कीमत पर भी बहुत कम compatibility देते हैं
      उन पर चलने वाले apps Linux kernel से ज्यादा मजबूत isolation में नहीं, बल्कि कमजोर isolation में चलते हैं। अगर privacy और security आपके लिए अहम हैं, तो ये OS Android Open Source Project की तुलना में कहीं कम private और कहीं कम secure हैं। इनमें पूर्ण और काम करने वाला app sandbox या permission model नहीं है, आधुनिक vulnerability mitigations नहीं हैं, और data extraction रोकने के लिए जरूरी गंभीर hardware-based encryption features भी नहीं हैं
      अच्छे hardware पर AOSP-based OS iPhone का विकल्प हो सकता है, लेकिन privacy और security के नजरिए से ये कोई गंभीर विकल्प नहीं हैं। यह warning Google Mobile Services OS में जोड़ी जा रही है, और Android Open Source Project पर आधारित अन्य OS पर इसका नकारात्मक असर नहीं पड़ेगा
      Linux का मतलब जरूरी नहीं कि GNU/Linux या systemd/Linux हो, और न ही इसका मतलब यह है कि glibc, systemd, GNU coreutils, Bash, GNOME आदि इस्तेमाल हो रहे हैं। AOSP और GrapheneOS सहित Android-based OS भी Linux distributions हैं। Alpine glibc इस्तेमाल नहीं करता और SailfishOS के पास भी public/private software का अपना मिश्रण है। कोई typical desktop Linux user-space stack इस्तेमाल करता है या नहीं, इससे यह तय नहीं होता कि वह Linux है या नहीं; desktop पर भी usage configuration एक जैसी नहीं होती
    • मैं Librem 5 को daily-use phone के रूप में इस्तेमाल कर रहा हूं। PureOS सक्रिय रूप से develop हो रहा है और Debian-based है; monthly development updates यहां आते हैं: https://puri.sm/posts/tag/advanced-readers/
      व्यक्तिगत रूप से मैं Librem 5 पर Android apps इस्तेमाल नहीं करता, लेकिन PureOS repository में Waydroid मौजूद है। Waydroid एक container-based approach है जो Wayland-based desktop environment इस्तेमाल करने वाले सामान्य GNU/Linux system पर पूरा Android system boot करता है
      PureOS, Phosh के जरिए convergence भी देता है। यहां convergence का मतलब है कि वही apps phone और बड़े screen दोनों पर इस्तेमाल हों, और GUI उपलब्ध screen size के हिसाब से adjust हो जाए
      Phosh का उद्देश्य mainline Linux चलाने वाले mobile devices पर daily use के लिए मजबूत और आसान graphical user environment देना है। इसे मूल रूप से Purism developers ने Librem 5 के लिए शुरू किया था, लेकिन अब यह smartphones, tablets, convertibles जैसे कई devices पर इस्तेमाल होता है और laptops पर भी दिख चुका है
    • Usability के मामले में यह Android और iOS तो दूर, 5 साल पुराने versions तक के बराबर भी नहीं है
      UI/UX महंगा काम है, और ज्यादातर free और open source projects के लिए कंपनियों के बड़े निवेश या startups के support के बिना इसे ठीक से बनाना मुश्किल होता है। उदाहरण के लिए Red Hat के UX designers ने GNOME में बड़ा योगदान दिया, और Zed, Element, Bluesky जैसे startup examples भी हैं
      ऐसे support के बिना projects, कम से कम Gen Z के नजरिए से, ज्यादातर इस्तेमाल करने में कठिन होते हैं
    • जरूरी banking apps या सरकारी identity apps न चला पाएं तो सब बेकार हो जाता है
    • Security बेहद खराब स्तर की है। mainstream Android से अलग विकल्प के रूप में स्वीकार करने लायक सिर्फ GrapheneOS है

  • Android यूज़र्स को Graphene पर शिफ्ट होना चाहिए
    किसी को Linux-आधारित मोबाइल OS फ़ाउंडेशन बनाना चाहिए। Google का दबदबा कई बड़ी कंपनियों के हितों के भी खिलाफ है, और Meta जैसी कंपनियों से संपर्क किया जाए तो रणनीतिक हितों की वजह से वे बड़ी रकम दान कर सकती हैं

    • GrapheneOS अभी किसी आशीर्वाद-प्राप्त बच्चे जैसी स्थिति में है। पुराने CyanogenMod की तरह, Android को हार्डन करने का काम फिलहाल Google के लिए फायदेमंद है, इसलिए Google Play Services तक पहुंच की अनुमति है
      जब Google को लगेगा कि उसने हार्डन्ड मेमोरी allocator और tagged memory में पर्याप्त स्थिरता और compatibility हासिल कर ली है, और Qualcomm से पूरे product lineup में support दिलवा सकता है, तब वह Graphene को और मुश्किल बनाता जाएगा और आखिरकार असंभव कर देगा
      लेख पुराना है, लेकिन [1] के मुताबिक Google के Android और Open Handset Alliance के सदस्यों को contract के तहत Google द्वारा मंज़ूर न किए गए devices बनाने से रोका गया है
      मुकाबला करना हो तो compatible Google Play Services भी बनानी होंगी और ऐसे manufacturers भी ढूंढने होंगे जो उसे support करें। Samsung ने कुछ समय तक Tizen के साथ अपने apps और store [2] चलाए थे; शायद bargaining power हासिल करने या सैद्धांतिक transition के लिए। लेकिन बाद में उसने वह प्रयास बंद कर दिया
      [1] https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on...
      [2] https://arstechnica.com/tech-policy/2021/07/google-bought-of...
    • GrapheneOS फिलहाल सिर्फ Google Pixel smartphones को support नहीं करता क्या? ज्यादातर users के लिए इसका मतलब है कि उन्हें पहले अपना फोन बदलना पड़ेगा
      आम users, खासकर अमेरिका के बाहर, में कई लोग इसका खर्च नहीं उठा सकते। ऊपर से Google phone खरीदना Google को ही पोसना है, इसलिए व्यक्तिगत तौर पर मैं इससे बचना चाहूंगा
    • AOSP एक Linux-आधारित मोबाइल OS है। यह बिना lower-level बदलावों वाले standard Linux kernel पर भी अच्छे से चलता है
      नए Mali GPU जैसे components के लिए closed-source user-space drivers की जरूरत खत्म करना AOSP से भी संभव है, और ऐसा करना सबसे ज्यादा लोगों के हित में होगा। कई कंपनियां और अन्य पक्ष मिलकर AOSP में यह कर सकते हैं
      Google के antitrust कानून उल्लंघन की वजह से government intervention से भी ऐसा हो सकता है, लेकिन गलत तरीके से किया गया तो open source को नुकसान पहुंचाने वाले रूप में निपटाया जा सकता है
    • मैंने कोशिश की थी, लेकिन बैंकिंग या सरकारी संसाधनों जैसी ज़रूरी services तक पहुंच नहीं मिल सकी
    • मैं अब भी उम्मीद करता रहता हूं कि Jolla और SailfishOS बड़े स्तर पर उभरें, या postmarketOS सचमुच का alternative बन जाए—कुछ ज्यादा radical हो। लेकिन मौजूदा trend देखें तो 10 साल के भीतर smart glasses के phones की जगह लेने और phones को ही छोड़ देने की संभावना ज्यादा लगती है

  • झुंझलाहट समझ में आती है। मैं खुद भी कई devices पर fdroid खूब इस्तेमाल करता हूं। लेकिन वायरस, Trojan horse, “malware companies” जैसे शब्दों की वजह से यह लेख बचकाना लगता है
    ऐसे लेख कई लोगों को, शायद Google को भी, fdroid की बात को “गंभीरता से लेने लायक नहीं, बचकाना दावा” कहकर खारिज करने का बहाना देते हैं। उदाहरण के लिए कोई प्रतिष्ठित media outlet यह लेख प्रकाशित नहीं करेगा
    और जोड़ दूं तो https://keepandroidopen.org/ बेहतर तरीके से बनाया गया उदाहरण है

    • शुरुआत में मुझे भी ऐसा ही लगा था, लेकिन असल में इसमें दम है। घोषित उद्देश्य functionality के बहुत छोटे हिस्से को ही cover करता है। contract terms की ओर इशारा करता है, और terms में, पिछली बार देखने पर, लिखा था कि वे बिना कारण बताए कभी भी service खत्म कर सकते हैं
      इसकी कोई guarantee नहीं है कि इसे security के अलावा किसी और मकसद से इस्तेमाल नहीं किया जाएगा। और यह भी सही है कि असल में security में इससे कोई खास मदद नहीं मिलती
      Google Search से पूछें तो AI malware को ऐसा software बताता है जिसे unauthorized access, disruption, extortion, या device takeover के लिए design किया गया हो। फिर भी अगर आपको लगता है कि यह शब्द सही नहीं है, तो सोचिए कि यही functionality वाला app कोई और बना दे। Google तुरंत उसे malware बताकर हटा देगा। वह उसे साफ तौर पर malware मानेगा
    • असल मुद्दा लगता है कि Google ने terms में यह कह रखा है कि malware क्या है, यह वे खुद define कर सकते हैं। इसलिए यह दिखाने की कोशिश है कि अगर Google मनमाने तरीके से किसी चीज़ को malware कह सके तो क्या खतरे पैदा होते हैं
    • यह लेख उस label को लगाने लायक पर्याप्त आधार देता है। दूसरी तरफ Google किसी भी चीज़ को मनमाने तौर पर malware कह सकता है। लगता है लेख इसी contrast को दिखाना चाहता है
    • मैं इसे बिल्कुल उल्टा देखता हूं। Google “security” के नाम पर हर तरह की घटिया हरकतें कर रहा है, इसलिए अब उसी खेल के हिसाब से Android पर Google के नियंत्रण को security vulnerability के तौर पर report करने का समय है

  • Android इस्तेमाल करने की वजह यह है कि मैं अपने phone पर जो चाहूं install कर सकता हूं, और यह विवाद का विषय नहीं होना चाहिए। phone या तो मेरा है, या नहीं है। मुझे Google की सुरक्षा नहीं चाहिए। खासकर तब तो बिल्कुल नहीं, जब उसे reject नहीं किया जा सकता

    • Google के बिना Android चलाया जा सकता है। समस्या यह है कि जरूरी security services Apple या Google device मांगती हैं, और समाज के सदस्य के रूप में आपको वे security services इस्तेमाल करनी पड़ती हैं

  • computing में Trojan horse malware का एक प्रकार है, जो normal program जैसा दिखकर users को अपने असली इरादे के बारे में गुमराह करता है [1]
    Google नीचे तक पूरा Trojan horse है। लगभग हर Google product का असली उद्देश्य क्या है? data harvesting
    हर product किसी न किसी रूप में spyware है। manufacturers को subsidy देकर अपना spyware पहले से load करवाता है, और TV तक को Trojan horse बना दिया है
    [1] https://en.wikipedia.org/wiki/Trojan_horse_(computing)

  • कुछ बिंदु देखें तो, sideloading दुनिया भर के Android users में 1–2% से भी कम लोग इस्तेमाल करते हैं, और बहुत हुआ तो करीब 5 करोड़ लोग होंगे। Google ने इसे सिर्फ 24 घंटे की देरी के साथ खुला रखा है, यानी उल्टा उसने एक तरह से रियायत ही दी है। यह और भी बुरा हो सकता था, लेकिन अभी तो developer options से छेड़छाड़ करने वाली हमेशा की hobby activity के दायरे में कोई बड़ी बात नहीं है। निजी तौर पर मैं Google का आभारी हूँ
    GMS उन app developers को जबरदस्त सुविधा देता है जिन्हें सरकारों समेत कड़े नियंत्रण की जरूरत होती है। वे किसी भी तरह के users के खिलाफ अपने apps को सुरक्षित रख सकते हैं। इसमें निगरानी को support करने वाले छिपे backdoor की संभावना और EU में Google की सीधी lobbying जोड़ दें, तो भले ही अभी EU का रुख anti-American दिशा में दिखे, GMS के बिना जाना बहुत मुश्किल है और Europe में यह सबसे आखिर में replace होगा
    “Google से मुक्ति” के भी कई स्तर हैं। microG के बिना या उसके साथ पूरी तरह open OS install करने से लेकर, stock Android पर Google account में login न करने तक यह एक spectrum है। लेकिन आजादी वाले छोर पर मौजूद लोगों को जेल वाले छोर पर मौजूद लोगों जैसे अधिकार कभी नहीं मिलेंगे
    developer certification ad blocking रोकने के लिए नहीं है। DNS level पर जो चाहें block करने का एक आसान और मुफ्त तरीका है। Private DNS चुनें और controld.com जैसी जगहों से ads, trackers और porn block करने के लिए सही URL डाल दें। कोई और बहाना ढूँढना होगा। जैसे सरकारों के साथ लगातार बिस्तर साझा करने के लिए users पर मजबूत नियंत्रण, या जल्द आने वाली बच्चों की identity verification के जरिए आखिरकार पूरी user surveillance तक पहुँचना

    • यह सचमुच हैरान करने वाला है कि हम IBM के PC को lock करने की कोशिश वाले दौर से असली open hardware तक पहुँचे, और अब इस बात के लिए Google का शुक्रिया अदा करने तक आ गए हैं कि वह हमारे खरीदे और हमारे स्वामित्व वाले device पर हम क्या कर सकते हैं, उसे “ज्यादातर ही” सीमित कर रहा है
      बाकी सब भी Google की तरफदारी के ही अलग-अलग रूप हैं। सच कहूँ तो यह गहराई से निराशाजनक है, और खासकर “Hacker” News पर ऐसी प्रतिक्रिया देखना और भी ज्यादा

  • malicious software से लड़ने में source verification एक शक्तिशाली हथियार है, लेकिन anonymous software install और run कर सकने की क्षमता को बचाए रखना authoritarian regimes और भ्रष्ट systems के खिलाफ लड़ने के लिए जरूरी है
    अगर हम यह स्वीकार कर लेते हैं कि users के phones पर सिर्फ signed और approved software ही install/run हो सकता है, तो democracy और freedom खत्म हैं। चाहे West हो या East, या AI overlords के खिलाफ खड़े होने की स्थिति हो—बात वही है

  • जिस hardware और software पर हम निर्भर हैं, उनमें से बहुतों में हम मनमाने बदलाव नहीं कर सकते। उनके design को देख भी नहीं सकते, reproduce नहीं कर सकते, और कभी-कभी repair भी नहीं कर सकते
    कभी-कभी हमें यह भी नहीं पता चल सकता कि वे हमारे हितों के खिलाफ design किए गए हैं या नहीं, और पता चल भी जाए तो हम कुछ नहीं कर पाते। हमें price और privacy के बीच, monopoly या official systems के साथ interoperability और freedom के बीच चुनने के लिए मजबूर किया जा रहा है
    Android का इस दिशा में एक और कदम बढ़ाना खराब है। लेकिन खुद को धोखा न दें। हम दशकों से cyberpunk serfdom में गले तक डूबे हुए हैं। Android की यह लड़ाई जीत भी लें, तो यह बस एक छोटी जीत होगी
    मैं defeatist होकर नहीं कह रहा, बल्कि यह कि बड़ी लड़ाई को न भूलें। यह feudal Goliath कैसे खत्म होगा? कब कहा जाएगा कि अब बहुत हो गया?

  • इस बीच Luxembourg में Google, EU के 4.7 अरब डॉलर Android fine वाले मुकदमे में हार गया
    https://www.msn.com/en-us/money/other/google-loses-fight-aga...

  • मैं अब भी थोड़ा उलझन में हूँ कि EU इस मामले में कार्रवाई क्यों नहीं कर रहा। यह साफ तौर पर monopoly operator की overreach है, और इसे शुरुआत से ही रोकना चाहिए

    • वे पहले ही कर चुके हैं। EU ने Digital Markets Act के Article 6(4) के चौथे paragraph में बताए अनुसार “security” के नाम पर Google की ऐसी कार्रवाइयों को आधिकारिक तौर पर अनुमति दी है
      https://www.eu-digital-markets-act.com/Digital_Markets_Act_A...
    • सही। यह भी जानना चाहूँगा कि क्या यह labour law से टकराता है। blacklist illegal है, और whitelist यानी certification आम तौर पर कई competing third-party certification authorities संभालती हैं
    • अगर EU को करना होता, तो उसे पहले ज्यादा locked-down और मिलती-जुलती market dominance रखने वाले Apple से शुरू करना चाहिए था। जब भी कानून के जरिए compatibility बढ़ती है, Apple fans पहले ही हंगामा कर देते हैं अगर Apple इसे भयानक बताकर marketing करे
      हमने दशकों तक यह स्वीकार किया कि OS vendors ऐसा कर सकते हैं। मुझे लगता है वह गलती थी—Google को एकमात्र संभव supplier के रूप में depend करना। Google इतने समय तक open रहा है, सिर्फ इस वजह से उसे punish करने वाला कानून नहीं बनाया जा सकता
      बेशक, दूसरे HN hackers की तरह मैं भी Apple को open करने के लिए मजबूर करने के पक्ष में हूँ, लेकिन फिलहाल EU चलाने वाले power elites और कई voters उस digital identity project के लिए remote DRM attestation को काफी पसंद करते दिखते हैं, जिसकी जल्द ही उन सभी चीजों के लिए जरूरत होगी जो toddlers के लिए suitable नहीं हैं और dark web के जरिए accessible नहीं हैं
    • EU को ऐसी चीजें पसंद आएँगी। यह सबके सामने खुद को expose करने वाली “transparency” wave का हिस्सा है
      HN users, खासकर Americans, भोलेपन में EU को freedom का गढ़ समझते हैं। बिल्कुल नहीं। EU बस एक विशाल nanny state बनना चाहता है, और यह एक plausible तरीका है जिससे approved दायरे में कुछ भी करने दिया जा सके