Starting in version 90, Chrome’s address bar will use https:// by default, improving privacy and even loading speed for users visiting websites that support HTTPS. Chrome users who navigate to websites by manually typing a URL often don’t include “http://” or “https://”. For example, users often type “example.com” instead of “https://example.com” in the address bar. In this case, if it was a user’s first visit to a website, Chrome would previously choose http:// as the default protocol1. This was a practical default in the past, when much of the web did not support HTTPS.
Chrome will now default to HTTPS for most typed navigations that don’t specify a protocol2. HTTPS is the more secure and most widely used scheme in Chrome on all major platforms. In addition to being a clear security and privacy improvement, this change improves the initial loading speed of sites that support HTTPS, since Chrome will connect directly to the HTTPS endpoint without needing to be redirected from http:// to https://. For sites that don’t yet support HTTPS, Chrome will fall back to HTTP when the HTTPS attempt fails (including when there are certificate errors, such as name mismatch or untrusted self-signed certificate, or connection errors, such as DNS resolution failure). This change is rolling out initially on Chrome Desktop and Chrome for Android in version 90, with a release for Chrome on iOS following soon after.
HTTPS protects users by encrypting traffic sent over the network, so that sensitive information users enter on websites cannot be intercepted or modified by attackers or eavesdroppers. Chrome is invested in ensuring that HTTPS is the default protocol for the web, and this change is one more step towards ensuring Chrome always uses secure connections by default.
1 One notable exception to this is any site in the HSTS preload list, which Chrome will always default to HTTPS. 2 IP addresses, single label domains, and reserved hostnames such as test/ or localhost/ will continue defaulting to HTTP.
The web platform relies on the origin as a fundamental security boundary, and browsers do a pretty good job at preventing explicit leakage of data from one origin to another. Attacks like Spectre, however, show that we still have work to do to mitigate implicit data leakage. The side-channels exploited through these attacks prove that attackers can read any data which enters a process hosting that attackers' code. These attacks are quite practical today, and pose a real risk to users.
Our goal must be to ensure that sensitive data doesn't unexpectedly enter an attacker's process. Browsers shoulder a large chunk of this responsibility: Chromium's Site Isolation can separate the sites you visit into distinct OS-level processes, cross-origin read blocking prevents attackers from loading a subset of otherwise-vulnerable cross-origin resources, and APIs that substantially increase attackers' bandwidth (like SharedArrayBuffer) are being locked to cross-origin isolated contexts. This last mechanism, however, points in the direction of work that browsers can't do on their own.
Web developers know their applications intimately, and can make informed decisions about each page's and resource's risk of exposure. To defend users' data against exfiltration, web developers must step in, evaluate resources they host, and instruct browsers to isolate those resources accordingly. At a high-level, this defense consists of:
Together, these various defenses help all browsers offer some degree of process-level protection for users' data, whether or not Site Isolation is available.
To find out more about employing these defenses, check out Post-Spectre Web Development. It includes practical examples that explain in more detail how the security primitives discussed above apply to resources you might have on your sites.
These are useful steps you can take today to protect your origin against implicit data leaks. Looking forward, we hope to help the web shift to safer defaults which protect users against these attacks without requiring developer action.
Unless otherwise noted, changes described below apply to the newest Chrome beta channel release for Android, Chrome OS, Linux, macOS, and Windows. Learn more about the features listed here through the provided links or from the list on ChromeStatus.com. Chrome 90 is beta as of March 11, 2021.
An AV1 encoder is shipping in Chrome desktop that is specifically optimized for video conferencing with WebRTC integration. The benefits of AV1 include:
This is an important addition to WebRTC especially since it recently became an official W3C and IETF standard.
This version of Chrome introduces the origin trials described below. Origin trials allow you to try new features and give feedback on usability, practicality, and effectiveness to the web standards community. To register for any of the origin trials currently supported in Chrome, including the ones described below, visit the Chrome Origin Trials dashboard. To learn more about origin trials in Chrome, visit the Origin Trials Guide for Web Developers. Microsoft Edge runs its own origin trials separate from Chrome. To learn more, see the Microsoft Edge Origin Trials Developer Console.
The mediaDevices.getCurrentBrowsingContextMedia() method allows capturing a MediaStream with the current tab's video (and potentially audio), similar to getDisplayMedia(). Unlike getDisplayMedia(), calling this new method will eventually present the user with a simple accept/reject dialog box. If the user accepts, the current tab is captured. However, this will require some additional security measures which are still being finalized. Until then, or if the call is made with these measures absent, a dialog is displayed to the user that allows the selection of any source, but highlights the option of the current tab (whereas normally getDisplayMedia highlights the option of entire-screen).
An API for manipulating raw media carried by MediaStreamTracks such as the output of a camera, microphone, screen capture, or the decoder part of a codec and the input to the decoder part of a codec. It uses WebCodecs interfaces to represent raw media frames and exposes them using streams, similar to the way the WebRTC Insertable Streams API exposes encoded data from RTCPeerConnections. This is intended to support use cases such as:
This origin trial is expected to run through Chrome 92.
Subresource loading with Web Bundles provides a new approach to loading a large number of resources efficiently using a format that allows multiple resources to be bundled., e.g. Web Bundles.
The output of JavaScript bundlers (e.g. webpack) doesn't interact well with browsers. They are good tools but:
This origin trial also allows a bundle to include the source for an opaque-origin iframe as urn:uuid: resources. The scheme for these resources is expected to change in Chrome 91.
urn:uuid:
WebAssembly now provides exception handling support. Exception handling allows code to break control flow when an exception is thrown. The exception can be any that is known by the WebAssembly module, or it may be an unknown exception that was thrown by a called imported function. This origin trial is expected to run through Chrome 94.
The following features, previously in a Chrome origin trial, are now enabled by default.
Lighting estimation allows sites to query for estimates of the environmental lighting conditions within WebXR sessions. This exposes both spherical harmonics representing the ambient lighting, as well as a cubemap texture representing "reflections". Adding Lighting Estimation can make your models feel more natural and like they "fit" better with the user's environment.
The aspect-ratio property allows for automatically computing the other dimension if only one of width or height is specified on any element. This property was originally launched as non-interpolable (meaning that it would snap to the target value) when animated. This feature provides smooth interpolation from one aspect ratio to another.
aspect-ratio
Custom elements now expose their states via the state CSS pseudo class. Built-in elements have states that can change over time depending on user interaction and other factors, which are exposed to web authors through pseudo classes. For example, some form controls have the "invalid" state, which is exposed through the :invalid pseudo class. Since custom elements also have states it makes sense to expose their states in a manner similar to built-in elements.
The default values of CSS property appearance and -webkit-appearance for the following form controls are changed to 'auto'.
appearance
-webkit-appearance
'auto'
<input type=color>
<select>
<input type=date>
<input type=datetime-local>
<input type=month>
<input type=time>
<input type=week>
Note that the default rendering of these controls are not changed.
The clip value for overflow results in a box's content being clipped to the box's overflow clip edge. In addition, no scrolling interface is provided, and the content cannot be scrolled by the user or programmatically. Additionally the box is not considered a scroll container, and does not start a new formatting context. As a result, this value has better performance than overflow: hidden.
clip
overflow
overflow: hidden
The overflow-clip-margin property enables specifying how far outside the bounds an element is allowed to paint before being clipped. It also allows the developer to expand the clip border. This is particularly useful for cases where there is ink overflow that should be visible.
overflow-clip-margin
The Permissions-Policy HTTP header replaces the existing Feature-Policy header for controlling delegation of permissions and powerful features. The header allows sites to more tightly restrict which origins can be granted access to features.
Permissions-Policy
Feature-Policy
The Feature Policy API, introduced in Chrome 74, was recently renamed to "Permissions Policy", and the HTTP header has been renamed along with it. At the same time, the community has settled on a new syntax, based on structured field values for HTTP.
Protect application/x-protobuffer from speculative execution attacks by adding it to the list of never sniffed MIME types used by Cross-Origin-Read-Blocking. application/x-protobuf is already protected as a never sniffed mime type. application/x-protobuffer is another commonly used MIME type that is defined as an "ALT_CONTENT_TYPE" by the protobuf library.
application/x-protobuffer
Cross-Origin-Read-Blocking
application/x-protobuf
"ALT_CONTENT_TYPE"
When data is passed to FileSystemWritableFileStream.write() that would extend past the end of the file, the file is now extended by writing 0x00 (NUL). This enables creating sparse files and greatly simplifies saving content to a file when the data to be written is received out of order. Without this functionality, applications that receive file contents out of order (for example, BiTtorrent downloads) would have to manually resize the file either ahead of time or when needed during writing.
FileSystemWritableFileStream.write()
0x00
NUL
Currently, Range is the only constructible range type available to web authors. However, Range objects are "live" and maintaining them can be expensive. For every tree change, all affected Range objects need to be updated. The new StaticRange objects are not live and represent a lightweight range type that is not subject to the same maintenance cost as Range. Making StaticRange constructible allows web authors to use them for ranges that do not need to be updated on every DOM tree change.
Range
StaticRange
The <source> element now supports width and height properties when used inside a <picture> element. This allows Chrome to compute an aspect ratio for <picture> elements. This matches similar behavior for <img>, <canvas> and <video> elements.
<source>
width
height
<picture>
<img>
<canvas>
<video>
It is no longer possible to set periodicWave to null when creating a new OscillatorNode object. This value is set on the options object passed to the OscillatorNode() constructor. The WebAudio spec doesn't allow setting this value to null. Chrome now matches both the spec and Firefox.
OscillatorNode
OscillatorNode()
This version of Chrome incorporates version 9.0 of the V8 JavaScript engine. It specifically includes the changes listed below. You can find a complete list of recent features in the V8 release notes.
Array, String, and TypedArray now support the at() method, which supports relative indexing with negative numbers. For example, the code below returns the last item in the given array.
at()
let arr = [1,2,3,4]; arr.at(-1);
This version of Chrome introduces the deprecations and removals listed below. Visit ChromeStatus.com for lists of current deprecations and previous removals.
The 'plugin-types' directive allows developers to restrict which types of plugin can be loaded via <embed> or <object> html elements. This allowed developers to block Flash in their pages. Since Flash support has been discontinued, there is no longer any need for this policy directive.
<embed>
<object>
Chrome has removed support for the non-standard RTP data channels in WebRTC. Users should use the standard SCTP-based data channels instead.
Chrome now returns empty for navigator.plugins and navigator.mimeTypes. With the removal of Flash, there is no longer the need to return anything for these properties.
navigator.plugins
navigator.mimeTypes
Starting in Chrome 91 (May, 2021), cross-origin isolation will be required on all platforms in order to access APIs like SharedArrayBuffer and performance.measureUserAgentSpecificMemory(). This brings our desktop platforms in line with Android, which shipped this restriction in Chrome 88.
In order to continue using these APIs, ensure that your pages are cross-origin isolated by serving the page with the following headers:
Cross-Origin-Embedder-Policy: require-corpCross-Origin-Opener-Policy: same-origin
Be aware, once you do this, your page will not be able to load cross-origin content unless the resource explicitly allows it via a Cross-Origin-Resource-Policy header or CORS headers (Access-Control-Allow-* and so forth).
For more detailed adoption instructions and considerations, take a look at the web.dev guide to enable cross-origin isolation.
Unless otherwise noted, changes described below apply to the newest Chrome beta channel release for Android, Chrome OS, Linux, macOS, and Windows. Learn more about the features listed here through the provided links or from the list on ChromeStatus.com. Chrome 89 is beta as of January 28, 2021.
There is a long tail of human interface devices (HIDs) that are too new, too old, or too uncommon to be accessible by systems' device drivers. The WebHID API solves this by providing a way to implement device-specific logic in JavaScript.
A human interface device is one that takes input from or provides output to humans. Examples of devices include keyboards, pointing devices (mice, touchscreens, etc.), and gamepads.
The inability to access uncommon or unusual HID devices is particularly painful, for example, when it comes to gamepad support. Gamepad inputs and outputs are not well standardized and web browsers often require custom logic for specific devices. This is unsustainable and results in poor support for the long tail of older and uncommon devices.
With its origin trial over, WebHID is enabled by default in Chrome 89 on desktop. To learn how to use it, check out Connecting to uncommon HID devices, and see demos in Human interface devices on the web: a few quick examples.
NFC stands for Near Field Communications, a short-range wireless technology for transmitting small amounts of data, usually between a specialized NFC device and a reader. If you've scanned a badge to enter a building, you may have used NFC.
Web NFC allows a web app to read from and write to NFC tags. This opens new use cases to the web, including providing information about museum exhibits, inventory management, providing information in a conference badge, and many others. In Chrome 89 on Android, Web NFC is enabled by default.
Web NFC cards demo at Chrome Dev Summit
With NFC reading and writing are simple operations. You'll need a little instruction for constructing and interpreting payloads, but it's not complicated. Fortunately, we have an article, Interact with NFC devices on the web. Check it out. We have some samples you can play with. Here's a taste:
Writing a string to an NFC tag:
if ("NDEFReader" in window) { const ndef = new NDEFReader(); await ndef.write("Hello world!"); }
Scanning messages from NFC tags:
if ("NDEFReader" in window) { const ndef = new NDEFReader(); await ndef.scan(); ndef.onreading = ({ message }) => { console.log(`Records read from a NFC tag: ${message.records.length}`); }; }
A serial port is a bidirectional communication interface that allows sending and receiving data byte by byte. The Web Serial API brings this capability to websites, letting them control devices such as microcontrollers and 3D printers.
In educational, hobbyist, and industrial settings, peripheral devices are already controlled through web pages. In all such cases device control requires installation of adapters and drivers. The Web Serial API improves the user experience by enabling direct communication between a website and a peripheral.
Its origin trial is over and the Web Serial API is now enabled on desktop. A demo is available on GitHub. For information about using it, see Read to and write from a serial port.
To allow users to easily share content on social networks, developers have manually integrated sharing buttons into their site for each social service. This often leads to users not being able to share with the services they actually use, in addition to bloated page sizes and security risks from third-party code. On the receiving end, only platform apps could register to be share targets and receive shares from other apps.
Chrome for Android started adding these features between Chrome 61 and 75. In Chrome 89, web sharing is available on Windows and ChromeOS, while registering as a share target is supported on ChromeOS. On these platforms, sites can now use navigator.share() on desktop to trigger a share dialog box. And an entry to the web app manifest allows a PWA to act as a share target.
navigator.share()
For information on web sharing, see Integrate with the OS sharing UI with the Web Share API. To learn to configure a PWA as a share target, see Receiving shared data with the Web Share Target API.
There are no new origin trials in this version of Chrome. To register for current origin trials, visit the Origin Trials dashboard. To learn more about origin trials themselves, visit the Origin Trials Guide for Web Developers.
Chrome now supports decoding AVIF content natively using existing AV1 decoders on Android and WebView. (Desktop support was added in Chrome 85.) AVIF is a next generation image format standardized by the Alliance for Open Media. There are three primary motivations for supporting AVIF:
A new reporting API helps developers deploy cross-origin opener policy. In addition to reporting breakages when COOP is enforced, the API provides a report-only mode for COOP. The report-only mode for COOP will not enforce COOP, but it will report potential breakages that would have happened had we enforced COOP. Developers can inspect the reporting API with Chrome DevTools.
The new display_override field for the web app manifest allows developers to specify an explicit fallback chain for the display field. The following example specifies a "minimal-ui", falling back to "standalone".
display_override
display
"minimal-ui"
"standalone"
{ "display": "standalone", "display_override": ["minimal-ui"], }
This API is intended for advanced use cases and display modes, and its capabilities are limited. You can learn more in its Chrome Status entry.
Chrome now exposes the ReadableStreamDefaultController interface on the global object, as with the other ReadableStream-related classes. This eliminates a previous limitation where instances had to be created inside stream constructors.
ReadableStreamDefaultController
The feature adds a performance.measureUserAgentSpecificMemory() function which estimates the memory usage of the web page. The method is gated behind COOP/COEP thus the web site needs to be cross-origin isolated to use it.
performance.measureUserAgentSpecificMemory()
To conform to current web standards, Chrome now treats all data: urls as potentially trustworthy. For background, It's often necessary to evaluate whether a URL is secure in order to only enable certain features when minimum standards of authentication and confidentiality are met. For that purpose, web standards rely on the definition of "potentially trustworthy URL", which includes URLs with the "data" scheme in the latest version of the Secure Contexts specification. Blink previously only treated some data: URLs as potential trustworthy.
The streams APIs provide ubiquitous, interoperable primitives for creating, composing, and consuming streams of data. For streams representing bytes, Chrome now supports an extended version of the readable stream to handle bytes efficiently, specifically by minimizing copies.
Byte streams allow for Bring Your Own Buffer (BYOB) readers to be acquired. The default implementation can give a range of different outputs such as strings or array buffers in the case of web sockets, whereas byte streams guarantee byte output. Furthermore, being able to have BYOB readers has stability benefits. This is because if a buffer detaches, there's now a guarantee that the same buffer won't be written to twice, hence avoiding race conditions. BYOB readers also do not need to garbage collect for every read, because buffers are reused.
Chrome now allows the full syntax of the 'filter' property to be used on SVG elements which previously only supported single url() references. This lets filter functions such as blur(), sepia() and grayscale() apply to both SVG elements and non-SVG elements. It makes the platform support for 'filter' more uniform and allows for easier application of some "canned" effects. Without this feature developers need to use a full SVG <filter> element definition even for basic filters such as grayscale() or blur().
'filter'
url()
blur()
sepia()
grayscale()
<filter>
Chrome now supports two new features related to the Web Authentication API. The AuthenticatorSelectionCriteria.residentKey property specifies for web authentication credential registration whether a client-side discoverable credential should be created.
AuthenticatorSelectionCriteria.residentKey
The Web Authentication credProps extension indicates to the relying party whether a created credential is client-side discoverable. "Client-side discoverable credentials" are a type of WebAuthn credential that can be challenged by a relying party without needing to provide the credential ID in the WebAuthn API request. Browsers display a list of all discoverable credentials from a given authenticator (either external security key or built-in) and let the user choose one to sign in with.
credProps
Adds a highlight pseudo element to allow authors to style scroll-to-text fragments differently from the default user agent highlighting.
scroll-to-text
Flow-relative corner rounding properties now allow control of corners using logical mappings rather than physical properties. Additionally, this allows authors to set different corner border radii depending on the direction and writing mode of the page.This brings Chrome in line with the CSS Logical Properties and Values spec. The following logical properties have been added:
border-start-start-radius
border-start-end-radius
border-end-start-radius
border-end-end-radius
The forced-colors media feature detects whether the user agent is enforcing a user-chosen limited color palette on the page.
forced-colors
The forced-color-adjust property allows authors to opt particular elements out of forced colors mode, restoring full control over the colors to CSS.
forced-color-adjust
This version of Chrome incorporates version 8.9 of the V8 JavaScript engine. It specifically includes the changes listed below. You can find a complete list of recent features in the V8 release notes.
Chrome now allows the await keyword at the top level within JavaScript modules. This allows more seamless integration of asynchronous calls into the module loading process. Today this is accomplished by wrapping modules in async functions, but this pushes complexity into dependent modules and exposes implementation details.
await
EXIF information is now always used to orient cross-origin images. That is, setting image-orientation: none in CSS has no effect on non-secure-origin images. The spec discussion behind the change is available in a CSS working group draft.
image-orientation: none
The legacy prefixed events (webkitprerenderstart, webkitprerenderstop, webkitprerenderload, and webkitprerenderdomcontentloaded) dispatched on <link rel=prerender> are now removed from Chrome.
webkitprerenderstart
webkitprerenderstop
webkitprerenderload
webkitprerenderdomcontentloaded
<link rel=prerender>
When a window is opened with noopener, Chrome will no longer clone the sessionStorage of its opener; it will instead start an empty sessionStorage namespace. This brings Chrome in conformance with the HTML specification.
sessionStorage