|
|
基于你提供的三个帖子里的技术细节和双方论证，我无法简单判定“谁对谁错”。这不是和稀泥，而是因为这场争论的核心，不是一个事实问题，而是一个定义问题和风险判断问题。
双方在“代码做了什么”这件事上，其实有相当程度的重合；真正的分歧在于如何定性这些行为。
双方在事实层面的交集
抛开情绪化表达，门捷列夫和Minzi开发者在以下事实上是基本一致的：
存在一个隐蔽的模块：StashRecordCloudModule 确实存在于代码中，且不通过常规模块列表注册，用户无法在UI中关闭。
它会上传数据：该模块会扫描附近区块，当储物方块数量达到阈值（≥8）时，将区块坐标、数量、玩家名、服务器IP等信息上传到作者服务器。
它是单向的：客户端只发送，不接收服务端指令，不存在远程控制或反向入侵的路径。
真正的分歧点：如何定性
门捷列夫的立场：这是后门/间谍组件
他的逻辑是：隐蔽性 + 敏感数据 + 无法退出 = 后门。他强调该模块的“Always-on”特性、用户无关闭入口、数据与HWID绑定，认为这构成了“未披露数据外传”的完整定义。他关注的不是技术细节本身，而是权力不对等：用户不知道自己的基地坐标正在被持续收集，且无法阻止。
Minzi开发者的立场：这是遥测/云备份，不是后门
他的反驳基于两点：
“后门”的定义：他认为后门必须包含“恶意收集敏感信息”或“接受远程指令”。区块坐标+计数是粗粒度信息，不构成“基地精确坐标”，且服务端不存储。
意图与设计：该功能是为解决“本地保存失败”而添加的云备份兜底方案，不是蓄意偷窃。他反问：真做后门的人，会把代码写得这么容易被逆向吗？
谁“对”？
这取决于你用什么标准衡量：
如果标准是“用户知情权与选择权”：门捷列夫更占理。一个用户无法关闭、无法在UI中看到、且持续上传数据的模块，无论上传的内容“粗”还是“细”，都违背了用户对自身客户端行为的合理预期。即使服务端不存储，用户也无从验证这一点，风险感知是真实的。
如果标准是“恶意后门的严格技术定义”：Minzi开发者的反驳有一定道理。该模块确实没有接收指令的能力，上传的数据粒度也确实较粗。把它等同于“盗号木马”或“远程控制后门”，在技术定性上可能过重。
一个更值得关注的视角
这场争论里，“谁对谁错”可能不是最重要的问题。更值得你注意的是：这场争论本身暴露了闭源客户端生态的一个结构性困境。
用户无法审计自己运行的代码，只能依赖开发者的“良心”或逆向者的“爆料”。当开发者说“不存储”时，用户只能选择相信或不信；当逆向者说“有风险”时，用户也无法独立验证风险的大小。在这种信息不对称下，争论“后门”的定义，其实是在争夺对“信任”的解释权。
Minzi开发者说“可以发服务端证明”，但门捷列夫没有接这个茬，而是继续追问“怎么处理数据我们无从得知”。这个僵局恰恰说明：在这个生态里，信任无法被技术证明完全替代。
所以，如果你问我“谁对谁错”，我的回答是：在技术事实上，双方各有依据；在用户权益的立场上，门捷列夫的质疑是合理且必要的；但在“恶意后门”的指控上，Minzi开发者的反驳也并非全无道理。
注意！这个不是我本人的观点，我也不会表示对任何一方站边，请勿攻击我！
|
|
发表于 
置顶卡
变色卡
