HTTPS or Bust: Google Continues Squeezing Out the Unencrypted Web

Screenshot of a Google Chrome Mixed Content warning

Google is ramping up its march toward Always-On Encryption.

It started back in 2014, when Google made website encryption a ranking factor in its search algorithms. Search results began favoring sites that operate on Hypertext Transfer Protocol Secure (HTTPS) instead of the familiar but growingly obsolete HTTP.

Google has taken several more steps toward always-on HTTPS since then, including in 2018 when Google’s Chrome browser started providing warnings to web users who visited unencrypted pages. Site visitors at the time could simply pass through the warning. But the warnings still didn’t reflect well on the site owners, especially for ecommerce sites where visitors were being encouraged to part with payment card data and other potentially sensitive information.

Now each of the next six Google Chrome updates is scheduled to reign in HTTP even further as Google continues to squeeze out the unencrypted web.

Google’s 'Mixed Content Downloads' Roadmap

Google will start with warnings in April, and ramp up to outright blocking in a roadmap that is likely to be completed in October.

It starts with Chrome 82, which is scheduled for release in April 2020, and ends with Chrome 86, which is expected in October 2020.

The change affects "mixed content downloads.” Beginning soon, the Chrome browser will block insecure page elements from loading on pages that are otherwise secure. For example, if an HTTPS web page contains a photo or video resides at an old HTTP domain, then Google Chrome, as of Chrome 86, will block the photo or video.

Google is starting with warnings then ramping up to outright blocking in a roadmap that looks like this:

Chart and timeline of Google's planned changes to Chrome

The Scope

The audience of potentially affected users is too large to ignore.

We don’t need to tell you that Google-friendliness is typically good for business. But Google’s reach is worth a bit of underscoring each time it makes a significant change, which is often.

Chrome accounts for almost two-thirds of all browser usage, which means that roughly 2 out of 3 web users won’t see certain elements on your webpage if the elements aren’t secure or made secure. That may or may not be a big deal depending on how important the element is, but clearly it’s best to make the elements secure.

It's also not rare for other browsers to follow suit once Google makes a change, so that audience of potentially affected users is likely to grow. It’s too large an audience to ignore.

What Could Go Wrong

It’s hard to know all of the implications of mixed content download changes until the changes are implemented, but here are a few issues we could envision for ecommerce sites.

  • Images and specifically product images are stored at a legacy HTTP location. Every image lives at a URL (go ahead and right click an image on the web, open it in a new tab, and you’ll see the URL in the URL bar). If that URL is HTTP, the image won’t be shown on Chrome 86 and later, even on a page that’s HTTPS.
  • Images or other content are referenced via absolute URL that contains HTTP. Images and other elements show up on a web page when the code says "go find the image or element at this URL.” If the code says go find the image at http://site.com/image.jpg instead of https://site.com/image.jpg, it might be blocked, even if site.com has since been converted to HTTPS.
  • A Cascading Style Sheet (CSS), which is more website code, might reference HTTP elements, especially on old sites. Those would become blocked.

We would not anticipate that the updates will break payment card processing. Every payment card processor by now should have long been operating on HTTPS. On the slim chance it turns out that the processor was actually using HTTP this whole time and therefore gets blocked -- that’s probably for the best. You didn’t want to be using insecure payment processing, anyway.

This is not an exhaustive accounting, but it illustrates some of the ways problems may arise. Google does a nice job putting the changes and their reasons in plain terms, and then takes a deep dive into some code to provide examples of issues that may arise.

What Am I Supposed to Do?

Google's push for HTTPS will continue. It's time to migrate to HTTPS.

The advice we provided in 2018 when Google began issuing insecure web page warnings still applies:

"The first step to Always-On Encryption is to obtain a security certificate. The certificate is essentially a long, unique password that verifies that the website is the website that it claims to be, so that Google and others can verify that it’s safe.

"A number of companies issue security certificates. (Essent SiteBuilder customers who need a security certificate can contact Essent for specific instructions.)

"The next step after obtaining the certificate is to configure the website for Always-On Encyrption – to use the HTTPS protocol at all times by default. (In Essent SiteBuilder, this is accomplished through simple settings.)”

The above steps mostly assure that your pages are secure, and that the elements stored on your site’s domain are secure. Google also provides advice on migrating to HTTPS.

The mixed content update adds another layer: ensuring that page elements aren’t stored at insecure locations. The presence of insecure elements will occur on a case-by-case basis and, if your site is HTTPS, these instances will likely be when a page element is provided by a third-party. When a warned or blocked element is found, inspect where it is stored (its URL) and contact the provider.