磁盘副本、对服务器的实时控制和对手机的访问是三种不同情形；一个笼统保证无法涵盖三者。
如果一款消息应用的服务器被控制，“哪些内容会泄露？”的准确答案取决于所存储的数据、密钥所在位置以及攻击者的访问类型。取得磁盘副本，与实时控制服务及应用发布渠道，并不是同一回事。
本文依据 Livara 的公开文档讨论一个假设情景，并不对 Livara 数据中心的位置、是否发生过查封，或服务在互联网中断期间能否保证运行作出断言。内容加密、网络可用性与基础设施安全是不同问题。
首先明确访问类型
**服务器的存储副本：**攻击者能够访问该副本所包含的文件、数据库或备份。如果私密内容已在设备上正确加密，且服务器不掌握解密密钥，仅持有该副本本身并不会暴露聊天明文。
**主动控制服务：**除读取现有数据外，攻击者还可能阻止某些请求、返回旧数据，或改变受控组件的行为。在这种情景下，核对联系人的身份、版本控制以及客户端完整性更加重要。
**同时访问设备：**未锁定的手机、恶意软件，或聊天成员持有的可读副本，可能通过完全不同的路径暴露内容。Livara 的威胁模型也不保证保护未锁定或已感染的设备。
根据 Livara 文档，服务器能看到哪些数据？
标注版本 0.1.68 的Livara 安全页面将 LVR1 直接聊天及兼容的 LGS1 私密群组内容，与运行所需的信息区分开来。同一页面明确说明，不兼容的旧群组仍不在端到端加密范围内，因此必须检查具体聊天的状态。
| 数据类别 | 文档所述边界与可能的后果 |
|---|---|
| 受保护聊天的文本与附件 | 服务器保存加密副本；读取需要相应密钥 |
| 通信元数据 | 服务可以获取通信双方、时间、大小及投递状态等信息 |
| 群组成员关系 | 属于服务器运行信息与操作权限的一部分 |
| 公共频道 | 内容公开，服务器可以读取 |
| v7 身份恢复包 | 上传前加密，需要独立的恢复秘密 |
| 可选的服务器端录制模式 | 通过 REC 标记与 E2EE 模式区分，不能假定其具有端到端隐私性 |
文档提到了保护元数据的 LSS1 代码，但它尚未接入普通消息发送流程。项目中出现某个协议名称，并不能证明它已在所有通信中启用。
此表描述的是产品声明，而非真实查封测试的结果，也不是对所有数据库副本开展独立审计的结论。
元数据可能有多重要？
人与人之间的联系、时间和群组成员关系等信息，即使没有消息文本，也可能十分敏感。不过，如果不了解保留期限、日志覆盖范围和取得的数据副本，就不能准确地声称“整个通信关系图会永久泄露”。
真正的评估需要询问：收集了哪些字段、保留了多久，以及哪些备份可被访问。内容加密本身并不决定数据保留政策，也不能根据一款消息应用的架构推断所有消息应用必然保存相同的元数据。
控制服务器会给未来消息带来什么风险？
安全评估应分别测试篡改成员列表、提供不同的身份密钥、阻止更新以及投递恶意客户端的情况。每种攻击的效果，都取决于客户端验证、变更展示和身份确认。
没有实现测试，不能说每台被控制的服务器都必然能够加入隐藏成员；同样，也不能说主动控制服务器毫无影响。对于敏感聊天，应调查意外的身份或成员变更。通过独立且可信的渠道与联系人比对密钥指纹，比仅信任显示名称能提供更多信息。
如果攻击者改变设备上运行的代码，就可能在文本加密前看到它。因此，应用发布与更新的安全性是这一情景的一部分，而不是与密码学无关的问题。
后量子特性增加了什么？
针对 ML-KEM 的NIST FIPS 203 标准有助于建立共享秘密。在混合方案中正确使用它，可以降低某些未来密钥交换攻击的风险。但这一特性不能替代设备安全、有限的元数据保留，或服务器访问控制。
Proof Lab也仅展示部分本地 P-256、HKDF 和 AES-GCM 操作，并将完整的 LVR1/LGS1 组合排除在该实验范围之外。测试成功并不保证整个产品能够抵御基础设施被控制。
在评估或真实事件中应如何行动？
- 记录访问类型与已确认的信息；不要把中断传闻等同于已确认的安全事件。
- 检查应用版本及具体聊天的加密状态。
- 通过官方渠道检查身份变更、群组成员变化和不明会话。
- 不要为了所谓的“安全检查”向陌生人提供恢复秘密、密码或私密内容。
- 面对严重风险或法律问题，请寻求适当专业人士的帮助，不要仅凭一篇文章采取不可逆的行动。
可靠的结论应说明：哪些数据、在哪个版本中、针对何种访问得到了保护。“即使服务器被查封也什么都不会发生”不能替代这样的回答。
