Browsing the modern web on retro machines

[Rhetorica]

The TLS Apocalypse is the (never truly over) pattern whereby old HTTPS implementations become unusable with the modern web because of changing standards. NeXT machines are highly affected by this, but other victims include vintage Macs, Amigas, and basically every other machine from the 1990s or 2000s with a web browser.

Most annoyingly, the majority of sites no longer non-encrypted HTTP because of a perception (probably unfounded) that anything with a password field is automatically going to be the target of a MitM attack that can and will expose the bank account of millions of users. Admittedly, there was a brief period around 15 years ago when certain major ISPs in the US were injecting ad banners into non-encrypted HTTP traffic, but any actor worth their salt these days would be able to eavesdrop on HTTPS. (Personally, the only time I've ever been victimized in a data breach was because of a keylogger on a public computer that saw my Gmail password.) But, whatever, this is the world we live in now.

To fix this, we have to intercede with a functioning TLS implementation at some level. The ideal scenario is Crypto Ancienne, which we have a NeXT package for. Since it has a PA-RISC port I'm guessing it runs on NS3.3, though it was previously marked as only being for OPENSTEP. (If it does function on NS3.3, let me know.) The PDF included with the package describes set-up instructions for OmniWeb.

Note that this will not fix WorldWideWeb.app, as that uses the incompatible "HTTP/0.9" standard to fetch pages (it basically just sends "GET <URL>" with no headers.) At present floodgap.com is the only server I know of that honors WWW.app queries.

Unfortunately, CryptoAncienne is not a super-fast implementation, and on black hardware (real or simulated) the slowness is downright unbearable. A better solution is to run or use a proxy from an external source. Here's a guide for doing this on NetBSD via inetd, using CryptoAncienne's standalone carl utility, which is basically just a very primitive C99 curl with TLS built in. The same can be done on systemd systems by using xinetd. More conveniently, @jeffburg is working on a node.js solution that miiiiight possibly be easier to deploy on modern systems and should be less vulnerable to the Cameron Kaiser bus factor; I'm hopeful we can convince him to set up a registration service for a semi-open proxy that we could host here, so people can sign up to use it instead of having to run a service locally. (This is not easy for Windows plebes.)

Alternatively, and developed more or less as the same time as CryptoAncienne, there's a much less setup-intensive route where all the proxy functionality is wrapped by a web server; the browser never 'leaves' the server's site. These used to be fairly popular, though they have obvious privacy issues and are subject to the whims and censorship of the server owner. As a plus, though, the quality of TLS implementation is entirely a function of the software on the (presumably modern) host machine, and these can vary widely in ease of maintenance.

Currently, the FrogFind! service by Sean of ActionRetro is a very popular and well-publicized proxy meeting these requirements. It uses DuckDuckGo as its search provider and strips out most tags, making it easy to browse the web on machines with very limited HTML support. (Personally I think it strips out too much—even some basic HTML tags are missing!) Tragically, FrogFind! spends more time down than up, so many people have taken the FrogFind! source code and spun up independent instances:

• BoingSearch! is an Amiga-oriented clone, not a fork. Like the original it strips away nearly everything, leaving just informational content.
• RetroGateway is a standard FrogFind! instance with all the features working as intended, but it uses Google as the search provider. Paradoxically it also redirects you to HTTPS if possible.
• SlugSearch! is our in-house hacked-up version of FrogFind! optimized for OmniWeb. It strips out fewer tags, still uses DuckDuckGo, and removes dependencies where possible. Javascript is still removed. More likely than not you'll end up having to scroll past a bunch of garbage from the web layout before you get to the actual content, but I believe it's better to be inclusive, to avoid accidentally stripping out vital functionality. (Of course, if that's not your thing, the other services are also still around.)