When shown Chrome UI in research studies, users would look at the padlock to evaluate the trustworthiness of a hypothetical ecommerce site. We showed the site controls to experiment participants. The overlaid heat-maps represent the click patterns of respondents who were asked to indicate any information which was perceived helpful in the scenario.
The lock icon is currently a helpful entry point into site controls in Chrome. In 2021, we shared that we were experimenting with replacing the lock icon in Chrome with a more security-neutral entry point to site controls. We continued to mark HTTP as insecure in the URL bar. Users in the experiment opened the site controls more, and they didn't express any confusion that can follow major UI changes.
Site controls currently accessible from the lock icon.
Based on these research results from ourselves and others, and the broader shift towards HTTPS, we will be replacing the lock icon in Chrome with a variant of the tune icon. We think the tune icon:
Does not imply "trustworthy"
Is more obviously clickable
Is commonly associated with settings or other controls
We plan to replace the lock icon with a variant of the tune icon, which is commonly used to indicate controls and settings.
Replacing the lock icon with a neutral indicator prevents the misunderstanding that the lock icon is associated with the trustworthiness of a page, and emphasizes that security should be the default state in Chrome. Our research has also shown that many users never understood that clicking the lock icon showed important information and controls. We think the new icon helps make permission controls and additional security information more accessible, while avoiding the misunderstandings that plague the lock icon.
The new icon is scheduled to launch in Chrome 117, which releases in early September 2023, as part of a general design refresh for desktop platforms. Chrome will continue to alert users when their connection is not secure. You can see the new tune icon now in Chrome Canary if you enable Chrome Refresh 2023 at chrome://flags#chrome-refresh-2023, but keep in mind this flag enables work that is still actively in-progress and under development, and does not represent a final product.
Same page controls, new icon. The lock continues to exist as a precisely scoped entry point to connection security information, but with a new top-level access point.
We’ll be replacing the lock icon on Android at the same time as the broader desktop change. On iOS, the lock icon is not tappable, so we will be removing it entirely. On all platforms, we will continue to mark plaintext HTTP as insecure.
As HTTPS has become the norm, replacing the lock icon has long been a goal both of Chrome and the broader security community. We’re excited that HTTPS adoption has grown so much over the years, and that we’re finally able to safely take this step, and continue to move towards a web that is secure-by-default.
- By David Adrian, Serena Chen, Joe DeBlasio, Emily Stark, and Emanuel von Zezschwitz, and the rest of Chrome Trusty Transport from the Chrome Security team
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.Builderhave 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
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.
Last week, my calendar was constantly alerting me to the fact that many of us would be gathering at Google I/O, and it definitely made me sad that we can’t be together in person right now! We have been so impressed with the role that web developers have played in these trying times, as they focus on the fundamentals, make sure critical information is available, that commerce can come online, and that we can work and educate from home. Kudos to you all.
We want to help.
So, we’re planning a three day digital event - web.dev LIVE - where web developers can come together, from the comfort of their homes to hear about the latest, most helpful updates to the platform, learn modern web techniques and to connect with other developers — including those who are pushing the community forward and have been on the front line with COVID related work.
The event will take place from June 30th toJuly 2nd and will include short three-hour content streams (in English) hosted onweb.dev/live.
Reaching you where you are. In your time zone.
Planning a completely digital event has been an interesting challenge. While we can’t bring everyone together physically, we can still bring great content straight to your couch, kitchen or hammock-in-the-backyard. A digital event also gives us the opportunity to break out of physical constraints. We are no longer limited by space for attendance, and anyone, literally anywhere in the world, can “join” us at the click of a button (Oh and we, as part of the web community, should be proud of making that happen. Everyday!)
To really make this a regionally inclusive event, we will “travel” to three different time zones so we can answer your questions real-time, in your active hours. Each day will have unique content so you’re welcome to join us on all three days or watch the content on demand later, but developers in any timezone will have the team actively answering questions at least once through the event.
With unencrypted DNS, an attacker connected to the same network can observe other users’ browsing habits.
Benefits of DNS-over-HTTPS
Chrome’s Secure DNS feature uses DNS-over-HTTPS to encrypt the DNS communication, thereby helping prevent attackers from observing what sites you visit or sending you to phishing websites. As the name suggests, Chrome communicates with the DNS service provider over the HTTPS protocol, the same protocol used for communicating with websites in a safe and secure manner. HTTPS is particularly appealing because it provides the following protections:
Authenticity: Chrome can verify that it is communicating with the intended DNS service provider and not a fake service provider that’s controlled by an attacker.
Integrity: Chrome can verify that the response it got from the DNS service provider hasn’t been tampered with by attackers using the same network, thereby stopping phishing attacks.
Confidentiality: Chrome can talk to the DNS service provider over an encrypted channel which means that attackers can no longer rely on DNS to observe which websites other users are visiting when sharing the same connection, e.g. public WiFi in a library.
With DNS-over-HTTPS, an attacker can no longer rely on DNS to observe other users’ browsing habits.
The introduction of DNS-over-HTTPS gives the whole ecosystem a rare opportunity to start from a clean and dependable slate, making it easier to pursue further enhancements relying on DNS as a delivery mechanism. Thus far, the unencrypted nature of DNS has meant that features that extend DNS could randomly fail due to causes such as network equipment that may drop or modify newly introduced DNS fields. As DNS-over-HTTPS grows, it will put this concern aside because it benefits from the aforementioned HTTPS properties and sets a new reliable baseline to build upon.
Responsibly deploying DNS-over-HTTPS
Changing how DNS works is a non-trivial task. In particular, with more than 35 years of history, a lot of additional services and features have been built on top of DNS. For instance, some Internet Service Providers offer family-safe filtering via DNS. So, while we would love to have everyone benefit from Secure DNS immediately, we also know that we have to get there in a way that doesn’t break user expectations. Navigating these goals led us to the “same-provider DNS-over-HTTPS upgrade” approach that we experimented with at the end of 2019. The successful experiment gave us confidence about the performance and stability aspects for both Chrome’s Secure DNS and our partners’ DNS-over-HTTPS services. It also highlighted opportunities to improve the auto-upgrade success rate.
Here is how this “same-provider DNS-over-HTTP upgrade” approach works. Chrome maintains a list of DNS providers known to support DNS-over-HTTPS. Chrome uses this list to match the user’s current DNS service provider with that provider’s DNS-over-HTTPS service, if the provider offers one. By keeping the user’s chosen provider, we can preserve any extra services offered by the DNS service provider, such as family-safe filtering, and therefore avoid breaking user expectations. Furthermore, if there’s any hiccup with the DNS-over-HTTPS connection, Chrome will fall back to the regular DNS service of the user’s current provider by default, in order to avoid any disruption, while periodically retrying to secure the DNS communication. Finally, to avoid an issue that otherwise could arise for users running Windows, Chrome will also disable Secure DNS if Windows parental controls are enabled, so that any filtering software that relies on a regular DNS connection can continue to work while we collaborate with the ecosystem on ways for Secure DNS to co-exist with these filtering solutions.
If you are an IT administrator, Chrome will disable Secure DNS if it detects a managed environment via the presence of one or more enterprise policies. We’ve also added new DNS-over-HTTPS enterprise policies to allow for a managed configuration of Secure DNS and encourage IT administrators to look into deploying DNS-over-HTTPS for their users.
We believe that our approach strikes a good balance between moving security & privacy forward and maintaining user expectations. However, if this default behavior doesn’t suit your needs, head over to Chrome’s settings and search for Secure DNS to configure it to your liking. For instance, you can disable the feature altogether, or configure it in a no-fallback mode by choosing a specific DNS-over-HTTPS service provider among a list of popular options or by specifying a custom provider.
As ISPs and DNS service providers make progress on their DNS-over-HTTPS services, we expect to support more options in future milestones via our DNS-over-HTTPS program.
Chrome’s Secure DNS will progressively be made available on Chrome OS, Windows and Mac OS with Android and Linux coming soon.
Onwards
While these are early days, we are proud of playing a role in the adoption of DNS-over-HTTPS and helping our users benefit from a safer and more private way of browsing the web. At the same time, we also understand how intricate DNS is, which is why we’ve been and will continue to move carefully and transparently. As always, we’re open to feedback and welcome collaboration with stakeholders including ISPs, DNS service providers, and Online Child Safety advocates as we make further progress in securing DNS.
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:
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 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.
