Google protecting users from insecure downloads in Google Chrome

Get the PDF Version

Description

The other day Google announced a plan to begin blocking mixed content downloads in the Google Chrome browser to protect users from insecure downloads.  This effort began in September and will continue through the next several Chrome browser update releases.  The phased rollout plan begins with browser warnings and then advances to blocking the mixed content.

What’s impacted?

This may affect your end users’ ability to access non-HTTPS downloads or images started on secure pages.

Images

If a user is viewing a secure webpage (HTTPS), and if any of the content displayed as part of the webpage is hosted on a non-secure link (HTTP), then the content (for example, image or video) will be displayed as a broken image.

Downloads

If a user is viewing a secure webpage (HTTPS), if there is a download link or attachment in the webpage, and if the corresponding content is hosted on a non-secure site (HTTP or FTP only), then clicking on the link will result in error.

What action can customers take?

To avoid mixed content, broken images or failed downloads, you can choose not to upgrade at this time or rollback to a previous version of Google Chrome. 

Why is Google making this change?

Insecure downloads are a risk to user’s security and privacy. For instance, insecure downloads can be swapped out for malware by attackers, and eavesdroppers can read users’ insecurely-downloaded bank statements. To address these risks, Google plans to eventually remove support for insecure downloads in Chrome. Google has announced that Chrome will gradually ensure that secure (HTTPS) pages only download secure files. In a series of steps outlined in the timeline section, Chrome will start blocking mixed content downloads (non-HTTPS downloads started on secure pages). This move follows a plan Google announced last year to start blocking all insecure sub-resources on secure pages.  As a first step, Google is focusing on insecure downloads started on secure pages. These cases are especially concerning because Chrome currently gives no indication to the user that their privacy and security are at risk.

How can I get more information?

Read the Google Chrome blog for detailed information from Google and their expected timeline.  You can also reach out to our team by clicking the button below to schedule a call to discuss the impact this may have on your business.

Schedule a call

Resolution FAQs

What is mixed content?

Web pages are rendered by browsers based on two protocols – HTTP and HTTPS. A website that follows the HTTPS protocol is far safer than one that uses HTTP. HTTPS-enabled sites are encrypted, thus ensuring authentication, data integrity, secrecy. However, there are websites that load both HTTPS and HTTP content on the same page and this is called Mixed Content. Most sites that face mixed content issues have external resources such as images, videos, stylesheets, scripts loaded via the HTTP domain. Even though the initial request is sent as HTTPS, once the mixed content is rendered in the Google Chrome browser, it shows the site as insecure as there are chances that the HTTP resources may harm the users.

What is the timeline for the change?

The planned Google Chrome rollout begins with a browser warning and then advances to blocking mixed content downloads.  Here is the Google Chrome rollout schedule for your reference.

Type of Content

File examples

Browser Warning

Blocking

Executables

exe, apk

Chrome 84 (Aug)

Chrome 85 (Sep)

Archives

zip, iso

Chrome 85 (Sep)

Chrome 86 (Oct)

Documents

pdf, docx

Chrome 86 (Oct)

Chrome 87 (Nov)

Multimedia

png, mp3

Chrome 87 (Nov)

Chrome 89 (Jan ’21)

What’s NOT impacted?

1. HTTP only sites/URLs

The impact seems to be specific to a non-secure content display in a secure page, in other words, say if there a HTTP only page which is displaying a HTTP only content then it may not fail.

2.  HTTP page loading

Most importantly, the change does not block loading a site on HTTP only or rendering an email in an email client with no TLS. So the pages on HTTP only (no HTTPS) will still continue to work.