Nothing का iMessage ऐप एक सुरक्षा आपदा था, 24 घंटे में हटा दिया गया
एक Android ऐप जिसने Nothing फ़ोनों के लिए iMessage compatibility का वादा किया था, उसमें गंभीर सुरक्षा खामियाँ पाई गईं, जिनमें authentication tokens को unencrypted HTTP पर भेजना और plaintext messages को third-party services में log करना शामिल था। टिप्पणीकारों का तर्क है कि ऐप की architecture को देखते हुए यह अनुमानित था, वे white-label provider Sunbird और Nothing—दोनों की “end-to-end encryption” को बढ़ा-चढ़ाकर पेश करने के लिए आलोचना करते हैं, और इसे hype तथा कमजोर engineering culture के basic security practices पर हावी होने का उदाहरण मानते हैं। यह घटना iMessage lock-in, सुरक्षा विफलताओं में product बनाम engineering leadership की भूमिका, और Apple के प्रस्तावित RCS support जैसे व्यापक मुद्दों पर बहस को भी तेज करती है.
सुरक्षा मॉडल और थर्ड‑पार्टी ब्रिज
- कई टिप्पणियाँ Sunbird/Nothing Chat की तुलना Beeper और अन्य Matrix/Signal/Telegram ब्रिजों से करती हैं।
- मुख्य बात: अगर संदेशों को उपयोगकर्ता के अपने डिवाइस की बजाय किसी क्लाउड ब्रिज पर डिक्रिप्ट किया जाता है, तो वास्तविक एंड‑टू‑एंड एन्क्रिप्शन असंभव है; आपको ब्रिज ऑपरेटर पर भरोसा करना ही पड़ता है।
- Beeper के ओपन‑सोर्स ब्रिज और self-host करने का विकल्प एक सुधार माना जाता है, लेकिन कुछ लोग नोट करते हैं कि आधिकारिक Beeper क्लाइंट मनमाने homeservers के साथ काम नहीं करता और custom extensions का उपयोग करता है।
- कई लोगों का तर्क है कि अधिकांश उपयोगकर्ताओं के लिए, सर्वर पर थोड़ी देर के लिए डिक्रिप्शन, कम निजी मैसेंजर इस्तेमाल करने की तुलना में स्वीकार्य समझौता है; हालांकि अन्य लोग इसे कानून प्रवर्तन या दुरुपयोग के लिए एक प्रमुख लक्ष्य बताते हैं।
Sunbird/Nothing Chat की सुरक्षा विफलताएँ
- चर्चा किए गए मुद्दों में शामिल हैं: संदेशों की plaintext logging, Firebase में storage, टोकन का HTTP के जरिए भेजा जाना, और सावधानीपूर्वक redaction के बिना third-party error reporting का उपयोग।
- टिप्पणीकार इसे “shockingly bad” कहते हैं, जो आधुनिक मानकों से बहुत नीचे है, जहाँ HTTPS और basic logging hygiene अपेक्षित होती है।
- कुछ लोग इसे धोखाधड़ी से अलग नहीं मानते, क्योंकि Sunbird के marketing claims में E2E encryption और “no storage” की बात थी, साथ ही उसका anti–open-source rhetoric भी था।
जिम्मेदारी, संस्कृति, और क्षमता
- इस पर व्यापक बहस है कि दोष product managers, project managers, engineers, या executives पर जाता है।
- एक पक्ष: PMs/leadership “definition of done,” security requirements, और trade-offs के लिए जिम्मेदार हैं; यदि deadlines सुरक्षा पर हावी हैं, तो वह नेतृत्व की विफलता है।
- दूसरा पक्ष: engineers ने Sentry, HTTP endpoints, और logging configure किया; ये तकनीकी निर्णय हैं और सक्षम developers द्वारा रोके जाने चाहिए थे।
- व्यापक विषय: “security is everyone’s job” अक्सर किसी को भी जवाबदेह नहीं बनाता; टिप्पणीकार dedicated security orgs और मजबूत review processes की वकालत करते हैं।
- कई लोग सुझाव देते हैं कि implementation अनुभवहीन या outsourced टीमों द्वारा schedule pressure में की गई लगती है।
Nothing, hype, और ecosystem lock‑in
- कई लोगों के अनुसार Nothing “substance से अधिक hype” है, जहाँ robustness के बजाय सीमित distribution और flashy design पर जोर है।
- कुछ का मानना है कि Sunbird ने Nothing को ठगा; अन्य लोग दोनों को security overpromise में सह-भागी मानते हैं।
- चर्चा iMessage exclusivity और blue/green bubbles को Apple के lock‑in से जोड़ती है, खासकर US teens के बीच, हालांकि Europe/Australia के लोग WhatsApp, Signal जैसी बहुत अलग norms बताते हैं।
- iOS पर RCS support पर भी चर्चा होती है: इससे interoperability बेहतर होनी चाहिए, लेकिन Apple की branding (blue vs green) बदलने या iMessage को open बनाने की संभावना कम है।
Implementation details और feasibility
- कई टिप्पणियाँ bridge architecture को Mac minis या macOS VMs के रूप में वर्णित करती हैं, जो users के Apple IDs में logged in रहते हैं और local SQLite databases से iMessage डेटा पढ़ते हैं।
- कुछ लोग नोट करते हैं कि open-source projects (जैसे iMessage bridges, BlueBubbles) पहले से ही इसी तरह का काम अधिक सावधानी से करते हैं, जिससे यह और स्पष्ट होता है कि Sunbird की गलतियाँ टाली जा सकती थीं।