Editor’s note: based on industry research (from Chrome and others), and the ubiquity of HTTPS, we will be replacing the lock icon in Chrome’s address bar with a new “tune” icon – both to emphasize that security should be the default state, and to make site settings more accessible. Read on to learn about this multi-year journey.

Browsers have shown a lock icon when a site loads over HTTPS since the early versions of Netscape in the 1990s. For the last decade, Chrome participated in a major initiative to increase HTTPS adoption on the web, and to help make the web secure by default. As late as 2013, only 14% of the Alexa Top 1M sites supported HTTPS. Today, however, HTTPS has become the norm and over 95% of page loads in Chrome on Windows are over a secure channel using HTTPS. This is great news for the ecosystem; it also creates an opportunity to re-evaluate how we signal security protections in the browser. In particular, the lock icon.

The lock icon is meant to indicate that the network connection is a secure channel between the browser and site and that the network connection cannot be tampered with or eavesdropped on by third parties, but it’s a remnant of an era where HTTPS was uncommon. HTTPS was originally so rare that at one point, Internet Explorer popped up an alert to users to notify them that the connection was secured by HTTPS, reminiscent of the “Everything’s Okay” alarm from The Simpsons. When HTTPS was rare, the lock icon drew attention to the additional protections provided by HTTPS. Today, this is no longer true, and HTTPS is the norm, not the exception, and we've been evolving Chrome accordingly.

For example: we know that the lock icon does not indicate website trustworthiness. We redesigned the lock icon in 2016 after our research showed that many users misunderstood what the icon conveyed. Despite our best efforts, our research in 2021 showed that only 11% of study participants correctly understood the precise meaning of the lock icon. This misunderstanding is not harmless — nearly all phishing sites use HTTPS, and therefore also display the lock icon. Misunderstandings are so pervasive that many organizations, including the FBI, publish explicit guidance that the lock icon is not an indicator of website safety.

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.

• 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

In 2020, we announced we were in the early phases of establishing the Chrome Root Program and launching the Chrome Root Store. 

The Chrome Root Program ultimately determines which website certificates are trusted by default in Chrome, and enables more consistent and reliable website certificate validation across platforms. 

This post shares an update on our progress and how these changes help us better protect Chrome’s users.

Update (10/07/2020): Mixed form warnings were originally scheduled for Chrome 86, but will be delayed until Chrome 87.

Beginning in M86, Chrome will warn users when they try to complete forms on secure (HTTPS) pages that are submitted insecurely. These “mixed forms” (forms on HTTPS sites that do not submit on HTTPS) are a risk to users’ security and privacy. Information submitted on these forms can be visible to eavesdroppers, allowing malicious parties to read or change sensitive form data. 

Specifically, Chrome will be making the following changes to communicate the risks associated with mixed form submission:

• Autofill will be disabled on mixed forms.
  Note: On mixed forms with login and password prompts, Chrome’s password manager will continue to work. Chrome’s  password manager helps users input unique passwords, and it is safer to use unique passwords even on forms that are submitted insecurely, than to reuse passwords.

• When a user begins filling out a mixed form, they will see warning text alerting them that the form is not secure.

          

• If a user tries to submit a mixed form, they will see a full page warning alerting them of the potential risk and confirming if they’d like to submit anyway.

Before M86, mixed forms were only marked by removing the lock icon from the address bar. We saw that users found this experience unclear and it did not effectively communicate the risks associated with submitting data in insecure forms.