URL 会暴露什么

数据链接就是装着数据的 URL。这既是全部的想法，也带来一个容易说、容易忘的性质：

谁拿到那串字符，谁就拿到了数据。

不是「能登录的人」。不是「同一个网段的人」。是任何人。那串字符就是载荷。

链接实际上会去哪些地方

把 URL 逃逸的路径讲具体一点是有价值的，因为它们大多并不惊悚，只是日常：

• 聊天和 issue 追踪。 贴进评论里的链接，会被复制进别人的通知、搜索索引、 webhook，还可能进某个为搜索而索引 issue 的第三方服务。
• Referrer 头。 你接下来访问的页面可能知道你从哪儿来。 查询串在另一边被日志记录是家常便饭。
• 浏览器历史与同步。 本地的，但会同步到你的账号、被备份、 并且任何能访问这个 profile 的东西都能读到。
• CDN 缓存与代理。 查询串是缓存键的一部分，于是这条 URL—— 连同数据——被存到了你和作者都没选的地方。
• 截图。 地址栏。某个人的终端。白板上的照片。
• 错误追踪与日志。 记录完整 URL 的分析工具，会很乐意把数据一起记下来。

这些都不新奇。这就是 URL 的日常行为，也正是「把数据放进链接」 不构成「什么都可以放进链接」这张许可证的原因。

短链接的错觉

短链接看着像隐私功能，其实不是。 https://x-cmd.com/draw/c/5168… 把内容从眼前藏起来了，但是：

• 目标对任何拿到短链接的人照样可以取到；
• 短链接本身就是数据的 bearer token，走得一样远；
• 映射关系存在服务器上，于是现在有了一个私有链接的数据库—— 恰恰是我们想避开的那个状态；
• 而它许下的承诺（「数据在那边」）比一个明晃晃的参数串许下的承诺（「数据就在这儿， 和你看到的一模一样」）要弱得多。

短链接是给太长的 URL 用的，不是给太私密的 URL 用的。

那条规矩

如果一样东西不该出现在别人地址栏的截图里，它就不该在数据链接里。

它涵盖了密钥、令牌、个人数据和内部标识，而且不容例外、不需要临时判断。 这条规矩故意是钝的：另一种写法是每次都要判断一次，而那种规矩撑不过一个 deadline。

更难的那个问题

上面这条规矩是关于链接的读者的。它不关于数据的主体， 而后者才是更难的问题。

一条描述私密事物的公开链接，依然是一次披露。 一张贴在公开 issue 上的「按客户名统计的工单量」，既公布了客户名， 也公布了他们需要过支持这件事。一张「每个内部服务错误率」的图， 告诉读者系统的哪些部分很脆。把数据变得可链接，就是把它变得可被引用， 而可被引用这件事，对数据里面的人是有后果的，不只是对做数据的人。

两个我们还没有好答案的问题：

1. 数据链接要不要带一个敏感度标记？ 规范里已经有办法说明「这是估算值」， 它大概也应该有办法说明「这描述的是私事，链接时小心些」。
2. 一条公开链接归谁？ 如果一条链接在公开 issue 里挂了三年， 作者有权把它撤下吗？渲染器有权让它过期吗？

这些不是技术问题，也没有技术答案。 这就是为什么规范现在是一份草案，隐私那一节是敞开的，而不是一份定稿。

到目前为止我们做了什么

你正在看的这个站点：没有账号、没有 cookie、没有统计脚本、没有数据库。 它不存关于你的任何东西，除了普通的请求日志——短期保留，用于容量和滥用控制。 你的配色偏好存在你自己的浏览器里。这个页面上的每一张图都是一条可以复制的链接—— 而且每一条都可以放心复制，因为它们里面没有任何不该被复制的东西。