为什么 VPN 目录无法为其背后的节点担保
一条条目描述的是连接以及发布它的目录。收集与留存属于运营方，而运营方可能是另一方。
列出主机名、国家和一组协议的目录条目，是连通性方面的证据，而不是对端机器记录了什么。这里要做的决定，不是是否应当笼统地信任这些列表，而是哪一方有资格回答你真正在问的问题。
一条条目背后的四方
在读任何承诺之前，先把角色分开。目录发布条目，软件项目提供协议实现，托管服务商提供机器与网络，节点运营方配置服务。这四方中的任何一方都可能是另一个组织，每一方也只能就自己那部分发言。
这一拆分解释了为什么一句陈述可以属实却仍然没用。开发者记录协议不记录内容，并不说明在某个中继上开启详细连接日志的运营方。两句话可以并存而不矛盾。正因如此，问题必须提给被指名的那一方。
有些服务自己运营端点，此时条目和政策来自同一方。这是更强的位置，但仍需被证明，而不能从页面格式推断。索要那份声明，并检查它是否点名了条目所指向的服务。
索要与主张相符的记录
关于收集的主张需要一份文件，写明系统、数据类别和时段。关于留存的主张需要一个数字和一个范围。关于独立性的主张需要说明谁拥有什么，而不是一个形容词。
| Field in a listing | What it evidences | What it cannot evidence |
|---|---|---|
| Hostname or address | A reachable endpoint existed when the entry was published | Who runs it, or what it stores |
| Protocols offered | Which client configurations should interoperate | Whether logging was disabled on that deployment |
| Country | Where the endpoint claims to be located | Which legal process could reach the operator |
| Availability score | How often the entry answered a probe | Anything about data handling |
志愿项目往往是最清楚的例子，因为有些项目会公开其接纳节点时必须遵守的日志要求。那份文件是关于项目规则的一手证据，但它仍然不是关于某个无视这些规则的具体运营方的证据。
审计遵循同样的逻辑，只是尺度不同。一份在特定时间窗口内考察了特定部署的报告，在那个边界内有价值；一旦被拉伸到同一软件的每一个独立实例，它就变成了无人签发的保证。读结论之前先读范围那一段。
当供应商的隐私声明只覆盖它自己的服务时，就把它当作该供应商关于自身系统的声明来读。用它去描述第三方的中继属于类别错误，即使协议完全相同。
决定每个选项实际买到了什么
公共节点以问责为代价换取可达性与多样性。一个对你毫无义务的运营方可以随时消失、更改配置或不作通知地保留记录，你的退路仅限于更换端点。这笔交易对某些任务可以接受，对另一些则不行。
付费服务买到的是一个有公开政策、也有东西可失去的交易对手。它买不到技术保证，也不免除阅读政策的必要，但有留存声明的具名组织，比匿名中继更容易评估。
两种情况下都成立的决策规则，是让证据与风险相匹配。如果任务能容忍轮换端点，目录就是高效工具。如果任务依赖某项具体的数据处理承诺，只有能作出该承诺的一方才有意义，目录只是路由上的便利，而不是保证。
curl -s --interface tun0 https://example.net/ -o /dev/null -w '%{remote_ip}
'上面那条命令值得执行，因为它干净地分开了两个问题。它显示你的流量实际使用了哪个地址，这是连通性的事实；它对那个地址的运营者如何处理连接元数据则一言不发。
把客户端一侧的问题分开来看
运营方政策是一层，你在隧道里所做之事的另一层是安全性。目的地的 HTTPS、浏览器里的会话处理，以及你所登录账户的强度，仍由你掌控；宽松的中继不会削弱它们，优秀的中继也不会增强它们。
这一分层能防止两种常见错误。把严格运营方政策当作跳过 HTTPS 的理由是一种，把可用的 HTTPS 连接当作忽视谁在运营中继的理由是另一种。两种错误都把两层合并成一层，然后在错误的那层上争论。
一份简短的书面评估能同时处理两方面。写明每项承诺由哪一方作出，附上支持它的文件，并注明日期。然后再决定这项任务是更需要更强的承诺，还是只需要一条可用的通路。
条目在告诉你可以在哪里连接时就已经完成了它的工作。问题的其余部分属于运营那个端点的人，而诚实的答案往往是：你无法知道，因此应当据此选择。