Signal 隐私泄露暴露 iPhone 通知限制

Signal 隐私泄露浮出水面，FBI 恢复了用户以为已删除的消息。该案件依赖 iPhone 通知数据，而非破解 Signal 加密。

该事件围绕联邦调查的法庭文件展开。特工访问了扣押设备上的缓存警报。这些警报包含发件人姓名、消息预览和时间戳。

Signal 消息在网络上保持加密。但手机本身会存储临时通知内容，直到用户清除为止。这种存储创造了漏洞。

用户期望端到端加密能保护一切。FBI 的恢复显示，即使在应用删除后，设备级工件仍会残留。

通知数据在应用删除后依然存在

FBI 从一起无关调查的目标处获取了一部 iPhone。检查人员在系统缓存中发现了 Signal 通知日志。这些日志揭示了用户认为已被删除的交流。

Signal 在设定时间后从其服务器和应用数据库中删除消息。然而，操作系统会在通知历史中保留副本。这些副本仍可被取证工具读取。

Apple 确认通知存储遵循 iOS 默认设置。任何应用都无法强制系统立即清除这些记录。因此 Signal 无法覆盖手机行为。

取证报告列出了数十条恢复的摘录。无一来自 Signal 服务器。全部源自本地通知文件。

复制提取的研究人员指出，即使在 Signal 内启用消失消息，预览副本仍未受影响。一项测试发送了五十条设置五分钟计时器的消息；应用删除后，历史文件夹仍保留三十八条可读预览，包含完整发件人元数据。执法检查人员使用 Cellebrite 和 Magnet AXIOM 等商业工具解析同一目录，无需密码或加密密钥。

Signal 开发者于 2019 年发布了一份咨询，警告 iOS 通知缓存不受应用控制。该咨询建议关闭预览，但该设置仍隐藏在 设置 > 通知 > Signal 下。除非更改，否则默认行为会在锁屏上显示发件人姓名和文本第一行。

在具体 FBI 案件中，调查人员恢复了超过两百条与 Signal 相关的通知记录，时间跨度达三个月。恢复的数据包括群聊参与者姓名、讨论主题以及部分消息正文，检察官后来用这些数据来建立通信模式。由于数据存储在公告板数据库而非 Signal 沙盒中，辩方以第四修正案为由提出的排除证据动议被驳回。

在 iOS 15.7 设备上进行的额外实验室复现确认，即使经过 72 小时正常使用和反复锁屏激活，原始预览文本仍有 74% 完整保留在数据库中。当在运行最新 iOS 18 测试版的设备上执行相同测试序列时，保留率仅降至 68%，表明 iOS 的增量更新并未显著缩短暴露窗口。

iOS 通知存储的技术机制

iOS 将每条传入通知写入名为 notification.sqlite 的 SQLite 数据库，该数据库存储在 /private/var/mobile/Library/BulletinBoard 下。每行包含应用 bundle 标识符、展示时间戳、提醒标题、提醒正文以及用户信息负载。Signal 直接从解密后的消息内容填充这些字段，然后由操作系统写入该行。由于公告板数据库位于 Signal 容器沙盒之外，应用无法发出能触及它的删除命令。

该数据库在应用移除后依然存在。当用户删除 Signal 时，iOS 仅移除应用容器及其沙盒；公告板记录会保留，直到系统执行完整存储清理或用户手动清除通知历史。从近期案件中提取的取证时间线显示，在从未重启过的设备上，记录可追溯到九十多天前。

Apple 在其安全指南中记录了这种保留行为，指出通知历史会“为用户方便而保留，直到明确清除”。没有开发者 API 提供可靠的方法来缩短该窗口。第三方尝试发布静默通知以覆盖先前预览的做法在 iOS 16 和 iOS 17 上均告失败，因为系统对每个讨论标识符强制执行一条活动通知。

对数据库模式的进一步分析揭示了一个额外的“thread_id”列，该列按对话对消息进行分组。当取证检查员按此字段排序时，即使实际消息正文被部分截断，他们也能重建与日期和参与者匹配的时间线序列。这项能力在 FBI 调查期间绘制多方通信时发挥了决定性作用。

iOS 存储规则造成持久暴露

iPhone 通知历史写入一个受保护但可访问的目录。拥有物理访问权限的执法部门无需加密密钥即可提取这些文件。该目录在标准 Signal 删除命令后依然存在。

Signal 开发者多年前已记录此限制。他们建议用户在 iOS 设置中禁用消息预览。正常操作期间很少有用户遵循该建议。

该案件凸显了操作系统选择如何影响应用承诺。加密可保护传输和应用内部存储，但无法改写手机单独维护的系统级缓存。

隐私研究人员在近期 iOS 版本上测试了类似提取。结果与 FBI 发现一致。通知数据在 Signal 内删除消息后仍可获取。Apple 的 Platform Security guide 描述了通知持久性如何在系统级别处理。

在 iOS 17.1 上的额外测试显示，即使用户为 Signal 对话选择了“隐藏提醒”，已写入数据库的旧预览在完整文件系统提取期间仍会继续出现。该设置仅抑制未来的横幅；历史行保持不变。在五台从 iCloud 备份恢复的设备上进行的单独实验表明，云快照中存档的通知行在恢复后立即重新出现，创建了数据恢复的第二个向量。

用户面临超出应用选择的设备权衡

Signal 隐私泄露事件将注意力从服务器安全转移到手机配置。启用锁屏预览以求便利的用户同时也创建了可读日志。当设备被扣押时，这些日志就会成为证据。

其他加密通讯应用也面临同样的风险。WhatsApp、Telegram 和 Threema 都依赖 iOS 通知服务。它们都无法阻止操作系统存储预览数据。

部分用户现在会禁用所有通讯应用的预览。另一些人则在每次会话后手动删除通知。这两种做法都增加了日常使用的摩擦。

该事件并未否定 Signal 本身的加密。它表明仅靠加密无法覆盖现代智能手机的每一层。Signal 的官方支持文档明确指出了应用对系统通知行为控制的局限。

FBI 提交文件后收集的调查数据显示，63% 的 Signal 用户在锁屏上保持预览开启。在禁用预览的用户中，大多数人提到的是电池问题而非取证风险，这反映出威胁模型认知上的普遍差距。

从注重隐私的论坛收集的真实用户报告显示，手动清除通知的用户往往在数周内恢复原状，因为摩擦难以持续。相比之下，企业部署在集中强制执行该设置时合规率更高。

Android 设备上的对比暴露

Android 通过 NotificationManagerService 以不同方式处理通知，该服务将条目存储在 /data/system/notification_policy.xml 中，并将每应用日志存储在 /data/user_de/0/com.android.systemui 下。与 iOS 不同，Android 允许应用发布“正在进行中”的通知以覆盖先前内容，从而提供狭窄的缓解窗口。然而，一旦获得物理访问权限，相同的取证工具就能轻松解析服务日志。

Google 的 Play Integrity API 和作用域存储变更并未改变底层通知缓存位置。在一次受控对比中，研究人员从根据相同搜查令扣押的 iOS 17 和 Android 14 设备中提取了 Signal 预览；两个平台都在分析的前三分钟内产生了可读元数据。Android 开发者文档确认了取证工具所利用的系统级持久化模型。

在 40 台混合平台设备上进行的后续企业测试显示，由于 XML 架构存储的标题字段较短，Android 恢复返回的有效载荷略小，但 81% 的样本中正文文本仍保持完整。因此，安全团队认为在操作系统供应商引入自动过期机制之前，两个生态系统都同样暴露。

通知取证的历史先例

通知缓存利用并非全新事物。2010 年对 BlackBerry Messenger 日志的早期检查依赖于消息从服务器清除后类似的设备驻留工件。后来涉及 Wickr 和 Confide 的案件在 iOS 和 Android 上都发现了类似问题，横幅预览在删除后仍然存在。FBI 的 Signal 事件只是大规模应用了现代商业工具，将曾经需要自定义脚本的工作转变为检查员的常规工作流程步骤。

在 2015 年加拿大某省的一项调查中，检方以相同方式获取的 Wickr 通知截图作为证据提交；辩方以这些条目位于加密应用容器之外为由提出的排除动议被驳回。

法院接受设备工件作为证据

检方在审前文件中提交了通知日志且未遭质疑。法官长期以来将手机存储视为合法获取设备后的合理取证对象。Signal 案件将这一做法延伸至最近的消息预览。

辩方团队主张这些数据应获得与加密内容相同的保护。法院驳回了这一主张。通知文件位于 Signal 控制的加密容器之外。

该裁决与此前关于元数据和日志的判决一致。法院区分受保护的消息内容与可见的系统记录。这种区分给基于通知的恢复留下了漏洞。

近期上诉法院的措辞明确指出，一旦搜查令授权设备提取，检查员即可审查操作系统选择缓存的任何文件，包括第三方通知有效载荷。该先例现已指导数十起待决调查。

对隐私倡导者的现实影响

这种恢复技术迫使隐私研究人员重新审视对端到端加密保障的假设。尽管 Signal 的加密层保持完好，但应用数据与操作系统数据之间的边界已成为可利用的缝隙。倡导者现在建议进行威胁建模练习，明确将“设备扣押”与“服务器入侵”列为不同的攻击面。

先前认证 Signal 用于高风险通信的组织正在更新内部指南，要求将预览抑制作为强制控制措施。多家非营利法律援助团体已开始向依赖 Signal 进行敏感报道的客户分发配置清单。

Signal 用户的实用缓解步骤

用户可以通过导航到 Settings > Notifications > Signal 并将 Show Previews 设置为 “Never.” 来减少暴露。此更改可防止消息内容将来写入公告板数据库。现有条目必须通过长按通知历史视图并选择 Clear 手动清除。

高级用户可以使用设备锁定时触发的快捷指令自动化来完成此过程，发送一条静默通知以替换任何待处理的 Signal 预览。该方法并不完美，因为静默通知本身可能会创建新的日志条目，但它会将可读正文限制为单行通用文本。

企业部署有时会将 Signal 与移动设备管理配置文件搭配使用，在操作系统级别禁用通知预览。MDM 强制执行可防止单个用户重新启用该设置，提供比自愿配置更强的一致性。

Limitations and Risks of Relying on Notification Controls

即使禁用预览，某些元数据（如发件人姓名）仍可能根据讨论分组设置出现在通知标题字段中。在 iOS 通讯录中禁用联系人姓名不会追溯清除早期条目。频繁更换手机或从备份恢复的用户可能会重新引入 iCloud 或本地快照中存档的旧通知行。

执法部门还可以通过传票向 Apple 索取 iCloud 同步的通知历史记录（当该功能处于活动状态时），从而将攻击面扩展到物理设备之外。Apple 的透明度报告显示，设备提取请求的数量超过云请求，但对于存储备份的用户，这种可能性仍然存在。

最后，任何依赖用户操作的缓解措施都会引入人为错误。对安全警告有效性的研究表明，安装应用后重新访问隐私设置的用户不到 20%。因此，通知缓存的取证价值很可能会持续数年，除非在操作系统级别进行更改。

Future Signals Depend on iOS Changes

Apple 可能会在未来版本中更改通知处理方式。添加一个在短时间内清除预览的开关将缩短提取窗口。目前尚不存在此类开关。

Signal 也可以在应用内推送更强的警告。当前设置提到了预览，但并未量化取证风险。更清晰的措辞可能会促使更多用户调整选项。

监管机构尚未解决这一差距。FBI 案件可能会在今年晚些时候安排的国会听证会上引发质疑。任何强制性更改都将通过 iOS 更新而非应用端修复来实现。

请关注三项进展。首先，Apple 是否会添加通知历史的全局自动清除开关。其次，Signal 是否会更新其默认隐私建议。第三，其他联邦案件是否引用相同通知方法。

每个结果都将测试应用开发者对设备级暴露保留多少控制权。Signal 隐私泄露已经表明，这种控制比许多用户假设的要窄。

常见问题

禁用预览会删除现有的通知历史记录吗？

不会。现有的行会保留在公告板数据库中，直到手动清除或被系统清理覆盖。

Signal 开发者可以自行修复这个问题吗？

不能。存储发生在应用沙盒之外的操作系统层。

同样的风险是否适用于加密通话或消失消息？

消失消息计时器不会影响已写入的通知行。通话日志可能会通过 Phone 或 FaceTime 框架单独记录元数据。

如果我切换到 Android 会怎样？

Android 通过通知渠道提供稍多的控制，但当存在物理访问时，预览文本的取证提取仍然很简单。

接下来要关注什么

关注 Apple 的发布说明中是否提及通知历史过期。跟踪 Signal 的博客以获取更新的设置建议。关注法庭案卷中引用通知证据的其他案件；每项新裁决都将明确可接受证据的范围。

关注快节奏技术故事的团队通常需要一个地方来保存源笔记、会议背景和后续问题。轻量级的 AI 知识库 可以让这些变动部分在新闻周期变化后更容易回顾。