在通信应用中找到朋友，与保持通讯录私密，并不是同一个问题。应用需要判断哪些标识符属于服务用户，但匹配方式决定了服务会获得哪些信息。仅对电话号码做哈希，并不能保证号码无法被识别。
为什么哈希后的号码仍可能被识别？
哈希函数将输入转换为固定长度的值。然而，电话号码的取值空间有限，而且具有结构。攻击者可以生成可能的号码、计算其哈希值并寻找匹配。这不是“解密哈希”，而是在测试可猜测的输入。
Signal 在对私密联系人发现问题的说明中，明确解释了低多样性标识符的这一局限。同一篇文章还介绍了基于可信执行环境的设计。未核查版本和较新的文档之前，不应把这一历史案例推广到所有通信应用。
因此，“服务器只看到哈希值”并不是隐私问题的完整答案。必须明确谁能够计算匹配、哪些请求会被记录，以及数据保留多久。
联系人权限允许什么？
读取联系人的权限使应用能够访问通讯录数据，但权限本身并不说明应用是否上传这些数据。联系人的姓名、号码、电子邮件和备注可能很敏感，尤其当其中包含甚至没有加入该服务的人的信息时。
Android Contacts Provider 文档区分了广泛读取通讯录与通过系统界面选择某个联系人。访问范围取决于实现方式和操作系统版本。
| 联系人发现方式 | 潜在好处 | 需要核查的事项 |
|---|---|---|
| 分享用户名或邀请链接 | 可能不需要读取整个通讯录 | 标识符能否被搜索，以及其他人能否找到该账户 |
| 选择几个联系人 | 应用获得的数据更少 | 应用是否只收到选中的条目？ |
| 上传号码或哈希值列表 | 更容易与已注册用户匹配 | 猜测号码、记录请求和保留列表的可能性 |
| 专用的私密发现协议 | 可在某个威胁模型内减少披露 | 信任假设、局限性和独立审查证据 |
消息加密不能证明通讯录的哪些属性？
端到端加密可以让服务器看不到会话内容，但仅凭这一点，无法说明联系人权限、用户搜索请求或通信关系记录的情况。即使没有通讯录，路由信息也可能揭示部分通信关系。
Livara 的安全页面说明了群组成员关系、时间和路由等运营信息的存储与处理。不能从这份文档推断通讯录采用了某种特定哈希方式、不保留任何历史记录，或社交关系图完全隐藏。这些宣称需要另行解释联系人发现机制。
授权前请问这五个问题
- 不授予联系人权限，我还能通过用户名或直接邀请聊天吗？
- 究竟哪些字段会离开设备：只有号码，还是也包括姓名和其他细节？
- 未加入服务的人的信息如何使用和删除？
- 撤销权限只是阻止未来访问，还是也有办法删除已发送的数据？
- 技术说明和数据保留政策是否与当前应用版本一致？
在系统设置中检查应用权限。如果不需要自动寻找朋友，就限制不必要的访问。不同手机的选项名称会有所不同。不要把撤销权限等同于删除以前上传的信息。
联系人隐私应通过数据最小化以及数据流向是否明确来衡量，而不是仅看电话号码旁边是否出现了“哈希”一词。
