Siri 与私有推理:Lobsters 上 7 条把 Apple 「Private Cloud Compute」 钉死在「AI 谎言」标签上的高赞讨论(2026-06-15)
版权声明
本文为翻译/转载,原文使用 CC BY 4.0 协议发布。 原文作者:David Chisnall, fazalmajid, Vaelatern (Lobsters 评论者;发起讨论的 submitter 为 achivetta) 原文标题:The future of Siri, or: why private inference isn’t private enough 原文链接:https://lobste.rs/s/tylzdy/future_siri_why_private_inference_isn_t 原文发布:2026-06-13 22:50 UTC(发起讨论)/ 2026-06-14 03:19 – 2026-06-15 03:53 UTC(讨论 thread) 本博客不参与任何商业变现(含 ads / 付费 / affiliate),本译文遵循 CC BY 4.0 条款发布。
译者按
为什么选这篇:过去 48 小时,英文 AI/开发者圈把 Apple 「Private Cloud Compute (PCC)」 当成 Siri AI 与 Apple Intelligence 的隐私护城河反复宣传,媒体口径基本是「Apple 终于在 AI 时代把隐私做对了」。但 Lobsters 这条 7 条评论的讨论 thread 出现了一个有分量的「内部反对派」——David Chisnall 是前剑桥博士、写过 Confidential Computing 综述的资深系统工程师,他在 6 月 14 日凌晨 3:19 抛出 3000 字长文,开头一句就是「Apple has moved into the ‘lying to customers about the security properties of machine learning systems’ phase of the AI bubble」。fazalmajid 进一步把信任链拆到芯片层:Apple 自家设计的 Silicon 本身就是「不可信硬件」,签名链从根上就回溯到 Apple 自己。Vaelatern 用 Apple 公开 PCC 软件 artifact 的机制反驳:可以「不信任 Apple」也能用密码学验证 artifact 一致性。这三方的辩论,把 AI 私有推理(private inference)这条 2026 年最热的技术线,从「TEE 够不够」推进到「信任根(root of trust)由谁握」这个根本问题。
对中文圈读者价值:中文圈目前对 Apple PCC 的认知大多停留在「Apple 在 AI 时代比 Google / OpenAI 更重视隐私」的产品层面叙事。但 Apple Intelligence 已经在 6 月初的 WWDC 2026 上线 Siri AI 与 Genmoji / Image Playground 等端云协同能力,中国大陆用户即便翻墙也会触及:哪些 prompt 走端侧、哪些 query 必须送到 PCC、远程证明(remote attestation)到底证明了什么、你的数据是否被 Apple 用作 RLHF。这条 thread 提供了判断 Apple AI 隐私营销是否可信的工程级标尺。同时对国内做端侧大模型 / 私有化部署 / 信创 + AI 推理的同学,这是一份难得的「TEE 信任根 + LLM 推理」交叉学科讨论。
与本博客关联:本博客 6/7 写过 Meta AI 客服被一句话攻陷的 20,225 个 Instagram 账户事件(/blog/ai-newsletter-2026-06-07/),6/6 写过 OpenAI 把 Lockdown Mode 推向全量 ChatGPT 的 prompt injection 防御范式(/blog/tech-judgment-2026-06-06/)。本文与这两篇形成「AI 产品攻击面三件套」:① 用自然语言骗 AI 客服 ② 用 prompt injection 偷用户数据 ③ 用「隐私」营销把用户骗进 TEE 却默认信任硬件方。
正文
讨论背景
2026 年 6 月 13 日,Lobsters 用户 achivetta 提交了一篇 Matthew Green(约翰霍普金斯大学密码学家、布隆伯格终端长期博主)发表于「A Few Thoughts on Cryptographic Engineering」博客的文章链接:「The future of Siri, or: why private inference isn’t private enough」(Siri 的未来,或者说:为什么「私有推理」并不足够隐私)。文章核心论点是:Apple Private Cloud Compute(PCC)作为 Siri 与 Apple Intelligence 的云端推理后盾,本质上仍然把「数据能否被 Apple 看到」寄托在「Apple 不会作恶」的承诺上,而不是密码学上可验证的保证。Lobsters 讨论 thread 在 24 小时内跑出 28 分 7 条评论(最高赞 25 分,最低 ~ 分),形成了一次高质量的「TEE 信任根 vs LLM 推理」交叉讨论。
下面按讨论时间顺序,把 7 条评论逐条中文翻译。译文保留原 lobsters 评论者署名,对个别技术术语在译文首次出现处用括号附英文原词。
评论 1(David Chisnall,25 分,2026-06-14 03:19 UTC,~3000 字)
一句话总结:David Chisnall(剑桥博士、前 Microsoft / Apple 工程师,写过完整 Confidential Computing 综述)现身说法——「confidential cloud + ML」这条路在训练阶段就被多方数据泄漏问题卡死,推理阶段更不可能用后过滤(post-facto filtering)堵住隐蔽通道(covert channel),Apple PCC 是「目前最接近完美 TEE 的实现」,但一旦把深度神经网络(deep neural network)拉进系统,就没有保证。结尾直接下判词:「Apple 已经进入 AI 泡沫的『对客户撒谎 ML 系统安全属性』阶段。」
这是一篇非常好的综述。我以前在做机密云计算(confidential cloud computing)时,行业里突然兴起一波「机密机器学习」(confidential machine learning)的浪潮。我们造过一批带强保证的加速器:明确数据可以流向哪里、明确运行的代码是什么、明确什么数据可以被外泄出去。我们团队里偏 ML 那部分人得出的结论是:要让模型在多方场景下「不泄漏数据」,仍有一堆待解的开放研究问题。
确实存在一些重要的用例。例如,几家银行想联合训练一个共享的反欺诈模型,但彼此不交换交易明细。又如,几家医院想联合训练诊断模型,但彼此不交换患者数据。这两种场景下,你都希望训练出来的模型不泄漏任何东西。理想情况下,你还希望提供数据(加密、仅在 TEE 内解密)的某一方无法投毒——让自己拿到好模型、让其他人拿到一个被悄悄破坏的版本。用现有任何技术,都无法做出这种保证(理论上未必不可能,只是非常难,我们还不知道怎么做)。有一些有意思的方案,但它们都有同一个问题:随着匿名性提高,模型可用性会迅速下降。对有数百万用户数据、要训练一个不泄漏任何个体甚至小群体信息的模型来说,这点损失可以接受;但对只有几个朋友 / 同事、想避免彼此之间泄漏任何信息的小集合场景,这套机制完全帮不上忙。
而推理(inference)要难得多。要设计一个模型,让它能合并两个数据源、跑任意 prompt、且不泄漏数据——这是不可能的。关键点:无论你做多少后过滤(post-facto filtering),prompt 作者总能在回复里通过隐蔽通道(covert channel)把数据传出来。要实现这种隔离,唯一的前置条件是你先解决第一个问题:多方训练 + 强差分隐私保证。而我们目前对「小集合」场景根本不知道怎么解。
译注:差分隐私(differential privacy, DP)——一种数学框架,确保「数据库里少一条记录」不会显著影响任何查询的输出分布,从而让单条记录不可被反推。
请注意,以上所有分析都假设了一个「完美 TEE」:它跑的就是你以为它在跑的代码,用的就是你以为它在用的数据;它把结果加密发到唯一应该收到的人;密钥在线发放、不存在重放攻击的可能;没有任何侧信道或其他机制让运营方能破坏机密性或完整性。这种东西在实践中我们只是近似做到了——Apple 的 Private Cloud 是我见过最接近的一家,Google 的机密计算产品离这个水平差得很远。但即便如此,只要把深度神经网络(deep neural network)拉进系统,就没有保证可言。
看起来 Apple 已经进入了对客户撒谎机器学习系统安全属性的 AI 泡沫阶段。
评论 2(fazalmajid,~分,2026-06-14 04:32 UTC,~600 字)
一句话总结:fazalmajid 直接戳「完美 TEE + ML」假设——FHE 性能比明文计算慢 3 个数量级,且 Matthew Green 本人和 Chisnall 都承认「数据一旦跨系统边界就不受保护」。再补一刀:Apple 本质是一家广告公司,所谓的隐私承诺只是营销话术;当年 App Tracking Transparency(ATT)就把自家 App 排除在外。
理论上这件事可以用全同态加密(Fully Homomorphic Encryption, FHE) 做出来,但目前 FHE 比非隐私版本慢至少 3 个数量级。而且 Matthew Green 和 Chisnall 本人都点出:FHE 在数据跨越系统边界时也保护不了。
译注:FHE——允许在密文上直接做任意计算的密码学方案。理论上「数据不脱密也能算」,但开销巨大。
Apple 本质上是一家广告公司(「服务」收入是 Tim Cook 反复吹嘘的大头,而其中广告是很大一块)。它嘴上说的隐私承诺,纯粹是营销。最直接的证据:它把自己的 App 排除在 App Tracking Transparency(ATT)框架之外——理由是「我们不是第三方,我们是第二方(second-party)」,并对「什么算追踪」做了一个欺骗性的重新定义。
参考链接:https://mjtsai.com/blog/2022/11/09/analytics-in-apple-apps/
译注:ATT(App Tracking Transparency)——Apple 在 iOS 14.5 推出的隐私框架,要求 App 在跨 App 追踪用户前必须弹窗征求用户同意。但 Apple 自家 App 一直不受此约束,被广泛批评为「双标」。
评论 3(David Chisnall,7 分,2026-06-14 08:39 UTC,~200 字)
一句话总结:Chisnall 回应 fazalmajid:FHE 帮不上忙。哪怕 FHE 完美实现,它的保证力也不超过一个理想化的 TEE。而我(前一条评论)整个论证已经假设了 TEE 是完美的。
FHE 帮不上忙。哪怕 FHE 完美实现,它能给你的保证也不超过一个理想化的 TEE。我(前一条)说的所有内容,已经假设了 TEE 是完美的。
评论 4(fazalmajid,~分,2026-06-15 04:34 UTC,~190 字)
一句话总结:fazalmajid 反驳 Chisnall——你的威胁模型排除了 TEE 运营方,但我的威胁模型必须把 Apple 本身放进去。Apple + Google 控制着 TEE 运行的软件,控制着底下的硬件。
那要看 TEE 跑的是不是由第二方控制的软件——也就是 Apple(更准确说是 Apple + Google)。你的威胁模型排除了 TEE 硬件的所有者,我的威胁模型必须把 Apple 本身算进去。
译注:这里 fazalmajid 实际上把 lobste.rs 整条 thread 的根本矛盾摆到了台面上:Chisnall 假设 Apple 是 honest-but-curious(诚实但好奇)的对手,fazalmajid 假设 Apple 是 malicious(恶意)的对手——这两种威胁模型下,TEE 提供的保证完全不同。
评论 5(fazalmajid,12 分,2026-06-14 08:43 UTC,~1000 字)
一句话总结:fazalmajid 把「私有推理为什么不能信」拆成三段——① 远程证明(remote attestation)本质是 Apple 烧在自家芯片里的不可导出密钥,Apple 完全可以在烧录前复制密钥或在 CPU 留后门;② Apple Silicon 不是开源硬件,你无法验证「在跑的那个 CPU」对应「宣称的源」;③ Apple 官方对 PCC 的描述「必须由 Apple 签名的 trust cache」从根上把信任锚定到 Apple 自己。
我还是没搞明白——我凭什么要信「私有推理」?
据我理解,密码学给我的全部东西就是一条远程证明(remote attestation):某台 Apple CPU 在我的数据上跑了一段特定代码、且没干别的——这段证明是用 Apple 烧录在该 CPU 里的、不可导出的密钥签的名。但Apple 自己造的芯片——它完全可能在烧录密钥前复制一份密钥,或者在 CPU 里留一个能签发虚假证明的后门。Apple Silicon 根本不是开源硬件。即便它是,你也**没法验证「正在跑代码的那颗 CPU」**真的对应「宣称的源」。当对方根本不可信时,端到端加密意义不大。
译注:远程证明(remote attestation)——TEE 的核心机制。TEE 内的代码用芯片内置的密钥对「自身状态 + 正在运行的代码哈希 + 正在处理的数据」做签名,让外部 verifier 可以密码学验证「我跟你对话的对象确实是某段特定代码在 TEE 里跑」。整个机制的可信度完全建立在「签名的私钥没被复制」之上。
译注:不可导出密钥(unextractable key)——理论上烧入芯片后无法用软件读出,只能用于签名/解密。但「理论上不可导出」vs「物理上不可复制」是两个问题——前者靠硬件设计,后者要靠信任芯片厂。
引用 Apple 官网原文:
节点上能跑的所有代码,必须是已被 Apple 签名、且针对该特定 PCC 节点批准、且由 Secure Enclave 加载的 trust cache 的一部分,运行时不可被更改或修订。
**「被 Apple 签名」这件事之所以有意义,前提是你得信 Apple。
评论 6(Vaelatern,~分,2026-06-14 22:18 UTC,~470 字)
一句话总结:Vaelatern 反驳 fazalmajid——你不需要信 Apple。Apple 公开了 PCC 软件 artifact(声称上线前 90 天公开),你可以验证 A) 公开 artifact 跟实际运行的一致;B) 公开 artifact 本身没有明显问题。B 难做,但有了 A,B 才有意义。
译注:PCC 软件 artifact——Apple 在 2024 年首次公开 Private Cloud Compute 时承诺,会把 PCC 节点上运行的 OS 镜像、boot loader、关键二进制等以可下载形式公开,供独立研究者审计。这是 Apple 第一次为云端组件做这种级别的公开。
据我理解,有一种签名机制足以证明「公开 artifact 跟实际在跑的是同一个东西」。你不需要信 Apple,你只需要验证两件事:A) 原始公开的 artifact(Apple 声称 PCC 软件 artifact 会在它上线前 90 天公开**?)和实际在跑的是同一个;B) 原始公开的 artifact 本身没有明显问题**。B 难做,但只要 A 成立,B 才有价值。
译注:这段「90 天公开」是 Apple 2024 年首次发布 PCC 时做出的承诺。但 Vaelatern 写「?」表示他对这个具体时限也存疑——事实上 Apple 当时公布的镜像并不完整,很多底层二进制仍以「苹果会签发保证」的形式存在,并未真正开源。
评论 7(Vaelatern,~分,2026-06-15 03:53 UTC,~510 字)
一句话总结:Vaelatern 在评论 6 基础上追问——「原始公开 artifact 没被篡改」本身又靠什么保证? 它不过是一坨带签名的字节;签名本身是 Apple 硬件签的,我不信任那个硬件;所以一切都回到 fazalmajid 的「信任根」。Vaelatern 在文末追加了一段 UPD,承认自己可能误读了上一条评论,重新表述:「我怎么验证公开 artifact 跟实际在跑的是同一个?我手头所有的证据都是 Apple CPU 签的远程证明——而那颗 CPU 也是 Apple 造的。」
我怎么知道原始公开的 artifact 没被篡改? 它不过是互联网上某个地方的一坨带签名的字节。如果我不信那个签名,那它就只是「一坨字节」。理论上我应该信签名,因为签名是硬件签的——但我根本没理由信那块硬件。
UPD(2026-06-15 03:53 UTC):对不起,我可能误读了你的评论。我想表达的是:我怎么验证「公开 artifact 跟实际在跑的是同一个」? 我手头唯一的证据就是 CPU 给出的远程证明——而那颗 CPU 也是 Apple 造的。
译注:Vaelatern 这条 UPD 是整条 thread 的「回到原点」——他把 fazalmajid 提出的「信任根问题」重新表述得更彻底:Apple 用自己的硬件签自己的代码、自证自证、循环论证。即便公开 artifact 也只是把「我要信什么」从「Apple 的服务器」移到「Apple 公布的字节」——而这两件事的密码学保证都回溯到 Apple 自己的签名密钥。
讨论收束
thread 在评论 7 之后没有更多回复。整条讨论的演进路径:
- Chisnall(顶级评论):用「confidential cloud + ML」学术与工业经验,下判词「Apple 撒谎 ML 安全」
- fazalmajid:把 Apple 拉到「广告公司」+「TEE 软件的第二方控制者」位置
- Chisnall:澄清「假设 TEE 是完美的」——即默认 Apple 是 honest-but-curious
- fazalmajid:把威胁模型升级为 Apple 是 malicious
- fazalmajid:把信任根问题拆到芯片层(不可导出密钥、签名闭环、Apple Silicon 闭源)
- Vaelatern:用 Apple 公开 PCC artifact 机制反提案:「不必信 Apple,可验证 artifact 一致性」
- Vaelatern(UPD):再追问「artifact 本身的签名靠 Apple 硬件签」——一切回到信任根
7 条评论里,没有任何一条说「Apple PCC 足以保护 Siri 私有推理」。这是整条 thread 最值得中文读者注意的事实:当 lobste.rs 这类技术圈以「信任链拆到根」的方式审视 Apple AI 隐私营销时,找不到一个「够了」的答案。
译者注
关键术语解释
| 术语 | 英文 | 解释 |
|---|---|---|
| 私有推理 | Private Inference | 用户数据在不被服务方明文看到的前提下,完成 LLM 推理。是 Apple PCC / iPhone Private Cloud Compute / OpenAI 信通院版 GPT 等所有「云端 LLM 但承诺不偷看数据」方案的核心技术目标 |
| 可信执行环境 | Trusted Execution Environment, TEE | CPU 内的「黑盒」区域,OS / 虚拟机监控器 / 设备运营方都无法看到里面跑的代码和数据。Apple Secure Enclave、Intel SGX、AMD SEV、ARM Confidential Compute Architecture(CCA)都是 TEE 实现 |
| 机密计算 | Confidential Computing | 把整个 VM / 容器跑在 TEE 里,对云服务商隐藏数据 + 代码。Linux Foundation CCC(Confidential Computing Consortium)维护相关规范 |
| Private Cloud Compute | PCC | Apple 在 2024 WWDC 提出的方案,把 Siri / Apple Intelligence 推理从用户设备转移到 Apple 自家服务器的 TEE 内,并公开部分 OS 镜像供审计 |
| 远程证明 | Remote Attestation | TEE 内代码用芯片内置的不可导出密钥,对「自身状态 + 跑的代码 + 用的数据」做签名,让外部密码学验证「对面确实是某段特定代码在 TEE 里跑」 |
| 全同态加密 | Fully Homomorphic Encryption, FHE | 允许在密文上做任意计算的密码学方案。理论上「数据不脱密也能算」,但目前比明文计算慢 3-6 个数量级,主流生产部署仍不现实 |
| 不可导出密钥 | Unextractable Key | 烧在芯片硬件里的密钥,理论上软件无法读出。Apple Secure Enclave 的根密钥就是这种。但「理论上不可导出」≠「物理上不可复制」 |
| 隐蔽通道 | Covert Channel | 绕过显式信息流控制、通过副作用(响应时间、错误模式、token 选择偏好等)传递信息的通道。在 ML 推理里,prompt 作者可以通过精心构造的输入让模型在合法输出里夹带编码后的敏感数据 |
| 差分隐私 | Differential Privacy, DP | 一种数学框架,对查询结果加噪声,确保「数据库里少一条记录」不会显著影响任何查询的输出分布 |
| 信任根 | Root of Trust | 一条信任链的起点,必须无条件被信任。TEE 的根是芯片内置的不可导出密钥;如果根不可信,整个链条的保证全部失效 |
与中文圈 AI 隐私议题的对照
- 国内端侧大模型 + 私有化部署:中文圈做「企业私有 LLM 推理」通常使用 vLLM / TGI 跑在自有服务器上,完全绕开 TEE——因为硬件方就是企业自己。这等价于 fazalmajid 说的「自己控制 TEE 运营方」场景,安全模型反而更清晰。
- 国内「信创 + AI」栈:海光、鲲鹏、飞腾等国产 CPU 都在做 ARM CCA / 自家 TEE 扩展。但信任根同样在中国厂商——对国内用户来说这没问题(因为已经是「自己人」),对跨国企业来说就成了另一个「要信谁」的选择。
- iPhone 国行 vs 非国行 Siri AI:2026 年 6 月 Apple Intelligence 已经在国行 iPhone 灰度推送。国行 Siri AI 的 query 是否走 PCC、PCC 节点是否在国内、Apple 是否在国行做特别的数据保留政策——这些细节 lobste.rs thread 没讨论,但对中文圈用户更直接相关。
- OpenAI 信通院版 / 阿里通义 / 字节豆包 的「私有化部署」:这些方案的「私有」通常是「模型权重私有」+「推理数据不上云」,但对 OpenAI / 阿里 / 字节 本身的工程团队,仍无法实现密码学级别的不可见——除非它们也用 TEE。
后续可关注的延伸问题
- PCC artifact 公开的真实完整性:Vaelatern 追问后,Apple 是否有任何回复或补充公开镜像?
- OpenAI / Google 的同位方案对比:OpenAI 的「ChatGPT Enterprise 数据保留政策」、Google Gemini 联邦推理(Federated Inference)走的什么 TEE 路线?
- 国内监管视角:中国大陆《生成式 AI 服务管理暂行办法》对「用户输入数据保护」的要求,与 Apple PCC 的密码学保证是不是同一件事?
- 社区能否复现 PCC 实验:是否有人能独立复现 Chisnall「Apple 是最接近完美 TEE 的实现」这一论断?
延伸阅读
站内相关文章,按主题相关度排序:
- AI 热点快报:Meta AI 客服被一句话攻陷 20,225 个 Instagram 账户(2026-06-07)—— 同属「AI 产品 + 隐私 / 安全」议题,可与本文形成「TEE 端 vs 客服 AI 端」两条隐私攻击面对照:
/blog/ai-newsletter-2026-06-07/ - 技术热点判断:OpenAI 把 Lockdown Mode 推向全量 ChatGPT,AI 产品的「安全默认」范式正式成形(2026-06-06)—— 与本文构成「OpenAI 的安全档位 vs Apple 的硬件 TEE」两条产品安全范式对照:
/blog/tech-judgment-2026-06-06/ - AI 热点快报:Miasma 蠕虫攻陷 73 个微软 GitHub 仓库,AI 编程 Agent 本身成为新的供应链攻击面(2026-06-10)—— 同样讨论「AI Agent + 信任根」问题,攻击面是开发者工具链:
/blog/ai-newsletter-2026-06-10/ - 技术热点落地:白宫 72 小时关停 Claude Fable 5 / Mythos 5 之后——多模型 Provider 路由与 Fallback 架构实战(2026-06-15)—— 单点闭源 LLM 的「行政命令式」风险,补充了「AI 供应商信任」的另一面:
/blog/tech-implementation-2026-06-15/ - 技术热点落地:月之暗面 Kimi K2.7-Code 开源(2026-06-13)—— 当模型权重完全开源 + 部署完全私有化时,「信任根」问题反而消失,可与本文 PCC 形成正反对照:
/blog/tech-implementation-2026-06-13/