为什么是 PrivateBin：它解决的是“内容可见性”，不是“全能隐身”
在现实世界里，“取证”和“监视”往往不是电影式的黑客入侵，而是更朴素、更常见的路径：
- 聊天软件/邮件/云文档里长期留存的明文；
- 企业网关、DLP、杀软、聊天“链接预览/安全扫描”带来的自动化抓取；
- 服务器访问日志、反向代理日志、CDN/WAF 日志里记录的IP、时间、UA等元数据；
- 终端侧（你的电脑/手机）浏览器历史、剪贴板、截图、同步备份带来的本地痕迹。
PrivateBin 的核心价值，是把“内容”变成端到端加密（浏览器端加密/解密）：服务器只存密文，因此服务商天然更难“内容取证”。但它并不承诺让你在网络里隐身，也不承诺对抗恶意服务商投毒脚本这类“供应链式攻击”。官方也明确指出：用户仍需要信任服务端不要下发被篡改的脚本，必须使用 HTTPS，并且要理解访问日志仍可能暴露“谁在什么时候访问过”。
项目网址
- PrivateBin 官方站点：
https://privatebin.info/ - GitHub 仓库：
https://github.com/PrivateBin/PrivateBin - 官方演示实例（Try it out）：
https://privatebin.net/
下面我们用“隐私优先”的方式，把它讲透并教你落地。
PrivateBin 是什么：零知识（Zero-Knowledge）Pastebin 的工作方式
PrivateBin 是一个极简、开源、自托管的 pastebin 系统，官方描述它为“服务器对存储数据零知识（zero knowledge）”。其关键机制是：数据在浏览器中加密/解密，并使用 256bit AES-GCM。
它的“零知识”靠什么实现？
你可以把一次 PrivateBin 分享理解为两段式：
1) 服务器端拿到的只是密文：你提交的 paste 内容在本地（浏览器）被加密后上传，服务器存储的只是加密后的结果。
2) 解密钥匙不交给服务器：PrivateBin 生成的“解密 key”放在链接的 # 之后（URL fragment 部分）。Fragment 不会随 HTTP 请求发送到服务器，它只在客户端侧被浏览器处理；PrivateBin 官方 FAQ 也明确说明：解密 key 位于 URL 的 hash 之后，不存储也不传输。
换句话说：服务商即使拿到了数据库/文件系统里的所有 paste，也主要是拿到“上锁的盒子”；钥匙在你分享给对方的链接里（而且是链接 # 后面的部分）。
重要提醒：这也意味着“拿到完整链接的人=拿到钥匙的人”。官方强调：不设置密码时，任何拿到链接的人都能解密内容；需要“更私密”，就要再加一层“密码”。
加密与协议细节（技术向但很关键）
根据官方 Wiki（Encryption format）的说明，PrivateBin 在客户端侧大致做这些事：
- 生成一段随机的
paste_key（示例写的是 32 字节随机数），并把它编码后放进 URL fragment（#后面）。 - 若你设置了“额外密码”，密码会参与派生最终加密用密钥（你可以把它理解成“链接里的随机 key + 你输入的密码”共同决定最终能否解密）。
- 使用 PBKDF2（HMAC-SHA256）等方式进行密钥派生，并使用 AES-GCM 进行加密；同时可以启用压缩（例如 zlib）后再加密以减少体积。
你得到两道门：
- 门 1：完整链接（含
#后的 fragment key） - 门 2：你额外设置的密码（可选，但强烈建议在“对抗转发/日志泄漏”场景使用）
“一次性阅读（Burn after reading）”如何对抗链接扫描？
很多企业/邮箱/聊天系统会对外链做“安全扫描”和“内容预览”。如果你设置了“阅后即焚”，扫描器可能在你朋友打开之前就先访问一次，导致 paste 被销毁。
官方加密格式文档提到一种 URL 变体：在 fragment 里加入 #- 前缀，让打开链接时先需要用户确认才加载 paste，用来降低 URL 扫描器“自动执行 JS 并触发销毁”的概率（官方明确说这第二种 URL 主要是为 burn-after-reading 准备的）。
这点在“对抗监视/取证”的实操里非常有价值：你对抗的不是数学上的 AES，而是现实里的“自动化系统”。
提供商（服务商）能看到什么 / 看不到什么（最重要的一节）
一图看懂：服务商可见 vs 不可见
| 类别 | 服务商能看到（或推断） | 服务商看不到（除非你泄露链接/终端被入侵） |
|---|---|---|
| 内容本体 | 密文（ciphertext）、未加密的盐值/部分元数据字段 | 明文内容（paste 文本、附件内容、评论内容等在浏览器端加密） |
| 解密钥匙 | —— | URL # 后的解密 key：官方说明它不存储也不传输，位于 hash 后 |
| 你设置的密码 | —— | 密码不存储也不传输（官方 FAQ 明确写出） |
| 元数据（粘贴属性） | 例如：创建时间戳、过期秒数、格式类型（纯文本/代码/Markdown）、是否开启讨论等（部分元数据不加密） | —— |
| 访问层面日志 | 访问 IP、访问时间、User-Agent、可能的 Referer（取决于你的环境与服务端配置） | ——（这些本来就发生在传输层/HTTP 层） |
| 评论头像/图标 | 若启用基于 IP 的头像/标识，可能带来 IP 被猜测/关联的隐私风险（可配置禁用） | —— |
进一步拆解：哪些字段是“端到端加密”的？
官方 FAQ 给出了清单：以下内容在浏览器端端到端加密（上传前加密、下载后解密）：
- paste 文本
- 文件与文件名
- 讨论区评论
- 讨论用用户名（昵称）
同时，FAQ 也明确指出：有些元数据不加密，比如时间戳、过期时间、格式、是否开启讨论、以及某些基于 IP 的用户图标等。
这就是为什么“PrivateBin 让服务商看不到内容”，但不能让服务商“看不到你和谁在什么时候互动过”。
使用 PrivateBin 的正确姿势
第 1 步：选实例——能自建就自建，不能自建就做最小信任选择
官方 FAQ 的建议非常直接：推荐自建；否则就找你信任的运营者。
如果你必须用别人的实例：
- 确认地址栏是
https://； - 可用 SSL Labs、securityheaders、MDN Observatory 等做基础检查（官方给了清单）；
- 也可以使用官方的实例目录（instance directory）辅助选择。
第 2 步：新建 paste 时，优先做这 4 个隐私决策
1) 设置过期时间：越短越好（减少“未来被翻旧账”的取证窗口）。
2) 需要时启用阅后即焚（burn after reading）：一次访问就销毁，适合一次性口令。
3) 强烈建议设置“额外密码”：因为“完整链接就是钥匙”，而链接可能被转发、被截屏、被日志记录；加密密码是第二道门。
4) 慎用讨论功能：讨论会引入更多交互与元数据；如果一定要用，考虑隐藏评论时间显示（配置项允许不展示时间以增加隐私，但内部仍会记录用于排序）。
第 3 步：复制并保存“删除链接”（很多人忽略）
PrivateBin 在创建 paste 后通常会给你一个删除链接/删除 token（用于提前删除）。官方 FAQ 说明：没有删除 token 就只能等过期或等清理周期。
隐私建议：把删除链接保存到你的密码管理器/安全笔记中，避免“发错了却删不掉”。
第 4 步：分享链接要“分流”——链接和密码不要走同一条通道
因为：
- 链接里包含 fragment key（“钥匙”），拿到链接的人理论上就能解密（没设密码时尤其如此）。
- URL 缩短服务会记录访问日志，官方明确不推荐；并且配置文档也提醒：URL shortener 会泄露加密 key，建议只用自建短链。
一个实用的“反取证/反监视”习惯是：
- 链接走 A 通道（例如邮件）；
- 密码走 B 通道（例如端到端加密聊天、电话口述、当面）。
第 5 步：接收方打开时，尽量避免留下本地痕迹（“端点取证”才是大头）
PrivateBin 解决的是“服务器看不见内容”，但本地仍可能留下：浏览器历史、缓存、剪贴板、截图、同步备份。
实操建议：
- 用无痕窗口/临时浏览器 profile；
- 不要让浏览器/输入法云同步剪贴板；
- 在“高风险场景”用隔离环境（例如专用浏览器、临时虚拟机）；
- 别把完整链接（含
#）粘进会被记录的地方（工单系统、群公告、笔记软件）。
自建 PrivateBin（把信任面缩到最小）
如果你的目的是“对抗警察取证和监视”，自建几乎永远是加分项：你把“可被强制调取日志/可下发恶意脚本”的第三方，缩减成你自己（或你信任的组织）。
第 1 步：确认运行环境与最低要求
官方安装文档写明最低要求：
- PHP 7.4+
- zlib 扩展
- 浏览器启用 JavaScript
（可选）如果你使用特定头像库可能需要 GD 扩展；jdenticon 不需要 GD。
第 2 步：下载与部署（官方 TL;DR 路线）
官方给的“TL;DR”是：下载最新 release archive，解压到 Web 目录。
我们建议你阅读安全小节与配置选项，别把默认配置当“万能安全”。
第 3 步：把敏感目录移出 Web 根目录（强烈建议）
安装文档提供了一个非常重要的加固思路：你可以在 index.php 中定义不同的 PATH，把 cfg/、data/、tpl/、vendor/ 等目录移出 document root，只让 Web 可访问静态入口，从而降低被误配置暴露的风险。
这一步对“对抗取证”也有意义：即使 Web 服务层面出现路径穿越/静态目录暴露一类问题，你也尽量不把数据直接放在可被下载的位置。
第 4 步：配置文件与功能开关（把“隐私默认值”调到位）
官方配置文档说明：复制 cfg/conf.sample.php 为 cfg/conf.php 并修改。
建议的“隐私优先”取向（按需取舍）：
- password = true：允许用户为 paste 设置额外密码（建议启用）。
- fileupload：默认 false；除非你确实需要传文件，否则建议保持关闭，缩小攻击面与误上传风险。
- discussiondatedisplay：如果你开讨论，可考虑不显示评论时间（减少旁观者通过截图/转发做时间线分析），但注意内部仍会记录用于排序。
- icon = “none”：评论头像可能与 IP 推断相关，配置页面明确说这是潜在漏洞点，并引用了安全审计（ZeroBin audit 的相关问题）；对“隐私极致”场景建议禁用。
- cspheader：保持严格 CSP，减少第三方资源加载与被动追踪面；FAQ 也解释了默认 CSP 会阻止第三方图片，以防用“追踪像素”跟踪访问者。
- urlshortener：除非你自建短链，否则不要启用；配置文档明确说这会泄露 paste 的加密 key。
第 5 步：必须上 HTTPS（否则“对抗监视”从根上失败）
安装文档写得很直白：没有 HTTPS PrivateBin 不安全，因为 JS/WebAssembly 文件可能在传输中被篡改。
此外，官方首页也强调：用户需要信任服务端不会注入恶意代码；并建议使用 HTTPS、HSTS 等。
这背后的逻辑是：PrivateBin 的加密发生在浏览器端，如果你拿到的是被动过手脚的脚本，“端到端加密”可能会被绕开（例如脚本在解密后把明文偷偷发走）。这也是官方反复提示的边界。
第 6 步：阻止搜索引擎与机器人“捡到钥匙”
安装文档提到：根目录提供 robots.txt，请求搜索引擎不要索引/爬取，从而避免 paste key 泄露；如果你把 PrivateBin 装在子目录，建议把 robots.txt 放到站点根并调整路径。
文档还提到 .htaccess.disabled：可用于阻挡一些已知机器人/链接扫描 bot（Apache 下可改名启用；其他 Web 服务器需手动配置）。
真正“对抗取证与监视”的关键：你要防的是这些“现实攻击面”
1) 访问日志依然能出卖你：IP/时间/频率
官方首页提醒：管理员可能被迫交出访问日志；PrivateBin 加密了内容，但“谁访问过（尤其首次访问）”仍可能通过日志暴露。
因此，如果你对“监视”敏感：
- 选择你信任的运营者或自建；
- 尽量减少日志留存（反向代理/应用/系统日志策略）；
- 高风险场景使用 Tor/VPN 等降低 IP 关联（这属于通用网络匿名性范畴，PrivateBin 本身不替你解决）。
2) URL 本身就是“证据”：浏览器历史、聊天记录、工单系统都可能保存它
因为解密 key 在 URL # 后面，完整 URL 一旦被记录，就等于钥匙被记录。FAQ 明确说“key 是 URL 的一部分”；并强调不要在公开场合发布链接。
落地建议：
- 避免把链接粘贴到会被长期保存/可审计的系统；
- 不要用第三方短链；官方明确警告短链服务可能从访问日志取到你的完整 URL（含 key）。
3) 讨论区的“头像/标识”可能引入 IP 推断/关联风险
配置文档明确说明：PrivateBin 的评论头像基于评论者 IP 生成，这是潜在隐私问题；为最大安全可禁用。
被引用的安全审计中也提到：基于 IP 派生的 vizhash 头像存在“在线猜测”风险（尽管评估为较低影响，但在高敏感场景仍应减少不必要的可关联信号）。
常见误区：PrivateBin 不能替你解决的 5 件事
1) 它不能防“恶意服务商/被入侵服务商”下发恶意脚本：官方明确承认 JavaScript 加密的概念性问题：你仍需信任服务端不投毒脚本；要更强就自建并用 HTTPS，或使用第三方客户端。
2) 它不能抹除访问日志元数据：IP/时间等依旧可能存在。
3) 它不能保护你的终端：浏览器扩展、木马、系统级取证、剪贴板记录、截图等都能绕过“服务器零知识”。（这是端到端加密工具普遍边界）
4) “不设密码”并不私密：拿到链接的人就能解密，官方在 FAQ 里写得很直白。
5) HTTP（无 TLS）= 直接破功：官方安装文档强调没有 HTTPS 不安全，因为脚本可能被篡改。
实操：一次“隐私优先”的 PrivateBin 分享（10 步流程）
1) 尽量使用自建实例；做不到则选可信运营者并确认 https://。
2) 打开新建 paste 页面。
3) 粘贴敏感内容（例如一次性口令、服务器日志片段、配置片段）。
4) 设置较短过期时间（例如 10 分钟/1 小时），避免长期暴露。
5) 勾选 burn after reading（如果是一次性秘密）。
6) 设置一段足够强的“额外密码”。
7) 创建 paste，复制“访问链接”和“删除链接/token”。
8) 链接发给对方，但密码走另一个通道（端到端加密聊天/电话/当面）。
9) 如果你担心“链接扫描器提前访问”，考虑使用官方文档提到的“需要确认才加载”的 URL 变体思路（尤其搭配阅后即焚）。
10) 对方读完后，你用删除链接手动删除（或等待阅后即焚/过期自动清理）。
附录：隐私加固清单
使用者清单（你在用别人实例时）
- 只用 HTTPS（不然别发敏感内容）
- 永远设置过期时间（越短越好）
- 高敏感内容：开启阅后即焚 + 额外密码
- 不用第三方短链（会泄露 key）
- 不在公共平台贴完整链接（完整链接≈钥匙）
站长清单（你在自建时）
- PHP 7.4+、zlib 扩展到位
- 配置 HTTPS（并考虑 HSTS/安全头）
- 将
cfg/、data/等移出 Web 根目录（PATH 技巧） - 设好文件权限：避免其他系统用户读取 conf 与 data
- 严格 CSP，默认阻止第三方图片追踪
- 视需求禁用 IP 派生头像/标识（icon=none）
- robots.txt 与机器人拦截策略，避免搜索引擎/扫描器“捡到钥匙”