匿名性没有完美，但可以减少漏洞
没有人能够承诺完美的匿名性。
对方的能力、通信环境、服务日志、过去信息、设备状态以及本人的行为，都会改变具体情况。
但是，认为“既然不完美就没有意义”也是错误的。
匿名性会随着漏洞减少而变强。即使无法消除一切，只要减少对方可以用来关联的材料，风险就会下降。
追求完美会让人无法行动
如果试图把匿名性做到完美，就会什么都做不了。
隐藏所有通信。删除所有过去信息。改变所有。管理所有日志。现实中很难做到。
| 完美主义 | 会发生什么 |
|---|---|
| 试图删除一切 | 工作永远做不完 |
| 过度执着于工具 | 忽略发帖内容和运营方式 |
| 因不安而停住 | 无法进行必要的咨询或发声 |
| 一次失败就放弃 | 失去改进机会 |
匿名性不是零或一百的问题。
现实的做法，是一个一个减少薄弱点。
减少漏洞是什么意思
漏洞，是指会连接到身份或相关人员的线索。
例如实名账号、脸部照片、发帖时间、文件元数据、、旧网名、云端所有者名称等。
| 漏洞 | 减少方式 |
|---|---|
| 实名账号 | 与匿名用途分开 |
| 脸部照片 | 不公开、处理后使用、改用其他素材 |
| 发帖时间 | 避免现场发帖、错开发帖时间 |
| 文件元数据 | 发布前确认 |
| 旧网名 | 不重复使用，先搜索确认 |
只减少一个漏洞，也会削弱关联。
确定优先级
不需要同时修正所有问题。
先从影响大的漏洞开始减少。
| 优先级 | 要看的内容 |
|---|---|
| 高 | 本名、脸、地址、职场、学校、信源 |
| 高 | 与实名账号的连接 |
| 中 | 发帖时间、日常活动范围、文体、图片背景 |
| 中 | 文件名、元数据、共享历史 |
| 低到中 | 细小表达、旧的弱线索 |
在高风险活动中，不能放着高优先级漏洞不管。
即使是低风险的日常发帖，减少脸部和日常活动范围的暴露也有价值。
持续回顾
匿名性不是设置一次就结束。
每增加一篇新帖子、一张新照片、一个新账号、一项新服务，漏洞也会增加。
| 时机 | 确认内容 |
|---|---|
| 发帖前 | 照片、正文、时间、账号 |
| 文件共享前 | 元数据、所有者名称、共享范围 |
| 创建新账号时 | 旧 ID、邮箱、电话号码、图片 |
| 发布后 | 回复、扩散、应删除的信息 |
| 定期检查 | 搜索结果、过去帖子、图片搜索 |
匿名性靠持续检查来维护。
发现漏洞也不要慌
发现匿名性的漏洞时，人会感到不安。
但是，如果慌忙全部删除、用另一个账号解释、把咨询内容扩散给周围的人，反而会增加更多漏洞。发现漏洞时，首先要区分类型。
| 发现的漏洞 | 最先做什么 | 要避免什么 |
|---|---|---|
| 出现本名或脸 | 确认影响范围并考虑删除 | 情绪化的解释发帖 |
| 出现相关人员信息 | 考虑对相关人员的影响 | 只靠自己判断 |
| 文件元数据残留 | 确认原文件和发布位置 | 不看原因就重新发布 |
| 与旧 ID 连接 | 确认搜索结果和过去信息 | 突然大量修改 |
| 发生威胁或曝光 | 记录并寻找咨询对象 | 反击或请求扩散 |
减少漏洞的工作要冷静进行。
如果风险很高，请不要只靠文章判断。涉及法律问题、身体危险、职场或学校报复时，可能需要咨询律师、支援团体或可信赖的专业窗口。
积累小改进
匿名性不是一次性做出完美配置。
它是小改进的积累。不使用旧 ID。不重复使用头像。发帖前确认图片。不在实名浏览器里登录匿名账号。不立刻回复。
| 小改进 | 效果 |
|---|---|
| 不使用旧网名 | 减少与过去账号的搜索关联 |
| 发帖前查看图片 | 减少背景、通知、位置信息泄露 |
| 使用专用浏览器 | 避免 Cookie 和登录状态混用 |
| 延迟回复 | 减少情绪化地追加信息 |
| 定期搜索 | 更容易注意到外部可见的信息 |
这些改进并不显眼。
但是，匿名性会通过朴素的运营变强。比起醒目的工具，每次确认有时会制造更大的差异。
目标不是完美，而是能够说明
在匿名性中，比起追求“绝对安全”的状态，更应该追求能够说明自己判断的状态。
你要从谁那里保护什么。哪些信息仍然可见。接受了哪些信任对象。哪些漏洞还残留，为什么现在可以容忍。
| 能够说明的事 | 例子 | 意义 |
|---|---|---|
| 防范对象 | 熟人、职场、服务运营者 | 能决定对策强度 |
| 保护信息 | 本名、脸、日常活动范围、信源 | 能决定优先级 |
| 残留信息 | 发帖时间、语言、通信量 | 能避免过度评价 |
| 信任对象 | 服务商、邮件服务商、咨询对象 | 能理解谁可以看到什么 |
| 可容忍的漏洞 | 低风险话题、一般性的地区信息 | 不会因完美主义而停住 |
无法说明的对策，是容易崩掉的对策。
如果能用语言说明为什么使用那个工具、为什么不公开那项信息、为什么延迟发帖，下一次判断也会更容易。
最后不要留下无法判断的项目
不需要完美，并不意味着可以在不明白的状态下继续。
重要的是，不要把不明白的项目当作安全。
| 无法判断的项目例子 | 停下来的理由 | 接下来做什么 |
|---|---|---|
| 不确定这张图片里拍到了什么 | 背景和反射会成为线索 | 发帖前放大确认 |
| 不知道这个文件的元数据 | 作者和编辑历史可能残留 | 调查确认方法 |
| 不知道这篇帖子会传到谁那里 | 可能被预想外的人看到 | 确认发布范围 |
| 不知道这个咨询对象是否安全 | 会交出额外个人信息 | 确认官方信息和可信度 |
| 不知道这次删除会删除什么 | 截图和引用会残留 | 确认影响范围 |
匿名性没有完美。
但是，也没有必要把不明白的东西在不明白的状态下放行。减少漏洞，也意味着发现不明点、停下来、再确认。
总结
匿名性没有完美。
但是，漏洞可以减少。
实名账号、脸部照片、发帖时间、文件元数据、旧网名、云端共享等连接身份的线索，要一个一个减少。
比起追求完美而停住，确定优先级并持续改进更现实。
匿名性不是保证，而是为了降低风险而进行的持续运营。