文件传输工具的隐私设计原则
如何将隐私设计原则应用于文件传输工具，确保数据保护融入共享流程的每一个环节。
隐私设计（Privacy by Design）落实在文件传输工具上，意味着默认配置本身就能保护个人数据，用户无需手动调整任何设置。GDPR 第 25 条将其拆分为两个层面：第 25(1) 条要求在规划阶段就将技术保护措施嵌入产品；第 25(2) 条要求默认配置只处理必要数据、只向必要人员开放、只保留必要时长。落实到传输工具上，就是：默认启用客户端加密、到期时限不超过 30 天、最小化元数据采集、一键撤销分享链接。《个人信息保护法》（PIPL）第 19 条同样要求个人信息保留期限不超过实现目的所必要的时间，与这一思路高度吻合。
Cavoukian 七原则与传输架构的对应关系
Ann Cavoukian 20 世纪 90 年代提出的框架——主动而非被动、以隐私为默认、嵌入设计、全功能、端到端安全、可见性与透明度、尊重用户隐私——可以直接映射到文件传输的系统架构。主动：在部署前通过自动化 SAST 扫描检测弱密码。默认：AES-256-GCM 开箱即用，无退出选项。嵌入：加密在上传管道内完成，而非单独步骤。全功能：加密文件仍支持通过客户端解密实现预览。端到端：平台从不接触明文。可见：公开加密技术规格文档。尊重：用户自主控制保留期限和链接有效期。
第 25(1) 条：设计阶段的义务
第 25(1) 条要求在"确定处理手段时以及处理本身时"均采取隐私保护措施，也就是说隐私义务要在架构设计阶段承担，而非事后补救。在第一行代码落地前，就要确定传输协议（HTTPS/TLS 1.3）、密码套件（AES-256-GCM 或 XChaCha20-Poly1305）、密钥派生函数（PBKDF2-SHA-256 迭代 60 万次或 Argon2id）以及存储区域（欧盟境内）。将这些选择记录在架构决策记录（ADR）中，供后续工程师查阅约束背景。
第 25(2) 条：默认配置的义务
第 25(2) 条明确了四项默认要求：限制个人数据采集量、限制处理范围、限制保留期、限制访问权限。对于传输工具，具体体现为：仅采集发件人和收件人邮箱（不需要姓名、电话、地址）；文件处理完毕立即删除；保留 7 天而非永久；限制特定收件人访问，而非生成可被搜索引擎索引的公开链接。WeTransfer 免费版的公开分享链接便捷，但若无额外保障措施则不符合第 25(2) 条要求。
上传流程中的数据最小化
上传表单是数据最小化的起点。糟糕的设计：收集发件人姓名、公司、电话、收件人姓名、收件人公司、留言——每个字段都是存储和分析的个人数据。良好的设计：仅填写邮箱，留言字段可选，无跟踪像素。SwissTransfer 和 HexaTransfer 均采用极简表单；WeTransfer 和 Dropbox Transfer 则采集更多信息。如果无法在客户端剥离图片 EXIF 元数据，应在服务器端完成处理。若文件名本身包含个人数据，不要直接记录——对其哈希化后用于审计追踪，映射表仅存储在服务端。
性能不再是加密按需开启的借口
现代浏览器通过 Web Crypto API 运行 AES-256-GCM，在 2020 年前后的普通笔记本上速度可达约 200—500 MB/s，一个 100 MB 的文件加密耗时不足一秒。libsodium 的 XChaCha20-Poly1305 速度相近。"加密影响性能"不再是将加密设为可选项的理由。使用从用户持有的密钥派生的每文件密钥——基于密码或嵌入在 URL 片段（# 号后）的随机密钥，服务端永远看不到该密钥。可参考 Firefox Send（2017—2019 年）的成熟架构：URL 片段携带密钥，服务端只见密文。
假名化处理减少泄露面
GDPR 第 4(5) 条定义了假名化（pseudonymization），第 28 条建议在整个条例框架中推广使用。对于文件传输，假名化意味着替换系统元数据中的直接标识符：sender@company.com 在审计日志中以 SHA-256 哈希值存储，映射表另外存储在访问控制更严格的环境中。收件人同理。即使攻击者获取了审计日志，看到的也只是哈希值，而非完整的联系人图谱。映射表体量更小，保存在独立存储库中，受不同密钥和访问策略保护。
通过公开架构实现透明度
第 25 条并未强制要求开源，但透明度是隐私设计的核心原则之一。应公开：加密规格（算法、KDF、迭代次数、认证标签长度）、数据流程图、分包处理商名单及其所在司法管辖区、数据保留计划、违规通知时限以及审计日志结构。Proton、Tresorit 和 HexaTransfer 均发布了技术白皮书。含糊的"军事级加密"说法无法被验证，属于警示信号——如果供应商连使用的密码算法都不公开，应假设其安全性存疑。
用户控制权应是默认功能，而非付费功能
当隐私控制功能被锁定在付费套餐背后时，隐私设计便走偏了。密码保护链接不应收取额外费用，下载次数限制不应是高级功能，链接撤销不应需要联系客服。最基本的隐私保障——到期设置、密码保护、链接撤销、下载通知——应当免费提供，付费层级只在规模（存储空间、团队管理）或便利性（品牌链接、更长保留期）上有所提升。这既是 GDPR 合规立场，也是商业策略：用户更信赖让他们掌握控制权的产品。
审计日志本身也是个人数据
过度记录会制造新的泄露面；记录不足则无法满足 GDPR 第 33 条要求或依据第 5(2) 条证明合规。平衡点：记录事件类型、时间戳、文件 ID 哈希值、操作者 ID 哈希值、操作结果。不要记录完整 IP——IPv4 截断到 /24，IPv6 截断到 /64。不要记录完整 User-Agent——提取浏览器家族和主版本号即可。按安全与合规所需的最短周期保留日志（通常六个月），之后滚动清除。对日志传输管道实施端到端加密；访问日志本身也应成为一条审计事件。
上线前的安全态势验证
安排一位未参与开发的工程师做数据流审计。逐系统追问：哪些个人数据经过该系统？存储在哪里？保留多久？谁能访问？访问如何记录？如何删除？将答案与 DPIA 中记录的第 25 条承诺对照。针对既有架构做渗透测试——服务端是否真的只接触密文？URL 片段密钥是否真的不出现在日志里？声称站得住脚的隐私设计若失败这类测试，问题会迅速暴露。HexaTransfer 的 7 天到期配合客户端 AES-256-GCM 架构，能够经受检验，因为其技术实现与文档描述完全一致。
在 hexatransfer.com 上试试 — 免费、无需注册、最多 10 GB。