Handling “non-secure” radio streams

Hello everybody.

Earlier today, we put out this tweet mentioning that non-secure radio streams would not play in the latest version of Google Chrome when used within Minnit Chat. I wanted to take a moment to explain what exactly that means, as we’ve gotten quite a few tickets and inquiries.

First, what is a “non-secure” radio stream? A “non-secure” radio stream is one that is served over a standard HTTP connection. This protocol is incredibly unsecure, and it is very easy for others on your network, your ISP, or even a government (not necessarily your government) to view exactly what you’re doing. Secure content (HTTPS) fixes this by encrypting all data. If you are on a website that has a lock icon, like Minnit Chat, then you are on a secure and encrypted connection. If you are on a website that has the text “Not Secure”, you are on a standard HTTP connection.

What did Google do to break the radios, and why did they do it? The latest update to Google Chrome prevents secure content, like Minnit Chat, from loading non-secure content, like a vast majority of the owners’ radio streams.

The main reason they did that is simple: If you are on a website that says “Secure”, you should trust that everything you do on that page is secure. Having a “secure page” that loads a ton of scripts, assets, and other content from non-secure sources is misleading to the end-user, and, in an increasingly dangerous online world, it is important for users to know what they can trust, and what they can not trust. Google is moving in that direction by saying “If the page is secure, then it is entirely secure”. This is a good move for user privacy and security, but it does come with the sad caveat of non-secure radio streams being prevented from being streamed via the secure chat.

Now, what are the options to get the radio working again? If you own the radio station, you can put it on a server that supports the encrypted HTTPS protocol and link that in your chat settings. If you don’t know how to do that, contact your web master or hosting provider and ask about how to upgrade your service to HTTPS and to ensure that it won’t break your existing radio stream setup. Alternatively, if you embed Minnit onto your website, and your website is “Not Secure”, and you want to get the radio working again, you can embed the radio stream directly. Minnit Chat uses the standard HTML5 audio tag to broadcast content. You can put this onto your website yourself by pasting this code snippet:

<audio controls><source src="YOUR_STREAM_URL_HERE" type="audio/ogg"><source src="YOUR_STREAM_URL_HERE" type="audio/mpeg"></audio>

You can put this directly above, or below, your chat’s embed code, and a separate player will appear directly on your website. This, like our chat’s player, requires no plugins, and works great on every modern device.

Is there anything Minnit could do to fix this issue? As this is a policy that is in place by Google Chrome, and likely will be adopted by other browsers in the coming months, there is nothing we can do. The only possible option on the table is for Minnit to abandon the secure, encrypted HTTPS standard and revert back to the non-secure HTTP version, but we will never do that. That will put you, and your users, at risk of having your data viewed and your accounts at risk of being compromised. I have personally been interested in security exploits on websites since I was 11 years old, and so every single decision I make with Minnit is made with security in mind. I know that making Minnit Chat unsecure just for the radio to work is not a trade-off that owners want, and certainly not one I want.

Hopefully all of this is clear. If you have any more questions, feel free to contact Support and ask for me directly, and I will be more than happy to answer any questions you may have.

Have a great weekend, and happy chatting!

Jesse

Exit mobile version