As I mentioned in an earlier post, one of my goals in moving to a self-hosted blogging platform was to protect the privacy of my readers. WordPress, by default, has a few tendrils that slither out across the Internet and violate that privacy letting any number of 3rd-party websites track your movements across the web.
By default it: loads special fonts from Google’s servers; uses the Gravatar service to show an image next to your name if you leave a comment; sends your email address and other data off to a third party to run heuristics as part of the bundled anti-spam tool.
I’ve excised my installation of these issues. When you load this blog I do not enable any other services to track your movements.
Instead of using the bundled anti-spam tool, Akismet, which sends your data to a 3rd party, I’m using some less powerful, but locally controlled, methods that include things like a simple checkbox on the comment page to confirm you’re not a spam bot. These more primitive methods of fighting spam would probably not work for a high traffic site (thus high value target), but will probably be just fine for us.
You may have noticed the social media sharing buttons at the top of each post. Normally this would allow each of those services to track your visit to this site. But these buttons are a little different than what you’re probably used to.
These buttons require two clicks to work. One click activates the button and connects to the associated social media service (which in turns means that they are now able to track your visit to this site). A second click does the normally expected behavior for sharing something to that service. This privacy-protecting method of enabling social media sharing is powered by the Social Share Privacy project. The project is still a little rough around the edges, but it does work (though it took me longer than I expected to configure).
The final piece that I’m working on is migrating all the old media to my server. Currently the pictures and videos in old posts are still hosted on Blogger’s (a.k.a., Google’s) servers. I’m slowly working through bringing those files to my server so that you don’t need to interact with any 3rd party to visit this blog.
Also, if you really like, you’re free to visit this site using an encrypted (https) connection. However, at the moment I’m still using a self-signed certificate (so your browser will warn you that it’s not secure, just add an exception). It’s a lie to say it’s not secure, what it really means is that I just haven’t paid one of the certificate companies to verify my identity. The connection will still be encrypted as any other. If you really care I’d be happy to take your phone call and verify that the certificate your browser sees is in fact the one I created.
If you’re looking for a free SSL certificate that’ll avoid browser warnings (except on ancient platforms like IE on XP, IIRC), you might take a look at StartCom’s StartSSL: https://www.startssl.com/
I’m using their certs on a couple of small sites, and they work great for me. There are a few limitations to the free tier (no wildcards, so each cert is only valid for a single subdomain, and they’re only valid for a year at a time), which may be a problem for your use. But if not, they’ve been offering this program for years now, and they seem pretty legitimate.
I actually have one from StartSSL already; but from what I can tell, you can only get one subdomain cert per domain for free. So I have a real cert for a different subdomain than blog.serindu.com. I may or may not pay for a wildcard cert once I have a few more uses up and running. But probably not since most of the https sites I need are just for my own log-in security.