This website has undergone significant changes in the last month or two, and I plan to continue to make more changes to it moving forward. I figured I’d write a post to outline what has changed and to act as a bit of an ‘update’ on what exactly is going on, especially as I haven’t posted here in over a year.
The most obvious change to the site that anybody who had viewed my site in the past will have noticed is the change of domain. The site previously was located at ‘mikejzx.github.io’, which was a domain I had access to for free through GitHub Pages. I’ve now set up the old domain to redirect here, to the new ‘skec.site’, which I purchased recently. The biggest but probably least-obvious change to the site is one that is under-the-bonnet—the site is now entirely self-hosted1 on an OpenBSD VPS through Vultr. I’ve mucked around very superficially with OpenBSD in the past, and was curious about using it on a server. Debian GNU/Linux is of course the usual, almost traditional option for servers but I wanted something more interesting to play with and learn. I’m still learning how to use it of course, but in general it’s fairly straightforward to use, has fantastic documentation, and works beautifully as a server operating system.
I also went through the notoriously painful rigmarole of setting up my own mail server, that is now fully-functional and properly set up for the most part, and was something that I had always planned to learn and do myself at some point. Since around late 2019 I had been using ProtonMail as my primary e-mail provider, but over time had become increasingly suspicious of the service. There are major annoyances in using ProtonMail, particularly when one chooses to use it outside of the provided web-interface (as one typically would like to do from a desktop)—one must set up some kind of ‘bridge’ software in order to use ProtonMail with a typical mail user agent, as obviously ProtonMail have their own layer built on top of the usual e-mail stack, to provide seamless and convenient encryption to their users. ProtonMail provide their own bridge (now also open-source) for their paid users only. Users who do not want to pay for the service, such as myself, must either go without IMAP support, or resort to alternative/community bridge implementations such as hydroxide—which has it’s own host of issues, with occasional breakages and bugs due to internal API changes on ProtonMail’s end. I am especially grateful to finally be moving away from ProtonMail as the hydroxide project also appears to be slowly dying, with suggestions by it’s author to remove IMAP support, due to a general lack of maintenance, and a supposed lack of purpose now that the official bridge is open-source, as circumventing ProtonMail’s pricing, which myself and likely a large number of end-users had used it for, is not at all officially recognised as being one of the project’s goals. When hydroxide does become unmaintained and die, my only option to access my ProtonMail mailbox (other than upgrading to a paid plan and using the official bridge software) would be to use the official webmail client, that I dislike. Hence, although I have used ProtonMail and dealt with it’s many issues for a good while, I generally cannot see it as a viable e-mail solution for the long-term, as it brings in so much additional complexity and cruft that trying to use it as if it were a normal e-mail service necessitates that you build these convoluted and fragile systems that can (and do) break at any point, are inefficient, and are annoying to work with overall. By operating my own traditional mail server, I don’t have to deal with these problems anymore and I can finally just use a normal (good) mail user agent like Mutt, and everything works as you’d expect it to. No more confusion and complications about PGP and signing too, as this is now handled where it is supposed to be handled—in the damn mail user agent!
I will add that the purported benefits of ‘seamless end-to-end encryption’ in ProtonMail are in practice quite meaningless for the most part, as for such a system to work at all in a convenient fashion it requires that ProtonMail be used a homogeneous e-mail provider among communicators (friends, colleagues, conspirators, and whatnot). The majority of people whom you might contact that accept encrypted e-mail often don’t even use an encrypted e-mail service like ProtonMail, but rather instead simply use a standard mail service (or their own mail server) and offer their own PGP keys to the public (as I do on my homepage). I think it is dumb to try and build an e-mail system on top of PGP like ProtonMail does, hiding and abstracting away the concept of it entirely in an attempt to create a ‘seamless’ experience, as if the provider is performing some kind of black magic behind the scenes to keep your mail safe. All this does is foster confusion and ignorance in users of the service, who are often oblivious to the fact that ProtonMail’s advantages over other standard, non-encrypted mail providers are highly circumstantial, despite the service’s marketing claims suggesting otherwise (at a first, naïve glance). Using PGP manually when necessary generally requires interested users to actually read into things at least a little to understand how the protection layer actually works, how to use it correctly, what it protects them from, and gives them a chance to actually ask themselves why they are using it and whether an alternative medium of communication would be better. ProtonMail’s approach can create a false sense of security especially in the less technically-inclined, who are perhaps ProtonMail’s targeted audience anyway, as their goal is supposedly to bring convenient encryption to the layman and protect him from mass surveillance, despite him often not realising that the vast majority of his contacts are not using the same e-mail provider that promises to apply these protections to his communication channels. Trying to use PGP through a slow, clunky webpage, in an e-mail service for which traditional (manual) PGP encryption and signing support appears to have been slapped on as an afterthought2 can be quite frustrating and if anything deters people from using encrypted e-mail, rather than encourages them. Using PGP locally when available is simply more logical, and gives the user much more (very much necessary) control over how their e-mail will be sent, and is generally massively more flexible than the ProtonMail approach. I find that it is simply better to just accept that e-mail is inherently insecure to begin with and that it hence would be wise to not use it at all for sensitive communications. There is little reason to use an e-mail service that markets itself as being secure when it in reality is no more secure, and offers less control, for also a greater price than a traditional self-hosted mail server, which is not only literally just as secure (particularly if you take the ‘offline’ approach that I do, in which mail is downloaded and removed off the server immediately upon retrieval), but is drastically more liberating to it’s administrator/users.
I am also in the process of migrating my source code repositories that I care about from GitHub over to this server. I have no intentions to really host any new projects on GitHub or use GitHub for any other reason than to occasionally contribute to projects that happen to be hosted there. I generally dislike the GitHub workflow and it’s interface, and the idea of hosting my source code there when I can now easily (and more safely) just host here seems a little bizarre to me. I plan to have a simple web interface to my repositories. I initially was going to use cgit for this but am experimenting with and considering the simpler, static alternative stagit.
I was hit with a bit of inspiration recently and have various ideas of software projects that I would like to begin working on at some point. One such idea is a complete re-write of my ‘sr71’ terminal Gemini/Gopher client, which I wrote early on last year. I intended to make a post about this program in the past but never got around to doing so as I felt uncomfortable announcing it officially in the state it was in (due to potential inherent security flaws that are still unaddressed, and just general bugs in it). My interest in the text-based ‘small Internet’ (Gopher and Gemini) seems to have been recently renewed, despite the novelty of Gemini having clearly worn off in the last year or two, I do really like the idea of just browsing pure text documents online. I don’t intend to turn this site into a Gemini capsule or Gopherhole anytime soon, but I do think that trying to improve my client ‘sr71’ and even write some simple servers for these protocols would be interesting and quite fun, and it could be cool to run such servers here on this VPS (provided I am confident that they are secure enough).
1. | The term “self-hosted” can be interpreted differently depending on who you ask—some interpret it to mean hosting a server on one’s own hardware on a network that they have physical access to, while others interpret it more broadly to include the case of hosting on a remote system (e.g. a VPS). I use the latter, broader definition in this article. |
2. | E.g.: there is no way through the interface to decrypt messages you have received that have been encrypted with a different key, signing with your own external PGP key seems impossible, etc. Even if these features were available, would you even really trust a JavaScript-based application on the Internet with your own private keys to perform the decryption and signing for you? Why would you do this through such an interface when you could just do it yourself, and more safely, on your own local machine? |