When verifying the ownership of a phone number, it is typically done by sending a one-time-password (OTP) over SMS which must be manually entered by the user (or copied and pasted). This manual user flow requires directing the user to the native SMS app and back to their web app with the code. With the Web OTP API, developers can help users enter the code with one tap.
For more information, see Verify phone numbers on the web with the Web OTP API.
Web Animations
Animations on the web help users navigate a digital space, help users remember your app or site, and provide implicit hints around how to use your product. Now, developers have greater control over web animations with the Web Animations API.
Although parts of the API have been around for some time, the new implementation in Chrome is a milestone in its development. In addition to greater spec compliance, Chrome now supports compositing operations, which control how effects are combined and offers many new hooks which enable replaceable events. Additionally, the API now supports Promises, which allow for animation sequencing and for greater control over how animations interact with other app features.
For more information and instructions for using web animations, see Web Animations API improvements in Chromium 84.
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.
The Idle Detection API notifies developers when a user is idle, indicating such things as lack of interaction with the keyboard, mouse, screen, activation of a screensaver, locking of the screen, or moving to a different screen. A developer-defined threshold triggers the notification. For more information, see Detect inactive users with the Idle Detection API.
Origin Isolation
Origin isolation allows web developers to opt in to giving up certain cross-origin same-site access capabilities—namely synchronous scripting via document.domain, and calling postMessage() to WebAssembly.Module instances. This gives the browser more flexibility in implementation technologies. In particular, Chrome now uses this as a hint to put the origin in its own process, subject to resource or platform limitations.
Site isolation, i.e. process-per-site, is the current state of the art in protecting websites from each other. Certain legacy features prevent us from aligning this protection boundary with the origin boundary. Origin isolation allows developers to voluntarily give up these legacy features, in exchange for better isolation.
WebAssembly SIMD
WebAssembly SIMD exposes hardware SIMD instructions to WebAssembly applications in a platform-independent way. The SIMD proposal introduces a new 128-bit value type that can be used to represent different types of packed data, and several vector operations that operate on packed data.
SIMD can boost performance by exploiting data level parallelism and is also useful when compiling native code to WebAssembly.
Completed Origin Trials
The following features, previously in a Chrome origin trial, are now enabled by default.
Content Indexing API
The Content Indexing API, now out of its origin trial, provides metadata about content that your web app has already cached. More specifically, it stores URLs for HTML documents that display stored media. The new API lets you add, list, and remove resources. Browsers can use the information in the index to display a list of offline-capable content. For more information, read Indexing your offline-capable pages with the Content Indexing API.
Wake Lock API Based on Promises
The Wake Lock API has been updated with promises. 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
App shortcuts
To improve users' productivity and facilitate re-engagement with key tasks, Chrome now supports app shortcuts in Android. They allow web developers to provide quick access to a handful of common actions that users need frequently. For sites that are already Progressive Web Apps, creating shortcuts requires only adding items to the web app manifest. For more information, see Get things done quickly with app shortcuts.
Autoupgrade Image Mixed Content
"Mixed content" is when an HTTPS page loads content such as scripts or images over insecure HTTP. Previously, mixed images were allowed to load, but the lock icon was removed and, as of Chrome 80, replaced with a Not Secure chip. This was confusing and did not sufficiently discourage developers from loading insecure content that threatens the confidentiality and integrity of users' data. Starting in Chrome 84, mixed image content will be upgraded to https and images will be blocked if they fail to load after upgrading. Auto upgrading of mixed audio and video content is expected in a future release.
Blocking Insecure Downloads from Secure (HTTPS) Contexts
Chrome intends to block insecurely-delivered downloads initiated from secure contexts ("mixed content downloads"). Once downloaded, a malicious file can circumvent any protections Chrome puts in place. Furthermore, Chrome does not and cannot warn users by downgrading security indicators on secure pages that initiate insecure downloads, as it does not reliably know whether an action will initiate an insecure download until the request is made.
User-visible warnings will start in Chrome 84 on desktop with plans to block insecure downloads completely in Chrome 88. Warnings will not appear in Android until Chrome 85. For details, see Protecting users from insecure downloads in Google Chrome.
ReportingObserver on Workers
The ReportingObserver API, added in Chrome 69, provides a JavaScript callback function invoked in response to deprecations and browser interventions. The report can be saved, sent to the server, or or handled using arbitrary JavaScript. This feature is designed to give developers greater insight into the operation of their sites on real-world devices. Starting in Chrome 84, this API is exposed on workers. For more information on the API, see Know your code health with the ReportingObserver API.
Resize Observer Updates
The Resize Observer API was updated to conform to recent specs. ResizeObserverEntry has three new properties, contentBoxSize, borderBoxSize, and devicePixelContentBoxSize to provide more detailed information about the DOM feature being observed. This information is returned in an array of ResizeObserverSize objects, which are also new. For information about the API generally, including updates about the features, see ResizeObserver: it's like document.onresize for elements.
The ruby-position property is now supported
in Chrome. This is an unprefixed version of -webkit-ruby-position, which controls the position of a ruby annotation. This property has three possible values: over, under, and inter-character, but Chrome has only implemented the first two. This change creates feature parity with Firefox.
Web Authenticator API: Cross-origin iframe Support
This version of Chrome incorporates version 8.4 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.
Private Methods and Accessors
Keeping state and behavior private to a class lets library authors present a clear, stable interface, while changing their code over time behind the scenes. Private class fields, which shipped in Chrome 74, added private fields for classes and instances. Now in Chrome 84, methods and properties can also be private. With this enhancement, any JavaScript class element can be private.
Weak references
The V8 engine now supports weak references to JavaScript objects, which help web developers define cleanup routines that don't keep the related objects alive but are (optionally) executed after the related object is garbage-collected. For more information, see Weak references and finalizers.
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.
@import rules in CSSStyleSheet.replace() Removed
The original spec for constructable stylesheets allowed for calls to:
sheet.replace("@import('some.css');")
This use case is being removed. Calls to replace() now throw an exception if @import rules are found in the replaced content.
Remove TLS 1.0 and TLS 1.1
TLS (Transport Layer Security) is the protocol which secures HTTPS. It has a long history stretching back to the nearly twenty-year-old TLS 1.0 and its even older predecessor, SSL. Both TLS 1.0 and 1.1 have a number of weaknesses.
TLS 1.0 and 1.1 use MD5 and SHA-1, both weak hashes, in the transcript hash for the Finished message.
TLS 1.0 and 1.1 use MD5 and SHA-1 in the server signature. (Note: this is not the signature in the certificate.)
TLS 1.0 and 1.1 only support RC4 and CBC ciphers. RC4 is broken and has since been removed. TLS's CBC mode construction is flawed and is vulnerable to attacks.
TLS 1.0's CBC ciphers additionally construct their initialization vectors incorrectly.
TLS 1.0 is no longer PCI-DSS compliant.
Supporting TLS 1.2 is a prerequisite to avoiding the above problems. The TLS working group has deprecated TLS 1.0 and 1.1. Chrome has now also deprecated these protocols.
Unfortunately, browser notifications can be used to mislead users, phish for private information or promote malware. These abusive patterns fall into two broad categories, “permission request issues" and "notification issues."
Permission request issues are requests designed to mislead, trick, or force users into allowing notifications. One example of this is websites that require users to allow notifications in order to gain access to site content or that are preceded by misleading pre-prompts.
Notification issues include fake messages that resemble chat messages, warnings, or system dialogs. They also include phishing attacks, an abusive tactic that tries to steal or trick users into sharing personal information, and malware notifications that promote or link to malicious software.
Starting with Chrome 84, releasing to stable on July 14 2020, sites with abusive permission requests or abusive notifications will be automatically enrolled in quieter notifications UI and notification enrollment prompts will advise users that the site may be trying to trick them. These changes are described in more detail below.
Why are you doing this?
Abusive notification prompts are one of the top user complaints we receive about Chrome. A large percentage of notification requests and notifications come from a small number of abusive sites. Protecting users from these sites improves user safety & privacy on the web, and makes for a better browsing experience.
Only a small fraction of websites will be affected by this change but we expect the impact on notification volumes will be significant for some users.
Notification UI changes for Chrome 84
Abusive notification protection in Chrome 84 will only affect new notification permission requests from abusive sites. In the future, we may add protections for users who have already accepted notification permissions from abusive sites.
Desktop UI for quiet notifications UI on abusive websites. The new UI discourages users from allowing notifications from these websites.
Mobile UI for quiet notifications on abusive websites. The new UI discourages users from allowing notifications from these websites.
How do I know if my site has failed the abusive notification check?
The Abusive Notifications Report in Search Console informs site owners of abusive notification experiences on their site. The first time a site is found to be in “Failing” status, Search Console will send an email to registered site owners and users in Search Console at least 30 calendar days prior to the start of enforcement. Websites will have the opportunity during this time period to address the issue and re-submit their website for another review.
These initiatives were major technical endeavors, essential infrastructure for enabling the promise of HTML5 with support for video conferencing and streaming. But this was also a philosophical evolution for media as Product Manager Mike Jazayeri noted in his blog post hailing the launch of the WebM Project:
“A key factor in the web’s success is that its core technologies such as HTML, HTTP, TCP/IP, etc. are open and freely implementable.”
As emerging first-class participants in the web experience, media and communication components also had to be free and open.
A decade later, these principles have ensured compression and communication technologies capable of keeping pace with a web ecosystem characterized by exponential growth of media consumption, devices, and demand. Starting from VP8 in 2010, the WebM Project has delivered up to 50% video bitrate savings with VP9 in 2013 and an additional 30% with AV1 in 2018 - with adoption by YouTube, Facebook, Netflix, Twitch, and more. Equally importantly, the WebM team co-founded the Alliance for Open Media which has freely licensed the IP of over 40 major tech companies in support of open and free codecs. With Chrome, Edge, Firefox and Safari supporting WebRTC, more than 85% of all installed browsers globally have become a client for real-time communications on the Internet. WebRTC has become a stable standard and it is now the default solution for video calling on the Web. These technologies have succeeded together, as today over 90% of encoded WebRTC video in Chrome uses VP8 or VP9.
The need for these technologies has been highlighted by COVID-19, as people across the globe have found new ways to work, educate, and connect with loved ones via video chat. The compression of open codecs has been essential to keeping services running on limited bandwidth, with over a billion hours of VP9 and AV1 content viewed every day. WebRTC has allowed for an ecosystem of interoperable communications apps to flourish: since the beginning of March 2020, we have seen in Chrome a 13X increase in received video streams via WebRTC.
These successes would not have been possible without all the supporters that make an open source community. Thank you to all the code contributors, testers, bug filers, and corporate partners who helped make this ecosystem a reality. A decade in, Google remains as committed as ever to open media on the web. We look forward to continuing that work with all of you in the next decade and beyond.
Posted by Matt Frost, Product Director Chrome Media and Niklas Blum, Senior Product Manager WebRTC
Last week, my calendar was constantly alerting me to the fact that many of us would be gathering at Google I/O, and it definitely made me sad that we can’t be together in person right now! We have been so impressed with the role that web developers have played in these trying times, as they focus on the fundamentals, make sure critical information is available, that commerce can come online, and that we can work and educate from home. Kudos to you all.
We want to help.
So, we’re planning a three day digital event - web.dev LIVE - where web developers can come together, from the comfort of their homes to hear about the latest, most helpful updates to the platform, learn modern web techniques and to connect with other developers — including those who are pushing the community forward and have been on the front line with COVID related work.
The event will take place from June 30th toJuly 2nd and will include short three-hour content streams (in English) hosted onweb.dev/live.
Reaching you where you are. In your time zone.
Planning a completely digital event has been an interesting challenge. While we can’t bring everyone together physically, we can still bring great content straight to your couch, kitchen or hammock-in-the-backyard. A digital event also gives us the opportunity to break out of physical constraints. We are no longer limited by space for attendance, and anyone, literally anywhere in the world, can “join” us at the click of a button (Oh and we, as part of the web community, should be proud of making that happen. Everyday!)
To really make this a regionally inclusive event, we will “travel” to three different time zones so we can answer your questions real-time, in your active hours. Each day will have unique content so you’re welcome to join us on all three days or watch the content on demand later, but developers in any timezone will have the team actively answering questions at least once through the event.
With unencrypted DNS, an attacker connected to the same network can observe other users’ browsing habits.
Benefits of DNS-over-HTTPS
Chrome’s Secure DNS feature uses DNS-over-HTTPS to encrypt the DNS communication, thereby helping prevent attackers from observing what sites you visit or sending you to phishing websites. As the name suggests, Chrome communicates with the DNS service provider over the HTTPS protocol, the same protocol used for communicating with websites in a safe and secure manner. HTTPS is particularly appealing because it provides the following protections:
Authenticity: Chrome can verify that it is communicating with the intended DNS service provider and not a fake service provider that’s controlled by an attacker.
Integrity: Chrome can verify that the response it got from the DNS service provider hasn’t been tampered with by attackers using the same network, thereby stopping phishing attacks.
Confidentiality: Chrome can talk to the DNS service provider over an encrypted channel which means that attackers can no longer rely on DNS to observe which websites other users are visiting when sharing the same connection, e.g. public WiFi in a library.
With DNS-over-HTTPS, an attacker can no longer rely on DNS to observe other users’ browsing habits.
The introduction of DNS-over-HTTPS gives the whole ecosystem a rare opportunity to start from a clean and dependable slate, making it easier to pursue further enhancements relying on DNS as a delivery mechanism. Thus far, the unencrypted nature of DNS has meant that features that extend DNS could randomly fail due to causes such as network equipment that may drop or modify newly introduced DNS fields. As DNS-over-HTTPS grows, it will put this concern aside because it benefits from the aforementioned HTTPS properties and sets a new reliable baseline to build upon.
Responsibly deploying DNS-over-HTTPS
Changing how DNS works is a non-trivial task. In particular, with more than 35 years of history, a lot of additional services and features have been built on top of DNS. For instance, some Internet Service Providers offer family-safe filtering via DNS. So, while we would love to have everyone benefit from Secure DNS immediately, we also know that we have to get there in a way that doesn’t break user expectations. Navigating these goals led us to the “same-provider DNS-over-HTTPS upgrade” approach that we experimented with at the end of 2019. The successful experiment gave us confidence about the performance and stability aspects for both Chrome’s Secure DNS and our partners’ DNS-over-HTTPS services. It also highlighted opportunities to improve the auto-upgrade success rate.
Here is how this “same-provider DNS-over-HTTP upgrade” approach works. Chrome maintains a list of DNS providers known to support DNS-over-HTTPS. Chrome uses this list to match the user’s current DNS service provider with that provider’s DNS-over-HTTPS service, if the provider offers one. By keeping the user’s chosen provider, we can preserve any extra services offered by the DNS service provider, such as family-safe filtering, and therefore avoid breaking user expectations. Furthermore, if there’s any hiccup with the DNS-over-HTTPS connection, Chrome will fall back to the regular DNS service of the user’s current provider by default, in order to avoid any disruption, while periodically retrying to secure the DNS communication. Finally, to avoid an issue that otherwise could arise for users running Windows, Chrome will also disable Secure DNS if Windows parental controls are enabled, so that any filtering software that relies on a regular DNS connection can continue to work while we collaborate with the ecosystem on ways for Secure DNS to co-exist with these filtering solutions.
If you are an IT administrator, Chrome will disable Secure DNS if it detects a managed environment via the presence of one or more enterprise policies. We’ve also added new DNS-over-HTTPS enterprise policies to allow for a managed configuration of Secure DNS and encourage IT administrators to look into deploying DNS-over-HTTPS for their users.
We believe that our approach strikes a good balance between moving security & privacy forward and maintaining user expectations. However, if this default behavior doesn’t suit your needs, head over to Chrome’s settings and search for Secure DNS to configure it to your liking. For instance, you can disable the feature altogether, or configure it in a no-fallback mode by choosing a specific DNS-over-HTTPS service provider among a list of popular options or by specifying a custom provider.
As ISPs and DNS service providers make progress on their DNS-over-HTTPS services, we expect to support more options in future milestones via our DNS-over-HTTPS program.
Chrome’s Secure DNS will progressively be made available on Chrome OS, Windows and Mac OS with Android and Linux coming soon.
Onwards
While these are early days, we are proud of playing a role in the adoption of DNS-over-HTTPS and helping our users benefit from a safer and more private way of browsing the web. At the same time, we also understand how intricate DNS is, which is why we’ve been and will continue to move carefully and transparently. As always, we’re open to feedback and welcome collaboration with stakeholders including ISPs, DNS service providers, and Online Child Safety advocates as we make further progress in securing DNS.
We have recently discovered that a fraction of a percent of ads consume a disproportionate share of device resources, such as battery and network data, without the user knowing about it. These ads (such as those that mine cryptocurrency, are poorly programmed, or are unoptimized for network usage) can drain battery life, saturate already strained networks, and cost money.
In order to save our users’ batteries and data plans, and provide them with a good experience on the web, Chrome will limit the resources a display ad can use before the user interacts with the ad. When an ad reaches its limit, the ad's frame will navigate to an error page, informing the user that the ad has used too many resources. Here is an example of an ad that has been unloaded:
To determine the threshold limits for the unloading, we extensively measured the ads Chrome sees. We targeted the most egregious ads, those that use more CPU or network bandwidth than 99.9% of all detected ads for that resource. Chrome is setting the thresholds to 4MB of network data or 15 seconds of CPU usage in any 30 second period, or 60 seconds of total CPU usage. While only 0.3% of ads exceed this threshold today, they account for 27% of network data used by ads and 28% of all ad CPU usage.
The overall percentage of heavy and non-heavy ads and the total resource usage of each
We intend to experiment with this over the next several months, and to launch this intervention on Chrome stable near the end of August. Our intent with this extended rollout is to give appropriate time for ad creators and tool providers to prepare and incorporate these thresholds into their workflows. To help advertisers understand the impact of this intervention on their ads, they can access reports to learn which ads Chrome unloaded.
With these changes, Chrome is continuing to help ensure that people have good browsing experiences both on the screen and behind the scenes.
Today we are introducing a new program, Web Vitals, an initiative by Google to provide unified guidance for quality signals that, we believe, are essential to delivering a great user experience on the web.
Core Web Vitals
Measuring the quality of user experience has many facets. While some aspects of user experience are site and context specific, there is a common set of signals — "Core Web Vitals" — that is critical to all web experiences. Such core user experience needs include loading experience, interactivity, and visual stability of page content, and combined are the foundation of the 2020 Core Web Vitals.
Largest Contentful Paint measures perceived load speed and marks the point in the page load timeline when the page's main content has likely loaded.
First Input Delay measures responsiveness and quantifies the experience users feel when trying to first interact with the page.
Cumulative Layout Shift measures visual stability and quantifies the amount of unexpected layout shift of visible page content.
All of these metrics capture important user-centric outcomes, are field measurable, and have supporting lab diagnostic metric equivalents and tooling. For example, while Largest Contentful Paint is the topline loading metric, it is also highly dependent on First Contentful Paint (FCP) and Time to First Byte (TTFB), which remain critical to monitor and improve.
Measuring Core Web Vitals
Our goal is to make Core Web Vitals simple and easy to access and measure for all site owners and developers, both across Google surfaces as well as within their own dashboards and tools.
Chrome UX Report enables site owners to quickly assess performance of their site for each Web Vital, as experienced by real-world Chrome users. The BigQuery dataset already surfaces publicly accessible histograms for all of the Core Web Vitals, and we are working on a new REST API that will make accessing both URL and origin level data simple and easy — stay tuned.
We strongly encourage all site owners to gather their own real-user measurement analytics for each Core Web Vital. To enable that, a number of browsers, including Google Chrome, support the current Core Web Vitals draft specifications: Largest Contentful Paint, Layout Instability, and Event Timing. To make it easy for developers to measure Core Web Vitals performance for their sites, today we are launching an open-source web-vitals JavaScript library, which can be used with any analytics provider that supports custom metrics, or as a reference for how to accurately capture each of the Core Web Vitals for your site’s users.
// Example of using web-vitals to measure & report CLS, FID, and LCP.
In our testing and development process we’ve found it valuable to have easy access to the state of each Core Web Vital both in development and as we browse the web. To help developers spot optimization opportunities today we are also releasing a developer preview of the new Core Web Vitals extension. This extension surfaces a visual indicator in Chrome about the state of each vital as you browse the web and, in the future, will also allow you to view aggregated real-user insights (provided by Chrome UX Report) about the state of each core vital for the current URL and origin.
While today's Core Web Vitals metrics measure three important aspects of user experience on the web, there are many aspects of user experience that are not yet covered by Core Web Vitals. To improve our understanding of user experience going forward, we expect to update Core Web Vitals on an annual basis and provide regular updates on the future candidates, motivation, and implementation status.
Looking ahead towards 2021, we are investing in building better understanding and ability to measure page speed, and other critical user experience characteristics. For example, extending the ability to measure input latency across all interactions, not just the first; new metrics to measure and quantify smoothness; primitives and supporting metrics that will enable delivery of instant and privacy preserving experiences on the web; and more.
