Continuing to drop flame retardant on the dumpster fire that is web security, Google on Thursday said it will soon prevent Chrome users from downloading files over insecure, plain old, unencrypted HTTP.
“All insecure downloads are bad for privacy and security,” declared Joe DeBlasio, who works on the Chrome security team, in a Twitter thread. “An eavesdropper can see what a user is downloading, or an active attacker can swap the download for a malicious one.”
“We hope to stop all unsafe downloads, but Chrome doesn’t currently tell users on HTTPS pages that their downloads are insecure. That’s weird! Users expect that what they do on secure pages to be… well… secure! So we’re blocking these downloads first.”
Specifically, Google is going after mixed content, resources like files, images, and scripts that get loaded over insecure HTTP connections from a webpage that has been served over a secure HTTPS link.
Consistently insecure content – files served via HTTP from HTTP websites – are not affected by this change (users will still see the “Not Secure” omnibox badge in that case); only HTTPS sites will lose the ability to provide files via HTTP to Chrome users.
In April, 2020, when Chrome 82 arrives, Chrome users will see a warning when trying to download executable files (e.g. .exe, .apx) served via HTTP. In Chrome 83, due in June, users will be prevented from downloading such files at all. The warning notice meanwhile will shift to the attempted download of insecure archive files (e.g. .zip, .iso).
Come Chrome 84, in August, insecure executables and archives get blocked by default and other types of insecurely served files will prompt download warnings (e.g. .pdf, .docx).
And by Chrome 85, out in September, the mixed content warning will shift to images, audio, video, and text (e.g. .png, .mp3), with blocking becoming the default behavior for the other files. With Chrome 86, in October 2020, the warnings will be gone and Chrome will refuse to download any mixed content.
That’s the rollout schedule for Chrome for desktop operating systems (Linux, macOS, and Windows). For Android and iOS, the schedule will be delayed by one release cycle.
When Google initially discussed its plans to have Chrome intervene to save people from their disinterest in online security, the company said that “users will be able to enable a setting to opt out of mixed content blocking on particular websites.”
Google’s latest post on the subject however makes no mention of the general public: “Enterprise and education customers can disable blocking on a per-site basis via the existing InsecureContentAllowedForUrls policy by adding a pattern matching the page requesting the download.” The capabilities available to Chrome-using commoners are left unspecified.
But The Register understands that the Chrome-using hoi polloi will be allowed to override Google oversight. Mixed download blocking will be managed like other mixed content, so users will be able to click on the lock icon in the browser omnibox and then select Site Settings to change the setting for “Insecure content” to “Allow.”
Even so, it’s clear that Google expects some site breakage. Via Twitter, Mark Amery, a software developer at biotech startup Shield Diagnostics, expressed concern about the implications for web developers.
“Warning is good, but blocking outright seems wrong to me, especially for non-executables,” he wrote. “I can’t magic HTTPS into existence on a site I don’t own if I’d like to link to a data file it hosts, so this effectively means I just can’t hyperlink to such a resource at all.”
DeBlasio acknowledged that web developers will need to fix their sites, even as he admitted that warning prompts don’t do much because most people just ignore them.
“Our hope is that as more of the web moves to HTTPS, this won’t be a huge problem,” he replied. “That said, a huge and important part of the web is essentially static content that’s never going to be updated. We don’t want that content to be lost. This is something that we’re thinking hard about and trying to solve. Stay tuned.”