使用 OnionShare 传递文件时的注意事项

OnionShare 是用于通过 Tor 进行文件共享和传递的工具。

它有时会在需要匿名性的场景中使用。例如，传递采访资料、接收内部举报资料、直接与对方共享文件。

在 OnionShare 官方网站上，可以确认应用的获取方式、功能、使用方法、支持环境。

URL : https://onionshare.org/

介绍 OnionShare 的理由，是因为它是在匿名通信和安全文件共享语境中实际使用的开源工具。

但是，使用 OnionShare 并不意味着匿名性就完成了。

如果文件内容、元数据、对方的设备、共享 URL 的处理、使用地点、通信前后的行为薄弱，就会从那里发生关联。

OnionShare 会改变什么

OnionShare 使用 Tor 网络与对方连接。

它不同于普通云端共享那样，把文件上传到大型云服务后再发送链接的方式。你在自己的设备侧开始共享，对方通过 Tor 访问。

这很方便，但不能高估它能够保护的范围。

OnionShare 不是会自动匿名化文件内容的工具。

OnionShare 的信任模型

使用 OnionShare，可以不把文件放到普通云服务商那里就进行共享。

这是一个很大的优点。在某些情况下，可以避开云端所有者显示、共享历史、浏览者日志、账号信息。

另一方面，信任对象并不会完全消失。你仍然需要信任自己的设备、对方的设备、Tor 的使用方式、共享 URL 的传递路径、文件内容。

OnionShare 在某些场景中可以减少信任对象。

但是，它不会消除所有信任。

确认文件内容和元数据

用 OnionShare 传递前，要确认文件。

PDF、Office 文件、图片、音频、视频、压缩文件中，可能残留创建者信息、评论、修改历史、GPS、拍摄时间、文件名。

即使使用安全的共享路径，如果传递的是危险文件，也没有意义。

文件要把原本和发布用、提交用副本分开。

注意共享 URL 的处理

在 OnionShare 中，需要把共享用的 onion 地址告诉对方。

用什么路径传递该 URL 很重要。如果通过实名邮件、工作聊天、平时使用的 SNS、组织管理设备发送，记录会留在那里。

即使 OnionShare 的 URL 本身不包含实名信息，如果传递该 URL 的路径薄弱，也会发生关联。

对方侧的环境也很重要

文件共享并不只靠自己一方完成。

如果对方在实名环境中访问、在工作设备上下载、把文件保存到云端、没有确认元数据就公开，信息会在共享后泄露。

OnionShare 是帮助传递路径的工具。

它不会自动保护对方侧的运营。

高风险用途要先决定步骤

用于内部举报或信源保护时，要在发送前决定步骤。

传递哪个文件。是原本还是副本。如何传递 URL。对方在哪个环境中接收。接收后保存在哪里。

不要启动工具之后再思考，而是在使用前决定步骤。

不宜使用的场景

OnionShare 并不总是最佳选择。

对方无法安全使用 Tor、对方设备处于组织管理之下、文件的证据价值需要专业判断、法律风险高、无法安全传递共享 URL。遇到这些情况时，有时应优先考虑其他接收入口或向专家咨询。

工具选择要符合目的和对方的能力。

不要因为能用就使用，而是确认它是否符合这次的威胁模型。

传递后的删除和记录

文件传递后仍然需要确认。

查看共享是否已经停止、对方是否已经收到、不需要的副本是否残留、URL 是否残留在别处。

但是，对于需要证据价值的资料，有时不应删除原本或传递记录。

在内部举报和信源保护中，要分开判断删除和保全。

总结

OnionShare 是用于通过 Tor 进行文件共享和传递的开源工具。

它的有用之处在于，可以不使用普通云端共享来传递文件。

但是，OnionShare 不会自动匿名化文件内容或元数据。也需要确认共享 URL 的传递方式、对方侧的环境、接收后的保存、公开时的元数据。

在需要匿名性的文件共享中，要把工具、文件、对方、共享前后的行为作为一组来确认。

相关工具

相关文章