Hello listeners, and welcome to episode fifteen of Front End Center!

While a lot of time and effort goes into user interfaces, user experience, and what happens functionally in the user’s browser, it’s important to take the time to consider the length of cable and airwaves between your website’s host and your visitor’s browser.

Even casual web browsers are often aware of the little lock symbol in the address bar that accompanies a secure HTTPS page. There’s been a push in the last few years for increased awareness of security on the internet, and it’s a great indicator that things are on-the-level. When you’re doing online banking, dealing with sensitive documents, or more, that little lock provides a sense of security.

What’s going on behind the scenes, though, and what makes the difference between a plain ol’ HTTP connection, and its more secure, sexy sibling, HTTPS? While a lot of the nuances and implementation may seem more tied to the back-end of web development, having at least a solid grasp of the concept is crucial for front-end designers and developers alike.

Let’s start with the role of both, and what issues arise when we rely on just HTTP.

When you hit Enter on Google.com, a few specific things happen. First, your browser searches DNS for the IP address associated with that particular domain name. If you’ve filled out a search, or other kind of form, that data is sent alongside to the server waiting at the other end of that IP.

That server then responds, sending web pages, media, or other forms of data, depending on the request. It’s also possible that it requests resources to be sent from multiple locations, like spreading multiple images across a diverse Content Delivery Network to minimize load times.

While HTTP is the protocol wiring that makes all this possible… it’s also a very problematic little enabler. The traffic in both directions, from browser to server and vice-versa, is traveling in a very unprotected way. Anyone with a little bit of knowledge and access can view that information and copy it for themselves.

Banking, passwords, and other secure topics are the first concern raised by developers and users alike. Unprotected use of HTTP also opens the dangerous door of receiving altered resources on the return trip from the server to your browser. Without any sort of security, even without sensitive data being exchanged, an attacker could drop extra, unsavory bits of code and media into your browser with you none the wiser.

So what’s the big gain with HTTPS? Encryption.

Encrypting the information passed BOTH ways between browser and server makes every interaction substantially safer. Whether you’re handing over your Passport number, or just browsing Reddit, an HTTPS connection ensures no one in between is seeing (or changing!) the contents of your browsing.

HTTPS is as reliable as it is thanks to the certificate issuing authorities responsible for keeping records and identities up to date. While absolutely anyone CAN sign a security certificate and apply it to their own servers… modern browsers make sure to check how much actual weight that security holds. Self-signed certificates will, at best, alert the user to not being on a secure connection. At worst, the browser will block the page and alert the user to suspicious and potentially harmful deception, encouraging them not to visit the site in question.

For a long time, HTTPS was the realm of banks and other professional industries. Industrious developers might add an extra layer of security on sign-in forms, but it was often a perk rather than a requirement. Things starter changing in 2014, however, when Google gave a big thumbs-up to HTTPS enabled websites.

Like many of their initiatives, Google had equal parts self-interest and public altruism in their transition to favoring fully HTTPS sites. A more secure internet benefited all parties equally, from an industry and user perspective. There was just one, substantial hang-up: the difficulty and cost.

Security and large industries like banking are known for many things. Cost and ease-of-use are very close to the bottom of that list. While the process of obtaining and maintaining a security certificate was reliable and hard to falsify, it was also difficult and expensive for your average non-corporation-Joe.

(An aside for those of you reading along. Microsoft Word insists corporation should be capitalized, and Joe should not. I’m not sure whether that’s more humanly concerning or just hilarious.)

Once the doors opened on increasing use, prices and methods of acquisition became more mainstream. Many companies popped up to act as middle-men between consumers and the big, trusted certificate handlers, offering better price leverage thanks to increased buying scale.

Another project has come into the light recently that puts an even better foot forward, called Let’s Encrypt. It’s a service provided by the Internet Security Research Group, and has some very particular and important tenets. Its certificates are FREE. They can be automatically acquired, confirmed, and renewed for convenience. They are every bit as secure as the existing providers, and have completely open transparency of their records. Above all, they are open and cooperative with their automatic issuance and renewal methods, encouraging the world wide community to create services and ideas on top of their work.

Let’s Encrypt is backed by some very large names that ensure its high quality and enduring status. Mozilla, Akamai, the EFF, Facebook, and MANY more groups support the cause. I recently used Let’s Encrypt to add security to my own hosting for my personal site, http://landtiser.com, http://fec.fyi, and other client sites. Having made similar efforts a couple years ago without their assistance, I can confidently say they have improved the process an endless amount.

HTTPS is important for front-end specialists to pay close attention to as well, because we can often be the gate-keepers that make or break a successful implementation. As you assemble your next site, take a look at all the resources you pull. Are all of your external scripts coming from secured connections? If you have images on a CDN, are they coming through on an HTTP connection? What sort of limitations does your ad-network impose?

A website that’s 90% HTTPS secured isn’t really secured at all. A user’s browser will alert them immediately, or completely block the offending requests, if it detects an unsecured resource being called on an otherwise HTTPS specified page.

Speaking of impeccable HTTPS websites, who’s been watching the entries start coming in for the 10k Apart competition this month? There’s already a wide variety of really unique front-end projects. From games and CSS transformations to portfolios and complex poop-emoji rain effects, people have already started showcasing some amazing tricks and ideas. Their competition runs through September 30th, and I highly encourage anyone who wants to enter to give it a run!

The web community is at its best when we’re sharing and creating ridiculous ideas that end up more successful than anyone ever expected.

Until next week, this has been Chris Landtiser, and Front End Center.