Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, macOS, and Windows. Find more information about the features listed here through the provided links or from the list on ChromeStatus.com. Chrome 78 is beta as of September 19, 2019.

CSS Properties and Values

CSS variables are getting more power with CSS Properties and Values API Level 1. With it, you can register your variables as full custom properties, ensuring they're always a specific type, and letting you set a default value, or even, animate them.

Take the image below, for example.



What you're seeing is a transition created with a CSS custom property. In addition to being impossible without the new API, this transition is also type safe. For details and access to the code used to generate this image, see Smarter custom properties with Houdini's new API.

Native File System

The new Native File System API, now in an origin trial, enables developers to build powerful web apps that interact with files on the user's local device such as IDEs, photo and video editors, text editors, and more. After a user grants access, this API allows web apps to read or save changes directly to files and folders on the user's device. It does all this by invoking the platform's own open and save dialog boxes. The image below shows a web page invoked using the open dialog box on Mac.



To learn more, see sample code, and a text editor demonstration app, see The Native File System API: Simplifying access to local files for details.

See the Origin Trials section for information on signing up and for a list of other origin trials in this release.

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

Signed Exchange Subresource Prefetching and Loading by Extending the HTTP Link Header.

Signed Exchanges allow a distributor to provide content signed by a publisher and displayed in such a way that user agents show the publisher's URL, and scripts access the publisher's local storage. The URLs of subresources are fixed in the signed top-level HTML file, which prevents their loads from taking advantage of any signed versions that might be prefetched from the distributor's origin. To allow the subresources to be prefetched from the same distributor as the top-level page,the publisher needs to change the subresource URLs in the HTML to point to each distributors’ URL and needs to sign for each distributor. The intent of this is to allow publishers to create a single signed top-level HTML file that allows its subresources to be prefetched from a variety of distributors.

SMS Receiver API

Websites use SMS messages as a way to verify phone numbers by sending a one-time-password for manual entry into a form (or for copy and paste). Native platforms offer an API that gives programmatic access to such messages that allows users to skip manual interaction with the form.
The SMS Receiver API allows websites to access SMS messages that are delivered to the user's phone specifically addressed to the origin (via a special formatting convention).

Other Features in this Release

Apply Opacity for the Default Style of INPUT/TEXTAREA placeholder

Changes the default style for ::placeholder from #757575 to rgba(0, 0, 0, 0.54).

Extend Byte-for-Byte Update Check to all Service Worker importScripts() Resources

Byte-for-byte checks are now available for service worker scripts imported by importScripts(). Currently, service workers update only when the service worker main script has changed. In addition to not conforming to the latest spec, this forces developers to build workarounds such as adding hashes to the imported script's urls.

Faster Web Sockets

Chrome 78 improves the download speed of ArrayBuffer objects when used with WebSocket objects on desktop. We have seen the following improvements in our own testing. Results depend on network speed and hardware so your results may be vary.

• Linux: 7.5 times faster
• Windows: 4.1 times faster
• Mac: 7.8 times faster

More restrictive hasEnrolledInstrument() for Autofill Instruments

Improves the authorization of transactions by requiring unexpired cards and a billing address. This improves the quality of autofill data and increases the chances that PaymentRequest.hasEnrolledInstrument() returns true. This improves the user experience on transactions that use autofill data.

PaymentResponse.prototype.retry()

In cases where there is something wrong with the payment response's data (for example, the shipping address is a PO box), the retry() method of a PaymentResponse instance now allows you to ask a user to retry a payment.

Percentage Opacity

Adds support for percentage values to the opacity properties, specifically, opacity, stop-opacity, fill-opacity, stroke-opacity, and shape-image-threshold. For example, opacity: 50% is equivalent to opacity: 0.5. This brings consistency and spec compliance. The rgba() function already accepts percentage alpha value, for example rgba(0, 255, 0, 50%).

Redact Address in PaymentRequest.onshippingaddresschange Event

Removes fine-grained information from the shipping address before exposing it to a merchant website in the ShippingAddressChange event. PaymentRequest.onshippingaddresschange is used to communicate the shipping address a user has selected to the merchant so they can make adjustments to the payment amounts such as shipping cost and tax. At this point, the user has not fully committed to the transaction, so the principle should be to return as little information as possible to the merchant. The redaction removes recipient, organization, addressLine and phoneNumber from the shipping address because these are not typically needed for shipping cost and tax computation.

Seeking

Adds a media session action handler for the seekto action. An action handler is an event tied specifically to a common media function such as pause or play. The seekto action handler is called when the site should move the playback time to a specific time.

User Timing L3

Extends the existing User Timing API to enable two new use cases:

• Developers can pass custom timestamps to performance.measure() and performance.mark(), so as to conduct measurement across arbitrary timestamps.
• Developers can report arbitrary metadata with performance.mark() and performance.measure(), which provides rich data to analytics via a standardized API.

Deprecations, and Removals

XSS Auditor

XSS Auditor has been removed from Chrome. The XSS Auditor can introduce cross-site information leaks and mechanisms to bypass the Auditor are widely known.

Update: Due to a last minute technical issue, we have postponed this experiment to Chrome 79.

As part of  our long standing commitment to making the web safer to use, we will be conducting an experiment to validate our implementation of DNS-over-HTTPS (aka DoH) in Chrome 78. As the name implies, the idea is to bring the key security and privacy benefits of HTTPS to DNS, which is how your browser is able to determine which server is hosting a given website. For example, when connected on a public WiFi, DoH would prevent other WiFi users from seeing which websites you visit, as well as prevent potential spoofing or pharming attacks. This experiment will be done in collaboration with DNS providers who already support DoH, with the goal of improving our mutual users’ security and privacy by upgrading them to the DoH version of their current DNS service. With our approach, the DNS service used will not change, only the protocol will. As a result, existing content controls of your current DNS provider, including any existing protections for children, will remain active.

More concretely, the experiment in Chrome 78 will check if the user’s current DNS provider is among a list of DoH-compatible providers, and upgrade to the equivalent DoH service from the same provider. If the DNS provider isn’t in the list, Chrome will continue to operate as it does today. The providers included in the list were selected for their strong stance on privacy and security, as well as the readiness of their DoH services, and also agreed to participate in the experiment. The goals of this experiment are to validate our implementation and to evaluate the performance impact. 

Our experiment will run on all supported platforms (with the exception of Linux and iOS) for a fraction of Chrome users. On Android 9 and above, if the user has specified a DNS-over-TLS provider in the private DNS settings, Chrome may use the associated DoH provider, and will fallback to the system private DNS upon error.

By keeping the DNS provider as-is and only upgrading to the provider’s equivalent DoH service, the user experience would remain the same. For instance, malware protection or parental control features offered by the DNS provider will continue to work. If DoH fails, Chrome will revert to the provider’s regular DNS service. Opting-out of the experiment will be possible from Chrome 78 by disabling the flag at chrome://flags/#dns-over-https.


Most managed Chrome deployments are excluded from the experiment.  For enterprise and education customers, we invite administrators to read the upcoming release notes for details about DoH policies which will be published on our Chrome Enterprise blog.

With 35 years of history, DNS is used by multiple parties, and enables diverse use cases. In particular, we are aware of how DNS can play an important role in ISP-provided family-safe content filtering. So, we are and will continue to take an incremental approach where we respect any active user-facing features such as family-friendly filters, with steps informed by discussions involving key stakeholders, e.g. ISPs, DNS providers, and organizations with expertise in online safety. We will also take into account performance and reliability statistics sent by users who have agreed to help improve Chrome’s features and performance, as well as user feedback.

This experiment is the humble first step of a long collaborative journey to improve our users’ privacy, security, and safety. We can’t wait to see how DoH performs in the wild, and welcome your feedback!

Kenji Baheux, Chrome Product Manager