关于外链图片带来的问题的思考

现在很多网站提供了链接图片并预览的功能，但是这可能会泄露某些信息给那些图片提供者。而如果图片提供者是帖子的发布者，那么 ta 就可能会达成某种目的。

现在很多邮件会自动加载外链图片，这可以用来判断你是否打开了这个邮件。如果别人有某种目的，发个邮件就可能获取你的 IP 。

本文做了一下总结，没有参考其他文章，仅仅根据自身知识总结。所以可能会有所错误。

可能会有以下隐患

以下均为最坏的情况

泄露 IP 给图片提供者

网站加载图片时直接发送请求到图片地址，那么图片提供者就可以获取加载这个图片的用户 IP ，如果使用了分流规则，那这个 IP 可能是你的真实 IP （国内地址直连），或者代理 IP 。

泄露访问这个图片的浏览器的 UserAgent 、页面的域名、浏览器语言等信息

图片提供者还可以获取加载图片的页面的域名。如用户通过 https://abc.example.com/e.html 加载了一个图片 A ，那么默认情况下，图片 A 的提供者可以知道某用户通过 abc.example.com 查看了图片。这个是通过 img 的 referrerPolicy 属性来控制的。

还有 各种请求头信息：User-Agent 、Accept-Language

泄露访问的时间

访问就会发送请求，访问时间是一个很重要的信息

如何解决这个问题？

针对网站运营者

以下方法代价由高到低

缓存用户图片

针对用户外链的图片，可以在发帖时就缓存到服务器，然后改变原链接地址，类似于用户上传图片。

这种方法是隐私性最好的，但是当外链的图片变化时不能及时感知。 优点：

1. 无法获取访问者 IP 和 Header 等信息
2. 无法获取访问时间

缺点：

1. 存储大量图片

参考 GitHub

解决方法有很多，可以看看 GitHub 是怎么解决的。（ GitHub 最近更新了生成的 URL ）

1. 针对用户直接通过浏览器上传图片的场景。Github 会生成一个 https://github.com/{{owner}}/{{repo}}/assets/{{uuid4}} 的链接，然后通过 302 跳转到github-production-user-asset*****.amazonaws.com/******实际图片地址，这种情况显然除了 GitHub 谁也得不到访问者的地址和 referrer ，是安全的。

2. 通过外链链接图片 Github 支持 MarkDown ，可以填图片外链。这种情况 Github 会使用https://camo.githubusercontent.com这个域名代理用户图片，然后加载。这种情况显然也是安全的。

方法 2 其实很久前开源了一个项目https://github.com/atmos/camo.git 不过后来没有维护了

GitHub 的方法隐私性中等，不过不会有前一种方法图片更新导致的问题，而且不用存储图片。 优点：

1. 无法获取访问者 IP 和 Header 等信息

缺点：

1. 可以获取访问时间

退而求其次

上面的方法都要求服务端处理，要消耗较多的资源

限制图片域名

可以限制图片提供者，也就是只允许加载指定域名的图片。

这种情况下，只有指定的图片提供者可以获取用户信息，但是图片提供者也可能会提供一些信息给上传图片的发布者，如浏览量等，所以域名要谨慎选择。

PS：v 站在用户评论上采用了这个方案。

限制 referrer

见MDN referrerPolicy 默认情况下是 strict-origin-when-cross-origin （详细解释见文档）会发送页面域名给图片提供者。 设置为 no-referrer 就不会发送域名数据。

PS：v 站在用户评论和帖子外链上采用了这个方案。

针对网站用户

针对一些特殊网站，可以考虑默认不加载图片。

针对邮件，关闭邮件外链图片的自动加载功能

利用这个东西

邮件

利用图片自动加载的特性也不是什么新鲜玩意，有些邮件追踪就是用图片自动加载来实现的，而追踪的目的很可能是是否点开了这个邮件。这样一来那些部分邮件客户端提供的代理图片功能就用处不大了（除非是用的上面说的立即缓存方案）。

当然代理图片可以隐藏客户端的 IP 和 Header 等信息，也算是一种折衷。

网站

部分网站使用这种功能。

这个

当然了，在座的各位一个都跑不掉。