What happened to the lock icon?

What happened to the lock icon?

Speakers: Serena Chen, UX person on the Chrome security team, Google

Conference: BSides SF

YouTube: https://www.youtube.com/watch?v=XewZd2sqVMg

Overview

In a significant update rolled out in September 2023, Google Chrome removed the ubiquitous lock icon from its address bar, a symbol long associated with secure web connections. This talk, delivered by Serena Chen, a UX person on the Chrome security team, delves into the multifaceted reasons behind this seemingly minor yet profoundly symbolic change. Far from a mere aesthetic tweak, the removal of the lock icon represents the culmination of decades of effort to make the web fundamentally more secure, recalibrating user expectations, and addressing a critical misunderstanding about what the icon truly signified.

Chen meticulously unpacks the historical context of web security, the technical underpinnings of HTTPS, and extensive user research that revealed the lock icon was largely misinterpreted, fostering a false sense of security. The talk highlights how the icon, once a celebrated indicator of a rare secure connection, had devolved into a form of "security theater" as HTTPS became the default. By dissecting the evolution of web security and user perception, Chen makes a compelling case for why this removal was not just justified but necessary for a more accurate and effective communication of web security to the average user.

This article explores the journey from a web where secure connections were an anomaly to one where they are the expectation, and how browser UI must adapt to reflect this new reality. It examines the technical details, the research that drove the decision, and the broader implications for web security, user behavior, and the ongoing battle against online threats like phishing. Chen's presentation offers a rare glimpse into the complex interplay of technology, user experience, and human psychology that shapes the security landscape of the modern internet.

Background

▶ Watch: Chrome's lock icon redesign: What happened? (0:15)

The journey to understand the lock icon’s demise begins with the birth of HTTPS (Hypertext Transfer Protocol Secure) and its underlying protocols. In 1994, Netscape Navigator pioneered SSL (Secure Sockets Layer) version one, though it was never publicly released due to security flaws. Subsequent iterations, SSLv2 (1995) and SSLv3 (1996), eventually matured, with SSLv3 being standardized in the new millennium. Despite its invention, HTTPS remained a niche technology for nearly a decade; even in 2004, it was still considered a "web enthusiast type thing." Early versions of Internet Explorer even displayed warnings before connecting via HTTPS, a phenomenon Chen's colleague David Adrian humorously termed "the everything's okay alarm," highlighting the initial perception of HTTPS as unusual rather than the norm.

HTTPS guarantees three fundamental aspects of a web connection:

1. Authentication: It verifies that the website a user is interacting with is genuinely who it claims to be, preventing impersonation.
2. Encryption: It ensures that communications between the user's browser and the website are private and cannot be spied upon by third parties.
3. Data Integrity: It confirms that the messages exchanged have not been altered or tampered with during transit.

These guarantees are technically achieved through public key cryptography. This system assigns a unique public and private key pair to each entity. Messages can be easily encrypted using a public key, but can only be decrypted with the corresponding private key, making it virtually impossible for unauthorized parties to intercept and read communications. To establish a secure channel, the browser and server engage in a "diff exchange," publicly agreeing on parameters, then mixing these with their private keys to arrive at a shared secret.

The authentication aspect, proving a website's identity, proved to be the hardest part of the problem. On the web, this is managed by the Public Key Infrastructure (PKI). Websites are issued digital certificates by trusted Certificate Authorities (CAs). These CAs, in turn, are vouched for by higher authorities, forming a "chain of trust" that ultimately leads back to root certificates pre-installed in browsers and operating systems. This intricate system confirms that, for example, google.com is indeed the legitimate google.com. Crucially, Chen emphasizes that this entire framework, and by extension the lock icon it represented, guarantees only the security of the connection itself – not whether the website is trustworthy, will protect user data, or is free from malware or phishing attempts.

This critical distinction was the root of the problem. Chrome's own large-scale user study in 2021 revealed that while most people correctly associated the lock icon with "connection security," over half thought it meant "it's safe to enter your data," and almost half believed it signified that "the website was trustworthy in general." Alarmingly, only about 11% of participants correctly identified the actual, limited guarantees made by the lock icon, meaning over 89% overestimated its security implications. Prior research from 2019 similarly showed this overestimation of trustworthiness led to increased clickthrough rates on malicious sites. The danger was so pronounced that in June 2019, the FBI issued a public service announcement explicitly warning users not to trust a website solely based on the presence of a lock icon. The lock icon had become a "dangerous miscommunication."

The push for a more secure web gained significant momentum following Edward Snowden's revelations in 2013 about mass surveillance, which galvanized the tech industry to aggressively promote HTTPS. At this point, HTTPS traffic was still relatively rare, with Let's Encrypt telemetry indicating around 27% adoption. Google amplified this effort in May 2014 by announcing that HTTPS would be a factor in search rankings, and in November 2014, Let's Encrypt launched, providing free certificates and removing a significant barrier to HTTPS adoption. As HTTPS became more prevalent, Chrome's UI began to reflect this shift: insecure HTTP connections, once normal, received increasingly prominent warnings, while the HTTPS indicator, initially celebrated, became quieter as it normalized. This contextual evolution of UI design laid the groundwork for the eventual removal of the lock icon, hypothesizing that its utility as a special indicator had been outgrown.

Key Findings

▶ Watch: User study reveals lock icon misconceptions (6:07)

The central finding of the talk is that the lock icon, despite its historical importance, had become a detrimental piece of security theater. This term, originating from Bruce Schneier's critique of airport security, describes "performative security-flavored things that make you feel safe without actually making a difference to your safety." Chen cites examples like ineffective airport security (TSA failure rates of 80-95%), privacy-breaching "private" VPNs, and mandatory password rotations that lead to insecure practices. The lock icon, by falsely reassuring users about a website's overall trustworthiness, actively increased their susceptibility to sophisticated phishing attacks, where malicious sites could easily obtain a valid HTTPS certificate and display the comforting lock.

Chrome's extensive user studies provided quantitative evidence for this conclusion. The 2021 study revealed that a staggering 89% of users overestimated the security guarantees of the lock icon. They incorrectly believed it indicated data safety, general trustworthiness, or protection against malware, when in reality it only guaranteed the connection's authentication, encryption, and data integrity. This misinterpretation directly contributed to increased clickthrough rates on fraudulent websites, transforming a symbol of security into a vector for deception. The FBI's 2019 public service announcement served as an external validation of this pervasive problem.

To validate the safety of removing the icon, Chrome conducted a 1% experiment. The lock icon was replaced with a "security neutral drop-down icon" for 1% of Chrome users. The results were crucial: while users noticed the change and many clicked the new icon to investigate, there were no regressions observed on HTTPS pages or in form submissions over HTTPS. This demonstrated that removing the icon did not cause unnecessary panic or lead users away from secure connections. Simultaneously, hundreds of potential replacement icons were designed and evaluated, further cementing the decision to move to a neutral, informative indicator rather than another symbolic one.

Ultimately, the key finding is a clear differentiation between necessary reassurance and dangerous security theater. Necessary reassurance prevents users from opting for less safe alternatives (e.g., driving instead of flying after 9/11, leading to an estimated 2300 excess road deaths). Dangerous security theater, like the lock icon, actively leads people towards danger by creating a false sense of safety. By observing user behavior – the lack of negative impact when the lock was absent, and the increased vulnerability when it was present on phishing sites – Chrome concluded that the lock icon firmly belonged in the latter category. Its removal signifies a shift towards a web where HTTPS is the default, expected state, and insecure connections are the exception that warrants explicit warnings, making the web fundamentally safer by aligning user perception with technical reality.

Technical Deep Dive

▶ Watch: FBI warns against trusting the lock icon (7:40)

The technical foundation of the lock icon's meaning lies deep within the architecture of HTTPS and the Public Key Infrastructure (PKI). HTTPS, as previously discussed, ensures authentication, encryption, and data integrity. These are not trivial guarantees and rely on sophisticated cryptographic mechanisms.

At its core, encryption and data integrity are achieved through public key cryptography. This involves pairs of mathematically linked keys: a public key, which can be shared widely, and a private key, which must be kept secret. When a browser wants to establish a secure connection with a server, they engage in a key exchange protocol, often based on the Diffie-Hellman key exchange. Both parties publicly agree on certain parameters. Then, by combining these public parameters with their respective private keys and exchanging intermediate values, they can independently compute a shared secret key. This shared secret is never transmitted over the network, making it resistant to eavesdropping. This secret key is then used for symmetric encryption of the actual data exchanged between the browser and server, ensuring privacy and integrity.

The most challenging aspect, and where the lock icon's guarantees began and ended, is authentication. How does a user's browser verify that bank.com is truly bank.com and not a malicious imposter? This is the domain of PKI. Websites obtain digital certificates from trusted Certificate Authorities (CAs). These certificates contain the website's public key and are digitally signed by the CA. The browser comes pre-loaded with a set of trusted root CA certificates. When a browser connects to a website, it receives the website's certificate, then traces the chain of trust back to a root CA it implicitly trusts. If the chain is valid and the certificate hasn't expired or been revoked, the browser authenticates the server. This process confirms the server's identity and its public key, which is critical for establishing the secure, encrypted channel.

However, a crucial technical nuance, and the source of the lock icon's misinterpretation, is that a valid certificate and a secure HTTPS connection only attest to the identity of the server and the security of the communication channel. They say nothing about the server's intent, its business practices, or whether the content it serves is malicious. A phishing site, for instance, can easily obtain a legitimate (and often free, thanks to services like Let's Encrypt) HTTPS certificate for its malicious domain (e.g., paypal-secure-login.com). The lock icon would then appear, falsely reassuring users that the site was "trustworthy," despite its deceptive nature.

The evolution of browser security indicators reflects the changing landscape of web security. In the early days, when HTTPS was rare (e.g., ~27% page loads in 2013), the lock icon served as a positive indicator, celebrating a secure connection. As HTTPS adoption soared, largely driven by initiatives like Google's search ranking boost (2014) and Let's Encrypt's free certificates (2014), the UI strategy shifted. Insecure HTTP connections, once the norm, began to receive increasingly prominent "Not Secure" warnings. Conversely, the lock icon, representing what was becoming the default, gradually lost its significance as a special indicator. The current change formalizes this shift: a secure HTTPS connection is now the baseline expectation, and its indicator needs to be neutral, while insecure connections are the exception that requires explicit, loud warnings.

The new icon that replaced the lock is a neutral dropdown or settings-like icon. This design choice is not arbitrary; it maintains critical functionality. Clicking this icon still provides users with access to:

• Certificate details: For advanced users or security researchers, this allows inspection of the website's digital certificate, including issuer, validity period, and cryptographic details.
• Site-level permission controls: Users can easily manage permissions granted to the website, such as camera, microphone, or location access, offering a direct way to revoke trust for specific functionalities.

Looking ahead, Chrome continues to push the boundaries of web security. Upcoming changes include automatically upgrading HTTP connections to HTTPS by default, and eventually requiring explicit user consent for any insecure HTTP connection. Furthermore, Google is actively preparing the underlying systems for the era of quantum computing and quantum-resistant encryption. This involves significant "under the hood" work to support larger key sizes and new cryptographic primitives that can withstand potential attacks from future quantum computers, ensuring the integrity of the web's foundational PKI. The UI implications of quantum key exchange are yet to be determined, contingent on the actual risk posed when quantum computers become a practical threat to current encryption standards.

Demo / Proof of Concept

▶ Watch: Snowden revelations accelerate HTTPS adoption (8:10)

While Serena Chen's talk did not include a live technical demonstration or a traditional proof of concept, the presentation itself detailed a critical "1% experiment" conducted by the Chrome security team. This experiment served as a rigorous, data-driven validation of the decision to remove the lock icon, effectively acting as a scientific proof of concept for the UI change.

The experiment involved replacing the lock icon with a new, security-neutral drop-down icon for 1% of Chrome's vast user base. The primary objective was to observe user behavior and identify any unintended negative consequences, particularly regarding user perception of security and their interaction with HTTPS pages. The team closely monitored metrics such as:

• Click-through rates on the new icon: To understand if users noticed the change and were curious enough to investigate.
• Regressions on HTTPS page loads: To ensure that users were not deterred from visiting secure sites.
• Form submissions over HTTPS: To verify that the change did not negatively impact user confidence in submitting sensitive data on secure forms.

The findings from this large-scale experiment were instrumental. Users did indeed notice the change, and many clicked the new icon, indicating a level of awareness and engagement. Crucially, the experiment revealed no significant regressions on HTTPS pages or in form submissions. This lack of negative impact provided strong evidence that users did not "freak out" or perceive the web as unsafe due to the lock icon's absence. This empirical data, gathered from a real-world user base, was a cornerstone in convincing the Chrome team and the wider tech community that the removal was a safe and appropriate step.

In addition to the 1% experiment, the Chrome team undertook extensive design work, drawing "hundreds of potential replacement icons." This iterative design process, combined with the behavioral data from the experiment and the prior user studies on lock icon misinterpretation, formed the comprehensive evidence base that led to the final decision. The entire process, from initial hypothesis to large-scale testing and final implementation, exemplifies a data-informed approach to user experience and security design.

Defensive Implications

▶ Watch: Let's Encrypt removes a major HTTPS roadblock (9:15)

The removal of the lock icon carries significant implications for web defenders, requiring a shift in user education and security strategy. The primary defensive takeaway is the need to move beyond superficial indicators and educate users about the true nature of web security.

1. Rethink User Education on Trust: Defenders must actively dispel the myth that a lock icon (or any similar neutral indicator) signifies a website's overall trustworthiness, safety from malware, or ethical data handling. Instead, user education should focus on:

• Domain Name Verification: Emphasize meticulously checking the URL in the address bar for suspicious characters, misspellings (typosquatting), or unfamiliar domains, especially before entering credentials.
• Suspicious Content: Train users to identify red flags within the page content itself, such as poor grammar, unusual requests, or high-pressure tactics.
• Multi-Factor Authentication (MFA): Promote and enforce MFA as a critical layer of defense, as it significantly mitigates the risk of credential compromise even if a user falls victim to a phishing site.
• Strong, Unique Passwords: Reinforce the importance of using strong, unique passwords for every service, ideally managed by a reputable password manager.

1. Embrace HTTPS as the Baseline: For website administrators and developers, the message is clear: HTTPS is no longer an optional "feature" but the absolute minimum standard for all web properties. Ensure that all sites are served over HTTPS, with proper certificate configuration, and eliminate any mixed content warnings. Chrome's future plans for automatic HTTPS upgrades and explicit HTTP consent further underscore this necessity. This baseline security should be seen as foundational, not a differentiator.

1. Beware of Security Theater: The concept of "security theater" should prompt defenders to critically evaluate their own security practices. Are implemented controls genuinely enhancing safety, or merely providing a false sense of reassurance? Prioritize measures with demonstrable impact on reducing risk over those that only feel secure. This includes avoiding arbitrary password rotation policies that often lead to weaker passwords and focusing on robust incident response and monitoring.

1. Leverage New UI Elements: While the lock icon is gone, the new neutral icon still provides access to important information. Defenders can educate advanced users or IT support staff on how to access certificate details and site-level permission controls via this new icon. This empowers users to make more informed decisions about specific site permissions (e.g., camera, microphone access).

1. Stay Informed on Browser Security: Browser UI and underlying security mechanisms are constantly evolving. Defenders need to stay updated on changes from major browser vendors like Google Chrome, Mozilla Firefox, and Microsoft Edge. This includes understanding new warning indicators for insecure connections, upcoming cryptographic standards (e.g., quantum-resistant encryption), and privacy-enhancing features.

In essence, the removal of the lock icon represents a maturity in web security. It shifts the burden of explicit "secure" indication from the browser UI to the implicit expectation of a secure connection, while simultaneously placing a greater emphasis on user vigilance and education regarding the multifaceted nature of online trust. Defenders must adapt their strategies to this new reality, focusing on comprehensive security awareness and robust technical implementations.

Key Takeaways

• The lock icon was removed by Chrome because it was widely misunderstood by users, leading to a false sense of security and contributing to security theater.
• User studies revealed that over 89% of participants overestimated the lock icon's security guarantees, believing it signified overall trustworthiness or data safety, rather than just connection security.
• This misinterpretation was actively dangerous, making users more susceptible to phishing attacks from malicious sites that could easily obtain valid HTTPS certificates.
• HTTPS is now the default and expected state for web connections, making the lock icon's role as a celebratory indicator obsolete. Insecure HTTP connections are now the exception that receives explicit "Not Secure" warnings.
• Ecosystem-level security changes, like the decade-long push for HTTPS Everywhere, require unrelenting persistence and collaboration across hundreds of people and organizations.
• Defenders must shift user education from relying on simple visual cues like the lock icon to teaching comprehensive security practices, including domain verification, identifying suspicious content, and utilizing multi-factor authentication. The new neutral icon still provides access to critical certificate details and site-level permission controls.

About the Speaker(s)

Serena Chen is a UX person on the Chrome security team at Google. In this role, she combines her expertise in user experience design with a deep understanding of web security, working to make the internet a safer and more intuitive place for users. Her involvement in the decade-long initiative to promote "HTTPS Everywhere" spans the last three to four crucial years, during which she played a significant role in shaping how Chrome communicates security to its users. Chen's work on the Chrome team reflects a commitment to tackling large-scale, complex problems, and she often shares a philosophical perspective on the power of collective, persistent effort to effect monumental change, likening it to "moving mountains."