端到端加密限制服务商能够读取的内容，却没有涵盖对话可能存在的每一个地方。
针对消息服务商的法律请求，可以涉及其持有或能够访问的记录。端到端加密可以使私人消息的可读内容不在服务商掌握之中，但不会让账户匿名，也不会阻止调查人员从其他地方获取信息。
结果取决于服务实际的数据保留情况、使用的通信功能、证据来源以及适用的法律程序。传票、搜查令和设备检查并不能互相替代。本文解释的是技术边界，而非某个法院或司法辖区将如何处理案件；遇到实际请求时，应寻求合格的法律意见。
先看数据来自哪里
“警方能读取加密消息吗？”这样的问题过于宽泛。应当问，副本会从哪里来：
| 来源 | 可能获得的内容 | E2EE 改变了什么 |
|---|---|---|
| 消息服务商 | 账户记录、已存储的元数据、公开帖子和加密投递数据 | 在服务商没有密钥时，正确实现的 E2EE 限制其访问私人明文 |
| 参与者的设备 | 显示的对话、本地数据库、下载的文件或通知 | 传输中的加密不会隐藏已可在能够访问的终端上取得的数据 |
| 备份服务 | 按该备份自身的加密和密钥政策，备份中包含的任何内容 | 聊天 E2EE 并不会自动建立备份 E2EE |
| 接收者或群成员 | 他们的副本、截图、导出内容或证言 | 接收者可以披露自己收到的信息 |
这些类别可能重叠。没有可读私人历史记录的服务器，仍可能持有有用记录；保留大量记录的服务商，也可能已经依据保留政策删除某一项数据。仅凭加密标识无法推断任何一种结果。
一个有记录的例子：Signal 公开的回应
在其 2021 年 10 月加利福尼亚州大陪审团请求披露中，Signal 说明，它提供的是账户创建时间戳和最后连接日期，而不是请求中的消息、联系人和群组信息。这证明的是 Signal 在那次已披露回应中能够取得的记录。
这并不能证明每个加密消息应用都保留同样两个字段。数据最小化是独立的架构选择。这个例子也无法告诉我们调查人员能从用户设备、其他参与者或另一项服务获取什么。
Livara 如何说明服务器可见范围
Livara 标注适用于版本 0.1.68 的安全概览，描述了受 LVR1 保护的私聊消息和受 LGS1 保护的兼容私人群组；旧的不兼容群组仍会明确显示不受 E2EE 保护。其附件设计文档说明，文件在上传前加密，密钥通过加密的对话封装传递。
同一概览列出了保留的通信元数据，包括发送者和目标信息、时间戳、大小及群成员关系。公开频道可由服务器读取。可选的服务器录制通话会明确标示 REC，在这种录制模式下使用的是传输加密，而非 E2EE。应阅读具体功能的边界，而不是把同一应用里的所有内容一概而论。
文档还说明，LSS1 元数据保护并未接入普通发送流程。因此，声称正常消息通信会向服务隐藏通信关系图，将会产生误导。
这些是产品文档中的声明，不是针对法律要求公开的回应，也不是对每一条服务器记录的独立审计。威胁模型才是理解预期边界的适当起点。
加密与保留回答不同的问题
加密问的是谁拥有解释已存储字节所需的密钥；保留问的是哪些字节和记录仍然存在。加密文件可以长期保存，可读日志也可能只存在很短时间。“我们无法解密消息”的声明，并不能证明没有 IP 地址、支持对话、滥用举报或投递记录。
有用的透明度报告应注明报告期、请求类别、所要求的记录、实际提供的记录以及披露限制。隐私政策应区分收集与保留，并解释例外。不要从笼统的隐私承诺推断“无日志”。
身份认证也有自己的记录。SRP 可以在诚实的协议交互中避免发送密码，但服务器仍保留验证值。RFC 5054 第 3.3 节解释了验证值被盗的风险，包括密码猜测。“没有明文密码”不等于“没有任何敏感信息可被披露或窃取”。
依赖消息应用之前应问的问题
- E2EE 是否覆盖当前这一具体聊天、备份、通话和附件模式？
- 服务商文档列出了哪些元数据，保留多久？
- 其他设备或账户恢复路径是否可能暴露本地副本？
- 公开帖子、支持提交内容和被举报消息是否分开处理？
- 是否有注明日期的透明度报告或实际披露的请求，而非没有依据的法律豁免声明？
对于正在处理的法律事务，不要把博客文章当成擦除记录、更改保留设置或无视命令的指示。应获取适用于相关司法辖区的意见，并按照建议保全相关材料。
后量子加密会改变答案吗？
它可以加强设计得当的密钥建立协议，使其更能抵御未来针对已捕获密文的量子攻击。它不会移除现有元数据、公开内容、终端副本或法律义务。实际区分仍然是：识别数据、其位置、密钥，以及请求访问的程序。
