@Highlights AirPods 试一下直接在蓝牙界面连接，至少我这边音量菜单完全切换不了了。一夜回到解放前

然后 iCloud 还有一个选项是生成一串密码让大家写在纸上记下来，如果选择这个选项，那么 Apple 就不会把根密钥存到云上的 HMS 里。

@agagega iCloud 端，Apple 说他们用了一个可编程 HMS 集群，把用户的 iCloud Keychain 密钥存在里面。这样的话，当用户双重验证完自己的身份后，就会把密钥传到新登录的设备上。

根据 Apple 的白皮书，这些可编程 HMS 的编程认证硬件都被销毁了，所以不用担心 Apple 可以修改程序读取这些信息😂。至于 Apple 的话可不可信，就由大家判断了。

@agagega 有一类专门的硬件干这个事情，硬件安全模块（ HSM ），它会保存密钥，用密钥加密数据，验证通过后用密钥解密，并且没有导出密钥的功能。我不知道显微镜什么的可不可以拿来尝试解密，我不太清楚技术细节，但应该要比硬盘恢复数据这样困难得多。iPhone 上的 Secure Encleave 就是一个 HMS 。

然后就是一个加密密钥金字塔。比如说 iPhone 文件系统 /硬盘的密钥，存在硬件模块里，这样 iCloud Keychain 的密钥就可以明文存在文件系统里而不用担心华强北把 iPhone 硬盘拆下来解密了。当然，这样会有别的安全隐患，只要 iOS 文件系统沙盒被攻破，密钥就会被泄漏，所以可以把 Keychain 根密钥寸 HMS 里面，而剩下的密钥用根密钥加密过后，存在硬盘里。

@alphatoad 我估计苹果一开始的计划就是尽快推端对端，然后弄一个 CSAM 满足一下执法部门，结果被反噬

但其实 Apple 的说法非常含糊，比如说，它们的文档提到 CloudKit 里面的大文件，CKAsset，是自动加密的，可按照这个说法，既然 iCloud Photos 和 iCloud Drive 都改成了 CloudKit 后端，那么这些东西应该也是端对端加密的，但 Apple 并没有这么说。另外一个事情是，我很好奇 iCloud Web 端的实现是啥，应该不至于在浏览器里同步 Keychain 吧。

楼主不知道 Keychain Access 可以看吗？虽然那玩意贼难用。

苹果：只在本地扫描上传到 iCloud 的照片
网友：垃圾公司居然本地扫描我全部的照片
路人：可人家说了只扫描上传到 iCloud 的照片啊
网友：苹果的话你也信？说着转手就关了 iCloud 继续心安理得的用 iPhone 。

搞不懂为什么有人会不信 iCloud 但相信 iOS 不会在后台做坏事……

头戴我的 Max 是真的不夹耳朵，也没觉得重，但夏天热死了

@guanzhangzhang 不是，那是啥

@persistz PSI 和 NeuralHash 其实是解耦的。PSI 解决的问题大抵是：
我有一个 KV list，你有一堆 key，你想知道我的数据里你的 key 的对应的 value，并满足：
- 我不需要上传完整的数据交给你处理
- 只有你有 key 的部分我才能需要交给你
- 但我又不能有遗漏，你有 key 的我都必须交
Apple 的思路是弄个程序跑在你的本地，把结果提交上去匹配，公开程序的算法以及证明。

@persistz 根据 Apple 的描述，它们是对 NeuralHash 做了进一步的 hash （传统 CS 意义），而加密密钥是通过 NeuralHash 推出来的，所以如果我有 NeuralHash A 的图片，你有 B 的图片，我们都分到了数据库 hash 123，那么我拿 A 衍生的密钥加密，打上标记 123，你找你服务器上的 123 对应的密钥，是根据 NeuralHash B 算出来的，无法解密

杭州这边，我们走了双方案，主方案靠阿里云 WireGuard，辅助用的是 Shadowsocks 。最近居家办公，把公司和几个员工家里的网都打通了，然后去咖啡厅的时候用 Surge 规则模式分流。

@Kagari wow 👏 确实是个安全隐患

说句老实话，即使不考虑内容审查，数据在存 iCloud 的同时，也应当做好备份，毕竟 Apple 可没有给你做任何 SLA 保证，丢数据了它大可完全不负责任。

@kop1989

2 、识别结果不呈现给用户，那么如何佐证与呈现“特征库”的识别范围？有没有监督机制？
3 、技术上如何呈现“关闭 icloud 就不会被匹配”？（毕竟匹配是本地的）

这里非常反直觉的是，识别结果不是不呈现给用户，而是不呈现给你的设备。理论上来说，就算 Secure Enclave 失效，本地计算结果暴露，根据 PSI 系统的构造，这些计算结果对 iCloud 服务之外依然没有任何意义。

虽然我懒得给 Apple 当免费公关，但我还是一一回应一下 @VIVVACI：

> 安全性。理论上，哈希是敏感的，一个比特改变就会产生不同的哈希结果，这个显然不符合 apple 的初衷，所以一定是采用了图像处理技术。也就是说，这个算法可以直接拿到我的相册的真实内容。这意味着如果程序设计出问题、有人做出漏洞，也可以看到我的相册内容。所以不安全。

只有当程序的计算结果泄漏隐私，且该信息流出，个人隐私才会被破坏。这里需要注意，足够多的脱敏信息是可以暴露隐私的。

@crazydd 其实提到一点，就是特征向量会泄漏信息。但是 NeuralHash 会对 CNN 提取的特征向量做进一步处理。即使如此，NeuralHash 还是可能泄漏个人信息，所以 Apple 通过 private set intersection 确保了 NeuralHash 只有在匹配了数据库才会泄漏。

> 可靠性。虽然图像处理技术是可以避免哈希的敏感程度，但是用神经网络的就会有对抗攻击，那么我在原始图片下加入某种噪声，人眼看几乎没有任何区别，但是可以让敏感图片脱敏，神经网络失效。同样的，如果别人用加了某种噪声的正常图片发给我，那么有可能可以做到恶意的诬陷。所以不可靠。

「但是可以让敏感图片脱敏，神经网络失效。」有漏网之鱼很正常，至少这样没有破坏隐私。

「某种噪声的正常图片发给我」人工审查还是可以兜底的，尽管不完美，这点所有人都承认。

这里有个**很严肃的问题**，就是其实有一种潜在的攻击方式，是提供图片的组织本身想匹配图像 A，然后合成出图像 B，后者看起来就是个普通的儿童色情图片。Again，人工审查可以兜底……

> 敏感的界定。如果父母，记录孩子的成长过程，比如第一次洗澡的纪录，是否会触发？

不会，因为这是图片匹配。

> 算力开销问题。我的本地设备要生成 hash，那么这部分的算力开销是我自己承担的，也就是我花钱买了一个对我完全没有任何益处的功能。耗电量？手机性能损失？发热？这些问题谁来负责。

对一张图片跑个 CNN，算个 hash，影响不大。Apple 的产品经理比你我更关心这个事情。

@Xs0ul LSH 的作用是用来匹配图片……所以如果你把 Tim Cook 的图片弄成黑白的存在手机里，然后再把它塞入 CSAM 数据集里，照样可以匹配成功的。因为 CSAM 数据集不可能有你自己拍的裸照（除非你传出去），所以不会被匹配到。

注意，这也是 Apple 被抨击的一个点，如果 Apple 有意无意的让儿童色情之外的照片进入数据集里，那这些东西也会被匹配，使得这套系统被滥用。

@haiironezumi Thanks!