Not just user privacy: HTTPS is also for website owners

Many people think implementing HTTPS on a website is solely for the privacy of the site's users. Although privacy is an important benefit of using HTTPS, it's not the only one. Putting aside this very important topic, today I'll show you the benefits of HTTPS from the perspective of the website owner.

Before we dig in, Wikipedia has a good refresher on HTTPS.

HTTPS buys a website three things:

  • User privacy: but that's not what we're discussing
  • Data integrity: my favorite benefit as a website publisher
  • Authentication: a means to build trust

Data integrity means no content modification

Data integrity assures a website publisher that users are consuming the content as it was published. That is, users get to consume the content without fear someone changed it.

Data integrity assures a website publisher that users are consuming the content as it was published. That is, users get to consume the content without fear someone changed it.

What am I talking about? How many times have you logged into a hotel's (or some other public) WiFi and noticed an ad that wasn't meant to be there? I've personally experienced this, and it's common enough that the New York Times talked about it in 2012. Also, a user's ISP could inject ads into your website, just like what happened to And this is not a new problem! Back in 2008, University of Washington researchers found that 1% of 50,000 visitors received pages that had been changed "in-flight". To be sure, a lot of these modifications were client-side (such as ad blockers), but not always.

Why is this even possible? Simply because HTTP connections transfer plain text over the wire. Anyone can read it (just like anyone can read a postcard) and modify what it says (easier done digitally than with postcards). Public WiFi access points and ISPs are well-placed to do so as they're the last hop before the content reaches the browser.

The only way to preserve the integrity of your pages as a publisher is to use HTTPS. Because you're encrypting the connection, you're ensuring no one can read and modify the content before it reaches your users.

Authentication and trust

Authentication answers a simple question of trust: Am I really talking to the website I wanted to talk to? To rephrase for you reading this page right now, how can you be sure you're really accessing Your browser tells you by changing the address bar to make it clear that is the case, usually by displaying a green padlock. In Chrome, if you click on the green padlock in the address bar, you'd see something like this:

How does this work? One of the requirements for a valid HTTPS connection is that the TLS certificate correctly identifies the server to which a client (the user's browser) is connecting. Because of this, the user can be sure that they're consuming the content from the server they intended to reach, not an impostor.

This is one of the (many) reasons banking websites should have correctly-configured HTTPS servers: I really want to be sure I'm talking to my bank's real website. Similarly, trust is needed for other sites that may not immediately think they need authentication:

  • Financial advice sites: I want to be sure the advice comes from the service I trusted enough to seek its help.
  • Medical sites: I want to be sure I'm talking to the real Mayo Clinic or the UK's NHS online services.
  • News sites: Is it really, say, the AP's website reporting the surprising details of a major story, or someone maliciously changing the report by hijacking the connection?

This, in my view, helps build user trust in your site's contents because they are certain it's you who's serving the content they're consuming.

Your CMS passwords

Have you ever logged into your website's content management system (like Wordpress or Drupal or whatever) without using HTTPS? Come on, be honest here. Wouldn't it be nice if your site's admin password was not sent over your company network, the WiFi in the cafe from where you like to blog, and the internet in the clear?

Wrapping up

I hope I convinced you that you need a secure website even if user privacy considerations are not your top priority (although I'd disagree with you, but that's for another day).

The usual response I get from the above arguments is about getting started, and how to migrate to a secure site without hurting an existing insecure website's rankings. For both of these, I gave a talk at Google I/O 2014 with fellow Googler Ilya Grigorik. We cover all these points and more.