Google Chrome Begins Stronger HTTPS Warnings

Chrome 68 shipped on July 24, 2018 with a single widely noticed change: every HTTP page displayed a “Not secure” label in the address bar’s security chip, to the left of the URL. Previously, Chrome and other browsers had used a positive indicator model — HTTPS pages showed a green padlock icon with or without the domain name, while HTTP pages showed nothing or a neutral icon, creating the impression that HTTP was a safe baseline rather than an actively insecure choice. Google had been phasing in the change across multiple Chrome releases: Chrome 56 (January 2017) first added the “Not secure” label on HTTP pages containing password or credit card input fields; Chrome 62 (October 2017) extended the label to all HTTP pages with any form input and all HTTP pages in Incognito mode; Chrome 68 expanded it to all HTTP pages unconditionally. Chrome 70 (October 2018) made the label red-colored when users began typing into any HTTP page, adding visual urgency at the moment of risk. Google had announced this incremental plan in September 2016 as part of its public commitment to treating HTTPS as the baseline security assumption for the web.

The practical precondition for this policy was Let’s Encrypt, which had entered public beta in December 2015 and issued its one billionth certificate in March 2020. Before free automated certificates, the operational and financial cost of obtaining and maintaining TLS certificates was a real barrier for small sites: commercial CAs charged $10–$100/year for domain-validated certificates, and manual renewal processes made certificate expiration a common operational failure mode. Let’s Encrypt’s ACME protocol and Certbot client automated the entire process — generating a private key, proving domain control, receiving a 90-day certificate, and configuring the web server — in a single command, at no cost. HTTP/2 also provided a performance incentive to adopt HTTPS: the HTTP/2 specification (RFC 7540, May 2015) theoretically allowed plaintext HTTP/2, but all major browsers implemented HTTP/2 exclusively over TLS, meaning that migrating to HTTPS also enabled multiplexed connections, header compression (HPACK), and server push without any additional configuration.

The Chrome 68 policy change produced measurable results. Google’s HTTPS Transparency Report showed that approximately 70% of Chrome page loads were over HTTPS in July 2018, up from roughly 55% in January 2017 and ~30% in early 2015. The “Not secure” label increased user-visible security indicators for HTTP sites, creating pressure from users (who saw unfamiliar warnings in their browsers) on webmasters who hadn’t upgraded. The HSTS (HTTP Strict Transport Security) preload list, maintained by Google and embedded in Chrome, Firefox, and Safari, allowed sites to declare they should always be accessed over HTTPS even if the user typed the HTTP URL — preventing SSL-stripping attacks where a network observer downgraded a site’s first-load response before the browser learned the HTTPS redirect. Several top-level domains (.gov, .edu, .bank) were submitted to the preload list, making HTTPS mandatory for all websites on those TLDs. Mozilla Firefox followed Chrome’s timeline with similar security indicators, and Safari added similar warnings in Safari 12 (September 2018 alongside macOS Mojave), completing the browser industry’s coordinated push toward treating HTTP as visibly insecure.