关于FBI通过iPhone通知数据获取Signal消息这件事,从工程实现层面看,有必要厘清几个关键的技术细节。帖子里提到的"端到端加密失效"其实是个范畴误置——Signal的加密协议本身并未被攻破,问题出在iOS的通知推送机制(APNs)与本地数据存储的交互上。
具体而言,当用户开启"显示消息预览"功能时,iOS会将通知内容缓存在Notification Center的数据库中,这个文件位于~/Library/Application Support/NotificationCenter/路径下。FBI获取的并非Signal的密文消息,而是iOS系统层面的通知元数据。从威胁模型(threat model)的角度分析,这属于端点安全(endpoint security)的范畴,与传输层的安全协议是两个独立的安全域。其实
开源社区强调"可审计性"(auditability)而非"绝对免疫"。Signal的协议开源确实不能阻止国家机器通过操作系统层面的 subpoena 获取数据,但它确保了加密实现的数学正确性。2020年慕尼黑工业大学的研究显示,Signal的Double Ratchet算法在形式化验证(formal verification)下未发现实现缺陷。这种透明度是闭源方案如iMessage无法提供的——后者我们只能相信苹果的承诺,而无法独立验证。
我在肯尼亚参与通信基础设施建设时,经常需要评估不同加密方案在弱网环境下的可靠性。从工程实践看,任何安全系统都必须明确其威胁边界。Signal的设计假设是"服务器不可信,但端点可信",而现实中国家级的对手往往拥有端点访问能力。这并不意味着开源隐私是"幻觉",而是提醒我们安全是一个纵深防御(defense in depth)的体系,单靠应用层加密无法对抗操作系统级别的取证。
值得商榷的是将数据放在"自己写的Rails应用里"会更安全的观点。除非你能自己维护密码学库、审计每一行依赖代码、并确保服务器物理安全,否则自托管方案面临的是更大的攻击面。CISA 2023年的报告显示,自托管服务的配置错误导致的泄露事件远超端到端加密应用的协议漏洞。
从某种角度看,这次事件恰恰证明了开源的价值——漏洞被发现、被讨论、被修复。闭源系统的同类问题往往要潜伏数年才曝光。真正的工程思维不是追求绝对的安全神话,而是在明确的威胁模型下做理性的风险评估。
你提到监控资本主义的technical外衣,这一点我深有共鸣。但在技术实现层面,我们还是得区分"协议被攻破"和"端点被渗透"这两个截然不同的安全事件。对于需要高度机密的通信,正确的做法不是抛弃Signal,而是配合iOS的Lockdown Mode并关闭通知预览——当然,这属于OPSEC(操作安全)的范畴,已经超出了纯粹的技术讨论。
其实
potato2006之前说过,在非洲用卫星链路跑Signal比WhatsApp可靠多了,这种工程实践中的鲁棒性或许比对抗国家机器的幻想更有现实意义。说到底,隐私工具的选择应该基于具体的威胁模型,而不是非黑即白的意识形态站队。