Everything on the site is generated as static webpages using a custom built python engine. Static web pages ensure the web server's response is as fast as possible while at the same time loading the web server's processing power as lightly as possible. This approach also puts less computing load on the web browser you're using to view the website's pages.
Within python itself, the database is maintained using sqlite, facilitated by a custom wrapper that makes such things (much) easier. Because the site is generated to static web pages and absolutely no visitor interaction with the database occurs, the database is secure by default. So Little Bobby Tables can use the site without anyone having to call his mother.
The timelines are a custom, copyrighted system. The software that generates the timelines is also built in python.
The main website is built using wtfm, a custom documentation system. At this point, you're not likely to be surprised to learn that wtfm is also built in python.
The entire site complex, from the webpages to the database and the various software engines, is automatically and securely backed up in multiple locations with every update to ensure its long-term integrity in the face of hardware failure and related issues.
Between wtfm, the timeline generator, the tree diagram generator, the genealogy generator, the database engine wrapper, and all of the relevant data in the underlying databases, this represents my work output over many years.
I wrote all the latter software (and the associated detailed manuals) from scratch, built the genealogical and historical databases, and then put it all together in a massive dogfooding exercise to create both blish.org and ourtimelines.com.
This web site is designed for normal Internet use, by which I mean via http: access.
However, should you wish to use the site securely (that is, via https:), you can do so, although your browser will warn you severely about the risks of doing so. This is because I use a very long duration self-signed SSL certificate rather than one that links back to the the "approved" certificate authorities. I have learned, much to my dismay, that the fewer outside services I depend on, the less likely it is that my systems will break down consequent to failures I have no control over.
SSL certificates have two roles:
First, and as used on this site, once you connect with a website via https:, SSL certificates encrypt what you're doing. No one can see which web pages you're on, although they can see which websites you're visiting even if you're using an encrypted DNS provider (by simply reversing the resulting IP when your web browser accesses it.)
Second, if issued by what is somewhat risibly called a "legitimate certificate authority," they serve to tell you that at some point, the certificate authority has been convinced you own, or have the authority to manage, the resource(s) the certificate is issued for.
Unfortunately, the process of convincing a certificate authority you are who you say you are is:
(a) Riddled with weaknesses, and
(b) in no way solves the problem that the entire idea of "knowing who runs the website you're visiting" remains entirely vulnerable to website data compromise via certificate theft, and
(c) imbues website visitors with an almost entirely unjustified faith in that identification while conspiring the scare the living daylights out of them when they encounter self-signed certificates.
Lastly, I am old and not especially healthy. When my bucket is in fact kicked, as is unfortunately inevitable, it is my fond hope that this website will be able to remain online for many years without my (decidedly non-technical) inheritors having to deal — or try to deal — with SSL certificate esoterica.
If you'd prefer to avoid all that drama, just visit this web site using http: URLs. I honestly can't imagine that anyone cares what web pages you visit here anyway. ☺