You're using an old browser that may not display this page correctly.

This blog contains a Legacy version designed to work with browsers dating as far back as the late 1990s.

Cover image

Internet is finally leaving old systems behind

As you may know, I love vintage software, to the point of designing my blog to be capable to be seen in browsers all the way back from the Windows 9x era, which is over 25 years ago from the time of publishing this article.

However, as web technology progressed and these older systems have been dropped their support, websites have began breaking for the legacy systems.

1st hit: This website looks broken now!

At first, it began with the introduction of newer web layouts (CSS flexbox and grid) that became the new standard, but broke on old browsers, especially Internet Explorer, but with a bit of effort, you could still browse a website if you didn’t mind elements being out of place.

2nd hit: Why I can’t see anything in this website?

Later, it was followed by the release of groundbreaking JavaScript libraries for quickly updating a page’s content. The widespread of SPAs and reactive UIs that enforces you to use JavaScript at all times, and a browser that complies with the modern JavaScript features. Without any server-side rendering backing it all up with progressive enhancement, an old browser would display very little or nothing.

The SPA trend has waned down since then, but it’s still a noticeable problem on many sites, especially web apps.

For people who like to browse (or have no choice but to for whatever reason) without JavaScript, we’re living in hell right now.


Even now, many websites may be too eager to use the new web technologies or still haven’t applied a progressive enhancement approach to their sites, and end up making it only compatible for Google Chrome —the reigning browser to this day.

But since the 2020s, the world has dealt a lethal blow to these aging browsers.

The fatal blow: I can’t understand what this website wants me to say!

Back in the 1990s, web security paled in comparison to today. On that matter, the vast majority of websites used plain HTTP to communicate between browsers and the website server. This makes the communication between the two easily compromised by a third party who may be listening in to acquire sensitive information.

Netscape introduced HTTPS in 1994 using their own kind of encryption layer to secure that communication channel, which would be called Secure Sockets Layer (SSL). This would later be superseded by the Transport Layer Security version 1.0, which became standardized.

Both TLS and SSL (now deprecated) have as a core part what’s called cipher suites, which are a list of algorithms that are used to secure your connection with a server, and they are —somewhat— independent from the version of TLS or SSL you’re using. These have to be implemented by the web browsers:

With time, new cipher suites will appear, and it’s the browser’s job to implement support for them. Otherwise, a server that only chooses to use these newer and more secure suites will refuse to make a connection.

It’s kinda like:

Hi, I would like to purchase this thing, but because I’m sending my credit card information we should use encryption by talking in another language. I can speak Spanish, French and Japanese to do so. What should we use?


…What? Oh, guess I can’t deal with this person.



But newsflash: Support for these operating systems has been dropped years ago. Browsers that rely on the OS for encryption won’t be getting any new updates anytime soon. And with time, browser developers will just stop supporting these old systems and won’t be getting new updates to the tech they have built-in.

This leaves regular HTTP sites as the only reliable way for these browsers to be able to load a page. Still, adoption of HTTPS was rather slow, and it didn’t start really gaining traction until 2008. This excellent article has a detail timeline of that.

But it’s 2024 now, TLS 1.0 and 1.1 have now become obsolete and most servers have been upgraded to TLS 1.2 and 1.3, with way more sophisticated cipher suites. About 80% of Firefox users’ worldwide traffic is through HTTPS now, and several of the most popular sites have gone full on HTTPS-only. The web are finally closing its doors to older browsers.

I’m not saying that’s a bad thing, though. Technologies improve, and the old ends up becoming out of use with time. It’s how things are. This encourages people to renovate to stay with the current times. But should you try to start up your old computer to try and relive the Internet experience of yore, you will soon be out of luck.

But is there hope?

There is, actually! At least, for the time being.

If you are using Windows 9x, there is a browser out there with extended support for TLS 1.2: K-Meleon. This is arguably the best browser to browse the web in these systems, and while it has officially left Windows 9x behind, this version should be able to allow browsing the Internet natively on those systems until TLS 1.2 support is dropped.

This is not the case with Mac OS Classic, sadly. Classilla, the only browser with lasting support as of recent, stopped its development a couple years ago, and never got the extended support with new cipher suites as K-Meleon did.

Do note that the above is true for “native” browsing. It is still perfectly possible to browse the Internet with a proxy server that renders a modern page via HTTPS and delivers it to an old browser using images and other legacy-friendly components that it can work with via regular HTTP.

Browservice (10:51)

A proxy server software that uses Chromium Embedded Framework to display modern pages

In the case of The Yonic Corner, there is a Legacy version that’s safely hosted in Github Pages and allows plain HTTP connections. At least, as long as GitHub supports them…

This is why in the future I will plan on moving both the modern version and the Legacy one to a self-hosted server. Thus, I hope to be able to provide HTTPS connection for these browsers in the Legacy version, and if not, I can secure the possibility of allowing plain HTTP connections. After all, it’s just a static blog —you won’t be sending any sensitive information here.