Index Ask! Random

Question: Why can't they all be secure?

Why cant all connections be secure?

Susan

Answer

Hi Susan,

This is a great question, and the answer can be summarized with two words:

TIME and MONEY.

Before we get into TIME and MONEY, though, let's address this: You need to know first of all that for most websites, an HTTPS socket is not necessary. You see, that's only needed if visitors are going to be posting personal data like a credit card number, or similar protected information to the site. For example, when you sent me a question, you did it using your email software, and didn't even need to enter anything in my website. So security is not necessary here.

Okay, so let's talk about MONEY. In order to have a secure connection, website owners have to purchase a security certificate, which is not a large expense, but it's still an expense. So if they don't need it...why spend the money on it?

Second is the issue of TIME. You see, an encrypted connection is basically sending information to and from the site in code (which is what makes it secure). And guess what! The number of bytes required to send it in code is significantly more than the number of bytes required to send it unencoded. The result? It takes longer for you to download the page on your computer. Granted, this is less of an issue now than it was 15 years ago when the bulk of web users were on dial-up, but it's still an issue. Especially for sites that are graphics intensive, or have flash/java apps. If you visit my site The Problem Site, you will see that there are a lot of educational flash games on that site. I want those to download as quickly as possible, so visitors will get to play them immediately. A secure socket would get in the way of that.

So what does it boil down to for you? You need to pay close attention to whether a page has HTTP or HTTPS in the address, and make sure you're NEVER entering credit card/bank account information in a site that isn't secure.

Thanks for asking a great question!
Doug

Bookmark and Share