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


Labels: , ,


Posted by Ryan Dickson, Chris Clements, Emily Stark from Chrome Security
Labels: , ,

When a browser connects to websites over HTTPS (vs. HTTP), eavesdroppers and attackers on the network can't intercept or alter the data that's shared over that connection (including personal info, or even the page itself). This level of privacy and security is vital for the web ecosystem, so Chrome continues to invest in making HTTPS more widely supported.

Thankfully, HTTPS adoption has come a long way in recent years, and most operating systems now see 90%+ of page loads over HTTPS in Chrome. Still, there's more we can do to help make HTTPS the preferred protocol on the web, and better protect users on the remaining slice of the web that doesn’t yet support HTTPS, so today we're sharing some future work in this area.



Opting in to an HTTPS-First World


Beginning in M94, Chrome will offer HTTPS-First Mode, which will attempt to upgrade all page loads to HTTPS and display a full-page warning before loading sites that don’t support it. Users who enable this mode gain confidence that Chrome is connecting them to sites over HTTPS whenever possible, and that they will see a warning before connecting to sites over HTTP. Based on ecosystem feedback, we’ll explore making HTTPS-First mode the default for all users in the future. Mozilla has also shared their intent to make HTTPS-only mode the future of web browsing in Firefox.



Experimenting with the lock icon

As we approach an HTTPS-first future, we're also re-examining the lock icon that browsers typically show when a site loads over HTTPS. In particular, our research indicates that users often associate this icon with a site being trustworthy, when in fact it's only the connection that's secure. In a recent study, we found that only 11% of participants could correctly identify the meaning of the lock icon. To try and reduce this confusion, Chrome will run an experiment in M93 that replaces the lock in the address bar with a more neutral entry point to Page Info (example below). We hope that this experiment will improve the discoverability of critical privacy and security information and controls provided in Page Info, such as site permissions. Importantly, a "Not Secure" indicator will continue to show on sites without HTTPS support, and the experiment includes an enterprise policy in case organizations want to opt-out. In all cases, we'll provide advance notice if we decide to move ahead with a full launch.





Protecting users on the HTTP web


While we are excited to see users adopt HTTPS-First Mode in future versions of Chrome, HTTP connections will still continue to be supported and Chrome will take additional steps to protect and inform users whenever they are using insecure connections. Continuing from our past efforts to restrict new features to secure origins and deprecate powerful features on insecure origins, we’ll evaluate a broad set of web platform features to determine if they should be limited or restricted on HTTP webpages.

In order to focus on changes that provide the greatest security improvements to our users, we are relying on a set of guiding principles to prioritize our future work in this area:

  • Better inform users when making trust decisions about sites over insecure connections
  • Limit the ability for sites to opt out of security policies over insecure connections
  • Restrict how, and for how long, Chrome stores site content provided over insecure connections
A deeper explanation of how we plan to act on these principles, as well as an updated list of affected features will be maintained on the Chromium wiki and we are excited to announce more details later this year.

Posted by Shweta Panditrao, Devon O'Brien, Emily Stark, Google Chrome team


Labels: ,



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


We encourage developers to fully migrate forms on their site to HTTPS to protect their users. Developers with questions are welcome to email us at security-dev@chromium.org.


Posted by Shweta Panditrao, Chrome Security Team
Labels: , , ,