Nothing's iMessage app was a security catastrophe, taken down in 24 hours
An Android app that promised iMessage compatibility for Nothing phones was found to have severe security flaws, including sending authentication tokens over unencrypted HTTP and logging plaintext messages to third-party services. Commenters argue this was predictable given the app’s architecture, criticize both Sunbird (the white-label provider) and Nothing for overstating “end-to-end encryption,” and see it as an example of hype and weak engineering culture overriding basic security practices. The incident also feeds into broader debates over iMessage lock-in, the role of product vs. engineering leadership in security failures, and upcoming changes like Apple’s planned support for RCS.
Security models and third‑party bridges
- Several comments contrast Sunbird/Nothing Chat with Beeper and other Matrix/Signal/Telegram bridges.
- Core point: true end‑to‑end encryption is impossible if messages are decrypted on a cloud bridge instead of on the user’s own device; you must trust the bridge operator.
- Beeper’s open‑source bridges and the option to self‑host are seen as an improvement, but some note the official Beeper client doesn’t work with arbitrary homeservers and uses custom extensions.
- Many argue that for most users, brief decryption on a server is an acceptable trade‑off compared to using less private messengers, though others highlight this as a prime target for law enforcement or abuse.
Sunbird/Nothing Chat security failures
- The discussed issues include: plaintext logging of messages, storage in Firebase, tokens sent over HTTP, and use of third‑party error reporting without careful redaction.
- Commenters call this “shockingly bad,” well below modern baselines where HTTPS and basic logging hygiene are expected.
- Some see this as indistinguishable from fraud given Sunbird’s marketing claims of E2E encryption and “no storage,” and its anti–open‑source rhetoric.
Responsibility, culture, and competence
- Extensive debate over whether blame lies with product managers, project managers, engineers, or executives.
- One side: PMs/leadership own the “definition of done,” security requirements, and trade‑offs; if deadlines trump security, that’s leadership’s failure.
- Other side: engineers configured Sentry, HTTP endpoints, and logging; those are technical choices and should have been rejected by competent developers.
- Wider theme: “security is everyone’s job” often leads to no one being accountable; commenters advocate dedicated security orgs and strong review processes.
- Several suggest the implementation looks like it was done by inexperienced or outsourced teams under schedule pressure.
Nothing, hype, and ecosystem lock‑in
- Nothing is portrayed by many as more “hype than substance,” with limited distribution and flashy design over robustness.
- Some think Sunbird scammed Nothing; others see both as complicit in overselling security.
- Discussion links iMessage exclusivity and blue/green bubbles to Apple’s lock‑in, especially among US teens, though people from Europe/Australia report very different norms (WhatsApp, Signal).
- RCS support on iOS is discussed: it should improve interoperability but is unlikely to change Apple’s branding (blue vs green) or make iMessage open.
Implementation details and feasibility
- Multiple comments describe the bridge architecture as Mac minis or macOS VMs logged into users’ Apple IDs, reading iMessage data from local SQLite databases.
- Some note that open‑source projects (e.g., iMessage bridges, BlueBubbles) already do similar things more carefully, reinforcing that Sunbird’s mistakes were avoidable.