使用 Signal 用户名保护你的电话号码隐私

电话号码、用户名与匿名性

• 新功能允许用户分享“用户名 + 两位数字”，而不是电话号码；用户名只用于初次建立联系，不会显示在聊天中。
• 许多人欢迎能够向其他用户以及“谁在用 Signal”的查询隐藏号码。
• 也有很多强烈批评认为，注册仍然需要电话号码，而在许多国家，电话号码与政府身份证件紧密关联；一些人认为这使其不具备真正匿名性。
• 有人认为，基于电话的身份符合 Signal 最初“安全 SMS 替代品”的目标以及普通用户的预期；想要完全匿名的人被建议使用其他工具（Briar、Session 等）。

垃圾信息、滥用与账号验证

• 支持电话号码的一方：唯一且稀缺的标识符能让批量建号和垃圾信息更难；否则 Sybil 攻击就是“尚未解决”的问题。
• 批评者：电话号码可以批量低价获取，实际上并不能阻止垃圾信息，主要只是增加可追踪性，而不是安全性。
• 建议包括加密微支付、更好的产品级控制（消息请求、白名单）以及 CAPTCHA。

安全性 vs 可用性：强制更新与备份

• Signal 客户端大约 90 天后会失效，迫使用户更新，以确保协议和应用安全，并执行新的隐私规则。
• 支持者：向已知不安全的客户端投递消息，对一个“隐私”应用来说是不可接受的。
• 批评者：消息会悄无声息地停止工作，影响流量有限、经常旅行，或生活在应用商店可能被封锁的国家/地区的人；一些人认为这对压迫性政权下的用户不友好。
• 备份：Android 有本地加密备份，但离设备同步需要手动操作且很笨拙；iOS 没有真正的备份，只有设备到设备的迁移。很多人报告丢失了多年的消息；也有人认为长期存档与隐私目标相悖。

元数据、云存储与信任

• 官方说法：服务器只知道电话号码、注册时间和最后连接时间；“sealed sender”减少元数据。
• 多位发帖者称，自从引入 PIN 和云存储后，Signal 现在保留了加密的联系人图谱和个人资料数据，而隐私政策淡化了这一点；他们担心 AWS 托管以及合法访问或 SGX 风格攻击。
• 其他人反驳说，这些数据都是加密的，威胁模型本就假定服务器不可信，而且这仍然远胜于 WhatsApp/Meta。

中心化、联邦化与第三方客户端

• 围绕 Signal 的非联邦、单运营方设计与联邦式 Matrix/XMPP 之间展开了长期争论。
• 支持中心化：联邦化会让升级缓慢且混乱，破坏 UX，还导致 XMPP/Matrix 碎片化；Signal 想要的是一个单一、连贯、能“正常工作”的系统。
• 支持联邦化：总部位于美国的中心化服务是单点故障和控制点；人们认为 Matrix/XMPP 更有韧性，即使体验更粗糙。
• Molly 和 Session 之类的分支表明第三方客户端/服务器是可行的，但 Signal 不鼓励其他人使用其生产服务器。

对比与 UX 问题

• Telegram 因 UX、频道以及非号码式手柄而受到称赞，但也因默认并非 E2EE、服务器端可访问内容，以及与俄罗斯资金/国家的关联而受到严厉批评。
• Matrix 被视为强大且开放，但往往资源消耗大、易出错，并且对非技术用户来说令人困惑。
• 许多人抱怨过去当某人加入 Signal 时，联系人会收到通知，包括被拉黑/施暴的前任；一位 Signal 工程师指出，现在这项功能默认关闭，而且可以禁用可发现性。
• 反复出现的愿望：支持多手机号并完整同步历史记录、真正的跨设备备份、不依赖单一手机的桌面端，以及无需任何电话号码即可注册。