Firefox 对网站消息推送将采取更严格的限制

现在很多网页能推送消息，通过使用 Notifications API 实现在网站打开的前提下推送桌面通知。但这要求用户先要打开特定的 URL，这推动了 Push API 的产生，只需用户打开浏览器就能实现推送，但就像每一个开放的新标准都容易被玩坏，很多网站利用消息推送给用户造成了很大打扰，最近 Mozilla 做了一些实验并将在之后的版本严格限制消息推送的使用，其实会影响到绝大多数网站，也包括了没有滥用，真的有消息需要推送的那些。这里简单讲下消息推送的实现和为了应对 Firefox 的限制网站应该有哪些改动。

太长（若）不看（请看这里）：

• 前台或后台消息推送均需向用户获得通知权限。
• 通知权限用户接受度非常低，只有大约 1% 的用户会开启。
• 用户对采用交互获取通知权限的请求有更高的接受度。
• Firefox 会降低网站通知权限对用户的打扰，并推动网站修改权限获取方式。

消息推送的实现

主要涉及的部分有三个：

• Notification
• Service Worker

对于单纯的网页消息推送，只利用到 Notification API，先获取用户消息推送的权限，当用户允许时，通过桌面通知的形式显示。

这种需要网站处于开启状态，浏览器可以最小化运行。

使用 Push API，网站可以安装一个 Service Worker，这是一个只有有限功能的后台页面，能够绑定推送服务，站点可以不显示通知信息而利用推送在后台更新数据，实现不访问网站也能进行消息推送。

Push API 所需权限与 Notification API 相同，如果你已经给了一个站点发送通知的权限，它将同时也能够使用 Push API。

这两个技术，我们可以理解为就是服务器和 Service Worker 之间，Service Worker 和用户之间的消息通信。

• Push API：服务端将更新的信息传递给 Service Worker
• Notification API：Service Worker 将更新的信息推送给用户

Web Push 需要和浏览器绑定，特定浏览器有自己的实现，比如 Chrome 使用 FCM，在 Firefox 桌面版上，推送服务由 Mozilla 完成，Android 版的 Firefox 同时使用 Mozilla 的 Web 推送服务和 GCM 推送。

完整的流程是：使用 Service Worker 注册对象，询问用户是否允许接受消息通知，如果点击允许，浏览器会向浏览器的推送服务商请求生成一个 subscription（订阅）的标志信息，然后把这个 subscription 发给服务端存起来，用来发 Push 给当前用户。服务端使用这个 subscription 的信息调 Web Push 提供的 API 向浏览器的推送服务商发送消息，服务商再下发给对应的浏览器。然后浏览器会触发 Service Worker 的 Push 事件，让 Service Worker 调 showNotification 显示这个 Push 的内容，在操作系统中完成显示。

当然这其中还有些附加问题，比如推送信息会先传到浏览器的推送服务商，是否会存在隐私泄露，对 Firefox 来说，推送信息是按照 IETF规范 进行加密的，并且只有用户自己的 FireFox 能够对其进行解密。Chrome 使用的 FCM（Firebase）在国内无法访问，各浏览器需要单独做适配等。

平时使用的网站里，YouTube、Reddit 使用了完整的消息推送，也就是说只需打开浏览器不需要访问网站，但也仅适配了 Chrome。Bilibili、微博使用了普通的消息推送，需要先访问网站并登陆，好处是所有浏览器都兼容。

为什么需要限制消息推送

Push API 的优势是无须用户主动访问网站就可以推送消息，虽然国内由于浏览器适配（主要是对 Chrome FCM）的原因没有太多网站使用，但在国外因为不存在网络问题，很多网站将这个服务当成一种营销手段和提升用户增长的方式，就像手机上的 APP 消息推送。

很多网站会在首次加载时就询问用户是否需要通知，对用户来说，如果他是第一次访问这个网站，很难在初次打开时知道自己需不需要消息推送。对于一些恶意网站，可能用户无意间访问，并允许了消息推送，后台推送的机制使得用户不清楚这个推送消息是从哪里来的，虽然可以再次访问这个网站在左上角权限中关掉，或在 选项 中找到这个网站删除。但对一般用户而言，这个操作过于复杂。

这是 Firefox 70.0 正式版之前的消息推送显示样式，在“暂时不要”的下拉菜单是“永不允许”。今年 4 月 Firefox 进行了一项研究，通过统计使用 Firefox 测试版的小部分用户在一个月内接收到的消息推送数量和他们进行的操作，可得出以下几条结论：

• 消息推送非常普遍且不被用户接受

消息推送的权限请求远多于其他类别权限的请求，比如摄像头、麦克风或地理定位，用户接受的比例低于 3%，绝大多数会被忽略，甚至有 19% 的用户在出现提示后立刻离开网站。对比摄像头、麦克风的提示接受率约为 85%。这项统计在正式版用户中比例更低，约 99% 的通知提示不被接受，48% 的提示被用户主动拒绝。

• 重复提醒不会使用户接受率上升

曾经有一个假设是“当用户多次访问这个网站时他更容易接受消息推送”，统计数据表明只有约 15% 最终接受网站通知的用户，曾在该网站点击过“暂时不要”，也就是说用户对一个网站的消息推送是否接受，并不取决于他是否多次访问，或收到过多次询问。

• 大多数网站询问消息推送前都没有和用户进行交互

通常网站会在第一次访问时直接询问用户是否接受消息通知，而这时用户还未对网站进行浏览，他也不会知道这个消息推送的目的是什么，和他是否需要。这点做得比较好的比如 Gmail，它会在登陆后询问是否想要接受新邮件提醒，如果选择是，才会请求网页的通知权限。

• 用户对于采用交互的通知权限请求明显有更高的接受度

如上一条所述，在请求通知权限前通过交互的方式让用户理解权限的目的，带来了用户接受度的显著提升，现有用户会接受 24% 的通知，新用户会接受 56% 的通知。

Firefox 在通知权限方面的改进

去年 Firefox 引入了一个新的设置，允许用户管理所有网站的通知权限，只允许有限网站进行推送，或屏蔽所有网站的通知权限请求，在 选项-隐私与安全-权限-通知 中：

这项设置在一些理解它使用的用户中很受欢迎，但对大众用户而言位置较深，且不容易理解，无法帮助那些饱受垃圾消息困扰的用户。根据之前研究的结果，Mozilla 准备实行两项新的限制：

• 从 Firefox 70 开始，将“暂时不要”选项替换为“永不允许”，用户更容易屏蔽掉网站的通知请求，以前的“暂时不要”只能通过点击关闭按钮实现。
• 从 Firefox 72 开始，需要页面有用户交互，才会显示通知权限提示。如果页面只是在加载中请求通知权限，只会在 URL 栏中显示一个小图标，用户需要点击才能确认。

通知权限的小图标会一直在地址栏中显示，当用户想改变权限时可以通过手动点击来使用。

和这项改动相关的 Bug 可见：1536413 - [meta] Breakage from requiring user interaction for notification permission prompts

在实际操作中我已经观察到有一些网站即使通过交互的方式请求通知权限，在 Firefox 中没有任何提示，或是通过传统刷新的方式请求权限但没有触发地址栏的通知图标，所以这项功能还需完善，可到 Bugzilla 上提新的 Bug。

为什么进行这些改变，除了根据研究数据会对用户使用有明显的改善外（比如贸然的通知权限请求会使用户迅速离开网站），对网站来说，设计一个简单的交互使用户理解请求通知权限的意义是一项比较简单的改进，而且会提升用户的接受度。

这种用户交互是非常清晰的，比之前通过猜测“用户过去经常访问这个网站吗”不同，对于开发人员和用户来说，交互更容易理解。另外不推荐试图模仿浏览器 UI 进行的交互，因为这会被认为是有安全风险的，将来可能会受到更严格的限制。有关如何创建 Firefox 可接受的通知权限交互，在 Mozilla Hacks 博客上将来会有介绍，可以提前关注。

在通知权限的控制方面，Firefox 可能走得比较激进，但在未来其他浏览器可能也会跟进，对开发人员而言应该提早准备。