My website is not secure, but is that a bad thing?

Google has been flexing its muscles recently when it comes to user security, with a series of updates to its Chrome browser that have been sparking some discussion in the web development community. Lead Developer, Steven Knibbs, talks about what these updates mean for website owners and users.

Going back to late 2016, the internet giant posted a security blog article outlining its quest to mark all HTTP pages in Chrome as ‘not secure’. This is in an effort to encourage websites to use secure connections, or HTTPS, and thus making it increasingly difficult for user data to be taken.

Secure pages are not new: take a trip to Amazon or your banking website and you’ll find the padlock symbol in your address bar. This indicates that the connection between your computer and the server is encrypted, making your data safe from being intercepted during transit.

According to Mozilla (the company behind the Firefox browser) and Google, studies have shown that network traffic via secure connections to their browsers now accounts for 50%, and this number is rising.

While Google was making noise about making the web more secure as far back as 2010, it has decided now is the time to put these words into tangible action.

Its quest started with the release of Chrome 56 in January 2017, which shows a ‘not secure’ warning in the address bar on HTTP pages that collect password or credit card details. Recently, Google stated that an October 2017 update of the market-leading browser would extend the warning to include HTTP pages viewed in Incognito mode and all HTTP pages asking for any user data, not just passwords and credit cards. Firefox is also taking a similar approach.

It’s a bold move to implement what is, in effect, a ‘name and shame’ campaign to make companies more accountable to the end-user. Personally, I believe this is the right direction to go in: securing a site with an HTTPS connection is a relatively cheap and painless process these days, something that has been a roadblock for some in the past.

The approach Google has taken also demonstrates its understanding of the internet landscape we’re in right now. It could have introduced an update that forces secure connections overnight, which probably would’ve been greeted with cries of mercy from developers like myself.

Instead, it has isolated the most sensitive user data and applied the updates in incremental steps. For an agency managing a large catalogue of websites, all varying in size and complexity, it allows us to roll out the security update in a methodical way with little disruption. We can then identify the websites where users could react most negatively if presented with non-secure pages.

This actually brings me to an important point that needs to be cleared up.

I’ve read articles about the upcoming update that say the warning will be shown across the entire site. While it is Google’s eventual goal to have HTTPS on all website pages, that isn’t how the upcoming update will work.

The warnings will only apply on affected pages, not every page across the entire website.

So should website owners and users be concerned when presented with a ‘not secure’ warning? It depends.

Pages asking for credit card details without a secure connection are definitely a no-no – it could be costly. On the other hand, performing a search or filtering a list may not expose data deemed personal to a user. There are also other methods available besides HTTPS that can encrypt data before it’s sent that may still register the ‘not secure’ warning.

Take ZDNet – a well-established technology news and reviews website. The majority of the site is unencrypted, including the search, yet if you go to sign up for a newsletter, the connection is encrypted. This, to me, is an understandable balance that protects sensitive user data yet doesn’t require extensive updates to make the entire site secure.

With the massive back-catalogue of articles it has, I wouldn’t want to be the poor soul sifting through them looking for non-secure references!