Chrome 94 版新 API 功能惹争议，Webkit 开发团队：侵犯隐私-技术圈

技术编辑：MissD丨发自思否编辑部

公众号：SegmentFault

刚刚，谷歌正式发布了 Chrome 94 稳定版。作为 3 周前 Chrome 93 版发布后的再次更新， Chrome 94 稳定版尽管更新幅度较小，但也有不少小惊喜和亮点。

下载地址：

https://www.google.com/intl/zh-CN/chrome/

全新 Chrome 94 稳定版升级了其画布颜色形式化管理，实现了屏幕捕获规范中的显示捕获功能策略。同时，新版本添加了围绕音频/视频编码和解码以及原始视频帧处理等的低级编解码器 API、虚拟键盘 API 、本地调度 API 以及用于确定用户是否与系统交互的空闲检测 API。

据悉，Webcodes API 这一功能最初是在 Chrome 93 中作为一个源代码试用引入的。此次 Chrome 94 稳定版引入 Webcodes API ，总体来说也是令人兴奋的，因为它已经通过了先前的 origin 试用版。WebCodecs 是围绕音频/视频编码和解码以及原始视频帧处理等的低级编解码器 API。WebCodecs API 处理旨在比 JavaScript 或 WebAssembly 编解码器实现更高效。

早在上个月，谷歌发布的 Chrome 93 稳定版中，就为桌面端添加了对 WebOTP 的支持，但废除了传输层安全（TLS）中的 3DES 密码套件。而 8 月 30 日，谷歌宣布了 Chrome v94 的测试版，并强调其中将包括一个新的 Webcodecs API，该 API 旨在处理广泛级别的低级别视频处理。

Chromium 在此前的博客中对这一新 API 的重要性进行了概括，原文指出：

“A low-level codec API would better support emerging applications, such as latency-sensitive game streaming, client-side effects or transcoding, and polyfillable media Container support, without the increased network and CPU cost of JavaScript or WebAssembly codec implementations.”

“低级别编解码器 API 将更好地支持新兴应用程序，如对延迟敏感的游戏流、客户端效果或转码，以及多填充媒体容器支持，而不会增加 JavaScript 或 WebAssembly 编解码器实现的网络和 CPU 成本。”

本次 Chrome 94 中包含了新的开发者界面——虚拟键盘 API。该 API 可以让网页开发者在如何放置虚拟键盘及其形状方面有更多控制权，目前该 API 是完全由用户代理行为处理的。

谷歌在全新的 Chrome 94 版本中删除了 AppCache，表示这是一个废弃的标准，并建议开发者使用 Service Workers 来代替。目前 Mozilla 和苹果也正在将其从各自的浏览器中删除。

Chrome 94 还将支持一个本地调度 API，该 API 允许开发者以用户阻挡、用户可见和背景这三个级别的优先级来调度任务。同时，本地调度 API 还启用了一个任务控制器（TaskController），以动态地改变任务的优先级或完全取消优先级。

另外，Chrome 94 还有一些让人兴奋的小亮点，比如将获得了一个新的显示捕捉功能政策，支持 2D 画布中的更多色彩空间。同时，Chrome 94 还更新了 WebGPU ，作为 WebGL 的下一代 web 图形 API 替代品，WebGPU 是为当今网络中的现代图形需求而设计的，它可以允许根据平台映射到 Vulkan、Direct3D 或 Metal。

默认启用“空闲检测 API” 引争议

此次 Chrome 94 稳定版的到来，除了上述令人兴奋的亮点之外，其中提供的“为开发者提供更多信号以了解用户何时处于闲置状态”的“空闲检测 API ”，成为该版本颇具争议的地方。

据悉，在 Chrome 94 稳定版中，更新后的“空闲检测 API ”为开发者提供了更多信号，以了解用户何时处于闲置状态。据悉，该面向开发者的通知现在不仅仅对当前的浏览器窗口进行监测，还将对（如与其他应用程序的互动）全局信号进行触发。

相比网络开发者更加积极的反应，但业内对该空闲检测 API 表示担忧。Mozilla 认为其是一种“资本主义的视监”，他们担心一些恶意网站会通过该 API 搞“破坏”，比如在用户不同意或不知道的情况下，最大限度地利用设备的计算资源。

对此，WebKit（苹果 Safari 浏览器引擎）背后开发团队也对该 API 表示反对。该团队表示：

“没有充足的理由来使用这个 API。首先，不能保证用户不会立即回到设备上。另外，这样的服务应该由谁来知道用户在任何时候可能使用的其他设备？我们肯定不会让一个网站知道一个特定的用户在任何时候可能使用的所有设备。这是对上述用户的隐私的非常严重的侵犯。在我看来，这样的压制/分发机制最好留给底层操作系统/网络浏览器来处理。

在这一点上，我将停止对这个主题的回应，因为这里或其他地方提出的用例没有一个是令人信服的，而且你在这里提出的和我在其他地方发现的隐私或安全缓解措施没有一个是充分的。然而，不回应这个主题或未来关于这个主题的主题并不意味着我们会重新考虑我们的立场。除非在我们提出的任何一个问题上有重大的新进展，否则我们的立场仍将是反对增加这个API，除非另有说明，无论我们是否继续在公开场合这么说。”

尽管有反对的声音，但目前这个空闲检测 API 将在 Chrome 94 中将会默认启用，以提供给开发者使用。

- END -