New browser feature will enforce connections over the encrypted web protocol

Google to bolster Chrome privacy protections with HTTPS-First Mode

UPDATED Chrome 94 will ship with a new feature, HTTPS-First Mode, that attempts to upgrade all web page connections to HTTPS, Google has announced.

If the site in question does not support the encrypted protocol, the browser will display a full-page warning to users, informing them that their connection will be insecure before loading the page.

Catch up on the latest browser security news and analysis

Users will have to activate HTTPS-First Mode themselves if they want the function enabled, but Google said it is considering switching the service on by default in future releases, depending on user feedback.

Mozilla introduced a similar function – HTTPS-Only Mode – for Firefox in November 2020.

Phasing out HTTP

HTTPS applies TLS encryption over the HTTP protocol in order to protect data shared via the connection from interception by eavesdroppers.

Although 95% of traffic across Google is now encrypted by HTTPS – up from 50% at the start of 2014 – Google said in a blog post that “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”.

Chart: HTTPS-encrypted connections as share of Google traffic 2014-2021HTTPS-encrypted connections now account for 95% of Google traffic, up from 50% in 2014 (Image: Google)

Chrome’s address bar already uses https:// by default for most typed navigations that don’t specify a protocol. This change has been in place since Chrome 90.

Google said it would continue to evaluate whether “powerful features” should be restricted or limited to secure origins such as HTTPS.

The introduction of HTTPS-First Mode was welcomed by Alexis Hancock, director of engineering on the Certbot team at The Electronic Frontier Foundation (EFF). The EFF, a pro-privacy nonprofit, co-developed the HTTPS Everywhere browser extension, which performs a similar function to the new Chrome feature, with the Tor Project.

“We are very excited to see HTTPS-First mode in Chrome,” Hancock told The Daily Swig. “Considering their lion’s share of browser adoption, this will give many users a default to utilize without any extra effort.

HTTPS Everywhere stood in that gap for 10 years and we are more than glad to see this feature come to fruition in all major browsers.”

Padlock icon under threat

Google is also running an experiment in Chrome 93 whereby the padlock icon displayed in the address bar to indicate a HTTPS connection will be replaced “with a more neutral entry point to Page Info”.

Organizations will be able to opt out of the experiment, and a ‘Not Secure’ indicator will continue to be displayed on sites that don’t support HTTPS.

RELATED Google abandons plans to simplify URLs in Chrome following real-world testing

Explaining the move, the tech giant points to a recent Google survey in which just 11% of respondents correctly identified what the lock icon represents.

“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,” said the Chrome development team.

“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.”

Guiding principles

Documented in a Chromium wiki, Google says its plans in this area will be guided by three security-focused principles.

These include better informing users of trust-related changes around insecure web connections, limiting sites’ ability to opt out of security policies related to insecure connections, and restricting how, and for how long, Chrome stores site content conveyed over insecure connections.

Google said more details will be announced later this year.

This article was updated with comment from the Electronic Frontier Foundation on July 15.

DON’T FORGET TO READ Firefox becomes latest browser to support Fetch Metadata request headers