Analytics Doesn’t Require Tracking

As a very fast follow to my previous post, I’ve now ditched Google Analytics as well. As I noted there, I was interested in privacy-respecting alternatives, so I found quite a few interesting ones.

The options I considered were Plausible, Offen, and GoatCounter. I ended up choosing GoatCounter because it provides a free SaaS tier for strictly personal use websites, which this is. Plausible looks super slick, but is $4/mo even for my minimal traffic, which is almost what I pay every month for hosting. It’s just too much for a low-traffic personal website, unfortunately.

If You’re Not The Customer, Then You’re The Product

You’ve probably heard this statement before, and I don’t know that it’s always true, but it’s become something of an axiom in the web/internet space. It’s true enough in the ways that matter, though, and that brings us to the topic of the day.

Today a post made it to the front page of HackerNews written by Supun Kavinda on his blog entitled “Disqus, the dark commenting system”. Thanks to the comments on HN about this post, I found out that I had somehow missed an announcement that Disqus was acquired by an ad-tech company in 2017, probably while I was still traveling and actively updating this site. I was also apalled by how user-hostile the tracking behavior of Disqus is.

This is going to be a short article, but I thought this might be useful to someone else. As many of you may already know, I use a service called Keybase. This service provides a number of features:

• Prove ownership of your social media identities via cryptographic cross-verification
• Prove your identify for your PGP key via cross-verificatin to your known social identities
• Prove ownership of your devices cryptographically
• Share encrypted files between your devices seamlessly using KBFS
• Track other Keybase users and encrypt messages to them simply

Of course as should be obvious upon setting up your Keybase account, it has no relation to the existing OpenPGP Web of Trust (WoT), and therefore no easy way to connect the two.

Introduction

Why Bother?

As should be abundantly clear from my prior writings I am about to leave on a trip for a year. During that time I’ll likely be making use of numerous public Wi-Fi access points, not to mention whatever dodgy cellular providers are available in each location I travel to. As part of my overall stance on privacy, its essential I take steps to secure my communication while traveling, the primary of which is using a VPN for basically everything on both my laptop and my phone. To do this, I’m using a droplet from DigitalOcean that’s just $5/mo and doesn’t have to be shared with anyone else (from an IP/network perspective anyway).

Just a quick post to share this with anyone else that needs it. I spent hours using Google and reading posts from random people on the net, including bug comments from Dan Walsh on a never solved Fedora bug specifically related to this. The conclusion I came to was that hardly anyone uses SELinux and the ones that do just hack around the problem rather than solving it.

In this particular case, the fault is really with the terrible implementation of Google Authenticator, which I found out during the course of this by reading through the source code. Long story short, it creates a new file named $HOME/.google_authenticator~ and renames it to $HOME/.google_authenticator. This of course plays havoc with SELinux.

Introduction

My apologies for the delay in posting part 2. I encountered a few chicken-and-egg problems in that I wanted to write this update from my new Macbook but needed complete the remainder of the setup in order to have a comfortable and secure environment to do so from. Without further ado, on to the meat of it.

Organization

I’m breaking this article up into several parts to both assist me in the process of writing it and to make it easier to digest. I’m taking some steps out of order, but am making an effort to organize them into the most logical order possible.

Introduction

That time has come again, and I have acquired a new Macbook Pro. In this case its primarily in preparation for my trip so that I can edit photos effectively on the go. It replaces my aged 2011 Macbook Air (which has served me well). It seems an opportune time then to write up my process for setting up a Macbook, and with a particular focus on security.

Organization

I’m breaking this article up into several parts to both assist me in the process of writing it and to make it easier to digest. I’m taking some steps out of order, but am making an effort to organize them into the most logical order possible.

This post was originally a response to a question I received from a friend via email, with some additions. I’m not going to try to get very in-depth here, this is more of a high-level overview of what you should be doing to secure a server running Linux. This is mainly focused on a business environment where you have multiple users and multiple servers (and are hopefully using configuration management software).