This week Google announced an update plan which could affect your podcast. On Thursday, February 6, 2020, Joe DeBlasio (Chrome security team) made a post to the Google Security Blog which outlines scheduled security changes to the Chrome browser between Chrome 81 (March 2020) and Chrome 86 (October 2020) with the details.
What is changing?
The announcement is to do with how Google Chrome will handle downloading of insecure files on secure websites. In short, a secure website (one that uses https) will eventually prevent files from being downloaded from non-secure (non https) locations.
Why is this changing?
If you weren’t aware, over the past several years, there has been a very large push to make websites uses https. There has been many changes within the industry, such as the creation of Let’s Encrypt (a non-profit which helps deliver the security certificates for free, something that used to always cost money), browsers changing how non-secured websites are displayed (the padlock icon and related functionality), and even Apple Podcasts making announcements about using secure RSS feeds. The intent is to create a more secure experience, helping minimize the potential compromise between a user and the website due to being an insecure (non-https) website, or insecure elements within a secure website.
Although there has been changes to the way that websites have to be coded, up to this point it has been relatively status-quo as far as what happens if a user clicks on an insecure download from a secure website. According to DeBlasio’s post, this is a concern because “Insecurely-downloaded files are a risk to users’ security and privacy. For instance, insecurely-downloaded programs can be swapped out for malware by attackers, and eavesdroppers can read users’ insecurely-downloaded bank statements.”
How does this affect podcasters?
This has the potential to directly affect podcasters from the perspective of their websites. If you’re currently using a website that has https, you need to be sure that any download links to your podcast files are also on https (for example a download link to your episode file, but depending on the code, potentially play links as well). This is important whether you’re using a website on your media host, or one that you’ve created yourself. I think it’s fair to assume that if you’re using a reputable media host, and they are the ones that have created your website (or you’re using their embed plugin), they’re probably going to take care of this for you; they may already have code in place for this. This isn’t something that is happening immediately, and by Google’s own post – it will be a gradual roll out, starting initially with warnings.
In my opinion, the biggest consideration is the places where you may have your podcast file directly linked, without using a plugin from your media-host. For example, our website here (https://www.betterpodcasting.com) has all of our episodes listed available for download on our show page; all of those links have at some point been manually entered to our website. As such, we’ll need to make sure the links to our individual episode file links are all pointing to an https location instead of http.
What action should I take?
If you’re running a website independent of your media host where you’re using a third party plugin/service to link to your media file (such as how we are here on BetterPodcasting.com), it’s probably not a bad idea to help make sure those are referencing https URLs. If you have hundreds of episodes, this could take you awhile to get updated so you may want to think about starting sooner than later. However, before you make any changes, you need to ensure that the actual hosting location for your file is indeed secure, with a proper SSL certificate. The easiest way to do this is to copy the direct URL to one of your files, and enter it in to Chrome replacing http with https. Chrome should load the file within the browser, and then you should see the padlock icon shows as locked (secure). Additionally once you’ve loaded the file, clicking on the padlock should provide a message that says “Connection is secure.” If the message says insecure or the padlock appears with an error, then the actual hosting location may not offer https. But if you have been able to confirm that the file is able to be served through https, then you can update your links on your website. (I should note that there is an on-going discussion about whether people should change URLs to be “https://” or simply “//”. At this time I’m not prepared to provide a recommendation; however, I did feel it necessary to advise of this point of consideration.)
If you’re using a media-host generated website (or you’re using a plugin by your media-host), again, I think it’s a reasonable assumption that they’ll be taking care of this for you. However, with any change like this, it doesn’t hurt to reach out to them and inquire – after all there is the old adage “You know what happens when you assume?” Alternatively, if you’re more of a “wait and see” person, you could wait until Chrome 81 is released in March, then see if there is a “Console Warning” that appears. You can access the Console by using Control-Shift-J on Windows or Control-Option-J on Mac. If this is too techy for you, you could also wait until Chrome 85 in September 2020 where a warning will start appearing without needing to access the console. Of course, the latter option will give you a tight deadline before the files become blocked with Chrome 86 in October.
Self-hosters: it’s entirely up to you to take action since you likely control your website and the actual hosting location.
Below is a chart provided by Google for the release schedule for these changes; a special shout-out to my friend Sunkast for highlighting this change to me.
