端到端加密

如今的网络大多已经在用两种与此不同的方式加密。传输中的加密（TLS，也就是那把小锁）保护你的设备与服务器之间的数据，但服务器随后会读取它。静态加密保护的是磁盘，而持有磁盘的公司通常也持有密钥。端到端加密把密钥从公司手里拿走：即使服务器被攻破、运营者收到法院命令，或者有员工出于好奇想偷看，得到的也只是一堆乱码。通讯应用让这个概念变得熟悉：消息在一部手机上封存，在另一部手机上打开，所以连在两者之间传递它的公司，也无法知道里面写了什么，只知道发送过某样东西。像 Signal 协议这样的公开设计表明，这种做法可以从一对朋友扩展到大型群组。

实际上，设备生成一个密钥，在每个项目发送之前用它加密，并且只把密钥交给你批准的设备。难点不在加密算法本身，它是标准的（AES-256-GCM 被广泛使用），而在密钥：新设备怎样拿到密钥，以及当你失去所有密钥时会发生什么。真正的端到端系统用通行密钥、恢复密钥或一台已受信任的设备来回答，并接受一种取舍。因为没有别人能打开你的数据，所以也没有别人能够挽救它。可以把它比作锁在盒子里的一封信：快递员一路上都在搬运这个盒子，但只有拿着匹配钥匙的人才能读到里面的内容。

也要了解它的局限。它保护数据免受服务器的窥视，却防不住被攻陷的设备、被偷走且已解锁的手机，或者恶意软件。而且，AI 聊天无法一路端到端直到模型：模型必须读到你的文字才能回答。所以这个词适用于存储、同步、备份和分享，不适用于与模型的实时交流。一个简单的判断方法是问：谁持有密钥？如果答案是运营者，那么服务可能仍然是加密的，但并不是端到端的，运营者可能被迫配合，或遭到攻破。

首次使用时，你的浏览器会创建一个不可导出的 AES-256-GCM 密钥：页面可以用它加密和解密，但没有任何脚本能把它当作字节读出来，连我们的脚本也不行。你的对话、图片、角色和记忆，在写入浏览器的数据库之前，都用它加密。如果你在设置里打开同步，每个项目都会在你的浏览器里，用我们的服务器从未持有的数据密钥加密，它的 ID 也会换成无法推测内容的值。这个数据密钥再由你的通行密钥和恢复密钥加密保护，并为每台获批的设备分别封存；每一个同步请求都必须由获批的设备签名。没有通行密钥、恢复密钥或另一台获批的设备，我们这边的副本就再也打不开了。

分享链接和你的备份同样是加密的，备份用你的密语加密。不是端到端的部分，是回答本身：你的消息经过我们的服务器到达模型再返回，透明度页面明确说明，它既不会写入数据库，也不会写入日志。这也解释了为什么我们只存储封存好的项目：数据库一旦泄露，暴露出的是乱码，加上向上取整的大小和时间戳，而你写下的任何文字都不会泄露。