Nothing 的 iMessage 应用是一场安全灾难，在 24 小时内被下架

原文 ↗ Hacker News 讨论 ↗

一款承诺让 Nothing 手机兼容 iMessage 的 Android 应用被发现存在严重安全漏洞，包括通过未加密的 HTTP 发送认证令牌，以及将明文消息记录到第三方服务。评论者认为，这种情况从其架构上就可以预见，批评 Sunbird（白标提供商）和 Nothing 都夸大了“端到端加密”，并将其视为炒作和薄弱工程文化压倒基本安全实践的例子。该事件也引发了关于 iMessage 锁定、产品领导与工程领导在安全失败中的责任，以及 Apple 计划支持 RCS 等更广泛讨论。

安全模型与第三方桥接

  • 几条评论对比了 Sunbird/Nothing Chat 与 Beeper 以及其他 Matrix/Signal/Telegram 桥接。
  • 核心观点：如果消息是在云端桥接上解密，而不是在用户自己的设备上解密，那么真正的端到端加密是不可能的；你必须信任桥接运营方。
  • Beeper 的开源桥接和自托管选项被视为一种改进，但也有人指出，官方 Beeper 客户端并不能与任意 homeserver 配合使用，并且使用了自定义扩展。
  • 许多人认为，对大多数用户来说，在服务器上短暂解密，相比使用隐私性更差的通讯工具，是可以接受的权衡；但也有人强调，这会成为执法机构或滥用行为的主要目标。

Sunbird/Nothing Chat 的安全失误

  • 讨论中提到的问题包括：明文记录消息、存储在 Firebase 中、令牌通过 HTTP 发送，以及在未谨慎脱敏的情况下使用第三方错误报告服务。
  • 评论者称这“糟糕得令人震惊”，远低于现代基线——如今 HTTPS 和基本日志卫生本应是默认要求。
  • 一些人认为，这与诈骗几乎没有区别，因为 Sunbird 的营销宣称其具备 E2E 加密和“无存储”，同时还带有反开源言论。

责任、文化与能力

  • 围绕责任究竟在产品经理、项目经理、工程师还是高管展开了大量争论。
  • 一方认为：PM/领导层负责“完成定义”、安全要求和权衡；如果截止日期压过安全，那就是领导层的失败。
  • 另一方认为：工程师配置了 Sentry、HTTP 端点和日志；这些都是技术选择，合格的开发者本应予以拒绝。
  • 更广泛的主题是：“安全是每个人的事”常常导致没有人真正负责；评论者主张设立专门的安全组织和强有力的审查流程。
  • 几条评论认为，这套实现看起来像是在赶工压力下，由缺乏经验或外包团队完成的。

Nothing、炒作与生态锁定

  • 许多人把 Nothing 描述为“炒作多于实质”，更注重有限分发和花哨设计，而不是稳健性。
  • 有人认为是 Sunbird 诈骗了 Nothing；也有人认为两者都在过度包装安全性。
  • 讨论将 iMessage 的排他性以及蓝/绿气泡与 Apple 的锁定联系起来，尤其是在美国青少年中；不过来自欧洲/澳大利亚的人报告的规范则很不一样（WhatsApp、Signal）。
  • 还讨论了 iOS 上的 RCS 支持：它应该能改善互操作性，但不太可能改变 Apple 的品牌区分（蓝色 vs 绿色）或让 iMessage 变得开放。

实现细节与可行性

  • 多条评论描述，这种桥接架构是：Mac mini 或 macOS 虚拟机登录到用户的 Apple ID，从本地 SQLite 数据库中读取 iMessage 数据。
  • 有人指出，开源项目（例如 iMessage bridges、BlueBubbles）已经以更谨慎的方式做了类似的事情，这进一步说明 Sunbird 的错误本可以避免。