Recall 的安全叙事再次变得更加复杂
微软的 Recall 功能本就是 Copilot+ PC 早期阶段最具争议的想法之一。它承诺提供一层由 AI 辅助的记忆能力，通过截图和可搜索历史记录来追踪用户活动，但其最初实现把高度敏感的内容存放在未加密的本地文件中。在记者和安全研究人员的强烈批评下，微软推迟了部署，重做了关键保护措施，对存储数据进行了加密，改进了对敏感内容的过滤，并将该功能改为默认关闭、由用户主动选择启用，而不是全员默认开启。
这次整改似乎回应了最直接的批评。但一款新更新的工具 TotalRecall Reloaded 现在指向了另一类风险。根据所提供的原文，问题并不在于 Recall 受保护数据库本身被直接突破。相反，风险出现在用户通过 Windows Hello 完成身份验证之后，Recall 数据被传递给另一个系统进程 AIXHost.exe，而该进程并不享有同等保护。开发该工具的研究者 Alexander Hagenah 用一个比喻概括了这个问题：保险库或许很牢固，但送达路径却不安全。
薄弱点在工作流，而不在存储层
这个区别很重要，因为它改变了争论的焦点。微软在第一次 Recall 风波后的回应，主要集中在存储安全上：加密、身份验证、更好的敏感内容排除以及默认关闭。这些措施当然重要。但新的发现表明，保护一项 AI 功能不能只停留在数据静态存放的安全，还必须覆盖数据在系统中正常流动时的每一个环节。
换句话说，与以前相比，Recall 也许更难被直接从磁盘中窃取，但在受保护数据变得可用的那一刻，仍然可能暴露于风险之下。这在安全工程中并不陌生。系统在静态架构图中往往最强，而在运行中的过渡阶段最脆弱：身份验证、解密、进程间通信，以及临时访问状态。对于一项旨在记录大量个人计算历史的功能来说，这些过渡点恰恰是风险最敏感的地方。
原文也明确说明了为什么即使微软已经改进 Recall，它仍然格外具争议。这并不只是另一个应用缓存或浏览器历史。它是一套被设计用来记录 PC 活动广泛范围、以便日后检索的系统。因此，即便只是部分失守，也可能暴露出比用户预期更多的上下文信息，远超单一薄弱环节通常会泄露的内容。
为什么这不仅关乎 Recall
Recall 事件正在成为更广泛行业问题的案例研究：那些在产品层面看起来便利的 AI 功能，往往会在系统层面累积风险。承诺本身很简单。由 NPU 支持的本地 AI 应该能让敏感功能保留在设备上，而不是送到远程云端。但本地处理并不自动等于本地安全。这意味着威胁模型发生了变化。攻击者不再需要拦截云端流量，只要能够针对终端、用户会话，或在身份验证后传送解密信息的软件路径即可。
随着操作系统吸纳更多模型驱动功能，这种动态很可能反复出现。搜索、摘要、活动历史、预测辅助和代理型工具都需要数据收集、解释和检索的某种组合。如果这些系统要被信任，厂商就需要保护访问的整个生命周期，而不仅仅是静态数据库。
更新后的 Recall 批评并没有抹去微软之前的改进。按原文自己的表述，数据库保护比以前强得多。但它也强化了一个更残酷的事实：当一个功能被设计成几乎记住一切时，对实现层漏洞的容忍度就极低。每一个新的变通办法或进程薄弱点，都会从另一个角度重新激活同样的根本担忧。
- 微软此前在原始存储方案被发现不安全后，已经重做了 Recall。
- 据称，新工具瞄准的是 Windows Hello 身份验证之后、Recall 数据交给 AIXHost.exe 的阶段。
- 这一事件凸显出，即使加入更强的加密和选择加入控制，AI 功能仍可能存在风险。
Recall 也许最终会成为 Windows 的稳定组成部分。但如果真是如此，原因将不仅是微软证明了记忆本身受到保护，还要证明访问这份记忆所需的每一步也同样受到保护。
本文根据 Ars Technica 的报道整理。阅读原文。
Originally published on arstechnica.com
