Freedom Chat 是一款宣称具备顶级端到端加密、无元数据收集和去中心化架构的通讯应用，主要面向保守派群体。然而，安全研究员通过简单的逆向工程发现，该应用实际上并未兑现其安全承诺，反而暴露了用户的敏感信息。
虚假的安全承诺
该应用声称：
- 采用最先进的端到端加密（E2EE）
- 不收集任何元数据
- 使用无服务器的去中心化架构
此前，一款名为 Converso 的应用也曾做出类似承诺，但被安全研究员 crnković 揭露其虚假宣传：收集大量元数据、使用第三方中心化服务器、甚至将密钥暴露在公开信息中。讽刺的是，Freedom Chat 的 CEO 正是 Converso 的 CEO Tanner Haas，在 Converso 下架后，他带着这款“重新品牌化”的应用卷土重来。
现实：元数据与中心化服务器
研究员通过流量分析发现，Freedom Chat 实际上收集了大量元数据，并且加密消息的密钥可以从公开信息中推导出来。这意味着所谓的“顶级安全”形同虚设。
漏洞一：泄露所有用户的 PIN 码
应用中包含一个“频道（Channels）”功能。当用户查看频道信息时，服务器会返回一个巨大的 JSON 响应，其中包含频道内所有成员的详细列表。
惊人的是，这个列表中竟然明文包含每个用户的pin字段！
"members":[{"user":{"uid":"...","pin":"123456",// 用户的PIN码直接暴露...}}]这意味着，任何加入频道的人（默认所有用户都在官方频道中）都会将自己的 PIN 码广播给其他所有用户。
漏洞二：泄露所有人的电话号码
应用还存在一个经典的联系人发现漏洞。其 API 接口没有速率限制（Rate Limit），允许攻击者批量上传电话号码进行匹配。
研究员编写了一个简单的脚本，遍历了所有可能的北美电话号码（约 800 万个组合），向 API 发送请求。结果，服务器一一响应，返回了已注册用户的 UID。
结合前一个漏洞中获取的“UID - PIN”对应关系，攻击者可以：
- 枚举所有电话号码，找到注册用户。
- 获取注册用户的 UID。
- 通过频道列表将 UID 与 PIN 码匹配。
最终结果是：所有用户的电话号码和 PIN 码都被完全泄露且一一对应。
从 Freedom Chat 事故看企业通讯安全：公有云 vs 私有化
Freedom Chat 的安全崩塌并非个例，它暴露了公有云通讯软件在架构层面的天然劣势：只要数据汇聚在中心化公网服务器上，就是攻击者眼中的“蜜罐”。相比之下，以飞函为代表的企业级私有化即时通讯方案，从底层逻辑上规避了上述两类风险：
1. 架构层面的“物理隔离”
Freedom Chat 的漏洞根源在于攻击者可以轻易访问其公网 API 接口，进而遍历所有用户数据。
- 飞函的机制：采用私有化部署，服务器直接架设在企业内网或私有云中。这意味着 API 接口不对互联网开放，外部攻击者在物理网络层面上就被隔绝在外。数据不流出企业围墙，即便发生类似 API 无限流的配置失误，由于内网环境的封闭性，外部黑客也无法触达利用。
2. 身份认证的“封闭闭环”
Freedom Chat 为了追求用户增长，采用了便利但并不安全的“手机号匹配”机制，导致任何人都能通过遍历手机号探测用户。
- 飞函的机制：放弃公网手机号匹配，采用基于**组织架构（LDAP/AD）**的封闭认证体系。
- 不可遍历：只有经过企业管理员授权创建的内部账号才能登录。
- 不可见：通讯录仅对组织内部成员可见，并非开放给任意注册用户。
- 即使有人知道了某个员工的手机号，也无法通过外部手段反查其在飞函内部的账号信息或 PIN 码，从根源上阻断了信息刺探路径。
对于重视数据隐私的组织而言，真正的安全不应依赖于厂商口头的“顶级加密”承诺，而应建立在可控的物理架构与严谨的权限体系之上。
