Chrome 80发布更新内容

Chrome 80 Beta版本于2019年12月19日发布

内容索引

渐进式网站应用可以通过Cache Storage API或IndexedDB离线存储图片、视频、文章等内容。但用户如何找到这些内容,他们如何知道这些内容在离线状态下也可以使用?

内容索引API(Content Indexing)提供你的应用已经缓存的媒体信息。新的API可以让你删除、添加、列出资源。浏览器可以使用这些信息显示可离线访问的资源列表。

在Web Workers中使用ECMAScript的模块

Worker的构造函数参数支持了type选项,值为module

const worker = new Worker('worker.js', {
  type: 'module'
});

其他更新内容

自动升级混合内容

在https页面中,Chrome会自动将页面中链接的http内容升级为https协议,即使内容不支持https。当前版本只对音频和视频生效,即https站点中的音频和视频必须支持https协议,否则将无法使用。

压缩流

JavaScript可以处理Gzip和deflate压缩流,通过CompressionStream和DecompressionStream接口实现的。
在这之前,可以通过一些第三方库来实现压缩和解压,但有了这个特性后,开发者可以更简单的对数据进行压缩、解压处理,避免了需要在代码里打包一个压缩器。

联系人选择API

联系人选择API是一个适用于安卓版Chrome的新API,允许用户从联系人列表中选择联系人,并与网站共享有限的信息。

Cookie升级

Chrome 51和Firefox 60中引入了SameSite属性,以允许站点声明cookie是否应限制在同一站点上下文中,从而降低了跨站点请求伪造(CSRF)的风险。
在Chrome 80中,下面的几个向后兼容的行为将被移除。
不允许将SameSite属性默认设置为“None”
SameSite属性现在默认就是宽松,这意味着您的cookie仅可用于顶级导航中的其他站点。正如最初在Chrome中实现的那样,SameSite属性默认为None,这实际上是Web的现状。Cookies具有有效的跨站点用例,但是如果站点所有者以前不希望允许跨站点Cookie的使用,则无法声明或强制执行此类意图。
在不安全的上下文中,不再允许“None”值
SameSite属性现在需要在设置None的同时,设置Secure属性。Secure属性要求cookie只有在安全的环境下(如https)可以被传输。

CSS改进
line-break: anywhere

https://developer.mozilla.org/zh-CN/docs/Web/CSS/line-break

overflow-wrap: anywhere

https://developer.mozilla.org/en-US/docs/Web/CSS/overflow-wrap

解码加密的媒体

现在的功能MediaCapabilities.decodingInfo()可用于加密媒体。该decodingInfo()方法(可在多个浏览器中使用)允许网站获取有关客户端解码能力的更多信息。这使用户能够更明智地选择媒体流,从而实现了诸如针对可用带宽和屏幕尺寸进行顺畅且节能的视频解码等方案。

在Web Payments中委派送货地址和联系信息

现在,使用付款处理程序API ,浏览器可以将送货地址和付款人的联系信息委托给付款处理程序。将收货地址和联系信息的收集委托给付款处理者可以带来更好的用户体验,因为付款应用程序可能比浏览器具有更准确的信息。由于浏览器可以直接显示付款处理程序窗口,而不是先显示付款单UI来收集收货地址和/或付款人的联系信息,因此还可以将结帐步骤减少一个。

获取元数据目标标头

Chrome现在支持Sec-Fetch-DestHTTP请求标头,该标头向服务器公开请求的目的地,并为服务器提供基于安全决策的信息。

HTMLVideoElement.getVideoPlaybackQuality()

此方法检索有关视频播放性能的信息。此类信息可用于向上或向下更改比特率,帧率或分辨率,以提供更好的用户体验。

Offscreen Canvas支持getTransform()
favicon支持使用svg
文字网址片段

之前通过URL锚点可以定位到页面指定id或name上,现在可以通过锚点定位到一段特定的文字内容上。当页面加载完毕后,浏览器会高亮显示,并将内容滚动到浏览器视窗内。

废弃与移除的功能

禁止在页面unload时弹出窗口
在页面关闭中禁止同步XMLHttpRequest()
不建议使用FTP

Chrome 80的FTP功能仅限于显示目录以及未加密的FTP的下载功能

移除Web Components v0
移除-webkit-appearance: button

SameSite Cookie介绍

通过显式声明跨域cookie以提高网站的安全性

Cookies是用于向网站添加持久状态的方法之一。多年来,它们的能力不断发展和壮大,但该平台遗留了一些问题。为了解决这个问题,浏览器(包括Chrome,Firefox和Edge)正在改变其行为,以强制实施更多的隐私保护默认值。

每个cookie都是一key=value对,并带有许多控制何时和何处使用cookie的属性。您可能已经使用这些属性来设置诸如到期日期之类的内容,或者指示cookie仅应通过HTTPS发送。服务器通过Set-Cookie在响应中发送适当命名的标头来设置Cookie 。

假设你有一个博客,你希望对你的用户展示一个更新内容的提示。用户可以点击取消,并且在一段时间内不再提示。你可以通过cookie来记录这个行为,将其设置为1个月过期(2,600,000秒),并且仅通过https传输这个cookie。则请求头如下:

Set-Cookie: promo_shown=1; Max-Age=2600000; Secure

当访问者满足如上条件,如通过https访问并且cookie没有超过过期时间(1个月),则浏览器会在请求时带上如下的请求头:

Cookie: promo_shown=1

何为一方Cookie和三方Cookie

您可能会注意到存在针对各种域的cookie,而不仅仅是您当前正在访问的cookie。与当前站点的域匹配的Cookie(即浏览器地址栏中显示的Cookie)称为第一方 Cookie。同样,来自当前站点以外的域的cookie也称为第三方 cookie。这不是绝对的,而是相对于用户的上下文。同一Cookie可以是第一方也可以是第三方,具体取决于用户当时所在的网站。

继续上面的示例,假设您的一篇博客文章中有一张特别令人惊奇的图片,该图片托管在 /blog/img/amazing-cat.png。因为这是一个热门图片,所以另一个人直接在他们的网站上使用它。如果访问者访问过您的博客并拥有 promo_shownCookie,则当他们浏览其他站点上引用你的 amazing-cat.png图片时,该图像请求中将发送 Cookie 。这是无用的,因为promo_shown对其他网站来说是不需要的cookie,只会增加请求开销。

什么时候会用到这个机制呢?通过这种机制,站点可以在第三方上下文中使用时保持状态。例如,如果您在自己的网站上嵌如腾讯视频,则访问者将在播放器中看到片头广告。如果您的访问者已经登录腾讯视频,并且是个VVIP会员,则该会话将通过第三方Cookie在嵌入式播放器中提供,也就是说,腾讯视频播放器将知道你是个交钱的用户和那些免费的穷B用户不一样,可以跳过广告或者查看VIP专属的广告。

网络文化之一是默认趋于开放状态,这也是为何很多人都愿意发布他们自己的内容和应用。但开放的同时也带来了一些隐私安全问题。跨站点请求伪造(CSRF)攻击依赖于将Cookie附加到给定源的任何请求,发起请求的是谁。例如,如果您访问evil.example那么它可以触发对的请求your-blog.example,并且您的浏览器会很高兴地附加关联的cookie(your-blog.example域下的cookie)。如果您的博客没有正确的处理这些请求,则evil.example可能触发删除帖子或添加自己的内容之类的操作。

用户也越来越意识到如何使用cookie来跟踪他们在多个站点上的活动。但是,到目前为止,还没有一种方法可以明确地表明您对Cookie的意图。您的promo_shownCookie仅应在第一方上下文中发送,而故意嵌入到其他站点的窗口小部件的会话cookie则有意在第三方上下文中提供登录状态。

使用SameSite属性显式声明Cookie的作用

sameSite属性允许你声明你的cookie仅限于一方使用或同一个站点的上下文使用。这里的站点指的是域后缀或域后缀的组合,如www.lyz810.com是lyz810.com站点的一部分。

如果用户在www.lyz810.com中请求一个来自img.lyz810.com的图片,则该请求为同一站点请求。

如果用户在blog.lyz810.com中请求一个来自img.lyz810.com的图片,则该请求为跨站点请求。

SameSite属性提供了3种方式控制cookie的行为。你可以选择不指定、指定严格模式Strict或宽松模式Lax来限制同站cookie策略。

如果设置,SameSite=Strict则意味着您的cookie仅在第一方上下文中发送。只有在Cookie的站点与浏览器的URL栏中当前显示的站点匹配时,才会发送cookie。因此,如果 promo_showncookie设置如下:

Set-Cookie: promo_shown=1; SameSite=Strict

当用户在您的网站上时,该cookie将与请求一起发送。但是,当通过链接打开您网站的时候,例如从另一个网站或通过朋友发送的电子邮件,在初始请求中,将不会发送cookie。如果您有与功能相关的Cookie,例如更改密码或购买链接,这些cookie只有在你打开链接后才会带上,而不会在初始页面就发送。

下面是通过SameSite=Lax来允许顶级导航发送cookie。让我们再次看下上面amazing-cat的网站示例,其中另一个网站引用了您的内容。他们直接利用您的猫照片,并提供指向您原始文章的链接。

<p>Look at this amazing cat!</p>
<img src="https://blog.example/blog/img/amazing-cat.png" />
<p>Read the <a href="https://blog.example/blog/cat.html">article</a>.</p>

cookie发送如下:

Set-Cookie: promo_shown=1; SameSite=Lax

当读者从别人站点看你的猫时,不会发送cookie。但当访客通过链接打开你的博客时,那张猫图的请求会带着cookie。

注意:Lax和Strict不是网站安全的完整解决方案,cookie应该与其他用户输入同等看待,需要进行必要的验证,切不可储存服务端的机密数据。

如果不设置值,则隐式表示你希望所有上下文均发送cookie,最新草案中,引入新的值明确了这一点SameSite=None。可以使用None来显式声明在任何上下文中都发送cookie。

不设置SameSite时默认行为的改变

SameSite已经被广泛支持,但不幸的是开发者基本上都没有正确的使用它。默认开放所有上下文发送cookie功能不安全,易产生CSRF攻击和以外的信息泄露风险。为了鼓励开发人员显式声明cookie用途并为用户提供更安全的体验,IETF提案了2个改进:

  • 没有SameSite属性的Cookies 将被视为SameSite=Lax
  • SameSite=None 必须和 Secure 同时指定。

Chrome在80版本已经实现了该功能,Firefox正在测试并在后续版本中将设置为默认行为,Edge也考虑更改默认行为。