StarDict X11 क्लिपबोर्ड को रिमोट सर्वर पर भेजता है

• StarDict में एक गंभीर सुरक्षा समस्या पाई गई है, जो X11 वातावरण में उपयोगकर्ता द्वारा चुने गए टेक्स्ट को बिना एन्क्रिप्शन वाले HTTP के जरिए बाहरी सर्वर पर भेजती है
• यह समस्या Debian की डिफ़ॉल्ट सेटिंग में YouDao और dict.cn प्लगइन के डिफ़ॉल्ट रूप से सक्षम होने के कारण उत्पन्न होती है
• इसका मतलब है कि जैसे ही उपयोगकर्ता कोई भी टेक्स्ट चुनता है, वह अपने-आप सर्वर पर भेज दिया जाता है, जिससे संवेदनशील जानकारी लीक होने का जोखिम है
• पैकेज मेंटेनरों ने इस फीचर को बंद करने और प्लगइन को अलग करने के प्रस्तावों पर विचार किया, लेकिन मूलभूत समाधान लागू करने में कमी रही
• यह समस्या अतीत में भी कई बार उठाई जा चुकी है, लेकिन पूर्ण प्रतिक्रिया की कमी और सुरक्षा जागरूकता के महत्व को फिर से उजागर करती है

---

StarDict के व्यवहार और सुरक्षा मुद्दे का सार

• StarDict GPLv3 लाइसेंस वाला एक cross-platform dictionary प्रोग्राम है, जिसमें कई भाषाओं का समर्थन और प्लगइन इकोसिस्टम मौजूद है
• Debian की डिफ़ॉल्ट सेटिंग में StarDict चलाने पर, उपयोगकर्ता द्वारा चुना गया टेक्स्ट बिना एन्क्रिप्शन वाले HTTP के माध्यम से youdao.com और dict.cn इन दो रिमोट सर्वरों पर भेजा जाता है
• इस समस्या की oss-security mailing list और Debian bug tracker में भी रिपोर्ट की गई है

समस्या का विस्तृत विवरण

• StarDict के डिज़ाइन में dictionary websites से संचार करने वाला कोड होना स्वाभाविक लग सकता है, लेकिन "scan" फीचर डिफ़ॉल्ट रूप से सक्षम है
  • इसका मतलब है कि जब उपयोगकर्ता माउस से टेक्स्ट चुनता है, तो अनुवाद पॉप-अप अपने-आप खुलता है और वह टेक्स्ट बाहरी सर्वर पर स्वतः भेज दिया जाता है
  • जब उपयोगकर्ता StarDict को हमेशा बैकग्राउंड में चलने देता है, तब समस्या और गंभीर हो जाती है

Linux वातावरण के अनुसार अंतर

• Wayland वातावरण में StarDict दूसरे एप्लिकेशन का टेक्स्ट कैप्चर नहीं कर सकता, इसलिए scan फीचर काम नहीं करता और यह सुरक्षा समस्या उत्पन्न नहीं होती
• यह समस्या फिलहाल केवल पुराने X11 वातावरण में मौजूद है

Debian और StarDict डेवलपर्स की प्रतिक्रिया

• Debian पैकेज मेंटेनर Xiao Sheng Wen ने कहा कि "scan फीचर और YouDao प्लगइन को बंद किया जा सकता है", इसलिए उन्होंने इसे बड़ा मुद्दा नहीं माना
• लेकिन रिपोर्ट करने वाले Vincent Lefevre ने कहा कि "privacy से जुड़े फीचर डिफ़ॉल्ट रूप से हमेशा बंद होने चाहिए"
• पैकेज विवरण के जरिए इस फीचर की जानकारी दी जा सकती है, लेकिन stardict-plugin के विवरण में online dictionary के उपयोग का उल्लेख नहीं है
• प्लगइन अलग करने जैसे सुधार प्रस्तावित हुए हैं, लेकिन तुरंत कोई कार्रवाई नहीं हुई

फीचर की उपयोगिता और सुरक्षा चिंता

• scan फीचर, विदेशी भाषा पढ़ते समय तेज़ dictionary lookup की जरूरत में, StarDict का एक प्रमुख लाभ है
• लेकिन उपयोगकर्ताओं के लिए यह अनुमान लगाना आसान नहीं कि यह संचार एन्क्रिप्टेड नहीं है। रास्ते में मौजूद कोई भी व्यक्ति संवेदनशील टेक्स्ट को देख सकता है

अतीत की समान सुरक्षा घटनाएँ और प्रतिक्रिया

• 2009 और 2015 में भी ऐसे ही मामले रिपोर्ट किए गए थे
  • 2009: network dictionary को डिफ़ॉल्ट रूप से कुछ समय के लिए बंद किया गया था
  • लेकिन 2016 में जोड़ा गया YouDao प्लगइन उस सेटिंग को नज़रअंदाज़ करता है
  • 2015 की समस्या का समाधान 2025 में जाकर प्लगइन हटाने के रूप में हुआ
• इससे पता चलता है कि मुद्दे का दोबारा सामने आना और प्रतिक्रिया में देरी, साथ ही मेंटेनर बदलना और प्राथमिकता तय करने में कमी, बार-बार दोहराई गई

उपयोगकर्ता संख्या और सुरक्षा प्रभाव

• Debian के आँकड़ों के अनुसार फिलहाल लगभग 178 उपयोगकर्ता ही StarDict इंस्टॉल करके इस्तेमाल कर रहे हैं, लेकिन आँकड़ों में शामिल न होने वाले सिस्टम आदि को देखते हुए संभव है कि कई वर्षों तक अधिक उपयोगकर्ता टेक्स्ट लीक के जोखिम में रहे हों
• पासवर्ड कॉपी करना, संवेदनशील ईमेल, दस्तावेज़ संपादन के दौरान चुना गया टेक्स्ट आदि सीधे बाहरी रूप से उजागर हो सकते हैं

ओपन सोर्स इकोसिस्टम और सुरक्षा एजेंडा

• Debian जैसे बड़े वितरण बहुत सारे पैकेज प्रबंधित करते हैं, इसलिए अपडेट छूट जाना और सॉफ़्टवेयर का पुराना हो जाना अक्सर होता है
• "काफी लोग देखेंगे तो bug उथला होगा" वाली Linus's Law तभी सच होती है जब कोई bug खोजे, रिपोर्ट करे, और फिर मेंटेनर उसे समस्या मानकर ठीक भी करे

X11 से Wayland की ओर बदलाव

• Wayland को अपनाने का एक कारण ऐसे सुरक्षा दोषों को कम करना भी है, खासकर एप्लिकेशन के बीच जानकारी लीक होने की संभावना को
• हालांकि इसके साथ फीचर संबंधी असुविधाएँ और नई permission handling जैसी चुनौतियाँ भी बनी रहती हैं

निष्कर्ष और संकेत

• यह चिंताजनक है कि खोजी गई, विश्लेषित और रिपोर्ट की गई सुरक्षा समस्याएँ अब भी अनसुलझी रह जाती हैं या फिर दोबारा सामने आती हैं
• Linux की security reputation बनाए रखने के लिए open source डेवलपर्स, पैकेज मेंटेनर और उपयोगकर्ताओं की निरंतर जागरूकता और तेज़ प्रतिक्रिया ज़रूरी है

[GN⁺]

Hacker News राय

• जैसा कि Xiao ने बताया, सॉफ़्टवेयर इंस्टॉल करने वाले उपयोगकर्ता पैकेज विवरण पढ़ सकते हैं, और उसमें स्कैन फ़ीचर का ज़िक्र वास्तव में है। लेकिन Debian मेंटेनर अक्सर bug report पर इस तरह जवाब देते हैं कि “आपको सभी पैकेजों के विवरण, यहाँ तक कि dependency के रूप में इंस्टॉल होने वाले सैकड़ों पैकेजों के भी, ध्यान से पढ़ने चाहिए,” और सच कहूँ तो अगर आपने कुछ दिन पहले रिलीज़ हुई Trixie के हिसाब से सभी विवरण और README पढ़ना शुरू किया होता, तो शायद अब तक भी पूरा न कर पाए होते

  • “योजनाएँ और demolition orders Alpha Centauri के स्थानीय दफ़्तर में आपकी पृथ्वी की समय-गणना के हिसाब से पचास साल से प्रदर्शित थीं। अगर आपको स्थानीय मामलों में दिलचस्पी नहीं है…” यह हिस्सा बिल्कुल सटीक लगता है youtube वीडियो लिंक
  • अगर इस तरह का जवाब आता है, तो मुझे इसे दुर्भावनापूर्ण इरादे के अलावा और कुछ मानना मुश्किल लगेगा
  • मैं Debian repository से प्रोग्राम इंस्टॉल करता हूँ तो उसकी वजह सुविधा और भरोसा है। जब मेंटेनर पैकेज के behavior को बदल देते हैं तो नाराज़गी होती ही है, लेकिन बेहतर होता अगर लोगों को clipboard जानकारी किसी और को भेजने वाली सुविधा को opt-in, यानी साफ़ तौर पर खुद enable करने दिया जाता। यह भरोसा तोड़ने जैसा है
  • मैं इस बात से सहमत हूँ कि Trixie रिलीज़ के समय सभी पैकेज विवरण और README पढ़ पाना मुश्किल है। जब मैंने 90 के दशक के आख़िर और 2000 के शुरुआती दौर में पहली बार Debian इस्तेमाल किया था, तब dselect से मनचाहे पैकेज चुनकर कुछ घंटे लगाकर सभी options को अपने असली hardware environment के हिसाब से सेट किया जा सकता था (तब चीज़ें आज की तरह dynamic नहीं थीं, इसलिए हर option अलग से चुनना पड़ता था)। अब पैकेज बहुत ज़्यादा हैं, kernel configuration भी बेहद विशाल हो चुकी है, इसलिए सब कुछ जाँच पाना व्यावहारिक नहीं रहा (क्या अभी भी कोई dselect इस्तेमाल करता है...?)
  • मैं आपकी बात से सहमत हूँ। ख़ासकर इसलिए कि उस पैकेज मेंटेनर ने कई बार अनपेक्षित behavior बनाया है; पुरानी समस्या की तरह दूसरे पैकेजों की config files तक बदल देना, ऐसा अनुचित व्यवहार बार-बार होता रहा है। ऐसी चीज़ें repository से हटा देनी चाहिए

• ज़ाहिर है, कोई सोच सकता है कि dictionary प्रोग्राम में वेबसाइट से communication करने वाला code होगा। लेकिन अगर मैं apt-get से dictionary इंस्टॉल करता हूँ, तो मैं यह उम्मीद कर सकता हूँ कि पूरी dictionary मेरे कंप्यूटर पर ही होगी। आखिर कागज़ी dictionary भी सदियों से इस्तेमाल होती आई है... Stardict online-आधारित है, तो यह सामान्य भी हो सकता है, लेकिन फिर भी इसमें कुछ trap जैसा एहसास होता है

  • मुझे लगता है यह पीढ़ियों का फ़र्क है। जो लोग मानते हैं कि app का इंटरनेट से बात करना स्वाभाविक है, वे आमतौर पर युवा पीढ़ी के हैं, जिन्हें local install होकर बाहर से communicate न करने वाले software की आदत नहीं है। डेवलपर की पृष्ठभूमि देखें तो वह computer science में काफ़ी दक्ष है, और यह भी अच्छी तरह जानता है कि offline dictionary संभव है, लेकिन लगता है वह अपनी पीढ़ी के “स्वाभाविक” मानक का पालन कर रहा है। यह दुखद है कि आज की दुनिया में local install होकर सिर्फ offline data पर चलने वाले apps लगभग शिष्टता-युग की किसी आदर्शवादी चीज़ जैसे लगते हैं, जिन्हें बस कुछ IT Don Quixote ही ज़िंदा रखे हुए हैं
  • भले ही यह सामान्य हो, unencrypted HTTP का इस्तेमाल करना बिल्कुल अस्वीकार्य है
  • पुराना ding प्रोग्राम local dictionary को बहुत अच्छी तरह support करता है। यह Debian में भी शामिल है ding लिंक
  • यह बात मेरी नज़र में भी आई। यह दुखद है कि आज ऐसी साधारण functionality तक के लिए live service की उम्मीद की जाती है
  • एक समय के बाद मैंने GUI apps को network access के बिना चलाना शुरू कर दिया। पहले firejail, फिर bubblewrap, और समय के साथ अपने बनाए bash scripts के ज़रिए sandbox environment में apps चलाने लगा। मैं यह flatpak से पहले से करता आ रहा हूँ

• मुझे यह जानकर काफ़ी झटका लगा कि Samsung फ़ोन पर सारा clipboard data मेरे Samsung account से जुड़े सभी devices पर share हो रहा था (passwords तक सहित), और उसका history भी बचा रह रहा था। मुझे याद नहीं कि यह default setting थी या मैंने गलती से सहमति दे दी थी। संभवतः यह data Samsung servers के ज़रिए होकर जाता है। मैंने sharing feature बंद कर दी, लेकिन clipboard history बंद नहीं हुई, और keyboard बदल देने के बाद भी अगर Samsung keyboard पर लौटूँ तो पुराना clipboard history जस का तस रहता है। अब अगला फ़ोन Samsung का लेने का इरादा नहीं है

  • Samsung TV के बारे में भी मेरी समझ यही है कि वह viewing history और personal data marketing कंपनियों के साथ share करता है। Samsung की privacy policy फ़ोन और TV दोनों के लिए एक जैसी है
  • मैंने KDE connect के ज़रिए Linux से कॉपी किया हुआ password Android clipboard history में दर्ज होते देखा है। सोचता हूँ क्या clipboard sharing पूरी तरह बंद किए बिना सिर्फ passwords को जाने से रोकने का कोई तरीका है
  • Samsung device इस्तेमाल करते समय मैं Samsung account बनाना या उसमें login करना ही टालने की सलाह दूँगा। इससे कंपनी को आपके data तक पहुँच के मौके काफ़ी कम हो जाते हैं

• मुझे लगता है Wayland को लेकर कुछ बातों में ग़लतफ़हमी की गुंजाइश है। आख़िरी सारांश सही है: “संभव है कि StarDict ने Wayland पर चलने के लिए विशेष permissions माँगी हों, और उपयोगकर्ता ने अभी की तरह वही default स्वीकार कर लिया हो।” यानी इसकी संभावना ज़्यादा है, और इंस्टॉलेशन प्रक्रिया में वे permissions अपने-आप सेट भी की गई होंगी। malware हमेशा रहेगा। Wayland कुछ हमलों से बचा सकता है, लेकिन distribution के हिस्से के रूप में इंस्टॉल हुए package से आपको सुरक्षित नहीं रख सकता

  • यह ग़लतफ़हमी नहीं है; Xorg की तुलना में Wayland इस पहलू में निश्चित रूप से बेहतर है। लेकिन समस्या का मूल इससे भी ज़्यादा संरचनात्मक है। उदाहरण के लिए, भेजा जा रहा data encrypted तक नहीं था! StarDict, X11 पर, Debian की default settings के साथ, उपयोगकर्ता द्वारा चुना गया text HTTP के ज़रिए दो remote servers को भेज देता है। भले ही आपने package description या YouDao plugin ध्यान से पढ़ा हो, कम-से-कम यह उम्मीद तो की जा सकती है कि communication encrypted होगा। लेकिन वास्तव में data dict.youdao.com और dict.cn servers को बिना किसी सुरक्षा के साधारण HTTP में भेजा जाता है, और रास्ते में मौजूद कोई भी व्यक्ति request की सामग्री देख सकता है

• हर clipboard selection पर local dictionary lookup ठीक है। remote dictionary request की सुविधा जोड़ना भी समस्या नहीं है। इन दोनों सुविधाओं को अगर किसी special flag जैसी चीज़ से अलग रखा गया होता और आसानी से जोड़ा जा सकता, तो यह समझ में आता; लेकिन default में इन दोनों को मिला देना लगभग दुर्भावनापूर्ण व्यवहार के क़रीब है

  • यहाँ जिस youdao की बात हो रही है, वह एक translation service है। offline translation, online translation की तुलना में बहुत कमज़ोर होती है, यानी मैं भी सिर्फ तब local google offline translation package जैसी किसी चीज़ का इस्तेमाल करना चाहूँगा जब data उपलब्ध न हो। मैं Stardict इस्तेमाल नहीं करता, लेकिन अगर लक्ष्य सिर्फ शब्दार्थ नहीं बल्कि उससे ज़्यादा translation देना हो, तो ऐसा behavior काफ़ी अपेक्षित है। अंततः इस पूरे लेख का सार यह है: “एक चीनी translation प्रोग्राम ने clipboard data अपनी वेबसाइट और एक चीनी translation service को भेजा, और वह भी बिना encryption वाले HTTP पर”

• “बेशक dictionary प्रोग्राम में वेबसाइट से जुड़ा code होता है” वाली बात पर मैं कहना चाहूँगा कि असलियत उपयोग के उद्देश्य पर निर्भर करती है। मेरी Finnish dictionary tsk का न्यूनतम version लगभग 30MB है और उसमें लगभग 2.5 लाख शब्द हैं, इसलिए dictionary सीधे binary में एम्बेड की गई है, और हर run पर prefix search फिर से बनाया जाता है। लेकिन lemmatization, etymology वगैरह को शामिल करने वाला विशाल database दर्जनों GB तक बढ़ सकता है। मेरा उद्देश्य पूरी तरह त्वरित, कीबोर्ड-इनपुट-स्तर की खोज था, इसलिए यह संरचना ज़रूरी थी। इसमें बहुत मेहनत लगी, इसलिए बाद के versions से इसे paid करने का फ़ैसला किया tsk Github paid version homepage (फ़िलहाल Windows code-signing समस्या के कारण offline है)। ज़्यादातर दूसरे use cases में server query करना कहीं ज़्यादा सुविधाजनक है। पूरी विशाल dictionary download करने की शायद ही कोई वजह हो, इसलिए hybrid structure (जैसे शीर्ष 10,000 शब्द local cache में, और बाकी दुर्लभ शब्दों के लिए server से communication) भी काफ़ी तर्कसंगत है

• ऐसी चीज़ें देखकर मुझे कई पहलुओं से यही लगता है कि इसमें दुर्भावना थी। मेंटेनर ने जवाब दिया: “उपयोगकर्ता ने ‘scan’ फ़ीचर खुद enable किया था, और text select करने पर translation action trigger होता है... फिर confidential data को translation query के लिए क्यों select किया?”

  • कहीं ऐसा तो नहीं कि मेंटेनर विदेशी भाषा में छिपे secrets को पहचान ही नहीं पाता... जैसे अगर किसी चीज़ पर “秘密” लिखा हो। “टीम लीड, लगता है दुश्मन translation server error का सामना कर रहा है!”

• Debian में डाले गए भारी प्रयास का मैं सम्मान करता हूँ, लेकिन पैकेज मैनेजर की इस तरह की “maximalism” हमेशा से नापसंद रही है। उदाहरण के लिए, अगर आप foo इंस्टॉल करना चाहें, तो वह संभव हो सके तो उससे जुड़ा हर software साथ में इंस्टॉल कर देता है, और अगर network daemon भी हो तो उसे तुरंत चला भी देता है। मुझे पता है कि “recommended packages” को इंस्टॉल होने से रोकने वाला flag है, लेकिन फिर भी लगता है कि default setting उपयोगकर्ता को असुविधा देती है

  • विनम्र असहमति। “Recommends” इंस्टॉल किए गए package की मुख्य functionality को बढ़ाने के लिए होता है। इसके बिना package टूटता नहीं, लेकिन कई ताकतवर features बंद रह जाते हैं। जिस package का ज़िक्र किया गया है, उसे “Recommends” नहीं बल्कि “Suggests” में वर्गीकृत किया जाना चाहिए। “Suggests” default रूप से इंस्टॉल नहीं होता। apt या aptitude इस्तेमाल करते समय इंस्टॉलेशन preview दिया जाता है और उपयोगकर्ता उसे चुन सकता है। minimalism और user convenience के बीच हमेशा तनाव रहता है। Debian 13 रिलीज़ में तो “Debian कभी user-friendly distribution रहा ही नहीं” जैसी राय भी सामने आई। व्यक्तिगत रूप से मुझे “DIY for DIY” IKEA शैली से ज़्यादा “स्थिर, बुनियादी और user-friendly distribution” पसंद है। और advanced users चाहें तो इसे कभी भी बदल सकते हैं। अगर default बदलना हो तो /etc/apt/conf.d/ में किया जा सकता है, और एक बार के लिए --no-install-recommends इस्तेमाल किया जा सकता है
  • यह सुविधा और सुरक्षा के बीच संतुलन खोजने की एक क्लासिक दुविधा है। Debian में “Recommends” का default ऐसे दौर के लिए डिज़ाइन किया गया था जब network को स्थायी मानकर नहीं चला जाता था, और local functionality को security boundary से ऊपर रखा जाता था
  • पहले APT::Install-Recommends का default false था, और Debian 6.0 Squeeze (2011-02-06) में इसे true किया गया। उस समय Debian और Ubuntu पर बहुत से अनावश्यक packages इंस्टॉल हो जाने से मुझे चिढ़ होती थी। अब पीछे मुड़कर देखता हूँ तो लगता है कि recommends और suggests के बीच भेद कभी-कभी धुंधला था, और “recommends” को default रूप से इंस्टॉल करना तथा उपयोगकर्ता को opt-out देना शायद बेहतर था। फिर भी जिन systems को मैं खुद प्रबंधित करता हूँ, उनमें recommended packages की automatic installation आज भी बंद रखता हूँ
  • --install-recommends का default होना अपने-आप में समस्या नहीं है। Recommends और Suggests के बीच “हममें से ज़्यादातर लोग यह चाहेंगे” बनाम “यह कुछ सीमित functionality है” जैसा सूक्ष्म फ़र्क रखना बुरा नहीं है। लेकिन मैं भी मानता हूँ कि अलग-अलग मेंटेनरों द्वारा Recommends field का दुरुपयोग समस्या है। उदाहरण के लिए, अगर किसी compression tool को इंस्टॉल करने पर कोई खास init system तक ठूँस दिया जाए, तो यह बेतुका है (file-roller, GNOME से जुड़ी टीम की ओर देख रहा हूँ)
  • इसके उलट, ज़रूरी functionality का opt-in विकल्प बनकर छूट जाना भी परेशानी की बात है। समस्या “recommended” packages इंस्टॉल होने में कम और package recommendations को और ज़्यादा conservative होना चाहिए, इसमें ज़्यादा है। वैसे Debian पहले से ही recommended और suggested के माध्यम से अनिवार्यता और वैकल्पिकता में फ़र्क करता है

• मुझे समझ नहीं आता कि यह सब offline क्यों नहीं है। पूरी चीनी dictionary 4 लाख शब्दों से कम है, और अगर हर शब्द के लिए सिर्फ 1k मान लें तो 400MB काफ़ी होगा। यह स्थानीय रूप से आसानी से implement किया जा सकता है; network connection पर निर्भर होना सिर्फ खराब design है

  • तो फिर पहले copyleft dictionary की ज़रूरत होगी

• इस तरह के मुद्दे देखकर मुझे बहुत गुस्सा आता है। यह बिल्कुल भी स्वीकार्य नहीं है

  • बस यह कहना चाहता हूँ कि आप अकेले नहीं हैं। जैसे Bill Gates पर pie फेंकने वाला क्षण था, वैसा ही कोई झटका देने वाला पल शायद फिर चाहिए