Chrome 81 现已发布,该版本最初计划于 3 月 17 日发布,但由于冠状病毒(COVID-19)爆发而导致推迟至了现在。Chrome 81 的延迟不可避免地扰乱了 Google 正常的六周发布时间表。因此 Google 此前也宣布,将直接跳过 Chrome 82 版本的发布,Chrome 的下一个版本将是 v83。

Google刚刚在所有受支持的平台(包括Linux,Windows和Mac)上发布了Chrome 81。

新版本为81.0.4044.92,其中包括多项显著改进,包括对Web NFC API的支持,这意味着Web应用程序最终可以使用内置NFC。

换句话说,如果您的设备与NFC捆绑在一起,则网络应用可以通过Google Chrome使用该设备,以进行数据传输或其他实现。

Google表示,该版本已解决了32个安全漏洞,该公司再次向举报这些漏洞的研究人员支付了数千美元的赏金。

标记为严重性等级高的三个安全漏洞:两个在free之后使用(一个在扩展中,另一个在音频中)和越界读取WebSQL中的错误。

Google Chrome 81 发布,适用于Linux、Windows和Mac

Google Chrome 82被跳过

Chrome 81是第一个新版本,是在冠状病毒大流行期间安排的Google更新的一部分,该搜索巨头计划完全跳过82版。

Google最近宣布将直接迁移到Chrome 83,该版本将于5月中旬发布,比原计划提前了约两周。

Google说,“ M83将比原计划提前三周发布,并将包括我们取消M82版本(所有渠道)后的所有M82工作。我们的Canary,Dev和Beta频道已经或将在本周恢复,M83移至Dev,M81继续处于Beta版。”

其他基于Chromium浏览器开发人员也已遵守此时间表,包括Microsoft。预计现在有一天将有一个新的Microsoft Edge稳定版本,而下一个主要版本将被跳过,而Edge 83预计将在Google为所有平台发布Chrome 83之后的5月中旬登陆。

此次更新包含两个主要功能,分别为:改进了对 WebXR(Chrome 的增强现实功能,最初在 Chrome 79 中发布)的支持,以及对 Web NFC 标准的初始支持

而原本计划但后来从却 Chrome 81 版本中删除的功能更改则包括有:针对 Chrome 的 Web 表单元素的 UI 重新设计,以及取消对 TLS 1.0 和 TLS 1.1 加密协议的支持。首次出现删除的情况是因为 Google 工程师无法及时完成重新设计。 现在,新的表单控件计划与 Chrome(Chromium)83一起使用,该版本有望在 5 月中旬发布。

从 Chrome 删除 TLS 1.0 和 TLS 1.1 加密协议的计划现在延迟到 Chrome84。延迟删除这两个协议的决定与当前的 COVID-19 爆发有关,因为删除了这两个协议 协议可能会阻止一些 Chrome 81 用户访问仍使用 TLS 1.0 和 1.1 来建立其 HTTPS 连接的重要政府医疗网站。删除支持将阻止用户完全访问这些网站,Google 希望避免这种情况的发生。

WEB NFC FIELD TRIALS

在当前 v81 版本中添加的所有新功能中,最重要的是新的 Web NFC API。Chrome 中添加的新的 Web NFC 标准将允许网站与 NFC 标签进行交互,从而无需用户在手机上安装特殊的应用程序。

Google 相信,新的 Web NFC 标准将在 Web 开发人员中赢得追随者,并有望得到广泛的应用,尤其是对于 Android 版 Chrome 而言,该标准可用于以下场景:

  • 当用户将运行 Chrome 的智能手机或平板电脑触摸展览附近的 NFC 卡时,博物馆和美术馆可以显示有关显示器的其他信息。
  • 处理公司库存的网站,公司站点和 Intranet 将能够读取数据或将数据写入容器或产品上的 NFC 标签,从而简化库存管理。
  • 会议现场可以使用它来扫描 NFC 徽章。
  • 内部网和其他公司站点可以使用 Web NFC 共享在整个组织中配置新设备所需的配置和初始机密。

目前,该功能并不是所有用户都可以广泛使用,而是只能作为 field trial。field trial 将从 Chrome 81 到 Chrome 83 进行。有关 Web NFC 的更多信息,请参见此处。该功能目前预定在 Chrome 84 中为所有用户启用,但是如果在 field trial 期间出现问题,此功能可能会更改。

Google 混合内容升级中的第 3/3 步

尽管 Google 避免删除 TLS 1.0 和 TLS 1.1,但 Chrome 81 确实以另一种方式提高了 HTTPS 连接的安全性。Chrome 81 标志着 Google 分三步走的计划中的最后一个版本,该计划旨在从网络上消除了混合 HTTPS 内容。

混合 HTTPS 内容是指通过 HTTP 和 HTTPS 加载图像、JavaScript 或样式表等内容的网页,这意味着该站点实际上并不完全通过 HTTPS 加载。

Google 宣布的最终目标是将所有 HTTP 内容自动升级到他们的模拟 HTTPS URL。但是,突然执行此操作很危险,因为这可能会导致 Internet 上的大量损坏。

因此,为了防止造成重大破坏,Google 为该过程选择了一个三步计划,如下所述,该计划目前以 Chrome 81 的发布结束:

  • 在 2019 年 12 月发布到稳定频道的 Chrome 79 中,该团队将引入一个新设置来取消阻止特定网站上的混合内容。此设置将应用于混合脚本、iframe 和Chrome 当前默认阻止的其他类型的内容。用户可以通过单击任意 https:// 页面上的锁定图标并单击“站点设置”来切换此设置。这将替换显示在多功能框右侧的屏蔽图标,以取消阻止以前版本的台式机 Chrome 浏览器中的混合内容。
  • 在 Chrome 80 中,混合的音频和视频资源将自动升级到 https://,如果它们无法通过 https:// 加载,则 Chrome 默认会阻止它们。Chrome 80 于 2020 年 1 月发布到早期版本的渠道。用户可以使用上述设置取消屏蔽受影响的音频和视频资源。
  • 同样在 Chrome 80 中,仍然可以加载混合图像,但它们会使 Chrome 在多功能框中显示“Not Secure”芯片。该团队期望这对于用户而言是一个更清晰的安全性 UI,它将促使网站将其图像迁移到 HTTPS。开发人员可以使用 upgrade-insecure-requests 或 block-all-mixed-content 内容安全策略指令来避免此警告。
  • 在 Chrome 81 中,混合图像会自动升级到 https://,如果无法通过 https:// 加载,Chrome 默认会阻止它们。
声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。