New Update Chrome to block insecure HTTP downloads

[Ink]

Google Chrome is preparing to launch a security option that will block “insecure” downloads through HTTP.

Over the last few years, Google has been adding new protections to Chrome to help encourage the use of HTTPS connections wherever possible.

Most notably, the browser now marks any older HTTP website as “Not Secure” in the address bar. Chrome also, by default, blocks secure websites from using insecure web forms or offering insecure downloads. This combination of secure and insecure elements is called “mixed content.”

More recently, the company created a toggle in Chrome’s security settings to “Always use secure connections.” Enabling this tells Chrome to attempt to “upgrade” to the HTTPS version of websites, if you ever accidentally navigate to the insecure version. If a secure version isn’t available, an on-screen warning is shown, asking if you would like to continue.

According to a new code change and associated explainer, Google is looking to expand that toggle to also protect Chrome users from any and all potentially insecure HTTP downloads. This goes beyond the existing mixed content download protections by blocking downloads from any connection even associated with an insecure website.

Source: Google Chrome preparing an option to block insecure HTTP downloads

Date: Thu Dec 29 18:05:55 2022

Add support for insecure download blocking

This CL adds the implementation for insecure download blocking. When the
previously-added flag is enabled, it will show a warning for all
downloads that were not securely delivered. This warning must be
explicitly ignored before the download will complete.

Insecure downloads can be insecure because of:
* the initiating page being insecure,
* the final file URL being insecure, or
* any redirect along the way being insecure.

This implementation is designed to let mixed download blocking behavior
take precedence over insecure download blocking generally. That means
that any download that's a mixed download is still blocked silently.

That means that this implementation is slightly over-complicated for
now -- since mixed downloads trigger on the final URL being insecure or
any redirect along the way being insecure, the only time that insecure
download blocking could trigger is if the initiating page is insecure.
The logic below theoretically could capture all three cases, though,
since I plan to widdle away the mixed downloads code soon, and it felt
valuable to keep insecure download checking comprehensively defined.

Future CLs will add metrics and clean up a lot of old mixed download
stuff.

Credit: 1352598 - chromium - An open-source project to help move the web forward. - Monorail