下游 GUI 的 CVD 订阅设备绑定与加密下发是否会泄露隐私

[ojibk]

Verification Steps

• I have read the documentation and confirmed that this feature is not implemented
• I have searched for the feature request I want to propose in the Issue Tracker and did not find it
• I am a non-Chinese user.

Description

了解了下 CVD 的核心工作原理，发现会收集硬件指纹，请问是否有隐私泄露的考虑？

CVD 方案引入了类似于网银、游戏设备锁的“硬件特征绑定”与“动态加密握手”机制：

[ 用户客户端 (拥有唯一硬件指纹) ]
│
├─ 1. 发起请求 (带上当前设备签名)
▼
[ CVD 下发关口 / 服务端 ] ── 2. 校验设备上限/解密指纹
│
├─ 3. 合法 ── 用该设备独有的密钥「动态加密」节点数据并下发
▼
[ 用户客户端 ] ── 4. 本地解密加载节点（其他人拿到该加密数据包也无法解密）
设备指纹绑定 (Device Binding)：当你第一次通过支持 CVD 的客户端下载订阅时，客户端会提取你当前设备的硬件特征（如主板UUID、网卡MAC的哈希值等）生成唯一的“设备指纹”传给服务器。服务器会将你的订阅与该设备物理绑定。如果超过了服务商允许的“最大设备数”，新设备将无法下发。

非对称加密下发 (Encrypted Delivery)：服务端发回的不再是普通的 YAML 明文节点配置，而是通过你当前设备专属的公钥加密后的密文。

防滥用与防抓包：即使你的 CVD 订阅链接被别人截获，或者别人把你下载好的配置文件盗走，只要他不是在你的电脑/手机上运行，由于缺乏匹配的本地硬件私钥，他的客户端会直接报错，完全无法解密和看到里面的节点。

[wwqgtxx]

所以CVD是什么东西？和我们有什么关系？

[ojibk]

所以CVD是什么东西？和我们有什么关系？

不是内核层面支持吗，是 UI 实现的？

[wwqgtxx]

内核永远不会支持这种打着为用户好的旗号来收集硬件指纹的行为，如果你发现有这种客户端欢迎举报，我们将在WIKI页明确警告用户不该使用该客户端

[ojibk]

内核永远不会支持这种打着为用户好的旗号来收集硬件指纹的行为，如果你发现有这种客户端欢迎举报，我们将在WIKI页明确警告用户不该使用该客户端

CVR 今天的自动构建版 v2.5.2+autobuild.0602.3283c04 新增了该功能，以为是内核支持的新特性。
可能 CVR 项目组没考虑到会泄露隐私，我去那边发帖讨论下。

鉴于CVR那边已经将讨论帖关闭并锁定，并删除部分回复，我们就在这里保留一些证据，并重申一下我们对 wonfen 提出的CVD的看法：

基于 wonfen 自己vibe出来的文档：

就连AI都能看出来， wonfen 设计之初的目的就不是为了所谓的"提高审查门槛"，而是想帮着机场实现精准控制用户

面对用户对于隐私问题的质疑

wonfen 的回应居然是

可以看到 wonfen 坚持将密钥设置为不可导出的，并声称

在我们看来，一个不可导出的、不能由用户自主控制的密钥无论从什么角度来说都和“安全、隐私、可靠”不沾边；而所谓的阵痛，与其说是为了推进反审查，不如说为了给机场主对客户端更大的掌控力，你用户权利的牺牲是不得不接受的

这里的回应就更是“先打靶后画圈”，如果CVD的私钥不从硬件指纹派生，那么任何一个第三方客户端都可以伪造一个合法CVD身份，对解决“订阅被人工抓取”问题毫无帮助；如果CVD的私钥采用DRM方式生成，那么就必然会和机器信息相绑定，将用户的设备信息直接上交给机场主

面对用户的质疑

wonfen 的回复更是令人大跌眼镜

合着您都把用户的设备信息上交机场了，就只是为了让管局烧点token花几分钟来vibe出一个能导出明文的实现？

---

此外，可以看出CVR项目组的其他成员并不认同 wonfen 的提案，是其为了自身利益强推上去的

通过git commit历史可知 Tunglies 才是目前CVR主要的代码维护者

而 wonfen 近期的提交除了更新赞助商信息，就是将默认urltest地址改成延迟更好看的cloudflare地址，甚至还是http的，这种美化数据的行为很难说对CVR项目有实质性贡献

所以我们有理由怀疑， wonfen 为了赚广告费已经失去基本的职业操守，完全不在乎用户权利而讨好机场主

其所说是 “对 cvr 的长远发展有利” 不如说是 对他靠着CVR的名气收广告费有利

毕竟这套设备绑定协议真正的好处是：机场主可以更好的控制你哪些设备可以获取订阅，准确的了解你的设备数，锁定你的使用设备，甚至未来您想更换个设备都可能成为续费付费才有的功能

引用一下原issue中的两段评论

CVR作为一个客户端软件试图去限制用户的自由，我们是不明白你到底是站在什么立场上做出这个决定的，是机场的广告费给的太多了么？

---

最终说一下我们的结论：

我们不反对订阅的加密下发，但：

• 任何客户端都 不该 控制用户密钥的生成方式
• 任何客户端都 不允许 限制密钥的导入导出
• 更 禁止 通过收集机器指纹信息来生成密钥

对于违反该原则的，我们将在WIKI页明确警告用户不该使用该客户端

对于CVR项目组，也请你们认真考虑一下，留 wonfen 在你们项目组到底合不合适，有这样一个只考虑机场主利益的member真的有利于项目未来的发展么？

[ojibk]

CVR没往客户端添加广告模块，只在项目页挂赞助，说明项目组非常克制，用户都是理解和支持的。
但是如果项目成员往客户端添加限制用户权力的私货或者是收集硬件信息，就是毁生态了，一旦这个窗口打开了，服务商可能会砸向更多GUI，于生态圈而言危害不可估量。