DRIVUNO 与 Dropbox 的真正区别

两种不同的架构 Dropbox 采用服务器端加密：文件以明文上传，到达后再加密，密钥由 Dropbox 管理。这使得预览、搜索、协作等功能成为可能，但同时也意味着提供商在技术上可以读取你的内容。

提供商在技术上可以做什么 - 在服务器端生成缩略图和预览 - 使用自动化系统分析内容 - 通过支持流程恢复账户访问 - 应法律请求交付明文内容

这并非丑闻 — 这是已记录的架构选择。但对于敏感文档而言，它与真正的机密性不兼容。

DRIVUNO 改变了什么 你的密码从不离开设备。它在本地通过 Argon2id 处理。每个文件都获得一个本地生成的唯一密钥（XChaCha20-Poly1305）。服务器只能看到密文。

Dropbox 何时仍然适用 对于非敏感协作、公开资料、没有机密价值的文件 — Dropbox 表现良好。这个对比只对真正需要保密的文件重要：合同、保密协议交付物、医疗记录、财务文档、私人照片、源代码、知识产权。

简单的规则 如果文件泄露会造成金钱、声誉或关系上的损失，密钥就应该在你手中 — 而不是在提供商那里。DRIVUNO 正是为此而构建的。

渐进式迁移更合理 DRIVUNO 并不打算取代 Dropbox。它打算与之共存。日常协作、公开素材、营销资料继续放在 Dropbox；真正需要保密的文件 — 合同、财务记录、医疗资料、私人照片、客户名单、源代码 — 迁移到 DRIVUNO。这是大多数专业人士采取的混合方案，也是最务实的方式。

关于元数据的诚实说明 即便是零知识架构，服务器也需要最少量的元数据：对象 ID、密文大小、时间戳、账户标识。这是配送文件并计费所必需的。DRIVUNO 把这一点写在文档里，并保证文件名、文件夹结构、标签、缩略图、OCR 文本这些"能透露内容"的元数据，绝不发送到服务器。这就是"诚实的零知识"与"营销的零知识"的区别。

与 Dropbox 的并存策略 你不必"二选一"。许多 DRIVUNO 用户继续使用 Dropbox 做团队协作，并把 DRIVUNO 专门用于敏感文档。两者解决不同问题，正确的答案通常是"两者都用"，而不是"取代"。

分享链接是如何工作的 DRIVUNO 生成的分享链接有一个特别的结构：解密密钥本身位于 URL 的"#"片段之后。根据浏览器规范，片段部分永远不会被发送到服务器。也就是说，即使你把链接复制粘贴发给别人，DRIVUNO 的服务器也从未接触过这把密钥。只有当接收方在自己的浏览器中打开链接时，本地才会进行解密。

法律与合规层面的含义 对企业而言，"提供商技术上能否读取数据"决定了在合规审计、法律请求、跨境数据传输和供应商风险评估中能给出什么样的答案。当提供商持有密钥时，答案永远是"是的，技术上可以，但我们承诺不会"。当提供商不持有密钥时，答案是"不，从架构上就做不到"。这是合规上完全不同的两种立场。

结论 本文并非在贬低 Dropbox。它在不同的设计目标下做得很好：协作和易用性。DRIVUNO 的设计目标是机密性 — 这两件事在同一个产品里很难同时做到最好。正确的做法是根据文件的实际敏感程度选用工具。

你应该问的唯一问题 评估任何云服务时，只需要问一个问题：「如果有人合法或非法地获得了对你服务器的完全访问权限，他能读到我的文件内容吗？」如果答案是"能"，那这项服务不适合你的敏感文件 — 无论它有多好用。DRIVUNO 对这个问题的回答是"不能 — 在架构上就不可能"。