Firefox 隐私加固:进阶的隐藏策略

2020年05月30日 • 更新于 2020年06月08日

本系列 上一篇文章 中说过推荐使用 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 设置:

user_pref("network.http.speculative-parallel-limit", 0);

很多隐私扩展早已在自己的设置页面中提供关闭选项,包括 uBlock Origin 和 Decentraleyes,并且称呼此特性为「链接预读取」。实际上是错误的叫法,它们关闭的是投机性预读取,因为这和我接下来就要提到的链接预读取是另一个概念。

链接预读取

链接预读取:服务器端告知浏览器,哪些资源文件可以提前获取,不必等到需要用的时候才去获取。这项特性受服务器端控制,需要服务器在 HTML 文件的 meta 标签中,或者响应头中提示该预取哪些资源。所以这有别于上面提到的投机性预读取:它则是浏览器决定的,服务器对此不知情。

user.js 设置:

user_pref("network.prefetch-next", false);

DNS 预解析

DNS 预解析 (DNS Prefetch): 浏览器会对页面中的链接,提前查询 DNS 解析域名,即使我们还没打开这些链接,或者永远都不会打开它们。但这只是在解析域名,实际上不会对链接指向的域名发起任何连接。是不是意味着不会被跟踪呢?由于 DNS 查询请求通常是不加密的 UDP 数据,所以可能会把查询记录泄漏给窃听者。窃听者通过分析域名查询记录的特征,可以推测我们在访问哪个具体页面。或者精心布置一个钓鱼网站,页面中的链接的域名组合是独一无二的;此时即使采用了匿名访问,只要泄漏了特定的 DNS 查询记录,就可被认为是访问过该网站的证据!

此特性似乎在启用 socks5 代理后无效,包括使用代理扩展和火狐自身的代理设置。在我把代理扩展禁用后,Firefox 才会进行 DNS 预解析。

PS: 测试这项特性的时候,不要和投机性预连接混淆了。因为投机性预连接也是要先进行 DNS 解析的。

目前 Firefox 默认启用这项特性,但仅限于在不加密的 HTTP 页面上。对于 HTTPS 页面,默认是关闭的,设置项为network.dns.disablePrefetchFromHTTPS,值为true。由于我们的出发点是尽可能地提升隐私,即使是糟糕的 HTTP 也不该容忍它存在,所以还是彻底将它关闭吧

user.js 设置:

user_pref("network.dns.disablePrefetch", true);

另一方面,该使用更安全的 DNS 查询方式,比如 DoT 或者 DoH 加密我们的 DNS 查询数据;再进一步,开启浏览器对 ESNI 的支持,从而加密 TLS 握手时的的域名信息。

知识共享许可协议

© 2020 rydesun

循序渐进理解:跨源跨域,再到 XSS 和 CSRF

Firefox 隐私加固:基础篇

开始加载评论