Trusted Web Activity will delegate some web app errors to native app crashes beginning in Chrome 86
Trusted Web Activity will delegate some web app errors to native app crashes beginning in Chrome 86

Trusted Web Activities are Chrome's recommended way to integrate fullscreen Progressive Web App content into an Android app. Unlike a WebView, a Trusted Web Activity is an instance of the Chrome browser and implements a complete and evergreen set of web platform APIs thanks to Chrome auto update. Since the release of Trusted Web Activity, we’ve been working on improving the integration of apps built using a Trusted Web Activity into the native ecosystem with features such as automatically generated splash screens and web notification delegation. 


In Chrome 86, we’ll take this integration a step further by delegating web application crash events into native equivalents. 


Web apps crash, but they crash differently

Web developers are more used to thinking about “errors” rather than crashes. When a user encounters an HTTP error in their web app journey, such as a 404 or a 5xx error, that’s effectively an application crash. Another example of a web app error that could be considered a crash is when the Chrome dino page appears because the user lost their internet connection and the app didn’t have a handler in the ServiceWorker for an offline resource request. This kind of ServiceWorker handling of errors can be used for 404 and 5xx resource loading errors as well. 


Crashes in the Android ecosystem

Android Vitals is an initiative by Google to improve the stability and performance of Android devices. The Google Play Console aggregates Android Vitals data and displays it in the Android vitals dashboard. Problems in Android Vitals indicate a low quality user experience in the app and can result in bad ratings and poor discoverability on the Play Store.


Starting in Chrome 86, Chrome will integrate critical web application crashes into native app crash events and Android Vitals. As this change will cause user facing crashes if these events are unhandled, developers using or planning to use a Trusted Web Activity should review this post carefully.


Critical web application crashes that will be delegated in Chrome 86 are: 


  1. an HTTP 404 or 5xx error in the application

  2. failure to return HTTP 200 for an offline network resource request

  3. failure to verify digital asset links at application launch


In this article we’ll provide more details on the exception conditions, impact on the application behavior and how to avoid these exceptions. 

Why is Chrome making this change?

Users installing an Android application from the Play Store expect the application to look and feel native. Native applications do not have a 404 or 5xx error page. Native applications are expected to handle internet service interruptions, at a minimum by providing a branded offline indicator. Finally, when digital asset links fail to verify, we cannot verify that the app owner is also the owner of the web content. Previously, this circumstance resulted in a fallback from Trusted web Activity to a CCT view. In practice we’ve found that a CCT fallback does not meet user expectations. Furthermore, the silent fallback bypasses a feedback mechanism (a Play console crash report) that is important for developers to understand what’s going wrong with their application. 


By integrating crash events into Android Vitals, Android app developers using Trusted Web Activity can make use of the Android Vitals dashboard to view information about the user experience of their app. This approach also rewards developers building high quality apps, since apps with better scores in Android vitals have better discoverability in the Play store. 

How will this work and what should I do about it? 

The table below details the web application crash triggers, the corresponding action and recommended mitigations. The Trusted Web Activity crash event will include a log message viewable in the Android Console with details about which trigger caused the exception and the URL at which the exception occurred to facilitate debugging. 


Exception trigger

Action

Recommended mitigations

HTTP 404 or 5xx error code returned on HTTP request for the main document to a trusted origin 









Exception raised by the Trusted Web Activity


  • Make sure your app doesn’t have 404 or 5xx errors

  • Use a ServiceWorker and handle 404 or 5xx errors using a ServiceWorker fetch event fallback response

Failure to return HTTP 200 on an HTTP request for the main document to a trusted origin when offline

  • Use a ServiceWorker

  • Handle offline resource requests using a ServiceWorker [tutorial]

Digital assetlinks verification failure 


(excludes failures when offline)

  • Review the Trusted Web Activity quick start guide for how to correctly implement Digital Assetlinks

TLS verification failure on a trusted origin

  • Ensure your TLS certificate is valid


Handling exceptions with native code

Exceptions raised by a Trusted Web Activity can also be handled using Android exception handling. However, consider avoiding these exceptions altogether with the mitigations recommended in the table above. 


First, the Trusted Web Activity exception will cause Chrome to exit. Even if the  exception is handled, it will still be a janky user experience. 


Second, implementing the mitigations in the web app will improve the experience of all users of your PWA in all web browsers. 

Future Android Vitals integrations 

Over time, we will continue to add integrations of important web application events into Android Vitals to make the user experience of web applications more consistent with native applications. 


For example, app startup time, battery usage, permission denials or App Not Responding (ANR) events.

A reminder about Trusted Web Activity quality criteria 

  1. Policies. Android apps using Trusted Web Activity must comply with all Play store policies, including for web content in the Trusted Web Activity, including policies for payments in-app purchases and other digital goods. 

  2. To ensure the quality of experience, content in a Trusted Web Activity must meet PWA installability criteria and load fast at the start URL. Loading speed is measured using Lighthouse at the Trusted Web Activity start URL and must achieve a performance score of 80. 


Lighthouse is an open-source, automated tool for auditing performance & progressive web apps and is useful both as a benchmark and to help you build better websites. 

Helping developers build a high quality trusted web activity 

Since the release of Trusted Web Activity, we’ve created the open source utility library Bubblewrap, which helps developers build high quality Android applications using their Progressive Web App. The Trusted Web Activity quick start guide helps developers new to Trusted Web Activity and Bubblewrap get going fast. 


We are continuously improving Bubblewrap, adding tools and scaffolds to make it easy for developers to build high quality Android apps using Trusted Web Activity and to provide build time warnings for common mistakes. 


Posted by PJ McLachlan, Product Manager


Last year, MDN ran the 2019 Web Developer Needs Assessment (DNA) survey. The DNA survey drew responses from over 28,000 developers from around the world, together contributing more than 10,000 hours of insights into what is and isn't working on the web today, and how the web needs to change to meet the needs of the developer community.


There were many needs expressed in the survey results, but one that stood out clearly was browser compatibility - the manner in which websites look or behave differently on different web browsers. It is clear that it is still painful to develop a website or web app that works reliably across browsers.


The div that looks different in every browser' (credit Martijn Cuppens) - it still reproduces today!

To help focus in on specific developer needs, MDN ran a follow-up survey in March 2020 - the MDN Browser Compatibility Survey. This survey, taken by over 3000 web developers and augmented by post-survey interviews, aimed to uncover the specific pain-points the web developer community is having with browser compatibility. Today I'd like to talk about our takeaways from the results, and what we - Google Chrome - are doing about them.


It is important to stress that these are just some early findings from the MDN Browser Compatibility survey and are focused on pain points developers have relating to Chrome.

Flexbox

Flexbox is a powerful tool for layout on the web. It offers an ergonomic way to define layouts that will respond gracefully on different sized viewports. But this power isn't much good when it can't be relied on across browsers. Flexbox is one of our top priorities for browser compatibility across the web in 2020, and we've put heavy investment into it already.


The Chrome rendering team has been working on a rearchitecture of the Chromium flexbox implementation on top of our modern LayoutNG layout engine. This work, which we plan to bring to Chrome 84, is expected to fix a number of Flexbox compatibility issues in Chromium.


We're also working towards bringing flex-gap and fieldset+flex support to Chromium this year. In fact, flex-gap will be available in Chrome 84 - try it out and let us know what you think.

Scrolling

Getting scrolling right in one browser can be tricky. Getting scrolling right across multiple browsers can be painful (for example, it takes an entire library to consistently lock body scrolling). We're still digging through the feedback on scrolling compatibility, but a few key areas have stood out so far:


  • How virtual keyboards affect - or don't affect - viewport units in different browsers. (Note recent work from Microsoft Edge on a VirtualKeyboard API that may help here.)

  • A lack of consistency in input-related events, and the outcome of interacting with them (e.g. what happens when you preventDefault() a touchmove).

  • Difficulty controlling how scrolling behaves across browsers (e.g. via scroll anchoring).


We plan to start here by investing more in understanding how we can effectively improve scrolling on the web. As part of that, we need to keep hearing from you. Please continue to tell us about your scrolling compatibility pains - especially as they relate to Chrome.

Form controls

Forms are a very old part of the web, added before even CSS. Form controls were intended to mimic the look and feel of the native platform, but it's clear that they have failed to do so consistently and have also failed to keep up with the needs of modern web development. The compatibility survey turned up two general themes here: stylability and inconsistent behavior across browsers.


On styling form controls, the Microsoft Edge and Google Chrome teams recently finished a year-long project to refresh and update the default form styles in Chromium-based browsers. This much needed refresh modernizes the default look and brings improved accessibility and touch support. However it's clear that without more control over how form controls are styled, they still present a compatibility pain for web developers. We don't have anything to announce here today, but we will be continuing to look at form stylability during 2020.


Out with the old, in with the new; some of the form controls refresh that landed in Chrome 83. (more in the blogpost).


In terms of behavior, there appears to be a general concern that form control behaviors either aren't well specified or that those specifications aren't consistently followed by browsers. Some concrete examples of inconsistencies across browsers that we heard are support for certain <input> types, autofill behaviors, and content restoration behavior when navigating away from and back to pages that contain forms. Again we have nothing specific to announce yet, but will be looking at this area going forward.

CSS Grid

Like Flexbox, CSS Grid is an important component of modern layout. Looking at the early survey results it seems like the story for CSS Grid support in Chromium is fairly good (we have our friends from Igalia to thank for that!). There is one clear exception - Chromium still doesn't support subgrid.


Hopefully it won't be an exception for much longer. It's still early days, but I'm excited to share that a team at Microsoft Edge are working on rearchitecting Chromium's Grid support to use the new LayoutNG engine - and as part of this are intending to add subgrid support! We're excited to see this feature land and want to express our appreciation to our partners at Microsoft, Igalia, and the many other Chromium contributors who have worked on CSS Grid support.

Launching features on the web

Unlike many platforms, the web has multiple implementations. This has downsides but it is also one of the web's greatest strengths. It vastly widens the diversity of inputs into the web platform, and provides a guarding factor against architectural mistakes that can occur when one blurs a platform (the web) and an implementation (a single browser).


In Chrome we strongly believe in moving the web forward, and in shipping new features that bring benefits to users and developers. But it is clear from the MDN Browser Compatibility Survey that some developers have concerns about how this may impact compatibility. We aren't going to stop moving the web forward, but we are planning to be more rigorous in how we approach it and in how we communicate about compatibility.  Look out for more on this soon.

Summing up

When it comes to browser compatibility, there are still too many missing features and edge-case bugs. But it doesn't have to be this way. Things can and will get better, if browser vendors can understand what is causing the most pain, and take action to address the causes. In Chrome we're doing our best to listen, and we're doing our best to address what we're hearing. We hope it helps, and we're looking forward to a more compatible 2021.


For all of the above, please tell us if we're right or wrong. Tweet us, file bugs and star the issues that you think we should prioritize, fill in this form, take part in the next web survey you see. Your voice matters to us and is a major factor in determining what work we prioritize.


Last year, MDN ran the 2019 Web Developer Needs Assessment (DNA) survey. The DNA survey drew responses from over 28,000 developers from around the world, together contributing more than 10,000 hours of insights into what is and isn't working on the web today, and how the web needs to change to meet the needs of the developer community.


There were many needs expressed in the survey results, but one that stood out clearly was browser compatibility - the manner in which websites look or behave differently on different web browsers. It is clear that it is still painful to develop a website or web app that works reliably across browsers.


The div that looks different in every browser' (credit Martijn Cuppens) - it still reproduces today!

To help focus in on specific developer needs, MDN ran a follow-up survey in March 2020 - the MDN Browser Compatibility Survey. This survey, taken by over 3000 web developers and augmented by post-survey interviews, aimed to uncover the specific pain-points the web developer community is having with browser compatibility. Today I'd like to talk about our takeaways from the results, and what we - Google Chrome - are doing about them.


It is important to stress that these are just some early findings from the MDN Browser Compatibility survey and are focused on pain points developers have relating to Chrome.

Flexbox

Flexbox is a powerful tool for layout on the web. It offers an ergonomic way to define layouts that will respond gracefully on different sized viewports. But this power isn't much good when it can't be relied on across browsers. Flexbox is one of our top priorities for browser compatibility across the web in 2020, and we've put heavy investment into it already.


The Chrome rendering team has been working on a rearchitecture of the Chromium flexbox implementation on top of our modern LayoutNG layout engine. This work, which we plan to bring to Chrome 84, is expected to fix a number of Flexbox compatibility issues in Chromium.


We're also working towards bringing flex-gap and fieldset+flex support to Chromium this year. In fact, flex-gap will be available in Chrome 84 - try it out and let us know what you think.

Scrolling

Getting scrolling right in one browser can be tricky. Getting scrolling right across multiple browsers can be painful (for example, it takes an entire library to consistently lock body scrolling). We're still digging through the feedback on scrolling compatibility, but a few key areas have stood out so far:


  • How virtual keyboards affect - or don't affect - viewport units in different browsers. (Note recent work from Microsoft Edge on a VirtualKeyboard API that may help here.)

  • A lack of consistency in input-related events, and the outcome of interacting with them (e.g. what happens when you preventDefault() a touchmove).

  • Difficulty controlling how scrolling behaves across browsers (e.g. via scroll anchoring).


We plan to start here by investing more in understanding how we can effectively improve scrolling on the web. As part of that, we need to keep hearing from you. Please continue to tell us about your scrolling compatibility pains - especially as they relate to Chrome.

Form controls

Forms are a very old part of the web, added before even CSS. Form controls were intended to mimic the look and feel of the native platform, but it's clear that they have failed to do so consistently and have also failed to keep up with the needs of modern web development. The compatibility survey turned up two general themes here: stylability and inconsistent behavior across browsers.


On styling form controls, the Microsoft Edge and Google Chrome teams recently finished a year-long project to refresh and update the default form styles in Chromium-based browsers. This much needed refresh modernizes the default look and brings improved accessibility and touch support. However it's clear that without more control over how form controls are styled, they still present a compatibility pain for web developers. We don't have anything to announce here today, but we will be continuing to look at form stylability during 2020.


Out with the old, in with the new; some of the form controls refresh that landed in Chrome 83. (more in the blogpost).


In terms of behavior, there appears to be a general concern that form control behaviors either aren't well specified or that those specifications aren't consistently followed by browsers. Some concrete examples of inconsistencies across browsers that we heard are support for certain <input> types, autofill behaviors, and content restoration behavior when navigating away from and back to pages that contain forms. Again we have nothing specific to announce yet, but will be looking at this area going forward.

CSS Grid

Like Flexbox, CSS Grid is an important component of modern layout. Looking at the early survey results it seems like the story for CSS Grid support in Chromium is fairly good (we have our friends from Igalia to thank for that!). There is one clear exception - Chromium still doesn't support subgrid.


Hopefully it won't be an exception for much longer. It's still early days, but I'm excited to share that a team at Microsoft Edge are working on rearchitecting Chromium's Grid support to use the new LayoutNG engine - and as part of this are intending to add subgrid support! We're excited to see this feature land and want to express our appreciation to our partners at Microsoft, Igalia, and the many other Chromium contributors who have worked on CSS Grid support.

Launching features on the web

Unlike many platforms, the web has multiple implementations. This has downsides but it is also one of the web's greatest strengths. It vastly widens the diversity of inputs into the web platform, and provides a guarding factor against architectural mistakes that can occur when one blurs a platform (the web) and an implementation (a single browser).


In Chrome we strongly believe in moving the web forward, and in shipping new features that bring benefits to users and developers. But it is clear from the MDN Browser Compatibility Survey that some developers have concerns about how this may impact compatibility. We aren't going to stop moving the web forward, but we are planning to be more rigorous in how we approach it and in how we communicate about compatibility.  Look out for more on this soon.

Summing up

When it comes to browser compatibility, there are still too many missing features and edge-case bugs. But it doesn't have to be this way. Things can and will get better, if browser vendors can understand what is causing the most pain, and take action to address the causes. In Chrome we're doing our best to listen, and we're doing our best to address what we're hearing. We hope it helps, and we're looking forward to a more compatible 2021.


For all of the above, please tell us if we're right or wrong. Tweet us, file bugs and star the issues that you think we should prioritize, fill in this form, take part in the next web survey you see. Your voice matters to us and is a major factor in determining what work we prioritize.




Posted by Stephen McGruer, Software Engineer, Chrome

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 ...
Unless otherwise noted, changes described below apply to the newest Chrome beta channel release for Android, Chrome OS, Linux, macOS, and Windows. Learn more about the features listed here through the provided links or from the list on ChromeStatus.com. Chrome 84 is beta as of May 28, 2020.

Web OTP API

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.

JavaScript

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

Private Methods and Accessors

Keeping state and behavior private to a class lets library authors present a clear, stable interface, while changing their code over time behind the scenes. Private class fields, which shipped in Chrome 74, added private fields for classes and instances. Now in Chrome 84, methods and properties can also be private. With this enhancement, any JavaScript class element can be private.

Weak references

The V8 engine now supports weak references to JavaScript objects, which help web developers define cleanup routines that don't keep the related objects alive but are (optionally) executed after the related object is garbage-collected. For more information, see Weak references and finalizers.

Deprecations, and Removals

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

@import rules in CSSStyleSheet.replace() Removed

The original spec for constructable stylesheets allowed for calls to:

sheet.replace("@import('some.css');")

This use case is being removed. Calls to replace() now throw an exception if @import rules are found in the replaced content.

Remove TLS 1.0 and TLS 1.1

TLS (Transport Layer Security) is the protocol which secures HTTPS. It has a long history stretching back to the nearly twenty-year-old TLS 1.0 and its even older predecessor, SSL. Both TLS 1.0 and 1.1 have a number of weaknesses.
  • TLS 1.0 and 1.1 use MD5 and SHA-1, both weak hashes, in the transcript hash for the Finished message.
  • TLS 1.0 and 1.1 use MD5 and SHA-1 in the server signature. (Note: this is not the signature in the certificate.)
  • TLS 1.0 and 1.1 only support RC4 and CBC ciphers. RC4 is broken and has since been removed. TLS's CBC mode construction is flawed and is vulnerable to attacks.
  • TLS 1.0's CBC ciphers additionally construct their initialization vectors incorrectly.
  • TLS 1.0 is no longer PCI-DSS compliant.
Supporting TLS 1.2 is a prerequisite to avoiding the above problems. The TLS working group has deprecated TLS 1.0 and 1.1. Chrome has now also deprecated these protocols.






Why are you doing this?


Notification UI changes for Chrome 84

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

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.
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 Chromium.org. 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 Web.dev.

Posted by Justin Schuh - Director, Chrome Engineering








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