评估通话安全时，不要只问“是否加密”；还要问加密在哪里终止，以及录制会带来什么变化。
仅有聊天加密，并不能证明音频、视频、屏幕共享或通话录制也受到同样的保护。评估通话时，应问清楚：媒体在传输到哪里之前始终保持加密，谁掌握密钥，以及启用录制等功能会改变什么。
本指南将安全声明拆分为可核查的不同层面；某个协议的名称或一个锁形图标，不能代替这些问题的答案。
同一个应用中的三条不同路径
| 路径 | 数据示例 | 安全问题 |
|---|---|---|
| 可存储的消息 | 文字、照片、文件和语音消息 | 谁能读取设备、服务器和备份中的副本？ |
| 实时媒体 | 麦克风音频、视频和屏幕共享 | 加密在接收方设备上终止，还是在中间服务器上终止？ |
| 信令 | 通话邀请、应答和连接协调信息 | 谁能修改控制消息或目标方的身份？ |
在聊天中发送的语音消息是一个文件；语音通话则是实时流。产品可能为两者使用不同的密钥和机制。音质良好或文字消息未送达，本身也不能说明另一种通信方式的安全性。
DTLS-SRTP 能说明什么？
在 WebRTC 中，SRTP 保护媒体流，DTLS-SRTP 则是为其建立密钥材料的一种方式。RFC 5764 说明了 DTLS-SRTP 的机制，RFC 3711 说明了媒体数据包的保护方式。
但仅凭“我们使用 WebRTC”，无法判断会议服务器是否会解密媒体。必须明确加密的端点及其身份验证方式。用户与服务器之间的连接可能经过加密，但服务器仍可能为了处理或录制而访问解密后的内容。这与参与者之间的 E2EE 并不相同。
RFC 8827 中的 WebRTC 安全架构 还表明，除了媒体保护之外，对 Web 应用的信任、信令路径和对方身份也很重要。数据包经过加密，并不意味着产品的所有组件都值得信任。
为什么必须单独评估信令？
信令负责协调谁与谁通话，以及如何建立连接。即使应用保护了控制消息，也仍需检查这种保护如何与参与者的真实身份和媒体密钥绑定。
阅读文档时，问以下三个问题即可：
- 邀请、应答和密钥信息是否受到防篡改保护？
- 用户如何知道密钥属于自己想联系的那个人？
- 密钥或设备发生变化时，会显示什么警告？
即使是 E2EE 通话，服务也可能知道路由信息、时间和通话成员。消息应用元数据详解一文讨论了这种区别。
通话录制构成了新的安全边界
“加密通话”并不能完整回答录制副本的安全问题。参与者可以用自己的设备录下声音或画面。服务器端录制也应有单独的文档说明：服务器是否为了录制而获得可读取的媒体内容？谁保管文件？什么时候删除？
如果启用录制会改变安全模式，就应让参与者清楚地看到这种变化。在讨论敏感话题前，应确认录制状态和各方的同意；内置录制指示未亮起，并不保证没有人用其他设备录制。
如何阅读 Livara 当前的文档？
Livara 安全页面 将直接通话和群组通话描述为 E2EE，但将可选的服务器端录制列为例外：在可见的 REC 模式下，通话保护会变为传输加密。这是产品文档中的声明，并非本文进行测试或独立审计得出的结论。
旧文中将所有群组通话限制为“Android 上的 2 至 6 人”，与当前文档不符，因此本指南不以此为依据。针对所需的容量、平台和版本，应查阅当前指南并检查应用的实际行为；本文不提供容量测试。
同样，仅凭 ML-KEM 等聊天算法的名称，并不能证明通话媒体也使用相同的算法。若要声称通话具备后量子安全性，就需要针对媒体路径和身份验证的专门证据。应结合功能页面阅读 Livara 威胁模型，而不是用它代替独立测试。
比较两项服务前的简短清单
每项回答为“是”时，也应记录版本名称和来源：
- 是否分别说明了双人通话、群组通话和屏幕共享？
- 是否明确说明服务器只是转发数据包，还是也能解密媒体？
- 是否可以核查参与者的身份和密钥？
- 更换设备、加入成员和开启录制时，是否有明确提示？
- Web 端与应用中的通话路径相同，还是存在差异？
- 是否说明了录制文件和元数据的保留方式？
- 测试或审计证据是否针对同一个版本和同一项功能？
如果文档中没有答案，就写“未知”；缺少答案既不是安全的证明，也不是窃听的证明。
常见问题
E2EE 通话能阻止对方录制吗？
不能。获得授权的接收者能够访问可读取的内容，并可能使用软件工具或其他设备将其录制下来。
传输加密不好吗？
传输加密对防止传输路径上的窃听提供了重要保护。区别在于，作为端点的服务可以访问解密后的内容；不应将其称为用户之间的 E2EE。
聊天使用后量子加密，就意味着通话也具备后量子安全性吗？
不是。声明必须针对同一层面、同一组算法和同一实现版本。请分别评估聊天与通话。
