Firefox iOS 原生广告拦截上线:EasyList 生效,但搜索广告仍被放行

2026-08-18 44 预计阅读时间: 1 分钟
来源: oschina.net AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间:8 分钟

Firefox for iOS 终于加入了内置广告拦截功能。它基于 EasyList 过滤规则,在网络层阻止第三方广告网络、广告追踪器和弹窗广告。不过,这不是一个默认开启的“全拦截”模式:功能目前被标记为实验性,需要用户手动启用,并且仍在渐进式推送中。

更值得开发者注意的是它的边界。搜索结果页广告不会被拦截,Firefox 主页中的部分广告或推广内容也属于例外。这意味着“开启拦截器”不等于“页面上不再出现广告”。

网络层拦截改变了什么

基于 EasyList 的拦截器会把页面发出的网络请求与过滤规则进行匹配。如果请求命中了已知广告域名、追踪端点或广告脚本路径,浏览器可以在资源下载前终止请求。

这种方式与单纯隐藏 DOM 元素不同。后者通常等到页面加载后,再通过 CSS 或脚本把广告容器设为不可见;网络层拦截则可能直接避免下载广告脚本、图片和追踪像素。因此,它通常能够同时影响三个方面:

  • 减少第三方请求和页面传输量;
  • 降低部分跨站追踪行为发生的机会;
  • 避免广告脚本执行后继续创建弹窗或追加请求。

不过,EasyList 是规则列表,不是内容语义识别系统。一个请求是否被拦截,取决于域名、URL 路径、资源类型和规则上下文。站点改名、使用第一方域名代理广告,或者把推广内容直接写入页面 HTML,都可能绕开传统过滤规则。

两类例外说明它不是“绝对无广告”模式

搜索结果页广告被明确放行后,用户仍可能在搜索引擎页面顶部看到带有“赞助”或“广告”标识的结果。Firefox 主页中的部分推广内容同样不应被当作拦截器失效。

这一区分对测试和客服排障很重要。不能仅凭“页面上还能看到广告”就判断功能没有开启,应当继续确认:

  • 广告来自搜索结果页、Firefox 主页,还是普通网站;
  • 显示的是远程广告资源,还是页面直接输出的原生推广内容;
  • 对应请求是否命中 EasyList;
  • 当前安装版本是否已经获得该实验功能。

对于网站开发者,这也提醒我们不要把广告拦截检测写成简单的真假判断。用户可能启用了拦截器,但当前广告属于例外;也可能只拦截了一部分资源。业务逻辑如果因此禁止阅读、循环刷新或反复弹窗,往往会制造新的可用性问题。

可以这样实践:对比开关前后的网络请求

下面是一种可复制的观察方法。这里使用 mitmproxy 记录 Firefox iOS 发出的请求,用同一个页面分别测试关闭和开启拦截器时的结果。该方法用于开发环境验证,不代表 Mozilla 官方测试流程。

在与 iPhone 位于同一局域网的电脑上运行:

python3 -m venv .venv
. .venv/bin/activate
python -m pip install --upgrade pip mitmproxy
mitmweb --listen-host 0.0.0.0 --listen-port 8080

接着查出电脑的局域网 IP。macOS 常见命令如下,实际网络接口可能不是 en0

ipconfig getifaddr en0

在 iPhone 的当前 Wi-Fi 设置中,把 HTTP 代理改为“手动”,服务器填写电脑的局域网 IP,端口填写 8080。随后根据 mitmproxy 的本地引导安装测试证书,打开一个包含第三方广告请求的自有测试页面。

建议执行两轮并保持其他条件一致:

  1. 关闭 Firefox 实验性广告拦截,清理页面缓存后加载测试页;
  2. 开启广告拦截,再次清理缓存并加载同一页面;
  3. 在 mitmweb 中按广告域名、adstrack 或具体资源路径筛选请求;
  4. 比较请求数量、响应体大小,以及广告脚本是否继续产生后续请求。

也可以把流量保存下来,便于离线比较:

mitmdump --listen-host 0.0.0.0 --listen-port 8080 \
  --save-stream-file firefox-ios.flows

测试结束后应立即关闭 iPhone 的手动代理,并删除不再需要的测试根证书。不要在生产账号、支付页面或包含敏感数据的会话中进行 TLS 解密测试。某些采用证书固定的服务也不会接受代理证书,因此抓包结果不能覆盖所有请求。

开发与采用时的检查清单

对普通用户而言,当前最重要的是确认功能是否已经出现在设置中,并理解它默认关闭、仍属实验功能。渐进式推送意味着相同版本的两台设备也可能暂时看到不同选项。

对开发团队而言,可以按以下范围验证站点:

  • 核心内容在广告脚本被阻止时仍能正常加载;
  • 广告位失败不会留下覆盖正文的空白层或无限加载状态;
  • 登录、支付、视频播放等关键能力不依赖追踪器成功返回;
  • 服务端监控能够区分请求被客户端阻止与真正的后端故障;
  • 不把搜索广告和 Firefox 主页例外误报为拦截器缺陷。

Firefox iOS 的这次变化提供了更直接的隐私与浏览控制,但它仍是一套带有产品例外、规则局限和发布节奏的实验能力。测试时应观察实际网络请求,而不是只看页面上有没有“广告”两个字。


相关推荐