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 79 is beta as of October 31, 2019.

Virtual Reality Comes to the Web

The WebXR Device API is shipping in Chrome. Developers can now create immersive experiences for smartphones and head-mounted displays. Other browsers will be supporting these specs soon, including Firefox Reality, Oculus Browser, Edge and Magic Leap's Helio browser, among others.

This launch sets the foundation for immersive features to come, such as supporting augmented reality, tools, and expanding the real-world understanding of immersive experiences. Many experiences can be enhanced with immersive functionality. Examples include games, home buying, viewing products in your home before buying them and more. To get started with virtual reality and the new API, read Virtual reality comes to the web.

Origin Trials

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 Origin Trials dashboard. To learn more about origin trials themselves, visit the Origin Trials Guide for Web Developers.

Support for rendersubtree Attribute

Adds the rendersubtree attribute to all HTML elements, which locks a DOM element for display. When rendersubtree is set to "invisible", the element's content is not drawn or hit-tested, allowing for rendering optimizations. The rendersubtree "activatable" token allows the browser to remove the invisible attribute, rendering the content, and making it visible.

Wake Lock API based on Promises

Adds an update of the Wake Lock API that introduce promises and wake lock types. The Wake Lock API brought a standard, secure, and safe way to prevent some device features such as the screen or CPU cycles from going into power saving state. This update addresses some of the shortcomings of the older API which was limited to screen Wake Lock and didn't address certain security and privacy issues.

Other Features in this Release

Adaptive Icon Display for Installed PWAs on Android

Android Oreo introduced adaptive icons, which enforced the same shape for all icons on the home screen and in the launcher. Before Android O icons could be any shape and there was no background behind each icon. For example, gmail was rectangular, and Play was a triangle. Consequently, such icons were placed in a white circle. With adaptive icon display, Android will automatically mask irregularly shaped icons to fit properly. To make PWA icons safe for display on Android O or later, read Adaptive icon support in PWAs with maskable icons.

Autofocus Support for any Focusable HTML/SVG Element

Adds the autofocus attribute to any focusable HTML or SVG element. The autofocus was previously supported for a limited number of HTML elements, and there were elements which could receive focus but didn't support the autofocus attribute. This feature fixes the inconsistencies.

Compute img/video Aspect Ratio from Width Or Height HTML Attributes

The aspect ratio of an image is now computed so that it can be used for sizing an image using CSS before it loads. This avoids unnecessary relayouts when the image loads.

font-optical-sizing

The font-optical-sizing property
automatically sets the font size to the opsz - optical sizing axis of variable fonts that support optical sizing. This improves styling and legibility of fonts depending on font size because the font chooses a glyph shape that works optimally at the given font size. For example, the glyph contrast is improved in fonts in heading sizes when compared to the same font at body text size.

list-style-type: <string>

Allows a stylesheet to use an arbitrary character for the list style marker. Examples include "-", "+", "★" and "▸". Since CSS Level 2, list-style-type has supported keywords like disc or decimal to define the appearance of the list item marker.
Without this, developers are often forced to hide the real marker and insert the arbitrary marker using a ::before pseudo element via the content property. Unfortunately, the fake marker won't be nicely positioned by list-style-position.

Reject Worklet.addModule() with a More Specific Error

When Worklet.addModule() fails, a promise rejects with a more specific error object than it did previously. Worklet.addModule() can fail for various reasons, including, for example, network errors and syntax errors. Before this change, Worklet.addModule() rejected with AbortError regardless of the actual cause. That made it difficult for developers to debug worklets. After this change, Worklet.addModule() rejects with a clearer error such as SyntaxError.

Retrieve a Service Worker Object Corresponding to a Worker Itself

A service worker can now get its ServiceWorker object with self.serviceWorker in a service worker script and its current state with self.serviceWorker.state. A service worker instance previously had no way to get its current lifecycle state. This removes the need for the hack wherein the current lifecycle state is tracked with a global variable, a method that is error prone and doesn't correctly capture waiting periods.

Stop Evaluating Script Elements Moved Between Documents During Fetching

Chrome no longer evaluates scripts or fire error and load events if <script> elements are moved between documents during fetching. Script elements can still be moved between documents, but they won't be executed. This prevents possible security bugs caused by exploitation of <script> elements moved between documents.

Deprecations, and Removals

This version of Chrome introduces the deprecations and removals listed below. Visit ChromeStatus.com for lists of current deprecations and previous removals.

-webkit-appearance Keywords for Arbitrary Elements

Changes -webkit-appearance keywords to work only with specific element types. If a keyword is applied to a non-supported element, the element takes the default appearance.

Whenever you type a URL into your browser (for example “redcross.org”), this information is sent to a domain name system (DNS) provider that converts that request into the unique numerical “IP address” (e.g. 162.6.217.119) that identifies websites on the Internet. Your browser then uses that numerical IP address to take you to the site you were looking for. Unfortunately, today the requests from your browser to the DNS provider are not encrypted (which makes you vulnerable to passive monitoring by strangers) nor authenticated (which makes you vulnerable to online attackers). This is especially true when you’re connected to public WiFi, for example at a cafe or airport, since anyone else using the network can see and track the websites you visit and maybe redirect your browser to a malicious website.

In September, we announced an experiment in Chrome to improve online privacy and security by enabling secure DNS connections with DNS-over-HTTPS (DoH) for users already using DNS providers that support it. DoH is being developed by the Internet standards community as a step toward better security and privacy by encrypting the traffic between your browser and your DNS provider. It improves privacy by removing one of the ways used by malicious actors to observe the browsing habits of other users on the same network. DoH is also a significant security improvement, as it helps stop man-in-the-middle attacks on DNS lookups. Many privacy-minded organizations, journalists, other browser providers and internet service providers (ISPs) agree that these changes will improve your privacy and security.

Unfortunately, there has been some misinformation and confusion about the goals of our approach and whether DoH will impact existing content controls offered by ISPs. The confusion comes from two particular claims and we want to address both.

The first claim is that Google is going to redirect user DNS traffic to Google's own DNS or another DoH-compliant DNS provider. That is incorrect. Because we believe in user choice and user control, we have no plans to force users to change their DNS provider. Today, there are many independent DNS providers, although ISPs serve approximately 97% of user DNS needs. As long as these service providers keep catering to user needs and concerns, it will remain a diverse ecosystem. We’re simply enabling support in Chrome for secure DoH connections if a user’s DNS provider of choice offers it. Chrome will check if the user’s DNS provider is among a list of participating DoH-compatible providers and if so, it will enable DoH. If the DNS provider is not on the list, Chrome won’t enable DoH and will continue to operate as it does today. As DoH adoption increases, we expect to see the number of DoH-enabled DNS providers grow.

The second claim we’ve seen is that the secure DoH connection will limit the family-safe content controls offered by some ISPs. In fact, any existing content controls of your DNS provider, including any protections for children, should remain active. DoH secures the URL data only while it’s in transit between your browser and the DNS provider, so your provider’s malware protection and parental control features will continue to work as they have in the past. As a proof point, CleanBrowsing offers the same parental control features on its DoH service as it does on its unencrypted service.

As we said last month, we’re taking an incremental approach with this experiment, and our current plan is to enable DoH support for just 1% of our users, provided that they are already using a DoH compliant DNS provider. This will allow Google and DoH providers to test the performance and reliability of DoH. We’ll also monitor feedback from our users and from other stakeholders, including ISPs. Most managed Chrome deployments such as schools and enterprises are excluded from the experiment by default. We also offer policies for administrators to control the feature. Finally, Chrome users may opt-out of the DoH experiment entirely by going to chrome://flags/#dns-over-https, starting in Chrome 79.

We are optimistic about the opportunities DoH offers for improving user privacy and security, but we also understand the importance of DNS and that there could be implementation concerns we haven’t foreseen. That’s why we plan to move carefully and transparently. We’re open to feedback and welcome constructive collaboration and engagement. We are committed to ensure that the deployment of DoH does not create unintended consequences and we will continue to work with stakeholders including ISPs, DNS providers, and Internet and child safety advocates as we make progress.


Posted by Kenji Baheux, Chrome Product Manager

UPDATE (10/28/2019): We've revised the 2nd and 3rd bullet points in the section "How to Prepare; Known Complexities" below.
In May, Chrome announced a secure-by-default model for cookies, enabled by a new cookie classification system (spec). This initiative is part of our ongoing effort to improve privacy and security across the web.
Chrome plans to implement the new model with Chrome 80 in February 2020. Mozilla and Microsoft have also indicated intent to implement the new model in Firefox and Edge, on their own timelines. While the Chrome changes are still a few months away, It’s important that developers who manage cookies assess their readiness today. This blog post outlines high level concepts; please see SameSite Cookies Explained on web.dev for developer guidance.

Understanding Cross-Site and Same-Site Cookie Context

Websites typically integrate external services for advertising, content recommendations, third party widgets, social embeds and other features. As you browse the web, these external services may store cookies in your browser and subsequently access those cookies to deliver personalized experiences or measure audience engagement. Every cookie has a domain associated with it. If the domain associated with a cookie matches an external service and not the website in the user’s address bar, this is considered a cross-site (or “third party”) context.

Less obvious cross-site use cases include situations where an entity that owns multiple websites uses a cookie across those properties. Although the same entity owns the cookie and the websites, this still counts as cross-site or “third party” context when the cookie’s domain does not match the site(s) from which the cookie is accessed.


In contrast, cookie access in a same-site (or “first party”) context occurs when a cookie’s domain matches the website domain in the user’s address bar. Same-site cookies are commonly used to keep people logged into individual websites, remember their preferences and support site analytics.

• Chrome for Android has enabled Site Isolation for sites where users enter passwords.
• On desktop platforms, Site Isolation now helps defend against attacks from fully compromised renderer processes, not just side-channel attacks.

Site Isolation on Android

Chrome 77 has brought Site Isolation and its benefits to Android users. Like Site Isolation on desktop, this launch leverages OS processes to make it harder for attackers to steal data from other websites. In particular, it offers the most effective defense against Spectre-like CPU vulnerabilities.

We wanted to ensure that Site Isolation does not adversely affect user experience in a resource-constrained environment like Android. This is why, unlike desktop platforms where we isolate all sites, Chrome on Android uses a slimmer form of Site Isolation, protecting fewer sites to keep overhead low. More specifically, Site Isolation is turned on only for high-value sites where users log in with a password. This protects sites with sensitive data that users likely care about, such as banks or shopping sites, while allowing process sharing among less critical sites.

Once Chrome observes a password interaction on a website, future visits to that site will be protected by Site Isolation. That means the site will be rendered in its own dedicated renderer process, walled off from other sites. Navigations to other sites will cause a tab to switch processes, and cross-site iframes are put into a different process, becoming "out-of-process iframes." Chrome keeps a list of isolated sites stored locally on the device and clears the list whenever users clear their browsing history or other site data. To bootstrap, Chrome also isolates a crowdsourced list of sites where mobile users have been entering passwords most frequently.

For the most part, Site Isolation is a behind-the-scenes architectural change that should not change the experience for users or developers. As on desktop platforms, it does cause Chrome to create more processes, which comes with performance tradeoffs: on the plus side, each renderer process is smaller, shorter-lived, and has less contention internally, but there is about a 3-5% total memory overhead in real workloads. We continue to work hard to optimize this behavior to keep Chrome both fast and secure.

In Chrome 77, password-triggered Site Isolation has been enabled for 99% of users (with a 1% holdback to monitor and improve performance) on Android devices that have a sufficient amount of RAM (currently 2GB). While we investigate how to bring this support to more devices, users who desire the most complete protection for their devices may manually opt in to full Site Isolation via chrome://flags/#enable-site-per-process, which will isolate all websites but carry higher memory cost.

In the future, we plan to add support for more ways of detecting when a site should be protected by Site Isolation. For example, we're working on allowing website operators to opt in any site to Site Isolation, without requiring user login.

Containing Compromised Renderers

On desktop platforms, Site Isolation in Chrome 77 now helps defend against significantly stronger attacks. Our initial launch targeted Spectre-like attacks which could leak any data from a given renderer process. Site Isolation can now handle even severe attacks where the renderer process is fully compromised via a security bug, such as memory corruption bugs or Universal Cross-Site Scripting (UXSS) logic errors.

For example, suppose an attacker discovered and exploited a memory corruption bug in Chrome's rendering engine, Blink. The bug might allow them to run arbitrary native code within the sandboxed renderer process, no longer constrained by the security checks in Blink. However, Chrome's browser process knows what site the renderer process is dedicated to, so it can restrict which cookies, passwords, and site data the entire process is allowed to receive. This makes it far more difficult for attackers to steal cross-site data.

In Chrome 77, Site Isolation helps protect many types of sensitive data from such compromised renderer processes:

• Authentication: Cookies and stored passwords can only be accessed by processes locked to the corresponding site.
• Network data: Site Isolation uses Cross-Origin Read Blocking to filter sensitive resource types (e.g., HTML, XML, JSON, PDF) from a process, even if that process tries to lie to Chrome's network stack about its origin. Resources labeled with a Cross-Origin-Resource-Policy header are also protected.
• Stored data and permissions: Renderer processes can only access stored data (e.g., localStorage) or permissions (e.g., microphone) based on the process's site lock. 
• Cross-origin messaging: Chrome's browser process can verify the source origin of postMessage and BroadcastChannel messages, preventing the renderer process from lying about who sent the message.

We are continuing to improve compromised renderer protections in several ways:

• Bringing these protections to Chrome for Android. This requires extra work to handle the case where only certain sites are isolated.
• Protecting CSRF defenses. Sec-Fetch-Site and Origin request headers can be verified to prevent compromised renderers from forging them.
• Protecting more types of data. We are investigating how to protect additional data types by default with Cross-Origin Read Blocking.
• Removing exceptions. We are working to remove cases where these protections may not yet apply. For example, a small set of extensions still have broader cross-site access from content scripts, until they update to the new security model. We have already worked with extension authors to bring the affected Chrome user population down from 14% to 2%, as well as harden other extension security issues. Also, Site Isolation does not apply to Flash, which is currently disabled by default and is on a deprecation path.

We're excited about the improvements this brings to Chrome's overall security model. As a result, we are broadening the scope of the Chrome Vulnerability Reward Program to also cover cross-site data disclosure attacks that involve compromised renderers. For a limited time, security bugs affecting Site Isolation may be eligible for higher rewards than the usual amount for information disclosure bugs. We are grateful for the contributions from security researchers that we have received so far, and we look forward to working together further to improve the state of web security.

Posted by Alex Moshchuk and Łukasz Anforowicz, Site Isolators

One of the foundational security features of Chromebooks is Verified Boot, which protects our users from potentially malicious software being run on their devices. The last chain of verification in this process is to validate the integrity of the root file system (rootfs). This blog post describes a recent enhancement to this rootfs validation to increase the cryptographic strength against attackers. This enhancement was carefully implemented to ensure that it didn’t negatively impact the startup time of Chromebooks.

Update (April 6, 2020): Mixed image autoupgrading was originally scheduled for Chrome 81, but will be delayed until at least Chrome 84. Check the Chrome Platform Status entry for the latest information about when mixed images will be autoupgraded and blocked if they fail to load over https://. Sites with mixed images will continue to trigger the “Not Secure” warning. 

Today we’re announcing that Chrome will gradually start ensuring that https:// pages can only load secure https:// subresources. In a series of steps outlined below, we’ll start blocking mixed content (insecure http:// subresources on https:// pages) by default. This change will improve user privacy and security on the web, and present a clearer browser security UX to users.

In the past several years, the web has made great progress in transitioning to HTTPS: Chrome users now spend over 90% of their browsing time on HTTPS on all major platforms. We’re now turning our attention to making sure that HTTPS configurations across the web are secure and up-to-date.

HTTPS pages commonly suffer from a problem called mixed content, where subresources on the page are loaded insecurely over http://. Browsers block many types of mixed content by default, like scripts and iframes, but images, audio, and video are still allowed to load, which threatens users’ privacy and security. For example, an attacker could tamper with a mixed image of a stock chart to mislead investors, or inject a tracking cookie into a mixed resource load. Loading mixed content also leads to a confusing browser security UX, where the page is presented as neither secure nor insecure but somewhere in between.

In a series of steps starting in Chrome 79, Chrome will gradually move to blocking all mixed content by default. To minimize breakage, we will autoupgrade mixed resources to https://, so sites will continue to work if their subresources are already available over https://. Users will be able to enable a setting to opt out of mixed content blocking on particular websites, and below we’ll describe the resources available to developers to help them find and fix mixed content.

Timeline

Instead of blocking all mixed content all at once, we’ll be rolling out this change in a series of steps.

• In Chrome 79, releasing to stable channel in December 2019, we’ll introduce a new setting to unblock mixed content on specific sites. This setting will apply to mixed scripts, iframes, and other types of content that Chrome currently blocks by default. Users can toggle this setting by clicking the lock icon on any https:// page and clicking Site Settings. This will replace the shield icon that shows up at the right side of the omnibox for unblocking mixed content in previous versions of desktop Chrome.

• In Chrome 80, mixed audio and video resources will be autoupgraded to https://, and Chrome will block them by default if they fail to load over https://. Chrome 80 will be released to early release channels in January 2020. Users can unblock affected audio and video resources with the setting described above.
• Also in Chrome 80, mixed images will still be allowed to load, but they will cause Chrome to show a “Not Secure” chip in the omnibox. We anticipate that this is a clearer security UI for users and that it will motivate websites to migrate their images to HTTPS. Developers can use the upgrade-insecure-requests or block-all-mixed-content Content Security Policy directives to avoid this warning. Here is the planned treatment:

• In Chrome 81, mixed images will be autoupgraded to https://, and Chrome will block them by default if they fail to load over https://. Chrome 81 will be released to early release channels in February 2020.

Resources for developers

Developers should migrate their mixed content to https:// immediately to avoid warnings and breakage. Here are some resources:

• Use Content Security Policy and Lighthouse’s mixed content audit to discover and fix mixed content on your site.
• See this guide for general advice on migrating servers to HTTPS.
• Check with your CDN, web host, or content management system to see if they have special tools for debugging mixed content. For example, Cloudflare offers a tool to rewrite mixed content to https://, and WordPress plugins are available as well.

Posted by Emily Stark and Carlos Joan Rafael Ibarra Lopez, Chrome security team

Update (April 6, 2020): The removal of legacy TLS versions was originally scheduled for Chrome 81, but is being delayed until at least Chrome 84. Chrome will continue to show the “Not Secure” indicator for sites using TLS 1.0 or 1.1, and Chrome 81 Beta will show the full page interstitial warning for affected sites. Our hope is that this will help alert affected site owners ahead of the delayed removal. Check the Chrome Platform Status entry for the latest information about the removal of TLS 1.0 and 1.1 support.

Last October we announced our plans to remove support for TLS 1.0 and 1.1 in Chrome 81. In this post we’re announcing a pre-removal phase in which we’ll introduce a gentler warning UI, and previewing the UI that we’ll use to block TLS 1.0 and 1.1 in Chrome 81. Site administrators should immediately enable TLS 1.2 or later to avoid these UI treatments.

While legacy TLS usage has decreased, we still see over 0.5% of page loads using these deprecated versions. To ease the transition to the final removal of support and to reduce user surprise when outdated configurations stop working, Chrome will discontinue support in two steps: first, showing new security indicators for sites using these deprecated versions; and second, blocking connections to these sites with a full page warning.

Pre-removal warning

Starting January 13, 2020, for Chrome 79 and higher, we will show a “Not Secure” indicator for sites using TLS 1.0 or 1.1 to alert users to the outdated configuration: