Lately, it seems as though Microsoft and Google have been competing for some sort of trophy for “weirdest experience-breaking update” to their signature products. Microsoft released two patches for Windows 10 on October 13th that were supposed to address known bugs, but instead caused a significant chunk of users to experience new problems like blue screen crashes and unresponsive File Explorer windows. Google, meanwhile, has baked a controversial feature into the latest version of Chrome that prevents users from downloading files. While the goal is to make their browser more secure, the implementation and rollout is odd.
A vast majority of the Internet uses HTTP—Hypertext Transfer Protocol—to transfer the data that our screens display as websites, as well as other information sent and received as we interact with those websites. HTTPS is a secure (hence the “S”) version of that protocol where data is encrypted before being transmitted. However, it generally makes pages less responsive and slower to load, and the added security isn’t always necessary. As a result, there are a great many pages on the Web that still use HTTP. The problem is that the latest version of Chrome bluntly blocks all downloads served via HTTP when the originating page uses HTTPS. In other words, if a secure page serves a non-secure download then Chrome will completely block it.
At first glance this may seem like a sound policy for security. However, as previously mentioned, the added security provided by HTTPS isn’t always necessary and, in some cases, just doesn’t make sense. Consider a payment processing page on a banking or e-commerce website—you’d probably want the extra layer of security because of the nature of the data being sent and received. But what about a PDF download of a standard privacy policy on that secure page? If it isn’t also (needlessly) served via HTTPS, Chrome will block it. That same theoretical issue applies to any similar scenario—any download link for a commonly available document on an otherwise necessarily secure page, for example.
Equally problematic is the lack of workarounds. Right now, Chrome users can right click on affected links and select “Save Link As”, which will initiate download. Should Google choose to patch that functionality out in future updates, the only other viable solution is to use a different browser for those specific downloads (or make the switch from Chrome entirely, which can be counterproductive if you live primarily in the Google ecosystem). It remains to be seen if extensions like EFF and the Tor Project’s “HTTPS Everywhere” alleviate the issue, but if they do then those sorts of utilities could potentially be another viable workaround—they just aren’t proven at this point.
Clearly, engineers and designers at Google have the right intent. Making the world’s most-used browser more secure will always be a worthwhile endeavor. But the implementation here seems odd, especially for professionals that should have a better understanding of how secure and nonsecure pages are intermingled on many websites. While the workarounds are easy right now, that could change in the future. Then again, so could Google’s attitude toward downloads served via HTTP on otherwise secure pages, at least in part.