本系列 上一篇文章 中说过推荐使用 user.js 控制 Firefox 隐藏的隐私设置，
以此取代about:config。关于 Firefox 的 user.js，就不得不提及
著名的 GitHub 项目 ghacks-user.js。
ghacks-user.js
推荐 ghacks-user.js， 目前极好的关于如何加强 Firefox 隐私保护的项目。
user.js 和about:config修改 Firefox 设置的效果是一致的。为什么不直接使用about:config呢？
因为about:config不方便维护，而且难以迁移配置。在 user.js 里只包含有我们需要修改的设置。
其实 user.js 和about:config都是在修改 prefs.js 这个文件。prefs.js 包含了所有 Firefox 的设置，
Firefox 最后也是依据这个文件作为自己的配置。只是不推荐修改文件 prefs.js，
我们只需要 user.js 就足够了，Firefox 会在每次启动后将 user.js 的设置写入到 prefs.js 中。
把 user.js 放在 Firefox 配置目录里，重启 Firefox 后生效。警告: 不要直接使用别人的 user.js！特别 是 ghacks-user.js 的 user.js，里面包含了太多的破坏网页的设置项了。必须每项确认后决定是否使用该项设置。
我写本文不是用来代替 ghacks-user.js 的 wiki，也不是翻译，而是配合上一篇文章的内容进行拓展。 所以，一切操作都要依照该项目的文档为准。 由于可能会破坏既有配置文件，所以事先要备份，否则后果自负。备份和恢复等等关于 user.js 的使用事项都 在 ghacks-user.js 的 wiki 中详细提到，强烈建议阅读后再进行操作！下面只是我一些简单的提醒， 一切使用方式还是遵照 ghacks-user.js 的说辞为好。
- 不管怎样，先备份好 Firefox 的整个配置目录。之后配置 user.js 需要准备足够的耐心和充足的时间来进行。
- 注释一行配置，比直接删除这行更好。
恢复配置的方法
想要恢复其中的一项设置为默认值，删除掉或者注释掉这一行是不够的，因为在 prefs.js 中对应的
那项设置仍旧是被修改后的值。一般做法是注释 user.js 中对应的那行设置，
然后重启 Firefox，在about:config中把该项恢复成默认值。
我的 user.js
由于 Firefox 设置项实在太多了，涉及的内容包罗万象，但是我们不要就此心生畏惧，只抽取其中一些关键的 设置项就能提升隐私保护。我抽取了我需要的那部分，这是 我的 user.js，包含了 上一篇文章 中提到的浏览器指纹等设置。
ghacks-user.js 起到了很好的指引作用，但我们也能找到不一样的观点。接下来是我的一些思考。
Firefox 该不该启用 Beacon
简单来说，不需要。Tor 浏览器也没有默认关闭它。
来自 官方的说法： sendBeacon API 的目的是为了能在页面卸载前异步发送统计数据，替换掉从前的方式：使用同步的 XHR 发送统计数据。即使你关闭了 sendBeacon API，JS 脚本也可以选择以旧有的方式发送。所以从结果上看， 不会改变被跟踪的事实。另一方面来看，反而可能影响性能，因为让 JS 发送的请求从异步方式回滚到了同步。
以前需要禁用这个 API 的一大原因是，uBlock Origin 无法过滤通过此 API 发出的请求。但在 2016 年，uBO 就 已经解决了这个问题， 结论来自 作者 gorhill 的说法。 既然现在 uBO 支持过滤 sendBeacon 请求，所以可以放心地启用它。
现代浏览器在后台的流量
虽然我只关注 Firefox，但这些内容却不仅限于 Firefox，因为像 chrome 之类的现代浏览器也在做着类似的事情。
建议直接浏览 Firefox 提供的帮助文档，以获得完整的内容： How to stop Firefox from making automatic connections (英文) 或者 如何阻止 Firefox 在未经我许可的情况下自动连接 (中文)。
略过自动更新、检查下载文件等内容，我感兴趣的是其中的一节: 「预先读取 (Prefetch)」。
事先声明，我没有实际阅读过 Firefox 的源码，我主要参考 MDN 文档和分析多次 Wireshark 抓包的 结果；但我会尽量保证真实性。
投机性预连接
投机性预连接：为了加快网页加载速度，鼠标悬停在链接上时，Firefox 就开始尝试连接了。
抓包试了几次，分析结果得知，似乎只对 HTTP 链接有效。如果链接从一开始就标明使用 HTTPS 协议， 不会自动连接。在 TCP 三向握手之后，不会请求任何资源，只会等待我们真正 打开链接。如果没有打开该链接，在等待大约 5 秒后 Firefox 会关闭此 TCP 连接。在这个过程中，不可避免的 同时会先进行域名的 DNS 解析。
因为 uBlock Origin 等一些反广告反跟踪的扩展的工作方式是拦截请求，但对于投机性预连接来说， 仅仅建立 TCP 连接， 这不算是一个请求。所以即使是被扩展阻止的域名， 也会因为这个特性而建立连接；虽然从结果上来说，稍后对该域名的请求会被拦截。
这显然不是我们所希望发生的：自动连接已经被列入黑名单中的域名。
user.js 设置：
|
|
很多隐私扩展早已在自己的设置页面中提供关闭选项，包括 uBlock Origin 和 Decentraleyes， 并且称呼此特性为「链接预读取」。实际上是错误的叫法，它们关闭的是投机性预读取， 因为这和我接下来就要提到的链接预读取是另一个概念。
链接预读取
链接预读取：服务器端告知浏览器，哪些资源文件可以提前获取，不必等到需要用的时候才去获取。 这项特性受服务器端控制，需要服务器在 HTML 文件的 meta 标签中，或者响应头中提示该预取哪些资源。 所以这有别于上面提到的投机性预读取：它则是浏览器决定的，服务器对此不知情。
user.js 设置：
|
|
DNS 预解析
DNS 预解析 (DNS Prefetch): 浏览器 会对页面中的链接，提前查询 DNS 解析域名，即使我们还没打开这些链接，或者永远都不会 打开它们。但这只是在解析域名，实际上不会对链接指向的域名发起任何连接。是不是意味着不会被跟踪呢？ 由于 DNS 查询请求通常是不加密的 UDP 数据，所以可能会把查询记录泄漏给窃听者。 窃听者通过分析域名查询记录的特征，可以推测我们在访问哪个具体页面。或者精心布置一个 钓鱼网站，页面中的链接的域名组合是独一无二的；此时即使采用了匿名访问，只要泄漏了 特定的 DNS 查询记录，就可被认为是访问过该网站的证据！
此特性似乎在启用 socks5 代理后无效，包括使用代理扩展和火狐自身的代理设置。 在我把代理扩展禁用后，Firefox 才会进行 DNS 预解析。
PS. 测试这项特性的时候，不要和投机性预连接混淆了。因为投机性预连接也是要先进行 DNS 解析的。
目前 Firefox 默认启用这项特性，但仅限于在不加密的 HTTP 页面上。对于 HTTPS 页面，默认是关闭的，
设置项为network.dns.disablePrefetchFromHTTPS，值为true。由于我们的出发点是尽可能地提升隐私，
即使是糟糕的 HTTP 也不该容忍它存在，所以还是彻底将它关闭吧
user.js 设置：
|
|
另一方面，该使用更安全的 DNS 查询方式，比如 DoT 或者 DoH 加密我们的 DNS 查询数据；再进一步， 开启浏览器对 ESNI 的支持，从而加密 TLS 握手时的的域名信息。
