Now serving over HTTPS and HTTP2

Every so often I check to see if GitHub have added a way to serve websites hosted on GitHub Pages with a custom domain over HTTPS rather than HTTP. Whilst clicking around to that end last night, I found that the answer is still no. I did stumble upon a service called Netlify however.

As this site uses Jekyll plugins I can’t push directly to my repo, it needs to be built first. To avoid having to do that manually, I setup a whole song and dance on Wercker that turned out to be more hassle than it was worth.

Netlify is, in short, a one-stop-shop for static sites. The features that attracted me to it were the Git integration—all I need to do is push a post to the repo and it’ll handle the rest (including building the site despite it using plugins, taking Wercker out of the mix), the free SSL certificates via Let’s Encrypt and the HTTP2 support. A global CDN, and fast DNS aren’t features to shake a stick at either, but GitHub pages has those covered too.

The setup was quick and easy: I pointed Netlify at the site’s repo, it detected that the generation engine was Jekyll, automatically setup a box, built it and served a preview. From there, I just removed the two A records that pointed at GitHub and added one that points to Netlify, added my custom domain in the admin and waited for the lot to propagate. Once it had, SSL was a click away and only one more click was needed to force TLS connections.

If your site’s repo is public on GitHub then Netlify gives you all this functionality on the house. From the few hours I’ve spent with it, I’d highly recommend it as an alternative to GitHub Pages.

Tidying up access

Following a temporary files-are-missing-and-I-didn’t-delete-them scare, I changed my Dropbox password. Whilst I was in my security settings, I checked the list of applications that currently had access to my Dropbox—something I can’t ever remember reviewing despite having had an account for many years.

18 apps had access, 12 of which had full access.

Whilst fortunately there weren’t any in there that I didn’t trust, there were plenty I didn’t need anymore and proceeded to revoke their access.

As I was scrolling down to the linked apps list, I was alarmed at the length of the linked devices list. 29 devices were linked to my Dropbox.

When you do a clean install on your Mac, iPhone, et cetera and Dropbox is re-installed and re-linked, it counts it as a new device. Once I figured that out and scanned the “most recent activity” column I was less concerned but again—I revoked access to everything that wasn’t needed leaving just 3.

Now that my mind was thinking about “What other services do I use that apps get linked to?” I went to check my Twitter account. Unlike my Dropbox, I have reviewed the list of apps that are linked to my Twitter account a few times in the past but not having used it in close to a year, I wondered what was in there that didn’t need to be. 23 apps that I no longer use had access. They too were revoked.

I consider myself to be pretty careful with which apps I give access to what so was surprised by how many had added up over time. Whilst I trusted (to a point) everything that did have access, 20-odd apps leaves a heck of a big margin for error.

If you haven’t done so in a while, I’d recommend checking your Dropbox, Twitter, et cetera, accounts for anything that has access that you no longer use.

From a user’s perspective, it’d be nice to receive and email from time-to-time from these companies recommending that the list be reviewed.

Dropbox’s account security settings.

Twitter’s connected services preferences.