内部举报者的匿名性

发布流程

内部举报中最危险的是，以为“只要不写名字就是匿名”。

内部文档、访问权限、分发范围、作者信息、编辑历史、内部术语、发布时间、联系路径。这些都会成为缩小举报者候选范围的材料。

在内部举报中，对方不一定是普通读者。

组织内部日志、文档管理系统、邮件历史、出入记录、设备管理、访问权限，可能有人处在能够查看这些信息的位置。需要考虑的不只是公开信息，还要考虑会与组织内部记录进行核对。

本文整理内部举报者思考匿名性时应查看的范围。

在需要法律判断或安全判断的场景中，不要只根据本文决定行动。重要的是使用适合具体情况的咨询对象，例如律师、劳动咨询窗口、可信的新闻机构、支援团体等。

一般的匿名发帖中，对方多半会寻找公开信息或 Web 上的线索。

在内部举报中，除此之外还会使用组织内部的信息。

谁能够访问那份文档。谁参加了那场会议。谁属于会使用那种表达的部门。谁在那个时间操作过终端。即使这些信息外部人员看不到，在组织内部也可能被确认。

在内部举报的匿名性中，重要的是不要低估对方的能力。

“从外部看不出来”，并不等于从组织内部也看不出来。

处理内部文档时，直接发送原件会带来很大风险。

Office 文件、PDF、图片、截图中，会残留正文以外的信息。包括作者名、编辑历史、评论、文件路径、模板名、创建日期时间、打印信息、内部标识符、水印、分发编号等。

在公开或提交之前，要把原件和工作副本分开。

原件有时需要作为证据保存。另一方面，对于交给外部的文件，要确认元数据、特定表达、标识符、文件名、图片中的映入内容。

但是，在证据价值会成为问题的场景中，随意加工会引发其他问题。

法律程序、劳动问题、刑事案件、重大的公益举报中，应向专家确认哪些要加工，哪些要作为原件保留。

在内部举报中，发送对象和发送路径非常重要。

如果直接发送到个人社交媒体账号、普通邮件、云端共享、匿名论坛等地方，会留下通信日志和账号信息。即使对方出于善意，只要接收方的运营薄弱，信息也会泄露。

有些新闻机构和 NGO 准备了接收匿名信息提交的机制。

SecureDrop 是新闻机构和 NGO 用于接收匿名信息提交的开源系统。它以通过访问、减少元数据、加密提交为前提进行设计。重要的是从已部署该系统的组织官方页面进入，并按照说明操作。

GlobaLeaks 是用于建立内部举报平台的自由、开源软件。新闻机构、团体、公共机构、企业等，有时会把它作为举报受理机制来使用。

Tor Browser 用于让连接目标难以直接看到用户的 IP 地址。在 SecureDrop 等匿名提交系统中，有时会以使用 Tor 为前提。

介绍这些，是因为它们是内部举报中实际使用的接收窗口。

但是，并不是使用工具就完成了匿名性。从职场终端访问、用实名账号搜索、使用公司的 Wi-Fi、直接发送原始文件、提交后立刻采取不自然的行动。这类失误会削弱工具的效果。

内部举报中最需要避免的是，无意识地使用由组织管理的终端或网络。

公司或学校的 PC、工作手机、内部 Wi-Fi、、MDM 管理终端、邮件账号、云存储中，会留下日志和管理信息。

组织管理的环境不一定站在你这边。

如果思考匿名性，就要分开处理终端、通信路径、账号、文件。具体需要分离到什么程度，会根据风险大小而变化。

高风险情况下，应遵循专家或可信接收窗口的流程。

即使删除了元数据，也可能从正文缩小候选范围。

内部举报的内容中，会包含只有少数人知道的信息。会议名、部门名、日期时间、案件编号、文档措辞、相关人员的表达、现场情况。如果这些直接出现，就会开始推理“谁能够访问这条信息”。