All Feeds | XSL | RSS | Embed | Edit

Chrome 84 Beta: Web OTP, Web Animations, New Origin Trials and More

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 Chrome 84 is beta as of May 28, 2020.


The Web OTP API (formerly called the SMS Receiver API) helps users enter an OTP on a web page when a specially-crafted SMS message is delivered to the user's Android phone.
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.

New Origin Trials

Cookie Store API

The Cookie Store API exposes HTTP cookies to service workers and offers an asynchronous alternative to document.cookie.

Idle Detection

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.

revert Keyword

The revert keyword resets the style of an element to the browser default.

Unprefixed Appearance CSS Property

An unprefixed version of -webkit-appearance is now available in CSS as appearance.

Unprefixed ruby-position CSS Property

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

Adds support for web authentication calls from cross-origin iframes if enabled by a feature policy. This brings Chrome in line with the Web Authentication Level Two specification.


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 for lists of current deprecations and previous removals.

@import rules in CSSStyleSheet.replace() Removed

The original spec for constructable stylesheets allowed for calls to:


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.
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.

Protecting Chrome users from abusive notifications

Notifications on the web help users receive important updates for a wide range of applications including messaging, calendars, email clients, ride sharing, social media and delivery services. 

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.

To learn more about abusive notifications, you can consult the complete list of abusive notifications identified by the Abusive Notifications Report in Search Console, described below in the "How do I know if my site has failed the abusive notifications check?" section.

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.  

The Search Console help center has additional information on the Abusive Notifications Report and the abusive notification review process.

What should I do if my website failed the abusive notification review? 

The Search Console help center has a guide for how to fix abusive notifications and request a new review of your website.  

Posted by PJ McLachlan, Web Platform PM

Resuming SameSite Cookie Changes in July

In April, we temporarily rolled back the enforcement of SameSite cookie labeling to ensure stability for websites providing essential services in the critical initial stage of COVID-19 response. We indicated plans to resume the rollout over the summer.

Since April we have continued to monitor overall ecosystem readiness, and engage with websites and services to ensure they are prepared for the SameSite labeling policy. We are planning to resume our SameSite cookie enforcement coinciding with the stable release of Chrome 84 on July 14, with enforcement enabled for Chrome 80+.

As with the previous rollout, the enforcement will be gradual and we will keep you informed on timing and any possible changes on the SameSite Updates page on Our overall guidance for developers hasn’t changed and you can find more information along with resources and channels to provide feedback in this previous Chromium post and on

Posted by Justin Schuh - Director, Chrome Engineering

Celebrating 10 years of WebM and WebRTC

Ten years ago, Google planted the seeds for two foundational web media technologies, hoping they would provide the roots for a more vibrant internet. Two acquisitions, On2 Technologies and Global IP Solutions, led to a pair of open source projects: the WebM Project, a family of cutting edge video compression technologies (codecs) offered by Google royalty-free, and the WebRTC Project building APIs for real-time voice and video communication on the web. 

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 LIVE: A digital event over three days and three time zones

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 - 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 to July 2nd and will include short three-hour content streams (in English) hosted on

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.

When will the event be live each day?

We have a ton of great content and fun stuff in store for you, so head to and sign up to get notified about the event.

Posted by Dion Almaer, Karaoke Lead for the Web Ecosystem

The Science Behind Web Vitals

Web Vitals is an initiative by Google to help business owners, marketers and developers alike identify opportunities to improve user experiences. These signals are guided by extensive work by many researchers in the fields of human–computer interaction (HCI) and user experience (UX). But figuring out the right metrics and thresholds is not as simple as picking up a research paper and finding the answer.

Journeys, not pages

Imagine you’re walking through an unfamiliar city to get to an important appointment. You walk through various streets and city centers on your way. But here and there, loose paving stones make you trip, there are slow automatic doors you have to wait for to open, and unexpected construction detours lead you astray. All of these events interrupt your progress, increase stress and distract you from reaching your destination.

People using the web are also on a journey, with each of their actions constituting one step in what would ideally be a continuous flow. And just like in the real world, they can be interrupted by delays, distracted from their tasks and led to make errors. These events, in turn, can lead to reduced satisfaction and abandonment of a site or the whole journey.

In both cases, removing interruptions and obstacles is the key to a smooth journey and a satisfied user.

So what trips users up on the web?

Interruptions due to waiting

The most common type of interruption web users experience is waiting for pages to load. For a developer, a page load is a discrete event and some delay might feel inevitable. However, a page load more often happens in the middle of a user's journey, as they learn about recent events in the news, research a new product or add items to a cart for purchase. So from the user's point of view, loading a particular page doesn't represent a natural break: they haven’t yet achieved their goal, which may make them less tolerant of delays.1 This means pages need to load fast so the user's journey can flow smoothly.

How fast is fast enough? In a way, that’s the wrong question. There’s no single magic number and there's three main reasons why.

First, the answer depends on the outcome you consider, for instance abandonment, user satisfaction or task performance. Different studies focus on different outcomes and yield different results.

Second, the effect of delays varies hugely depending on a user's personality, past experience and the urgency of their task.2 For example, if you were to plot how many users stayed on a site as a function of the delay they experienced, you would not see a clean step from 100% to 0% after X seconds. You would instead see a smooth distribution that might look like this:

Chart showing the percent of users remaining decreasing as the delay increases

So we must ask: which point on this curve do we aim for? In other words, how much do we invest in speed on the one hand, and how many of our users will we lose on the other?

Finally, the effect of delays varies depending on the context and situation. News sites, shopping sites and travel sites are often part of different kinds of user journeys, and the entire curve above might look different for each of them. Even within a context, site design and user behavior can change over time.

Although this is more difficult than we may have hoped, a distribution of outcomes at different levels of performance still contains useful hints. In particular, the distribution reveals how many users we may lose (or are losing currently) at a given level of performance. In addition, the steepness of the curve at different points can tell you how much return you’ll get for optimising speed by a particular amount. These are important factors in your tradeoff decision, since your time as a designer or engineer is also valuable.

So instead of looking for a single magic number, our goal is to find in the research useful ranges of values and reasonable guidelines. For example:

The empirical studies are drawn from data with high variability and gradual drop-offs rather than hard thresholds, and the others are based on predictions from theory. But collectively they suggest that it’s worth aiming to keep load times within a couple of seconds.

The Largest Contentful Paint (LCP) metric measures when a page-to-page navigation appears complete to a user. We recommend sites aim to keep LCP under 2.5 seconds for 75% of their page loads. This recommendation is further informed by Chrome analysis of the web today and aims to be feasible for enough sites to attain in practice. For more details of that analysis, see Defining the Core Web Vitals metric thresholds.

Interruptions and errors from instability

Most web pages need to load several elements, and often these load progressively. This can actually be a good thing: if some content appears as early as possible, it may allow a user to start making progress towards their goal without waiting for everything to load.

However, if the position of already-visible elements shifts as others load, this can negatively affect the user’s experience in two ways.

One is that if an element they’re looking at suddenly moves, it will take their eyes at least a couple hundred milliseconds to find its new position.7 If it scrolled out of view, it will take much longer. This type of interruption slows the user journey and can be very frustrating.

A more serious consequence is that unexpected layout shifts can lead to errors. If the user is trying to tap an element that then moves, they may end up tapping something else that moved into its original position. This is because the delay from perceiving the shift, deciding to abandon their action and then doing so can make it impossible for a human to respond appropriately. This could mean clicking a link or ad or "Buy Now" button unintentionally and significantly disrupting the user's intended journey.

Cumulative Layout Shift (CLS) measures how frequent and severe unexpected layout shifts are on a page. Fewer shifts mean less chance for interruption and errors. We recommend sites aim for a CLS of less than 0.1 for 75% of page loads.

Distraction and errors from low responsiveness

While page loads represent the larger transitions in a user’s journey – like entering a building – the small steps also matter.

When you’re walking, you don’t really want to be conscious of the mechanics of walking. Ideally, you actually forget that you’re walking and can focus on other things, like finding your way. But something like having a stone in your shoe will interfere with that concentration.

Likewise, you don’t want users’ experience to suffer from frictions in their moment-to-moment interactions with your site. Here are some research insights relevant to achieving this:

Just as for LCP, there’s no “magic number”, only markers representing distributions. Some individuals are much more sensitive than others,12 and shorter delays may be noticed when haptic or auditory feedback is involved.13

Aside from changing how the UI feels, delaying something people expect to be near-instantaneous can lead them to make errors. They may repeat an action because they think it didn’t work, and the second action can have an undesirable effect. For example, they may click an “add to cart” button twice and not realise that they’re now buying two items.

The responsiveness related to these experiences is measured by First Input Delay (FID), and we recommend sites aim to keep FID under 100 milliseconds for 75% of page loads.


We analyzed millions of page impressions to understand how these metrics and thresholds affect users. We found that when a site meets the above thresholds, users are 24% less likely to abandon page loads (by leaving the page before it finishes loading).

We also looked specifically at news and shopping sites, sites whose businesses depend on traffic and task completion, and found similar numbers: 22% less abandonment for news sites and 24% less abandonment for shopping sites. There are few interventions that can show this level of improvement for online businesses, and results like these are part of the reason we and our ecosystem partners prioritize the Web Vitals metrics.

Providing a smooth journey for users is one of the most effective ways to grow online traffic and web-based businesses. We hope the Web Vitals metrics and thresholds will provide publishers, developers and business owners with clear and actionable ways to make their sites part of fast, interruption-free journeys for more users.

Amar Sagoo, Staff Interaction Designer
Annie Sullivan, Software Engineer
Vivek Sekhar, Product Manager

1 Miller, R. B. (1968). Response time in man-computer conversational transactions. In Proceedings of the December 9-11, 1968, fall joint computer conference, part I (pp. 267–277).
2 Shneiderman, B. (1984). Response Time and Display Rate in Human Performance with Computers. ACM Computing Surveys (CSUR), 16(3), 265–285.
3 Galletta, D. F., Henry, R., McCoy, S. & Polak, P. (2004). Web Site Delays: How Tolerant are Users? Journal of the Association for Information Systems, 5(1), 1.
4 Hoxmeier, J. A. & DiCesare, C. (2000). System Response Time and User Satisfaction: An Experimental Study of Browser-based Applications. AMCIS 2000 Proceedings, 347.
5 Oulasvirta, A., Tamminen, S., Roto, V. & Kuorelahti, J. (2005). Interaction in 4-Second Bursts: The Fragmented Nature of Attentional Resources in Mobile HCI. In Proceedings of the SIGCHI conference on Human factors in computing systems (pp. 919–928).
6 Card, S. K., Robertson, G. G., & Mackinlay, J. D. (1991). The information visualizer, an information workspace. In Proceedings of the SIGCHI Conference on Human factors in computing systems (pp. 181-186).
Miller, R. B. (1968). Response time in man-computer conversational transactions. In Proceedings of the December 9-11, 1968, fall joint computer conference, part I (pp. 267–277).
Nielsen, J. (1993). Response Times: The 3 Important Limits. Nielsen Norman Group.
7 Purves D., Augustine G. J., Fitzpatrick D., et al. (2001). Types of Eye Movements and Their Functions. Neuroscience (2nd edition).
8 Kaaresoja, T., Brewster, S., & Lantz, V. (2014). Towards the Temporally Perfect Virtual Button: Touch-Feedback Simultaneity and Perceived Quality in Mobile Touchscreen Press Interactions. ACM Transactions on Applied Perception (TAP), 11(2), 1–25.
9 Card, S. K. (Ed.). (2018). The psychology of human-computer interaction. Crc Press.
10 Nielsen, J. (1993). Response Times: The 3 Important Limits. Nielsen Norman Group.
11 Miller, R. B. (1968). Response time in man-computer conversational transactions. In Proceedings of the December 9-11, 1968, fall joint computer conference, part I (pp. 267–277).
12 Jota, R., Ng, A., Dietz, P., & Wigdor, D. (2013, April). How fast is fast enough? a study of the effects of latency in direct-touch pointing tasks. In Proceedings of the sigchi conference on human factors in computing systems (pp. 2291-2300).
13 Kaaresoja, T., Brewster, S., & Lantz, V. (2014). Towards the Temporally Perfect Virtual Button: Touch-Feedback Simultaneity and Perceived Quality in Mobile Touchscreen Press Interactions. ACM Transactions on Applied Perception (TAP), 11(2), 1–25.

A safer and more private browsing experience with Secure DNS

With Chrome 83, we’ve started rolling out Secure DNS, a feature built on top of a secure DNS protocol called DNS-over-HTTPS, which is designed to improve your safety and privacy while browsing the web. More concretely, Chrome will automatically switch to DNS-over-HTTPS if your current DNS provider supports it, and provide manual configuration options for users who wish to use a specific provider. DNS-over-HTTPS introduces a significant change to the Domain Name System (DNS), a system designed more than 35 years ago that is central to how the web works even to this day. It’s the sort of change that requires careful planning and collaboration, which explains why it took us a little more than 2 years, gathering test data, listening to feedback, and addressing some misconceptions, to arrive at a design that put our users first with reasonable defaults and accessible controls.

Unencrypted DNS

When you want to access your favorite website, your browser first needs to determine which server is hosting it, a step known as “DNS lookup”. When DNS was first introduced, the internet was in its infancy, and the web did not yet exist. There was no e-commerce, no online banks, and many people did not yet see a strong need for encryption on the web. It took until 1994 for encryption to take-off with the introduction of the HTTPS protocol. Nowadays, the HTTPS protocol is almost ubiquitous and provides strong security and privacy guarantees. It helps you browse or transact on the web without fear of having your credit card or personal information stolen by other internet users, even when using a public WiFi connection. Unfortunately, DNS, on the other hand, until recently has remained unencrypted.

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.


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.

Posted by Kenji Baheux, Chrome Product Manager

Protecting against resource-heavy ads in Chrome

Chrome is developed to be fast and responsive without harmful or annoying experiences. Recently, following the Better Ads Standards, we have taken steps to address ads that most people find unacceptable. Prior to that, we also launched a set of protections against abusive experiences in Chrome.

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.

Posted by Marshall Vale, Product Manager, Chrome

Introducing Web Vitals: essential metrics for a healthy site

Optimizing for quality of user experience is key to the long-term success of any site on the web. Through our ongoing engagement and collaboration with millions of web developers and site owners, we’ve developed many helpful metrics and tools across Google to help business owners, marketers, and developers alike identify opportunities to improve user experiences. However, abundance of metrics and tools creates its own set of prioritization, clarity, and consistency challenges for many. 

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.
import {getCLS, getFID, getLCP} from 'web-vitals';

function reportToAnalytics(data) {
  const body = JSON.stringify(data);
  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
      fetch('/analytics', {body, method: 'POST', keepalive: true});

getCLS((metric) => reportToAnalytics({cls: metric.value}));
getFID((metric) => reportToAnalytics({fid: metric.value}));
getLCP((metric) => reportToAnalytics({lcp: metric.value}));

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. 

Finally, over the coming months we will be updating Lighthouse, Chrome DevTools, PageSpeed Insights, Search Console’s Speed Report, and other popular tools to highlight and provide consistent and actionable guidance for improving Core Web Vitals. 

Evolving Core Web Vitals

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.

Make sure to follow our updates on and subscribe to our mailing list for future updates on vitals and all things Web.

Ilya Grigorik, Web Performance Engineer

Keeping spam off the Chrome Web Store

Since the introduction of the Chrome Web Store in 2011, it has become the largest catalog of browser extensions with over 200,000 available to all of our users. This has helped millions of users to customize their browsing experience on Chrome in ways we could have never imagined, from niche utilities to companies building businesses around the platform’s capabilities.

In response, our abuse systems and review teams have been hard at work ensuring that the Chrome Web Store is free from abuse, as many of our developers have noticed an increase in review times lately. However, the increase in adoption of the extension platform has also attracted spammers and fraudsters introducing low-quality and misleading extensions in an attempt to deceive and trick our users into installing them to make a quick profit. We want to ensure that the path of a user discovering an extension from the Chrome Web Store is clear and informative and not muddled with copycats, misleading functionalities or fake reviews and ratings. Therefore, in order to keep the quality of our inventory high and help users find what they want, we’re introducing some updates to our spam policy:

  • Developers or their affiliates should not publish multiple extensions that provide duplicate experiences or functionality on the Chrome Web Store. 
  • Extensions should not have misleading, improperly formatted, non-descriptive, irrelevant, excessive, or inappropriate metadata, including but not limited to the extension’s description, developer name, title, icon, screenshots, and promotional images. Developers must provide a clear and well-written description. Unattributed or anonymous user testimonials in the app's description are also not allowed.
  • Developers must not attempt to manipulate the placement of any extensions in the Chrome Web Store. This includes, but is not limited to, inflating product ratings, reviews, or install counts by illegitimate means, such as fraudulent or incentivized downloads, reviews and ratings.
  • Extensions with a single purpose of installing or launching another app, theme, webpage, or extension are not allowed.
  • Extensions that abuse, or are associated with the abuse of, notifications by sending spam, ads, promotions, phishing attempts, or unwanted messages that harm the user’s browsing experience are not allowed. Extensions that send messages on behalf of the user without giving the user the ability to confirm the content and intended recipients are also not allowed.

The new policy can be found in our updated Developer Program Policies.

Developers must comply with this policy by August 27th 2020. After that date, extensions that violate the updated policy may be taken down and disabled. You can learn more about these changes and how they may apply to you in our Spam policy FAQ.

Posted by Rebecca Soares and Benjamin Ackerman, Chrome Policy and Anti-Abuse Team

Chrome 83 Beta: Cross-site Scripting Protection, Improved Form Controls, and Safe Cross-origin Resource Sharing

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 Chrome 83 is beta as of April 16, 2020.

Trusted Types for DOM Manipulation

DOM-based cross-site scripting (DOM XSS) is one of the most common web security vulnerabilities. It can even be introduced to your application unintentionally. Trusted types is a new technology that helps you write and maintain applications that are free of DOM XSS vulnerabilities by default. It does this by securing dangerous APIs.

Consider a property like Element.innerHTML. This property can open your site to harmful HTML manipulation. Trusted types would cause your script to throw an error if this property were used. To do this, set a new content security policy. For example:

Content-Security-Policy: require-trusted-types-for 'script';
report-uri //my-csp-endpoint.example

For more information on trusted types, see Prevent DOM-based cross-site scripting vulnerabilities with Trusted Types.

Improved Form Controls

HTML form controls provide the backbone for much of the web's interactivity. They're easy for developers to use, have built-in accessibility, and are familiar to our users. Unfortunately, the styling of form controls is wildly inconsistent. The earliest form controls matched the operating system on which they displayed, and later controls followed whatever design style was popular at the time they were created. This variation forced developers to spend extra time in development and to ship extra code.

Over the last year, Chrome and Edge have collaborated to improve the appearance and function of HTML form controls. This work included making the focused states of controls and other interactive elements easier to perceive. The images below show the old and new versions of some controls in Chrome.

The old versions:

The new versions:

The new form controls have already shipped in Microsoft Edge and are now available in Chrome 83. For more information see Microsoft's article Improving form controls in Microsoft Edge and Chromium or our post on the Chromium blog Updates to Form Controls and Focus.

New Cross-Origin Policies

Some web APIs increase the risk of side-channel attacks like Spectre. To mitigate that risk, browsers offer an opt-in-based isolated environment called cross-origin isolated. This is done through two new HTTP headers: Cross-Origin-Embedder-Policy
and Cross-Origin-Opener-Policy. With these headers, web pages can safely use privileged features including:
The cross-origin isolated state also prevents modifications of document.domain.

For more information, see Making your website "cross-origin isolated" using COOP and COEP.

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.

Native File System

The Native File System API is in a new origin trial, scheduled to run from Chrome 83 to Chrome 85. This API enables developers to build 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, the API lets apps read or save changes directly to files and folders on the user's device. It does this by invoking the platform's own open and save dialog boxes. For more information, see The Native File System API: Simplifying access to local files.


The new Performance.measureMemory() function estimates the memory usage of a web page to measure the memory usage of a web app or page in production. The use cases include:
Currently web developers resort to the non-standard performance.memory API that is used in 20% of page loads. For more information, see Monitor your web page's total memory usage with performance.measureMemory().

Prioritized Scheduler.postTask()

The Scheduler.postTask() method allows developers to schedule tasks (javascript callbacks) with a native browser scheduler at three levels of priority: user-blocking, user-visible, and background. It also exposes a TaskController object, which can be used to dynamically cancel tasks and change their priority.

WebRTC Insertable Streams

The WebRTC Insertable Streams API lets applications provide custom data processing in the encoding and decoding of a WebRTC MediaStreamTrack One use case for this is the end-to-end encryption of the data transferred between peer connections via an intermediate server. To use insertable streams add one of the new parameters to the RTCPeerConnection interface. Other WebRTC updates in the release are listed in the next section.

Other features in this release

ARIA Annotations

New ARIA annotations support screen reader accessibility for comments, suggestions, and text highlights with semantic meanings (similar to <mark>). Additionally, related information can now be tied semantically to an element allowing descriptions, definitions, footnotes and comments to be tied to another element.
Annotations were not previously possible without resorting to live region hacks, which are not as reliable as semantics, and do not work well with braille displays. As a result, screen reader users have non-optimal support for collaboration features of online word processors.

'auto' keyword for '-webkit-appearance' CSS property

The -webkit-appearance CSS property has a new auto keyword, which indicates the default appearance of the target element. This is a step on the way towards replacing the non-standard -webkit-appearance property with a future fully standardized appearance property.

Barcode Detection API

Chrome now supports the Barcode Detection API, a subset of the Shape Detection API which provides the ability to detect and decode barcodes in an image provided by a script. The image may come from any type of image buffer source such as an <image>, <video> or <canvas> tag. Previously supporting barcode detection on a web page required inclusion of a large third-party library. This API is only available on devices with Google Play Services installed and is not available on uncertified devices. For information about the Barcode Detection API as well as the other Shape Detection APIs, see The Shape Detection API: a picture is worth a thousand words, faces, and barcodes.

CSS contain-intrinsic-size

The contain-intrinsic-size property allows developers to specify a placeholder size which would be used while contain: size is applied. With contain-intrinsic-size specified, elements lay out as if they had a single child with fixed size, the one specified by this property, unless they have an explicit width/height.

The motivation for the property is to provide a placeholder sizing for subtree content which is either not yet available or not rendered. There was previously no way to provide this other than sizing the element itself which may not be desirable as it affects how the element lays out in its container. Examples are available from the WICG.

CSS Color Adjust: color-scheme meta tag

Many operating systems now have a "dark mode" preference. Some browsers already offer an option to transform web pages into a dark theme. The prefers-color-scheme media query lets authors support their own dark theme so they have full control over experiences they build. The meta tag lets a site explicitly opt-in to fully supporting a dark theme so that the browser loads a different user agent sheet and not ever apply transformations. For more information, read Improved dark mode default styling with the color-scheme CSS property and the corresponding meta tag.

display:inline-grid/grid/inline-flex/flex for <button>

The display keywords inline-grid, grid, inline-flex, and flex now function with the <button> element when the align property is applied. (Demo)

ES Modules for shared workers ('module' type option)

JavaScript now supports modules in shared workers. Setting module type by the constructor's type attribute, worker scripts are loaded as ES modules and the import statement is available in worker contexts. With this feature, web developers can more easily write programs in a composable way and share them among a page and workers. For more information, see What about shared workers in Threading the web with module workers.

Improvements to font-display: optional

A few changes have been made to the way font-display works on Chrome.
Consequently, when font-display: optional and preloading are used together, you'll never see layout shifting from font swapping. For more information, see Prevent layout shifting and flashes of invisibile text (FOIT) by preloading optional fonts.

IndexedDB relaxed durability transactions

IDBDatabase.transaction() now accepts an optional durability argument
to control flushing of data to storage. This allows developers to explicitly trade off durability for performance. Previously after writing an IndexedDB transaction, Firefox did not flush to disk but Chrome did. This provided increased durability by guaranteeing that data is written to the device's disk rather than merely to an intermediate OS cache. Unfortunately, this comes with a significant performance cost.
Valid options are "default", "strict", and "relaxed". The "default" option uses whatever behavior is provided by the user agent and is currently the default. An example is shown below. The current value may be read using IDBTransaction.durability.

const iDBTransaction = database.transaction(
  [ "storeName" ],
    durability: "relaxed"

Out-Of-Renderer Cross-Origin Resource Sharing

Out-Of-Renderer Cross-Origin Resource Sharing (OOR-CORS) is a new CORS implementation that inspects network accesses. Chrome's previous CORS implementation was only available to Blink core parts, XHR and Fetch APIs, while a simplified implementation was used in other parts of the application. HTTP requests made by some internal modules could not be inspected for CORS at all. The new implementation addresses these shortcomings.

Reversed range for <input type=time>

Chrome now supports reversed ranges for <input> elements whose type is time, allowing developers to express time inputs that cross midnight. A reversed range is one where the maximum is less than the minimum. In this state, the input allows values that are less than the minimum or greater than the maximum, but not between them. This functionality has been in the specification for many years, but has not yet been implemented in Chrome.

Support "JIS-B5" and "JIS-B4" @page

Chrome now supports two page sizes for the @page rule, both listed in the CSS Paged Media Module Level 3 spec.
This feature completes Chrome's implementation of this section of the standard.

@supports selector() feature query function

The new @supports function provides feature detection for CSS selectors. Web authors can use this feature to query whether the UA supports the selector before they actually try to apply the specified style rules matching the selector. For example:

@supports selector(::before) {
div { background: green };


Chrome has added the following web RTC features in addition to the one already mention under Origin Trials.


The canTrickleIceCandidates boolean property indicates whether a remote peer is capable of handling trickle candidates. It exposes information from the SDP session description.


This encoding parameter allows developers to limit the framerate on a video layer before sending. Use RTCRtpSender.setParameters() to set the new framerate, which takes effect after the current picture is complete. read it back using RTCRtpEncodingParameters.maxFramerate. Setting maxFramerate to 0 freezes the video on the next frame.


A new attribute for RTCRtpSendParameters called degradationPreference allows developers to control how quality degrades when constraints such as bandwidth or CPU prevent encoding at the configured frame rate and resolution. For example, on a screen share app, users will probably prefer screen legibility over animations. On a video conference users likely prefer a smooth frame rate over a higher resolution. Valid values for degradationPreference are "maintain-framerate", "maintain-resolution", and "balanced".

WebXR DOM Overlay

DOM overlay is a feature for immersive AR on handheld devices that lets two-dimensional page content be shown as an interactive transparent layer on top of the WebXR content and camera image. With this feature, developers can use the DOM to create user interfaces for WebXR experiences. For VR, inline sessions are by definition within the DOM. For AR, though, there is no inline mode making this particularly important for certain use cases. To try the feature use one of the two samples in Chrome 83. This feature is currently only available on ARCore-based handheld devices.


This version of Chrome incorporates version 8.3 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.

fractionalSecondDigits option for Intl.DateTimeFormat

Chrome 83 adds the fractionalSecondDigits property to the Intl.DateTimeFormat object to control the format of fractions of a second. The Date object in ECMAScript stores time information with millisecond precision, which some web developers need to output. The value of this property is an integer between 0 and 3 to represent how many digits the DateTimeFormat should output after the decimal mark.

Deprecations, and Removals

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

Disallow Downloads in Sandboxed iframes

Chrome now prevents downloads in sandboxed iframes, though this restriction can be lifted via an 'allow-downloads' keyword in the sandbox attribute list. This allows content providers to restrict malicious or abusive downloads. Downloads can bring security vulnerabilities to a system. Even though additional security checks are done in Chrome and the operating system, we feel blocking downloads in sandboxed iframes also fits the purpose of the sandbox.

Temporarily rolling back SameSite Cookie Changes

UPDATE 5/28: We are going to resume the rollout with the stable release of Chrome M84. More details.

With the stable release of Chrome 80 in February, Chrome began enforcing secure-by-default handling of third-party cookies as part of our ongoing effort to improve privacy and security across the web. We’ve been gradually rolling out this change since February and have been closely monitoring and evaluating ecosystem impact, including proactively reaching out to individual websites and services to ensure their cookies are labeled correctly.

However in light of the extraordinary global circumstances due to COVID-19, we are temporarily rolling back the enforcement of SameSite cookie labeling, starting today. While most of the web ecosystem was prepared for this change, we want to ensure stability for websites providing essential services including banking, online groceries, government services and healthcare that facilitate our daily life during this time. As we roll back enforcement, organizations, users and sites should see no disruption.

We recognize the efforts of sites and individual developers who prepared for this change and appreciate the feedback from the web ecosystem, which has helped inform this decision. We will provide advance notice on this blog and the SameSite Updates page when we plan to resume the enforcement, which we’re now aiming for over the summer.

Posted by Justin Schuh - Director, Chrome Engineering

Updates to Form Controls and Focus

HTML form controls provide the backbone for much of the web's interactivity. They're easy for developers to use, have built-in accessibility, and are familiar to our users. One issue with native form controls, however, is the inconsistency in their styling. Older controls, such as <button> and <select> were styled to match the user's operating system. Form controls that were added to the platform more recently were designed to match whatever style was popular at the time. For Chromium based browsers, this has led to controls that look mismatched and sometimes outdated, which causes developers to spend extra time (and ship extra code) styling around the controls' default appearance.

a meter, progress, and input type range element stacked vertically. Their visual styles are very different.
<meter>, <progress>, and <input type="range"> look like they come from different worlds in Chrome 80 on Windows.

To help fix this problem, the teams at Microsoft Edge and Google Chrome spent the last year collaborating to retheme and improve the functionality of the built-in form controls on Chromium browsers. The two teams also worked to make the focused states of form controls and other interactive elements like links easier to perceive. These changes are available today in Edge on Windows, and may be seen in Chrome 81 as part of experiments. The chrome://flags/#form-controls-refresh enables the changes in Chrome 81 as well. The changes will roll out in Chrome 83 on Windows, macOS, ChromeOS, and Linux. See the updated release schedule for Chrome 81 and 83. Updates for Chrome on Android should roll out later this year. If you want to hear more about what's coming to form controls, take a look at Nicole Sullivan and Greg Whitworth's talk from CDS 2019.

A Fresh Coat of Paint

The two teams wanted to make the controls feel like they were part of a matched set. This meant doing away with gradients and using more of a flat design inspired by current design systems.
As Nicole Sullivan, a member of the Chrome team, describes it:
We were going for beautiful, webby, and neutral. We hope that every design system would see a bit of themselves in the new designs and easily imagine how they might be adapted for their own branding.
Below is a comparison of the form controls as they previously appeared in Chromium and as they appear after the redesign:
Form controls as they appear in Chrome 80Form controls as they appear after the redesign. The styles are much more consistent.
Left: Prior styling of form controls in Chrome 80.
Right: Controls as they appear after the redesign.

Improved Accessibility and Touch Support

In addition to improving the default styling, the two teams also tuned up form controls' accessibility and enhanced touch support. 

These changes are most notable in a few key areas:

A More Visible Focus Ring

The focus indicator—sometimes referred to as the "focus ring"—is an important accessibility feature that helps people using a keyboard or switch device to identify which element they're interacting with.

Previously, Chromium used a light single color outline to indicate the focused element. However, if the focused element happened to be on a similarly colored background, the ring would be difficult to perceive:

A button on a blue background. The focus indictor on the button is not discernible.
The previous focus ring on a similarly colored background.

The new focus indicator uses a thick dark ring with a thin white outline, which should improve visibility on both light and dark backgrounds. This is an easy accessibility win that automatically improves the keyboarding experience on a number of sites without developers needing to write any new code.

Black and white double-strokes make the focus ring visible on both light background and dark background
The new two-line design for the focus indicator ensures that it's visible on both black and white backgrounds.

Note that there are still some scenarios where the focus ring may be hard to perceive—for example, if a black button is on a white background, or if the focus ring is clipped by elements that are positioned closely together.

If you run into a scenario where the focus ring is hard to perceive, or if the new focus indicator does not match the design of your site, there are ways to style focus including the new :focus-visible pseudo-class, which provides fine-grained control over when the focus indicator is displayed.

Increased Tap Target Sizes for Multi-input Displays

Over the past few years we've seen an increase in multi-input devices like 2-in-1 devices, tablets, and touch-enabled laptops. This means that touch becomes an important consideration for desktop. However, many of the existing form controls were not designed with multi-input surfaces in mind. For example, <input type="date"> works great on mobile, but the tap targets are much too small to be usable on a touch-screen laptop.

The input type date  element as it appears in Chrome 80. The element has very small buttons for incrementing and decrementing the date.
The previous design for <input type="date"> with small tap targets.

To improve functionality on touch screens, the updated controls will now have better flyouts, larger tap targets, and support for swiping and inertia when scrolling:

The redesigned input type date element. It has large buttons and easy to click dates.
The new design for <input type="date"> with much more accessible tap targets

Improved Color Picker

Previously the <input type="color"> element was not fully keyboard accessible, meaning users relying on a keyboard or switch device couldn't use it. Along with a new appearance, the control is also now fully keyboard accessible and includes additional modifier keys (Control, or Command on Mac). These improvements let users jump by ten color values at a time.

An animation of the redesigned color picker, showing improved keyboard navigation
The new <input type="color"> with improved keyboard accessibility. 

More Consistent Keyboard Access

Finally, the teams updated the ARIA role mapping of all the controls to match the recommendations in the HTML Accessibility API Mappings specification. This should provide a more consistent experience for anyone relying on a keyboard or assistive technology, like a screen reader, to access the page.

How You Can Get Involved

While the design refresh is a much needed change, the two teams have also heard from developers that it should be easier to style the built-in form controls and plan to tackle that work next. If you're excited by the idea of improved styling, functionality, and possibly even new high-level components, the folks at Edge and Chrome need your help!

Test Your Sites

Try out the new form controls and focus indicator in Edge and Chrome Beta. If the design changes have negatively affected your existing sites or apps, let us know using this bug template. Or, if you find a related bug, give it a star! ⭐️ Starring is extremely valuable because it helps platform teams triage and decide what to work on next.

Tell us What You Want to See

Much of the work on the new form controls was enabled through surveying developers, and interviewing design system and UI framework authors.

In an effort to help centralize this feedback and include as many developers as possible in the standards process, the team at Edge have created If you work on a design system, or a UI component set, consider sharing your knowledge on Open UI to help classify and identify gaps in the existing form controls.

Posted by Rob Dodson, Developer Advocate

Chrome and Chrome OS release updates

Cross-posted from the Chrome Releases Blog

We previously paused upcoming releases for Chrome and Chrome OS. Today we’re sharing an update as we’re now resuming releases with an adjusted schedule:

We continue to closely monitor that Chrome and Chrome OS are stable, secure, and work reliably. We’ll keep everyone informed of any changes on our schedule on our release blog and will share additional details on the schedule in the Chromium Developers group, as needed. You can also check our schedule page for specific dates for each milestone at any time.

Thanks everyone for the help and patience during this time.

Posted by the Chrome Release Team

Upcoming Chrome releases

Cross-posted from the Chrome Releases Blog

Due to adjusted work schedules at this time, we are pausing upcoming Chrome and Chrome OS releases. Our primary objectives are to ensure Chrome continues to be stable, secure, and work reliably for anyone who depends on them. We’ll continue to prioritize any updates related to security, which will be included in Chrome 80.

Please follow the Chrome Releases blog for updates.

Posted by the Chrome Release Team

New developer dashboard and registration flow for Chrome Web Store

Today we’re announcing two significant changes that affect the developer experience when publishing on the Chrome Web Store. The new developer dashboard is now the default experience, and the developer registration flow has changed.

New dashboard is now the default

We recently launched a new developer dashboard for Chrome Web Store developers to try out. Following a period of feedback and improvement, we’re announcing that this new dashboard is now the preferred dashboard. This dashboard appears by default on the following events:
You can opt out of the default behavior by clicking Show more… in the small dialog at the bottom left-hand corner of the new dashboard, then clicking opt out:

Opting out means that you’ll see the old dashboard in each of the cases listed above. You can always opt in again by clicking the link in the old dashboard’s banner:

Opting out is useful for specific use cases that affect a small number of developers. The new dashboard does not yet support the following tasks:
For more details and status on these features see the known issues document.

Developer registration fee now required earlier

The Chrome Web Store charges a $5.00 fee to register as a Chrome Web Store developer. This fee was previously required only before publishing an item to the public, but is now required for all Chrome Web Store developers.

Who does this affect?

Posted by Shumeng Gu, Chrome Web Store Engineer

Chrome 81: Near Field Communications, Augmented Reality, and More

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 Chrome 81 is beta as of February 13, 2020.

Web NFC for mobile

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 used NFC.

Web NFC allows a web app to read 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.

A demonstration of Web NFC cards

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. A few code samples are shown below.

Writing a string to an NFC tag:

if ("NDEFWriter" in window) {
const writer = new NDEFWriter();
await writer.write("Hello world!");

Scanning messages from NFC tags:

if ("NDEFReader" in window) {
const reader = new NDEFReader();
await reader.scan();
reader.onreading = ({ message }) => {
console.log(`Message read from a NFC tag: ${message}`);

Chrome 81 introduces the mobile web to NFC with an origin trial. See the Origin Trials section for information on signing up and for a list of other origin trials starting in this release.

Augmented Reality and Hit Testing

Chrome 81 adds two new immersive features to the web, both designed to support augmented reality. The WebXR Device API, first enabled in Chrome 79, now supports augmented reality. We've also added support for the WebXR Hit Test API, an API for placing objects in a real-world view.

If you've already used the new API to create virtual reality, you'll be happy to know there's very little new to learn to use AR. This is because the spec was designed with the spectrum of immersive experiences in mind. Regardless of the degree of augmentation or virtualization, the application flow is the same. The differences are merely a matter of setting and requesting different properties during object creation.

The WebXR Hit Test API provides a means for an immersive experience to interact with the real world. Specifically, it enables you to place virtual objects on real-world points in a camera view. The image below from one of the Immersive Web Working Group's sample apps illustrates this. The broken blue circle indicates a point returned from the hit test API. If I tap the screen a sunflower will be placed there. The new API captures both the location of a hit test and the orientation of the point that was detected. You'll notice in the image a sunflower has been placed on both the floor and the wall.

If you're completely new to the WebXR Device API, check out our earlier articles, Virtual reality comes to the web and Virtual reality comes to the web, part II. If you're already familiar with entering a WebXR session and constructing a frame loop, then check out our new article on Web AR. Also check out our article on the WebXR Hit Test API.

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.

PointerLock unadjustedMovement

Scripts now have the ability to request unadjusted and unaccelerated mouse movement data when in PointerLock. If unadjustedMovement is set to true, then pointer movements will not be affected by the underlying platform modifications such as mouse acceleration.

Other features in this release

Buffered Flag for Long Tasks

Chrome 81 updates the buffered flag of PerformanceObserver to support long tasks. In particular, this feature provides a way to gain insight into early long tasks for apps or pages that register a PerformanceObserver early.

CSS image-orientation property

Chrome will by default respect EXIF metadata within images indicating desired orientation. The accompanying image-orientation property allows developers to override this behavior.

CSS Color Adjust: color-scheme

A new meta tag and CSS property lets sites opt-in to following the preferred color scheme when rendering UI elements such as default colors of form controls and scrollbars as well as the used values of the CSS system colors. For Chrome 81 only initial color and background are affected.

Exclude Implicit Tracks from grid-template-rows and grid-template-columns Resolved Values

Implicit tracks are now excluded from the resolved values of the grid-template-rows and grid-template-columns. Previously, all tracks were included, whether implicit or explicit.

hrefTranslate attribute on HTMLAnchorElement

The HTMLAnchorElement now has an hrefTranslate attribute, providing the ability for a page to hint to a user agent's translation engine that the destination site of an href should be translated if followed.

IntersectionObserver Document Root

The IntersectionObserver() constructor now takes a Document as the 'root' argument, causing intersections to be calculated against the scrolling viewport of the document. This is primarily targeted towards observers running in an iframe. Previously, there was no way to measure intersection with the scrolling viewport of the iframe's document.

Modernized Form Controls

In version 81, Chrome modernizes the appearance of form controls on Windows, ChromeOS, and Linux while improving their accessibility and touch support. (Mac and Android support are coming soon.) It's hoped that this will reduce the need to build custom form controls. This change is the result of collaboration between Microsoft and Google. For more information, see the recent talk at CDS or the MS blog post. For a closer look at the controls, this page gives an example of all of the elements that changed.

Move onwebkit{animation,transition}XX handlers to GlobalEventHandlers

Until now, the prefixed onwebkit{animation,transition}XX handlers were only available on the Window object in Chrome. They are now on HTMLElement and Document as required by the spec. This fix brings Chrome in line with Gecko and Webkit.

Note: This change is intended to improve interoperability on existing web pages. These handlers are still obsolete so web developers should use the non-refixed versions on new pages.

Position State for Media Session

Adds support for tracking position state in a media session. The position state is a combination of the playback rate, duration, and current playback time. This can then be used by browsers to display position in the UI and with the addition of seeking can support seeking/scrubbing too. For a code sample and demonstration, see our sample.


Chrome now supports a SubmitEvent type, an Event subtype which is dispatched on form submission. The SubmitEvent has a submitter property that refers to attributes of the submitter button including the entry data, the formaction attribute, the formenctype attribute, the formmethod attribute, and the formtarget attribute.

Currently, applications are doing their own form submission by calling preventDefault() during onsubmit. This approach has the limitation that the received event does not include the button that triggered the submission.

WebAudio: ConvolverNode.channelCount and channelCountMode

For a ConvolverNode, the channelCount can now be set to 1 or 2. The channelCountMode can be "explicit" or "clamped-max". Previously, a channelCount of 1 was not allowed and neither was a mode of "explicit".

This release also extends ConvolverNode capabilities slightly to allow developers to choose the desired behavior without having to add a GainNode to do the desired mixing.


RTCPeerConnection.onicecandidateerror event changes

The candidateerror event now has an explicit address and port, replacing hostCandidate.

onclosing Event for RTCDataChannel

Adds the onclosing event to the RTCDataChannel object, which signals to the user of a data channel that the other side has started closing the channel. The user agent will continue reading from the queue (if it contains anything) until the queue is empty, but no more data can be sent.

WorkerOptions for shared workers constructor

Adds the WorkerOptions object as the second argument for a shared worker constructor. The previous second argument, a string containing the worker's name is still supported.


WritableStream objects now have a close() method that closes a stream if it is unlocked. This is directly equivalent to getting a writer, using the writer to close the stream, and then unlocking it again.


This version of Chrome incorporates version 8.1 of the V8 JavaScript engine. It specifically includes the changes listed below. You can find a complete list of recent changes in the V8 release notes.


The Intl.DisplayNames() object lets an app or script get localized names of language, script, currency codes, and commonly used names of date fields and symbols. This will reduce the size of apps (thereby improving latency), make it easier to build internationalized UI components, reduce translation costs, and provide more consistent translations across the web.

Deprecations, and Removals

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

Deprecation and Remove "basic-card" support Payment Handler

This version of Chrome removes the basic-card polyfill for Payment Request API in iOS Chrome. As a result, the Payment Request API is temporarily disabled in iOS Chrome. For full details, see Rethinking Payment Request for iOS.

Remove supportedType field from BasicCardRequest

Specifying "supportedTypes":[type] parameter for "basic-card" payment method shows cards of only the requested type, which is one of "credit", "debit", or "prepaid".

The card type parameter has been removed from the spec and is now removed from Chrome, because of the difficulty of accurate card type determination. Merchants today must check card type with their PSP, because they cannot trust the card type filter in the browser:

Firefox removed "supportedTypes" in version 65.

Remove the <discard> element

Chrome 81 removes the <discard> element. It is only implemented in Chromium, and is thus not possible to use interoperably. For most use cases it can be replaced with a combination of animation of the 'display' property and a removal (JavaScript) callback/event handler.

Remove TLS 1.0 and TLS 1.1

Note: Removal of TLS 1.0 and TLS 1.1 has been delayed to Chrome 83, which is expected to ship in late May 2020.

This version of Chrome removes 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.
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 deprecated these features in version 72 in early 2019.

TLS 1.3 downgrade hardening bypass

TLS 1.3 includes a backwards-compatible hardening measure to strengthen downgrade protections. However, when we shipped TLS 1.3 last year, we had to partially disable this measure due to incompatibilities with some non-compliant TLS-terminating proxies. Chrome currently implements the hardening measure for certificates which chain up to known roots, but allows a bypass for certificates chaining up to unknown roots. We intend to enable it for all connections.

Downgrade protection mitigates the security impact of the various legacy options we retain for compatibility. This means user's connections are more secure and, when security vulnerabilities are discovered, it is less of a scramble to respond to them. (That, in turn, means fewer broken sites for users down the road.) This also aligns with RFC 8446.

Protecting users from insecure downloads in Google Chrome

Update (April 6, 2020): Chrome was originally scheduled to start user-visible warnings on mixed downloads in Chrome 82. These warnings, as well as subsequent blocking, will be delayed by at least two releases. Console warnings on mixed downloads will begin as scheduled in Chrome 81.

At this time, we expect to start user-visible warnings in Chrome 84. The Chrome Platform Status entry will be kept up-to-date as timing is finalized. Developers who are otherwise able to do so are encouraged to transition to secure downloads as soon as possible to avoid future disruption.

Today we’re announcing that Chrome will gradually ensure that secure (HTTPS) pages only download secure files. In a series of steps outlined below, we’ll start blocking "mixed content downloads" (non-HTTPS downloads started on secure pages). This move follows a plan we announced last year to start blocking all insecure subresources on secure pages.

Insecurely-downloaded files are a risk to users' security and privacy. For instance, insecurely-downloaded programs can be swapped out for malware by attackers, and eavesdroppers can read users' insecurely-downloaded bank statements. To address these risks, we plan to eventually remove support for insecure downloads in Chrome.

As a first step, we are focusing on insecure downloads started on secure pages. These cases are especially concerning because Chrome currently gives no indication to the user that their privacy and security are at risk.

Starting in Chrome 82 (to be released April 2020), Chrome will gradually start warning on, and later blocking, these mixed content downloads. File types that pose the most risk to users (e.g., executables) will be impacted first, with subsequent releases covering more file types. This gradual rollout is designed to mitigate the worst risks quickly, provide developers an opportunity to update sites, and minimize how many warnings Chrome users have to see.

We plan to roll out restrictions on mixed content downloads on desktop platforms (Windows, macOS, Chrome OS and Linux) first. Our plan for desktop platforms is as follows:

Diagram of when warnings will take affect

Example of a potential warning

Chrome will delay the rollout for Android and iOS users by one release, starting warnings in Chrome 83. Mobile platforms have better native protection against malicious files, and this delay will give developers a head-start towards updating their sites before impacting mobile users. 

Developers can prevent users from ever seeing a download warning by ensuring that downloads only use HTTPS. In the current version of Chrome Canary, or in Chrome 81 once released, developers can activate a warning on all mixed content downloads for testing by enabling the "Treat risky downloads over insecure connections as active mixed content" flag at chrome://flags/#treat-unsafe-downloads-as-active-content

Enterprise and education customers can disable blocking on a per-site basis via the existing InsecureContentAllowedForUrls policy by adding a pattern matching the page requesting the download. 

In the future, we expect to further restrict insecure downloads in Chrome. We encourage developers to fully migrate to HTTPS to avoid future restrictions and fully protect their users. Developers with questions are welcome to email us at 

Posted by Joe DeBlasio, Chrome Security team

Videos with fewer intrusive ads

Chrome has always focused on creating the best possible experience for people browsing the web. We have a long history of protecting our users from annoying and harmful experiences—like blocking pop-up windows and warning users if a page has malware. For the last few years, we’ve worked to address a common complaint among Chrome users: annoying, intrusive ads. In 2018, we started removing the ads from websites that continually show intrusive ads that violate industry standards. Google also updated our own advertising offerings to ensure that we’re not selling or serving the kinds of ads that Internet users find the most annoying. Since then, we’ve seen ad blocking rates in North America and Europe drop significantly in Chrome. 
In order to determine which ads are the most intrusive to web experience, we rely on the Better Ads Standards which give companies like Google guidance based on feedback from people around the world. 
Today, the group responsible for developing the Better Ads Standards, the Coalition for Better Ads, announced a new set of standards for ads that show during video content, based on research from 45,000 consumers worldwide. 
There are many different types of ads that can run before, during, or after a video but according to the Coalition’s research, there are three ad experiences that people find to be particularly disruptive on video content that is less than 8 minutes long: 

Image Source: Coalition for Better Ads

Long, non-skippable pre-roll ads or groups of ads longer than 31 seconds that appear before a video and that cannot be skipped within the first 5 seconds.

Image Source: Coalition for Better Ads

Mid-roll ads of any duration that appear in the middle of a video, interrupting the user’s experience.

Image Source: Coalition for Better Ads

Image or text ads that appear on top of a playing video and are in the middle 1/3 of the video player window or cover more than 20 percent of the video content.

Does this affect my video content? 
The Coalition has announced that website owners should stop showing these ads to their site visitors in the next four months. Following the Coalition’s lead, beginning August 5, 2020, Chrome will expand its user protections and stop showing all ads on sites in any country that repeatedly show these disruptive ads. It’s important to note that, like other websites with video content, will be reviewed for compliance with the Standards. Similar to the previous Better Ads Standards, we’ll update our product plans across our ad platforms, including YouTube, as a result of this standard, and leverage the research as a tool to help guide product development in the future.
If you operate a website that shows ads, you should consider reviewing your site status in the Ad Experience Report, a tool that helps publishers to understand if Chrome has identified any violating ad experiences on your site. Starting this week, we’ll update the Ad Experience Report with information to help publishers resolve any issues with these new video standards currently on their site. For more information about this process, you can reference the Help Center and Community Forum.

Posted by Jason James, Product Manager

SameSite Cookie Changes in February 2020: What You Need to Know

With the stable release of Chrome 80 this month, Chrome will begin enforcing a new secure-by-default cookie classification system, treating cookies that have no declared SameSite value as  SameSite=Lax cookies. Only cookies set as SameSite=None; Secure will be available in third-party contexts, provided they are being accessed from secure connections.

Chrome first announced this change and published developer guidance in May 2019, following up with a reminder and additional context in October 2019.  As the rollout approaches, please review the video and information below to make sure you’re ready and know what to expect.

Launch Timing: The stable release of Chrome 80 is scheduled to begin on February 4. Enforcement of the new cookie classification system in Chrome 80 will begin later in February with a small population of users, gradually increasing over time. To get the latest information about the rollout timing and process,  monitor the SameSite Updates page. To see if your browser has been updated, you can visit this page; if all the rows are green then your browser is applying the new defaults.

Developer Tools Console Warnings: The Developer Tools console provides warnings when a page contains cross-site cookies that are missing the required settings.  If you see these warnings while viewing your site in Developer Tools, that could mean cookies which support features on your site are not properly configured. Here is a Developer Tools warning in Chrome 80; earlier versions of Chrome (77+) provide a similar one:

An exception is the case where a service issues a pair of redundant cookies: One cookie with the new settings, and one cookie with the legacy settings for incompatible clients. In that case, you may see a warning triggered by the legacy cookie even though the service is working as intended. This approach is described here.

Google Cookies: Some Google services will use the approach described above, issuing a cookie with the new settings and a cookie with legacy settings. For this reason, you might see the Developer Tools console warning for Google cookies even though the Google service is working as intended.

Temporary Transition Effects: If a cross-site cookie provider updates its cookies immediately before the Chrome 80 release, some known or returning users with Chrome 80 may temporarily appear as unknown or new users until their cookies are refreshed with the new settings. Providers who updated their cookies farther in advance are less likely to notice an impact because their users had a longer window of time to pick up cookies with the new settings.

Temporary Mitigation for Sign-On Flows: To help avoid broken user sign-on experiences when cookies are passed between websites and third-party providers during the authentication process, Chrome introduced a temporary mitigation known as “Lax + POST” so that, within a two-minute window, cookies without specified SameSite settings can be available for the type of top-level cross-site POST request typically used in sign-on flows. (This does not change behavior for top-level cross-site GET requests, which will attach “Lax” but not “Strict” SameSite cookies.) This mitigation is described in the Chromium tracker for the new model. If you use or provide third party sign-on services we strongly recommend testing your sign-on flow immediately.

Enterprise Policies: Enterprise administrators may need to implement special policies to temporarily revert Chrome Browser to legacy behavior if some services such as sign-on or internal applications are not ready for the Chrome 80 changes.

Testing and Troubleshooting: To see how a site or service will behave under the new model, we strongly recommend testing in Chrome 76+ with the “SameSite by default cookies” and “Cookies without SameSite must be secure” experimental flags enabled.  (To enable flags to go chrome://flags.)  Since the new model will roll out to Chrome 80 gradually, when testing, you should also enable the flags in Chrome 80 to make sure your browser reflects the new default settings.

You can also test whether any unexpected behavior you’re experiencing in Chrome 80 is attributable to the new model by disabling the “SameSite by default cookies” and “Cookies without SameSite must be secure” flags.  If the issue persists with the flags disabled, then the cookie changes are probably not the cause of the issue.  You can find more testing and debugging tips here.

More Resources:

Posted by Barb Smith, Chrome and Web Platform Partnerships

Rethinking Payment Request for iOS Chrome

The Payment Request API is a web standard to make it easier for web developers to build low-friction and secure payment flows. The browser facilitates the flow between a merchant website and “payment handlers”. A payment handler can be built-in to the browser, a native app installed on the user’s mobile device, or a Progressive Web App. Today, developers can use the Payment Request API to access several payment methods, including “basic-card” in Chrome on all platforms, Google Pay in Chrome on Android, and Apple Pay in Safari. The Chrome team continues to work with other browser vendors and digital wallet developers to make more payment handlers available with this new standard.

Shipping the Payment Request API over the last two years helped us better understand the challenges in building payment flows on the web. We learned that UX is critical for building user trust with a payment app, and new technology such as tokenization has made great strides in protecting users from online fraud by never exposing a user’s credit card number to a website. Unfortunately, Chrome’s built-in payment handler for “basic-card” falls short on both regards. As we considered solutions, we realized that the best way to enable more seamless and secure payments on the web is to enable an interoperable ecosystem, where digital wallets can bring their best experience to the web. This means shifting focus to the Payment Handler API, which is an emerging W3C standard that allows 3rd party payment handlers, which can be either native mobile apps or progressive web apps, to integrate with the browser to handle Payment Requests. This enables users to complete one-click payments anywhere on the web using their wallet of choice.

This shift in focus means that we will eventually sunset Chrome’s built-in “basic-card” payment handler. We will start by removing “basic-card” support from iOS Chrome, where this feature has the least usage. This change is coming in M81. In its place, we are investigating how to enable native apps on iOS to integrate with Payment Request API in Chrome. The “basic-card” payment method remains a W3C standard and developers can build compatible payment handlers using the Payment Handler API by setting method to “basic-card” when registering a payment handler with the browser.

This M81 change will deactivate Payment Request API on iOS Chrome because “basic-card” is the only supported payment method and because payment handlers are unavailable due to the lack of Payment Handler API support in WKWebView. If you’re a developer that uses Payment Request API, please make sure you use feature detection and provide a suitable fallback to ensure iOS users continue to have a working alternative. This is also needed to ensure your website works as expected in browsers that don’t yet support Payment Request API.

If you are a payment app developer, please check out our tutorials on how to integrate as a native payment handler on Android and how to integrate as a web-based payment handler via the Payment Handler API.

If you have feedback on Chrome’s web payments implementations, you can reach us at If you have feedback on the web payment API specifications, find us at the W3C Web Payments Working Group.

Posted by Danyao Wang, Web Payments Engineer

AppCache Scope Restricted

The Application Cache (AppCache) specification has been deprecated since December 2016 and in Chrome starting in version 79. In Chrome 70, AppCache was removed from insecure contexts. We plan to remove AppCache in Chrome 82. Prior to AppCache's removal in Chrome 82, we're announcing a security fix that introduces the concept of a manifest scope.

Beginning in Chrome 80 in January, 2020, the scope of the AppCache manifest will be restricted to the path it is served from. Previously, a manifest served from any location within a site's origin could override everything within that origin. For example, a manifest served from would previously allow overriding any URLs within Now it will only allow overriding URLs beginning with, the scope of the manifest.

Does This Affect My Website?
To see if this affects your website, go to chrome://appcache-internals/ and compare the path of the manifest to the paths under File URL. Note that this change only affects "Intercept" and "Fallback" properties. (See the image below.)

You should also test your site using the command line feature flag. To do so:
  1. Launch Chrome 80 using the following command:

    google-chrome --enable-features="AppCacheManifestScopeChecks"
  2. Open chrome://appcache-internals/, find your manifest and remove it.
  3. Open your site so a new AppCache instance is created.
  4. Open chrome://appcache-internals/, verify your manifest appears as expected and parser version is set to 1.
  5. Go offline, then access your site so it's served from AppCache. Verify all pages load as expected.
The replacement technology for AppCache is the Cache API, which requires a service worker. For a shorter term mitigation, add the following HTTP response header to your manifest responses:

X-AppCache-Allowed: /

This header is new in Chrome 80 and will be supported until Chrome 82, which is our announced AppCache removal milestone. Please be aware that AppCache, like all Chrome features, makes use of the disk cache to fetch server responses, so any long-lived disk cache entries for a manifest must be cleared in order to pick up a server X-AppCache-Allowed header change.

Moving Forward from Chrome Apps

The web platform has made substantial progress since the launch of Chrome Apps in 2013. As community members, we continue to work with other browsers and invest to bring rich new capabilities to the platform, as seen in the announcements made at the Chrome Developer Summit last November.

The progress of modern browsers puts the Web in a good position to answer the vast majority of use cases - evident in the success of companies like Figma and our own products like Google Earth. We are confident that the Web can deliver first class experiences on an open platform.

With this continued progress, we are expanding upon our earlier announcement and will begin phasing out support for Chrome Apps across all operating systems as follows:

This change does not impact support for Chrome Extensions. Google will continue to support and invest in Chrome Extensions on all existing platforms. Fostering a robust ecosystem of extensions is critical to Chrome's mission and we are committed to providing a useful extension platform for customizing the browsing experience for all users.

For additional details (e.g., timelines, recommendations, a FAQ, etc.) please visit our Chrome Apps migration site. This page will be kept up to date as we progress together through this process.

On behalf of the Chrome team, we thank the community of developers for building great experiences using Chrome Apps and look forward to seeing similar experiences that leverage open Web standards (e.g., PWAs) across all modern browsers.

Posted by Anthony Laforge, Technical Director, Chrome Platform Team

Building a more private web: A path towards making third party cookies obsolete

In August, we announced a new initiative (known as Privacy Sandbox) to develop a set of open standards to fundamentally enhance privacy on the web. Our goal for this open source initiative is to make the web more private and secure for users, while also supporting publishers. Today, we’d like to give you an update on our plans and ask for your help in increasing the privacy of web browsing.

After initial dialogue with the web community, we are confident that with continued iteration and feedback, privacy-preserving and open-standard mechanisms like the Privacy Sandbox can sustain a healthy, ad-supported web in a way that will render third-party cookies obsolete. Once these approaches have addressed the needs of users, publishers, and advertisers, and we have developed the tools to mitigate workarounds, we plan to phase out support for third-party cookies in Chrome. Our intention is to do this within two years. But we cannot get there alone, and that’s why we need the ecosystem to engage on these proposals. We plan to start the first origin trials by the end of this year, starting with conversion measurement and following with personalization.

Users are demanding greater privacy--including transparency, choice and control over how their data is used--and it’s clear the web ecosystem needs to evolve to meet these increasing demands. Some browsers have reacted to these concerns by blocking third-party cookies, but we believe this has unintended consequences that can negatively impact both users and the web ecosystem. By undermining the business model of many ad-supported websites, blunt approaches to cookies encourage the use of opaque techniques such as fingerprinting (an invasive workaround to replace cookies), which can actually reduce user privacy and control. We believe that we as a community can, and must, do better.

Fortunately, we have received positive feedback in forums like the W3C that the mechanisms underlying the Privacy Sandbox represent key use-cases and go in the right direction. This feedback, and related proposals from other standards participants, gives us confidence that solutions in this space can work. And our experience working with the standards community to create alternatives and phase out Flash and NPAPI has proven that we can come together to solve complex challenges.

We’ll also continue our work to make current web technologies more secure and private. As we previously announced, Chrome will limit insecure cross-site tracking starting in February, by treating cookies that don’t include a SameSite label as first-party only, and require cookies labeled for third-party use to be accessed over HTTPS. This will make third-party cookies more secure and give users more precise browser cookie controls. At the same time, we’re developing techniques to detect and mitigate covert tracking and workarounds by launching new anti-fingerprinting measures to discourage these kinds of deceptive and intrusive techniques, and we hope to launch these measures later this year.

We are working actively across the ecosystem so that browsers, publishers, developers, and advertisers have the opportunity to experiment with these new mechanisms, test whether they work well in various situations, and develop supporting implementations, including ad selection and measurement, denial of service (DoS) prevention, anti-spam/fraud, and federated authentication.

We are looking to build a more trustworthy and sustainable web together, and to do that we need your continued engagement. We encourage you to give feedback on the web standards community proposals via GitHub and make sure they address your needs. And if they don’t, file issues through GitHub or email the W3C group. If you rely on the web for your business, please ensure your technology vendors engage in this process and share your feedback with the trade groups that represent your interests.

We will continue to keep everyone posted on the progress of efforts to increase the privacy of web browsing.

Posted by Justin Schuh - Director, Chrome Engineering

Introducing quieter permission UI for notifications

Notifications on the web enable users to receive important updates even when they are not interacting with a website. Notifications are an essential capability for a wide range of applications including messaging, calendars, email clients, ride sharing, social media and delivery services. Unfortunately, notifications are also a common complaint as many websites request the notification permission on first visit rather than at contextually relevant moments in the user’s journey. Unsolicited permission requests interrupt the user’s workflow and result in a bad user experience. To protect notifications as a useful service for users, Chrome 80 will show, under certain conditions, a new, quieter notification permission UI that reduces the interruptiveness of notification permission requests. In Chrome 80, users will be able to opt-in to the new UI manually in Settings. In addition, the quieter UI will be automatically enabled for users under two conditions: first, for users who typically block notification permission requests and second, on sites with very low opt in rates. The automated enrollment will be enabled gradually after the Chrome 80 release while we gather user and developer feedback. Later in 2020 we plan to enable additional enforcement against abusive websites using web notifications for ads, malware or deceptive purposes. This enforcement will be described in detail in a future blog post.

Quiet UI overview

Quieter UI (Desktop and Mobile)

The quieter UI is available in both Desktop and Mobile. The first time the UI is presented to the user, it will be accompanied by a dismissable in-product help dialog that explains the new feature.

Enrollment & opt out

Users can be enrolled in the quieter UI in three ways.

Manual enrollment (and opt-out)

Manually enroll on Desktop or Mobile via Notifications Settings

Users can enroll for quieter prompts manually, or disable it completely. To enroll, the toggle ‘Sites can ask to send notifications’ must be enabled in Settings > Site Settings > Notifications, then the checkbox ‘Use quieter messaging’ must be checked.

Automatic enrollment for users who infrequently accept notifications

Users who repeatedly deny notifications across websites will be automatically enrolled in the quieter notifications UI.

Automatic enrollment on sites with low permission acceptance rates

Sites with very low acceptance rates will be automatically enrolled in quieter prompts. They will be unenrolled once acceptance rates improve, for example, if the developer of the site improves the notification permission request user experience. Per-site information about notification permission acceptance rates will be made available via the Chrome User Experience Report in Q1 2020 and automatic enrollment is based on Chrome usage statistics. 

Developer recommendations

First, we recommend that web developers test their site’s permission request flow with the quieter notification permission UI, by enabling it manually in chrome://settings/content/notifications. At the time of writing, the feature is being rolled out gradually to Canary, Dev, and Beta channels, and can be force-enabled in chrome://flags/#quiet-notification-prompts in Chrome 80 and later. Second, we recommend that developers follow best practices for requesting the notification permission from users. Websites that ask users to sign up for web notifications when they first arrive often have very low accept rates. Instead, we recommend that websites wait until users understand the context and see benefit in receiving notifications before prompting for the permission. Some websites display a pre-prompt in the content area before triggering the native permission prompt. This approach is also not recommended if it interrupts the user journey: sites that request the permission at contextually relevant moments enjoy lower bounce and higher conversion rates. For help with user permission UX, you can refer to this 5 minute video on improving your user permission acceptance rates, and read about best practices when requesting permissions.

Posted by PJ McLachlan, Product Manager