VPN 日志能显示浏览历史吗？证据究竟证明了什么
会话日志、解析器查询和流记录证明的是不同的事。先选定要问的问题，再把身份和时间关联起来，然后只陈述已被证明的部分。
两个审计问题听起来相似，需要的证据却属于不同种类。某个地址被哪个会话访问过，可以从连接记录和流记录中回答。某个页面被哪个人打开过，通常无法回答，至少无法从这些记录中回答。在选定问题之前先选定采集工具，正是网络团队最终把主机名当成浏览历史的常见方式。
先从审计必须确立的事件开始
把问题写成一句包含主语、动词和时间的话。仅这一条纪律就能揭示会话记录与页面浏览之间的差距。会话日志能确立的是：某个身份在一段时间内被接受，并获得了在已记录策略下分配的地址；它无法确立任何人读了哪个页面，因为它从未看到请求。
在设计采集方案之前先给这次观测命名。一个以访问过的站点命名、实际保存的却是解析后的名字的字段，不是便利，而是未来的一处错误。字段名的寿命比选定它的人更长，所以要选描述证据、而非描述结论的名字。
每种记录能支持什么、不能支持什么
几乎每一种审计设计里都会出现四类记录，每一类回答不同的问题。无论在报告里还是在管线里都要把它们分开，因为混为一谈正是一个站得住脚的结论变得尴尬的原因。
| The question being asked | Record that can answer it | What that record proves | What still needs a join |
|---|---|---|---|
| Was this address contacted? | Flow record | The connection five-tuple and when it was seen | Which session held the address at that moment |
| Which account held that address? | Session log | Which identity authenticated and the tunnel address it received | Which device or person used that account |
| Was this name looked up? | Resolver query | That this resolver was asked for this name | Whether a page was fetched, and by whom |
| Was this page viewed? | Proxy or application transaction | The request and identity recorded inside that application's scope | Traffic outside that application's visibility |
| Who was the person? | None of the four on its own | An account in use, at best | A named human, whenever accounts are shared |
读最后一列要像读中间那列一样仔细。流记录描述的是地址和端口，而对地址做反向查询并不能还原浏览器使用的名字，因为一个地址可以承载许多互不相关的站点。解析器查询证明的是问题被问过，而不是页面被展示过。TLS 协商期间可见的主机名同样不是加密的请求路径。
这些每一条都是真实的观测，却没有一条是人们以为的那种观测。坚持使用自家加密解析器的浏览器落在被监视范围之外，而分析无法恢复日志从未看见的东西。这个缺口应当作为明确写出的限制出现在报告里，而不是脚注。
提前解析与被缓存的结果
浏览器会提前解析名字，有时根本不加载任何内容。它们还会直接用缓存作答，不向你正在观察的解析器发送新查询，这意味着没有查询并不等于没有访问。这两种行为都打破了 DNS 日志与浏览历史之间那个天真的等号。
DNS over HTTPS 又添了一道边界：自带解析器的浏览器或访客应用，从不会向组织的日志器问任何问题。精确的事务只来自应用自身的事件，或来自你明确支持其日志的代理。普通的 HTTPS CONNECT 隧道不会让代理看到其中任何页面路径。拥有网络并不等于获准悄悄替换应用的信任模型。
地址属于会话，而不属于某个人
带有隧道网段地址的流记录是起点，而不是答案。要把那个地址和时间戳与当时生效的会话分配关联起来，因为同一个地址一小时后就可能分配给另一个会话。静态编址是保持这种关联的一种办法，而不是唯一的办法。
当某个转换环节在传感器上游把多台设备合并成一个源地址时，关联只能指向共享的网关会话。无论网络数据看起来多么完整，共享账号或多人共用的证书都会限制归因。这两点都应当作为限制写进报告，而不是留作事后的提醒。
要记录时区、时钟来源、观测点以及其间每一处转换边界。缺失值得和存在一样认真对待，因为记录缺失可能意味着流条目已经过期、传感器从未看到那个数据包，或者某个应用日志被关掉了。
按声明的目的设计，再证明整条管线
问题一旦确定，就界定需要哪些字段、谁可以读、保存多久。因为存储便宜就多收集，会制造出比调查本身活得更久的负担。RFC 6973中的隐私模型把关联、错误归因和过度收集当作设计问题，而不是事后的补充想法。
要把映射关系和记录当作一个对象来保护，因为单独任一部分的敏感程度都远低于两者合在一起。然后用你获准生成、并且已经理解的活动来验证设计，只使用报告将要依赖的最小查询。一条无法复现已知事件的管线，也无法复现未知事件。用证据允许的措辞报告证据所支持的事件，让读者自己去得出更大的结论。
把限制写在结论旁边：关联了什么、转换了什么、哪个日志始终沉默。一条说明自身边界的结论能经受住一份自信的摘要经受不住的审阅。这就是证据与关于证据的故事之间的区别。