加密聊天之所以能够搜索，是因为获准读取消息的设备也可以搜索这些消息。一种常见设计是在解密后建立本地索引。但端到端加密本身并不能证明搜索查询绝不会离开设备，也不能证明所有即时通信软件都采用同一种搜索架构。
当搜索缓慢、较早的结果消失，或新手机找不到旧手机上仍能看到的消息时，这一区别很重要。搜索覆盖范围、密钥是否可用以及数据同步是不同的问题。
本地搜索索引如何工作
应用可以把可读消息转化为索引，记录哪些词出现在哪些消息中。搜索时查询该索引，而不是把每条消息从头到尾扫描一遍。SQLite 的 FTS5 文档介绍了一种全文索引技术；在此提及它，并不意味着某个 Livara 客户端使用 FTS5。
典型的本地设计有四个阶段：
- 下载或接收加密消息。
- 使用已授权设备的密钥解密消息。
- 将可搜索内容加入本地索引。
- 从该设备当前可用的数据中返回结果。
索引属于敏感信息。即使不保存完整句子，词语和引用也可能透露会话内容。其存储、备份、删除行为与访问控制应当受到与聊天数据库同等的重视。
服务器端搜索是否总意味着服务器能读取一切？
不是。普通的服务器端明文索引让服务能够访问被索引的内容，但它不是唯一可能的远程搜索设计。有关可搜索对称加密的密码学研究描述了在明确的安全模型下搜索外包加密数据的方法。
这些技术也有自己的假设和潜在泄漏。有价值的评估会询问：服务器能从重复查询、匹配记录、访问模式和结果大小中获知什么？“搜索发生在云端”和“数据已加密”都无法单独解决这些问题。
| 设计 | 实际益处 | 需要调查的问题 |
|---|---|---|
| 本地索引 | 无需远程查询即可搜索可用历史记录 | 索引是否在静态存储时加密，并排除在不安全的备份之外？ |
| 服务器端明文索引 | 对存储数据集中建立索引和搜索 | 谁可以访问内容、查询和日志？ |
| 加密远程搜索方案 | 可以对受保护数据支持特定查询 | 该构造允许哪些泄漏与信任假设？ |
| 公开与私密混合搜索 | 对公开内容和私密内容采用不同处理方式 | 用户是否清楚搜索范围？ |
不能根据这张表给速度排序。硬件、索引质量、消息量、网络延迟和具体实现都很重要。本文未开展任何计时基准测试。
为什么搜索中可能缺少消息
在认定历史记录丢失之前，先确认问题范围：
- 会话中是否能看到这条消息？ 如果看不到，搜索可能只是反映了历史记录不可用，而不是索引损坏。
- 是否选择了正确的会话或账户？ 日期、发送者和媒体筛选条件可能排除本应有效的结果。
- 新设备是否已取得历史记录和解密材料？ 恢复身份密钥并不自动等于恢复每一条消息。
- 索引是否已建立完毕？ 大量导入和同步中断可能影响覆盖范围。
- 搜索是否识别该词的形式？ 短语匹配、拼写、标点和不同语言的分词方式可能有所差异。
在自己控制的会话中使用无害且独特的测试短语。检查断网前后能否搜索到它。这可以确认有关本地可用性的一个有限事实，但不能证明应用在线时绝不会发送遥测或搜索数据。
关于 Livara 能说些什么？
Livara 的安全页面称，私密消息内容经过加密，而路由、成员关系、投递状态和密文支持同步。其公开文档不足以证明它使用某种特定本地搜索引擎、所有情况下都可离线搜索、完全没有查询遥测，或具有经过测量的电池影响。
公开频道与私密聊天的隐私边界不同。服务可以为公开内容建立索引，而不对私密会话作出同样的声明。在将全局搜索结果视为机密之前，请查阅威胁模型。
值得向服务提供者询问的问题
询问哪些消息会被索引、索引存放在哪里、查询文本是否被传输或记录、关联设备会收到什么，以及删除消息如何影响索引和备份。清楚的回答应指出具体客户端及版本，而不是依赖“端到端加密搜索”这个说法。
搜索是一项有自己数据流的功能。 应当将这条数据流与消息加密一并评估，而不是假定加密回答了有关搜索的所有问题。
