Adhering to standards

 Been a while since the last one of these I wrote and for that I'm sorry. I'll try to do a better job in the future to be more prolific even if it's smaller posts.  

As you've probably figured out by now, I'm not that great of a coder though I do feel confident enough to say I am a tech nerd in general. I'm more comfortable with the command line and systems administration than dealing with the nitty-gritty of variables and functions in obfuscated code. This is why most of the work I do on THP tends to be optimization of server software and things like managing connections properly than things more noticeable on the actual boards. I do do the latter but that's a subject best left to another time, maybe when I talk about what it took to get the mobile client changes through ("soon").

For a long time, THP was a pretty typical small site, using standard configurations for most of its server software. Over the years, however, I've become a lot more proactive in prioritizing security and stability and things like switching the site to HTTPS-only stem from those efforts. Really, if I'm honest, most of that is due to the general state of the tech sector and the world more than any pressing practical need, but I decided that anything I'm involved in would have to make a decent effort to protect the security and privacy of the users.  

It takes a fair bit of time to keep up-to-date with what security researches and the various web-centric organizations propose and implement insofar standards and security is concerned. Some things aren't ready for the prime time for a long time and others have very specific use cases that a webserver's administrator has to think about whether or not it's worth the hassle to set up correctly. There's tools and a plethora of sites which let you see how compliant a webpage is and what is missing to make bring it up to scratch, as it were, that make things slightly easier.  

One of the latest things that I wanted to implement properly was the Content Security Policy header. The gist of CSP is that whenever request and server info is sent to a client, your web browser follows certain security rules about the content it receives. It can avoid certain types of vulnerabilities by loading, say, images and fonts only from specified sources and thus closing vectors for hijacked code that could compromise the secure session. The most important part of this is making sure that scripts (usually javascript) that are loaded come from the site that's serving the content or other trusted entities.  

To get a full grade on, for example, Mozilla's Observatory tool you have to make sure your settings are restricted enough to avoid certain possible vulnerabilities. Now, the reason THP can't comply with this standard fully is the fact that the old site code relies a lot on inline scripts. These scripts are present in the various board pages' source code instead of being called from an external script file. This practice is now frowned upon because there have been many ways to exploit inline code do naughty stuff to the webpage and its users.  

So, in order to make the site CSP-friendly, I’d have to rewrite a lot of code and move it around. Without breaking anything! Because of the very messy nature of the site’s code base, any effort to touch code must first include a mapping out of what relates to what and depends on whatever else. You sort of map out how it all comes together, which is sometimes complex and often not very clear. In other words, it’s a huge timesink for (often) little gain. I spent a good chunk of free time during a weekend figuring this out and moving some code around to follow more modern and safer practices. There’s still a lot left to do. The problem is that, since I’m already manipulating code, I may as well optimize and refactor it and change up other stuff on the site. Which, because the code is not clear and often interdependent with other stuff (or has hardcoded paths!) leads to a massive time investment and mission creep.

Some of the conclusions are that I may as well write some code from scratch, given how outdated and useless some code is and how I’d spend a comparable amount of effort redoing it as touching it up. So yeah, while I’d love to make the site fully CSP compliant, I have limited time and have to decide on priorities. Getting things like the mobile compatibility 100% sorted is more important, not to mention the other things I have in the pipeline (the mystery of the box lives on, fear not!).  

The patreon has helped this kind of work slightly. I’m not going to overstate its effect but I’ve spent a small amount of the extra money getting audits of bits and pieces of code and generally improving things behind-the-scenes. I honestly do feel bad at times that change is slow, as a lot of it depends on me having having the time and clarity of mind to work or coordinate work, but I haven’t given up yet! I’m not good at ETAs but things are still in motion more or less.  

Next time I write one of these I hope to talk about slightly more useful (at least from a user’s perspective) changes. Look forward to that and a little nugget of interesting statistics that I’ll share with all patrons by the weekend.