Chromium Blog: chrome

Better content sharing with Custom Tabs

Friday, January 22, 2021

Custom TabsAction Button

A default Action Button that shares the URL is added to the top bar when the application doesn’t provide one.

What do I need to do to enable the new default share action button in?

Nothing! The default Action Button will be automatically added to the application, as long as the application doesn’t set its own. Since this change will happen in the browser, it will be automatically applied to all apps using Custom Tabs.
Please note: this is a change in Chrome’s behavior and we hope other browsers will add similar functionality.

How can I opt-out from the share icon showing in my App?

Starting with androidx.browser version 1.3.0, developers can use the setShareState() method from the CustomTabsIntent.Builder to disable the default share:

val customTabsIntent = CustomTabsIntent.Builder()

.setShareState(CustomTabsIntent.SHARE_STATE_OFF)

.build();

As part of this change, the addDefaultShareMenuItem() and setDefaultShareMenuItemEnabled() methods from CustomTabsIntent.Builder have been deprecated and developers should use setShareState() instead.

If your application uses Custom Tabs, we’d like to hear your feedback, and you can reach out to us using this form.

Posted by André Bandarra, Developer Relations Engineer and Chirag Desai, Product Manager

Progress on Privacy Sandbox and building a more private web

Tuesday, October 6, 2020

Last year we announced a new initiative (known as Privacy Sandbox) to develop a set of open standards to fundamentally enhance privacy on the web. With Privacy Sandbox we’ve been exploring privacy-preserving mechanisms with the web community that protect user data and prevent intrusive cross-site tracking. Our aim is to preserve the vitality of the open web by continuing to enable the rich, quality content and services that people expect, but with even stronger guarantees of privacy and safety. Today we’re sharing progress on this long-term initiative and asking for your continued help in increasing the privacy of web browsing.

In January we shared our intent to develop privacy-preserving open-standards that will render third-party cookies obsolete. Since then, Google and others have proposed several new APIs to address use cases like fraud protection, ad selection, and conversion measurement without allowing users’ activity to be tracked across websites. Following web community input, some of these solutions are now available for experimental testing via Chrome origin trials:

Click Conversion Measurement API opened up for testing in September and aims to enable marketers to know whether an ad click resulted in a conversion (for example, a purchase or a sign-up) on another site, without connecting the identity of the user across both sites.

Trust Tokens opened up for testing in July and is intended to support a number of use cases evaluating a user’s authenticity, including combating fraud.

If you integrate APIs into your products and services, you can register for access to these and other APIs through Chrome origin trials. We encourage ecosystem stakeholders to participate and share their feedback and results. Developing and implementing web standards which change the core architecture of the web is a complex process, so we are taking a long-term, collaborative approach.

We’re also continuing our work to make current web technologies more secure and private.

Earlier this year Chrome started limiting cross-site tracking by treating cookies that don’t include a SameSite label as first-party only, and requiring cookies to be labeled and accessed over HTTPS in order to be available in third-party contexts. With this update — which Edge and Firefox are in the process of adopting — third-party cookies are no longer sent for the 99.9% of registered domains that do not require them, improving privacy and security for the vast majority of sites on the web.

In a release early next year, Chrome will also strengthen protection against additional types of network attacks that could hijack the users’ privileged credentials to perform malicious actions on their accounts.

We’re also rolling out changes in Chrome to mitigate deceptive and intrusive tracking techniques, such as fingerprinting.

In September we rolled out an update to prevent inadvertent sharing of information such as users' names and access tokens. When users navigate from one site to another we are reducing the information from the originating page’s URL that is sent to the destination site by default.

Also in September, we extended support of Secure DNS in Chrome beyond desktop to Android. Secure DNS is designed to improve user safety and privacy while browsing the web by automatically switching to DNS-over-HTTPS if the user's current provider supports it.

Coming soon, we’re also closing the ability for a site to observe other sites that a user might have visited through caching mechanisms.

As always, 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 that the trade groups who represent your interests are actively engaged.

We are appreciative of the continued engagement as we build a more trustworthy and sustainable web together. 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

Highlighting great user experiences on the mobile web

Monday, August 17, 2020

Over the last decade, Chrome and the web development community have worked towards providing users with a fast, responsive and delightful browsing experience. Features like <link rel=preload> and native lazy-loading, to name but a few, are helping pages meet this mark. Historically, Chrome has also successfully encouraged the adoption of best-practices such as HTTPS by distinguishing secure from insecure browsing in Chrome's UI.

To help users identify great experiences as they browse, we are excited to announce that Chrome will begin to highlight high quality user experiences on the web, starting with the labelling of fast links via the link context menu on Chrome for Android. This change will be rolling out starting in Chrome 85 Beta.

Labelling is based on signals from the Core Web Vitals metrics that quantify key aspects of users’ experience, as experienced by real-world Chrome users. The Core Web Vitals metrics measure dimensions of web usability such as loading time, responsiveness, and the stability of content as it loads, and define thresholds for these metrics to set a bar for providing a good user experience.

The changes that site owners make to improve on these aspects work towards making the web more delightful for users across all web browsers. Investing in these critical user-centric metrics helps to drive usability improvements for users and helps businesses see increased engagement.

Links to pages that have historically met or exceeded all metrics thresholds for the Core Web Vitals will be displayed with a new “Fast page” label. This is shown when a user long-presses a link prior to navigating to a page, and it indicates that most users navigating to it have a particularly good experience.

"Fast page" labelling may badge a link as fast if the URL (or URLs like it) have been historically fast for other users. When labelling, historical data from a site’s URLs with similar structure are aggregated together. Historical data is evaluated on a host-by-host basis when the URL data is insufficient to assess speed or is unavailable, for example, when the URL is new or less popular.

Our plan is to maintain alignment with Core Web Vitals as they evolve, so that we are always labeling pages that have optimized against the metrics that are most representative of a user's overall experience. As previously noted, developers should expect the definitions and thresholds of the Core Web Vitals to be stable, and updates to have prior notice and a predictable, annual cadence.

We anticipate that optimizing for the Core Web Vitals may require some investments in improving page quality. To help out, we updated our developer tools to surface information and recommendations: Lighthouse, DevTools, PageSpeed Insights, and Search Console team added a report dedicated to Core Web Vitals too.

Labelling is currently being rolled out to Chrome 85 beta, but if you would like to try labelling today, go to chrome://flags and enable “Context menu performance info and remote hint fetching”. Please note, this flag will only be available on Chrome for Android. Once fully rolled out, users will see labelling if they have Lite mode or “Make Searches and Browsing Better” turned on. Next, navigate to any qualifying page, such as the Wikipedia page for the Internet, and long-press on any link.

We believe the web serves a critical role in our lives, and hope that fast labelling proves helpful to users who are on slow or spotty network connections. Over time, we may also experiment with labelling in other parts of Chrome’s UI. Ultimately, our goal is to provide users of the web with a healthy level of transparency into the experience they may have with a page.

Chrome is committed to working with the ecosystem to ensure a thriving web, and the steps we take, such as the ones outlined above, are designed with these goals in mind.

By Addy Osmani, Ben Greenstein and Josh Simmons, fast page fans.

Helping people spot the spoofs: a URL experiment

Wednesday, August 12, 2020

On today’s web, URLs remain the primary way users determine the identity and authenticity of a site, yet we know URLs suffer from usability challenges. For example: there are myriad ways that attackers can manipulate URLs to confuse users about a website’s identity, which leads to rampant phishing, social engineering, and scams. In one study, more than 60% of users were fooled when a misleading brand name appeared in a URL’s path.

Different browsers approach this challenge in a number of ways, including showing only the domain by default, or visually highlighting the registrable domain (the “most significant” part of the domain name). In Chrome 86, we’re likewise going to experiment with how URLs are shown in the address bar on desktop platforms (animation below). Our goal is to understand -- through real-world usage -- whether showing URLs this way helps users realize they’re visiting a malicious website, and protects them from phishing and social engineering attacks.

An experiment in Chrome 86 shows the domain name by default and full URL on hover

Prefer to see the full URL?

If you find yourself in the experimental group, and you’d like to view the full URL for a given site, you’ll have two options. First you can hover over the URL, and it will expand fully. Second, you can right-click on the URL, and choose “Always show full URLs” in the context menu (screenshot below); enabling this setting will show the full URL for all future sites you visit. (Notably: Enterprise-enrolled devices won’t be included in this Chrome 86 experiment.)

A setting in the context menu allows you to always show full URLs in the address bar

We welcome your feedback!

If you’re not randomly assigned to this Chrome 86 experiment, and you’d like to try it out, please install Chrome Canary or Dev channel, open chrome://flags in Chrome 86, enable the following flags, and re-launch Chrome:

#omnibox-ui-reveal-steady-state-url-path-query-and-ref-on-hover
#omnibox-ui-sometimes-elide-to-registrable-domain
Optionally, #omnibox-ui-hide-steady-state-url-path-query-and-ref-on-interaction to show the full URL on page load until you interact with the page.

Thanks in advance for your thoughts! You can file bugs or feature requests on our bug tracker.

Posted by Emily Stark, Eric Mill, Shweta Panditrao, Chrome Security Team

web.dev LIVE: A digital event over three days and three time zones

Tuesday, May 26, 2020

Last week, my calendar was constantly alerting me to the fact that many of us would be gathering at Google I/O, and it definitely made me sad that we can’t be together in person right now! We have been so impressed with the role that web developers have played in these trying times, as they focus on the fundamentals, make sure critical information is available, that commerce can come online, and that we can work and educate from home. Kudos to you all.

We want to help.

So, we’re planning a three day digital event - web.dev LIVE - where web developers can come together, from the comfort of their homes to hear about the latest, most helpful updates to the platform, learn modern web techniques and to connect with other developers — including those who are pushing the community forward and have been on the front line with COVID related work.

The event will take place from June 30th to July 2nd and will include short three-hour content streams (in English) hosted on web.dev/live.

Reaching you where you are. In your time zone.

Planning a completely digital event has been an interesting challenge. While we can’t bring everyone together physically, we can still bring great content straight to your couch, kitchen or hammock-in-the-backyard. A digital event also gives us the opportunity to break out of physical constraints. We are no longer limited by space for attendance, and anyone, literally anywhere in the world, can “join” us at the click of a button (Oh and we, as part of the web community, should be proud of making that happen. Everyday!)

To really make this a regionally inclusive event, we will “travel” to three different time zones so we can answer your questions real-time, in your active hours. Each day will have unique content so you’re welcome to join us on all three days or watch the content on demand later, but developers in any timezone will have the team actively answering questions at least once through the event.

When will the event be live each day?

June 30th, 9am - 12pm PDT (Optimized for developers in the Americas)
July 1st, 12pm - 3pm GMT (Optimized for developers in Europe & Africa)
July 2nd, 1pm - 4pm IST (Optimized for developers in Asia & Australia)

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

Posted by Dion Almaer, Karaoke Lead for the Web Ecosystem

A safer and more private browsing experience with Secure DNS

Tuesday, May 19, 2020

gathering test dataaddressing some misconceptions Unencrypted DNSalmost ubiquitous

With unencrypted DNS, an attacker connected to the same network can observe other users’ browsing habits. Benefits of DNS-over-HTTPS

Authenticity: Chrome can verify that it is communicating with the intended DNS service provider and not a fake service provider that’s controlled by an attacker.
Integrity: Chrome can verify that the response it got from the DNS service provider hasn’t been tampered with by attackers using the same network, thereby stopping phishing attacks.
Confidentiality: Chrome can talk to the DNS service provider over an encrypted channel which means that attackers can no longer rely on DNS to observe which websites other users are visiting when sharing the same connection, e.g. public WiFi in a library.

With DNS-over-HTTPS, an attacker can no longer rely on DNS to observe other users’ browsing habits.

The introduction of DNS-over-HTTPS gives the whole ecosystem a rare opportunity to start from a clean and dependable slate, making it easier to pursue further enhancements relying on DNS as a delivery mechanism. Thus far, the unencrypted nature of DNS has meant that features that extend DNS could randomly fail due to causes such as network equipment that may drop or modify newly introduced DNS fields. As DNS-over-HTTPS grows, it will put this concern aside because it benefits from the aforementioned HTTPS properties and sets a new reliable baseline to build upon.

Responsibly deploying DNS-over-HTTPS

Changing how DNS works is a non-trivial task. In particular, with more than 35 years of history, a lot of additional services and features have been built on top of DNS. For instance, some Internet Service Providers offer family-safe filtering via DNS. So, while we would love to have everyone benefit from Secure DNS immediately, we also know that we have to get there in a way that doesn’t break user expectations. Navigating these goals led us to the “same-provider DNS-over-HTTPS upgrade” approach that we experimented with at the end of 2019. The successful experiment gave us confidence about the performance and stability aspects for both Chrome’s Secure DNS and our partners’ DNS-over-HTTPS services. It also highlighted opportunities to improve the auto-upgrade success rate.

Here is how this “same-provider DNS-over-HTTP upgrade” approach works. Chrome maintains a list of DNS providers known to support DNS-over-HTTPS. Chrome uses this list to match the user’s current DNS service provider with that provider’s DNS-over-HTTPS service, if the provider offers one. By keeping the user’s chosen provider, we can preserve any extra services offered by the DNS service provider, such as family-safe filtering, and therefore avoid breaking user expectations. Furthermore, if there’s any hiccup with the DNS-over-HTTPS connection, Chrome will fall back to the regular DNS service of the user’s current provider by default, in order to avoid any disruption, while periodically retrying to secure the DNS communication. Finally, to avoid an issue that otherwise could arise for users running Windows, Chrome will also disable Secure DNS if Windows parental controls are enabled, so that any filtering software that relies on a regular DNS connection can continue to work while we collaborate with the ecosystem on ways for Secure DNS to co-exist with these filtering solutions.

If you are an IT administrator, Chrome will disable Secure DNS if it detects a managed environment via the presence of one or more enterprise policies. We’ve also added new DNS-over-HTTPS enterprise policies to allow for a managed configuration of Secure DNS and encourage IT administrators to look into deploying DNS-over-HTTPS for their users.

We believe that our approach strikes a good balance between moving security & privacy forward and maintaining user expectations. However, if this default behavior doesn’t suit your needs, head over to Chrome’s settings and search for Secure DNS to configure it to your liking. For instance, you can disable the feature altogether, or configure it in a no-fallback mode by choosing a specific DNS-over-HTTPS service provider among a list of popular options or by specifying a custom provider.

As ISPs and DNS service providers make progress on their DNS-over-HTTPS services, we expect to support more options in future milestones via our DNS-over-HTTPS program.

Chrome’s Secure DNS will progressively be made available on Chrome OS, Windows and Mac OS with Android and Linux coming soon.

Onwards

While these are early days, we are proud of playing a role in the adoption of DNS-over-HTTPS and helping our users benefit from a safer and more private way of browsing the web. At the same time, we also understand how intricate DNS is, which is why we’ve been and will continue to move carefully and transparently. As always, we’re open to feedback and welcome collaboration with stakeholders including ISPs, DNS service providers, and Online Child Safety advocates as we make further progress in securing DNS.

Posted by Kenji Baheux, Chrome Product Manager

Videos with fewer intrusive ads

Wednesday, February 5, 2020

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 YouTube.com, 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

Moving Forward from Chrome Apps

Wednesday, January 15, 2020

Note: The timeline has been updated, please see our August 2020 post for more details. 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:

March 2020: Chrome Web Store will stop accepting new Chrome Apps. Developers will be able to update existing Chrome Apps through June 2022.

June 2020: End support for Chrome Apps on Windows, Mac, and Linux. Customers who have Chrome Enterprise and Chrome Education Upgrade will have access to a policy to extend support through December 2020.

December 2020: End support for Chrome Apps on Windows, Mac, and Linux.

June 2021: End support for NaCl, PNaCl, and PPAPI APIs.

June 2021: End support for Chrome Apps on Chrome OS. Customers who have Chrome Enterprise and Chrome Education Upgrade will have access to a policy to extend support through June 2022.

June 2022: End support for Chrome Apps on Chrome OS for all customers.

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

Tuesday, January 14, 2020

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

Tuesday, January 7, 2020

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

Chromium Blog