Skip to content
Under construction

Google’s Plan for a Secure Web

Published by Cory Underwood on February 10, 2020

While the sameSite cookie rollout is about to ramp up the week of February 17th, Google is not standing idle in suggesting enhancements to secure the web.

Next up on the list rolling out between Chrome versions 81 and 86 is a plan to address ‘Mixed-Content’ by eliminating insecure sub-resource downloads in an increasingly restrictive way. This is a win for security, as it creates a more secure environment when browsing the web. You can read Cloudflare’s article on the differences here.

So how are they doing this? Take a look at the following graph:

Source: Google

So here’s the rough timeline:

  • Chrome 81(March 17th): Warnings appear for all users in the developer console anytime the browser tries to download a file beginning with ‘http’ on a site prefixed with ‘https’.
  • Chrome 82 (April 28th): Executable files, which pose the greatest risk will prompt a warning for the user prior to being downloaded.
  • Chrome 83: Executables which were previously warned – will be blocked. Warnings will begin for archive files.
  • Chrome 84: Executables and Archives are blocked – warnings begin on other non-safe docs (PDFs, Word Files, etc).
  • Chrome 85: Everything above is blocked, and warnings start appearing for Images, and music files.
  • Chrome 86: All insecure resources in secure contexts will be blocked.

So what does this mean?

If your site is served over a secure connection via Transport Layer Security (HTTPS) then all the files loaded by that page should also be served over HTTPS. Chrome will increasingly block anything which is not served over HTTPS when the page itself is served over a secure context.

This means any tags, images, what have you, will eventually stop working if they are being served over HTTP with your site as HTTPS. This can affect site layout, functionality, analytics and more. Code that is blocked will not run – it’s terminated at the network level.

What can we do about it?

The major things you should do are:

  1. Determine if your site is served over Transport Layer Security (HTTPS).
  2. Determine if any of your page resources are served over HTTP.
  3. Work with development to upgrade the links to be called over HTTPS.
  4. Work with resource owners which have files that can’t be served over HTTPS. Suggest they enable TLS via a free certificate from Let’s Encrypt.
  5. Replace resources which can’t be served over HTTPS or accept they will not be served on Chrome going forward.

Note: If you are enabling HTTPS for the first time on your site, it’s worth a review of what Google Recommends from a SEO perspective. You’ll also want to look into a certificate management process.

Users can elect to over-ride the settings in Chrome – but it’s easier to upgrade your site so they never have to consider it and risk making the wrong choice.

Other Happenings

Also in the plan is Google’s desire to phase out the User Agent string that identifies browsers. However their suggestion to do this isn’t exactly going well. I consider it unlikely that it will be adopted in the near term given the level of pushback. However this would have a sizable impact to analytics, security, A/B test targeting and the like. It’ll be important to keep an eye on this to see if they make progress in swaying opinion or if they just decide to go forward with it on their own.

Published inBrowser UpdatesPrivacySecurity