Telegram Desktop की एक भेद्यता ने किसी भी उपयोगकर्ता की फ़ाइल चुराना संभव बनाया

मूल लेख ↗ Hacker News चर्चा ↗

Telegram के desktop client में हाल ही में पैच की गई एक खामी ने एक क्लिक किए गए लिंक के ज़रिए मशीन पर उपयोगकर्ता-पहुँच योग्य किसी भी फ़ाइल को exfiltrate करना और पीड़ित के Telegram खाते को hijack करना संभव बना दिया, जिससे ऐप की security posture को लेकर नई चिंताएँ बढ़ीं। टिप्पणीकार Telegram के polished UX और शक्तिशाली group/channel features की तुलना उसके डिफ़ॉल्ट end-to-end encryption की कमी, phone-number-based identity, और opaque infrastructure से करते हैं, और privacy के लिए अक्सर Signal या WhatsApp जैसे विकल्पों को तरजीह देते हैं। यह घटना desktop OSes पर भी व्यापक आलोचना को हवा देती है जो apps को डिफ़ॉल्ट रूप से सभी user files पढ़ने देती हैं, और बेहतर sandboxing तथा अधिक सावधान threat models की माँग को मज़बूत करती है, खासकर Telegram के रूसी हितों से संबंधों को लेकर संदेह के कारण।

Telegram Desktop बग का दायरा और गंभीरता

  • टिप्पणीकार ज़ोर देते हैं कि अकाउंट पर कब्ज़े से आगे बढ़कर, इस बग ने किसी भी उपयोगकर्ता-पहुँच योग्य फ़ाइल (SSH keys, browser stores, cloud creds, आदि) को बाहर निकालना संभव बना दिया।
  • मूल कारण के रूप में एक छिपी हुई internal URL scheme पर चर्चा हुई, जो Telegram की अपनी release publishing को आसान बनाने के लिए बनाई गई थी और arbitrary files अपलोड कर सकती थी।
  • कुछ लोगों को यह “feature” चौंकाने वाली लापरवाही लगती है; अन्य कहते हैं कि इसका exploit करने के लिए एक काफ़ी जटिल chain की ज़रूरत थी।

OS डिज़ाइन, sandboxing, और दोष

  • एक दृष्टिकोण: यह व्यापक desktop OS समस्या को दर्शाता है, जहाँ कोई भी user process किसी भी user file को पढ़ सकता है; apps को प्रति-app directories तक सीमित होना चाहिए।
  • विरोधी दृष्टिकोण: यह स्पष्ट रूप से Telegram-विशिष्ट vulnerability है; ज़्यादातर apps चुपचाप arbitrary files upload नहीं करतीं।
  • कई sandbox mechanisms का उल्लेख किया गया: OpenBSD unveil, Linux bubblewrap, SELinux, Flatpak, macOS और Windows Store sandboxes, FreeBSD jails, Qubes-style VMs।
  • कई उपयोगकर्ता पहले से browsers/Telegram को firejail, VMs, अलग users, या Flatpak के ज़रिए sandbox करते हैं, लेकिन ध्यान देते हैं कि opt-in sandboxes केवल तब मदद करती हैं जब apps उनका उपयोग करें।

Telegram की security posture और डिज़ाइन विकल्प

  • कई लोग दोहराते हैं कि Telegram को लंबे समय से “insecure by design” कहा जाता रहा है: डिफ़ॉल्ट रूप से E2EE नहीं, phone-number identity, closed server, अजीब crypto choices, और अतीत के विवादास्पद bugs।
  • आलोचना कि desktop clients अभी भी secret chats को properly support नहीं करते, और settings कथित तौर पर चुपचाप फिर से enabled हो जाती हैं।
  • कुछ का तर्क है कि Telegram को “secure messenger” बिल्कुल नहीं माना जाना चाहिए; अन्य कहते हैं कि सभी जटिल clients में bugs होते हैं।

लोग अब भी Telegram का उपयोग क्यों करते हैं

  • Telegram के UX की बहुत प्रशंसा: शक्तिशाली group tools, bots, formatting, voice transcription, multi-platform parity, और प्रभावी रूप से असीमित cloud storage।
  • कुछ लोग सुरक्षा trade-offs स्वीकार करते हैं क्योंकि उन्हें लगता है कि intelligence agencies, ad-tech data brokers की तुलना में कम बड़ा खतरा हैं, या क्योंकि जिन लोगों तक उन्हें पहुँचना है वे वहीं हैं।
  • अन्य कहते हैं कि वे इसका उपयोग मुख्यतः public channels, clubs, और makerspaces के लिए करते हैं जहाँ E2EE की कमी कम मायने रखती है।

Threat models, geopolitics, और trust

  • Telegram के रूस और दुबई से संबंधों पर गहरा अविश्वास; कुछ लोग इसे एक संभावित या de facto intelligence honeypot मानते हैं।
  • अन्य लोग सिर्फ़ देश-उत्पत्ति के आधार पर निर्णय देने का विरोध करते हैं, लेकिन फिर भी सभी content/metadata के केंद्रीकृत retention को लेकर चिंतित हैं।
  • Signal और, कुछ हद तक, WhatsApp से तुलना: डिफ़ॉल्ट रूप से E2EE, open clients (Signal के लिए), और अलग business models को स्पष्ट रूप से बेहतर माना जाता है।

E2EE, web apps, और updates

  • लंबे subthread debates इस बात पर हुए कि क्या web apps में सच्चा E2EE संभव है:
    • एक पक्ष: browser-based clients को प्रति-user स्वतंत्र रूप से pin या audit नहीं किया जा सकता; server चुपचाप code बदल सकता है, जिससे server पर भरोसा न करने का पूरा उद्देश्य कमजोर पड़ता है।
    • दूसरा पक्ष: automatic updates वाले native apps को भी इसी तरह के जोखिम का सामना करना पड़ता है; वास्तविक सुरक्षा update/signing models और device compromise पर भी निर्भर करती है।
  • कुछ लोग नोट करते हैं कि Electron-style desktop wrappers को कम-से-कम hash-checked और reproducibly built किया जा सकता है, live web code के विपरीत।

ऐप permissions पर व्यापक सीखें

  • बार-बार calls आती हैं कि मनमाने apps को default रूप से पूरे home directory को पढ़ने और unrestricted network connections बनाने देना बंद किया जाए।
  • सुझाव: filesystem/network access पर OS-level user-friendly controls, default-deny models with clear opt-outs, और commercial closed-source apps (Zoom, Steam, Dropbox, Telegram) को untrusted मानकर हमेशा sandbox करना।