Why your podcast needs https

Modern browsers warn users when they attempt to send data over an unencrypted http connection. This seems to have been effective, and most dynamic websites today are served over https.

But what if you are setting up a simple static blog or podcast website? Is it worth bothering with https, or is it above your paranoia level?

There are several reasons to use https even for a simple static site: for instance, to prevent ad injection by ISPs. You can easily imagine something even more nefarious, such as an evil twin hotspot in a popular San Francisco coffee shop invisibly adding malicious code to snippets that patrons copy-paste from unsecured blogs.

Yesterday I was at the Euston station in London waiting for a train. There were advertisements for free WiFi all over the place, to which I gratefully connected. I had recently discovered a new podcast, and I queued several episodes to listen to during the 2.5 hour ride.

The episodes downloaded very quickly, but when I tried to listen to them, they would not play.

It turned out that the free WiFi at Euston isn’t free internet; it’s a local network where you can watch ads and read magazines. All traffic, including requests for the mp3 files from my podcatcher, were redirected to their captive portal.

If the links in the podcast’s RSS feed were https links, the program would probably refuse to download the files when presented with no or invalid TLS certificate. (To be fair, it could have also looked at the content type of the files, which was probably text/html.)

But instead, the program simply downloaded the webpage thinking it was an mp3 file. So I had to undo this later by figuring out which episodes were corrupted (some I had downloaded earlier, and they were valid) and how to trigger their re-downloading.

So if you have a podcast, configure https on your host and make all links (especially in the RSS feed) https links. If you don’t do that, some of your listeners may hear this instead of your voice.