Hacker News Reader

And as you sunset FM radio, you cut huge swaths of humanity out of yet another communications channel. FM radios are cheap, well-established technology, perfectly suited to mass communications (as in emergency alerts, etc). It survives suboptimal conditions (fuzzy broadcasts are still intelligible, receivers can be operated on hand-crank power, replacing equipment can be done at a dollar-store, etc). The amazing new technology that replaces it is without exception more complex, less reliable, and requires more infrastructure, and the associated costs invariable lock some segment of society out of participation.

On the web side of this analogy, we're so fortunate to have people like Neocities trying to rebuild those bridges to the beginners, the resource-deprived, and the other edges of society, but with every crank of this ratchet we (literally!) excommunicate another set of our species, and that's depressing as hell.

My very, very old Telefunken FM Radio in my workshop full of dust and dirt works flawlessly. I tried to replace it with a modern, shiny one. But this new one broke after a few months. Now I placed the old one where it was for centuries and now it happily plays my favorite program again.

Some old sites are valuable for archeology, some because they contain information that’s still true and not replicated anywhere else, some simply because they are interesting culturally.

To say it’s ok to bail on all old sites is to say that it’s ok to bail on all old books.

Someone put time and effort in to freely sharing these things for a reason, and it’s a loss for us all to throw it out in the name of “new”.

Books, under normal conditions, will not decay by themselves either. However a librarian is still very much needed to preserve and organize them.

The main issue is that HTTPS as it is developing right now is the antithesis of HTTP1. Everything that HTTP1 relies on is defines as bad by HTTPS. Either we change the direction of HTTPS or we drop HTTP. We can't have both.

Of course, if the server is up and connected to the internet, it will always be accessible by browsers that can be configured to ignore the missing HTTPS features, as it is now. But as I said on a different comment we should not rely on this being here for much longer.

Definitely agree. I’m glad we’re having these discussions and that these points are being brought up.

The problems with archiving the web are numerous but I find it frustrating when this argument is used without getting historians involved. It feels like people use the idea of archiving as a cudgel rather than actually supporting real work in this area.

Though it seems counter to my argument, I agree with you. We need to stop using cudgels and just focus on the real work needed.

Funding is the core problem. My wife is a historian and every time the potential of things like digitization or archiving digital content comes up it always comes back to "grants are so incredibly small and archives don't have enough money to just maintain the books they already have, let alone expand". There's a lot of interesting research in this area but it isn't being put into practice because there is no funding.

Analog TV had to be moved because it was taking up limited resources. Old websites aren't taking up valuable real estate. There's no benefit to shutting them down.

Of course there is. If they're HTTP, they're insecure, which makes them an open attack vector.

Modern computer security is about removing as many known possible attack vectors as possible.

So that's the benefit.

EDIT: to those saying browsers are sandboxed or that there's nothing sensitive, it projects against e.g. Comcast injecting JavaScript into pages from other sites. [1] There are all sorts of types of bad actors out there. Surely I don't need to list them all here.

[1] https://thenextweb.com/insights/2017/12/11/comcast-continues...

There's no point having a web browser that doesn't browse just because it's more secure that way! Browsers have never had better sandboxes. Firefox disables certain features for sites served via plain HTTP. It's safer now to browse unencrypted sites than it was five years ago. There's no reason to remove functionality now.

Here I disagree. HTTPS gives guarantee to visitors of the site that they can trust the information being served to them.

A malicious actor hijacking plain HTTP connections does not necessarily have to inject code that harms the user's computer directly. He/she could also just alter bits and pieces of the served content to trick the user into doing something not in his/her interest.

So while having better browser sandboxing and protection is good (and welcome), HTTPS is still necessary.

Old and unmaintained websites are not collecting any information, let alone sensitive information. They’re mainly read-only, informative content that the web would be infinitely worse-off without.

The Internet Archive helps maintain that information far more reliably than a 20-year-old unpatched webserver could.

The internet archive is unfortunately poorly indexed/searchable bordering on not at all.

> Of course there is. If they're HTTP, they're insecure, which makes them an open attack vector.

If so they are only insecure because malicious JS can be MITMed into them, and realistically speaking browsers can’t defend against malicious JS.

> Modern computer security is about removing as many known possible attack vectors as possible.

So let’s remove enabled-by-default JS permissions instead of removing HTTP-content. Most old websites don’t depend on JS and would in fact be just fine.

Even better: make JS opt-in only for HTTP websites, and let users like me refuse the “upgrade” to HTTPS.

> If they're HTTP, they're insecure, which makes them an open attack vector.

No it doesn't. HTTPS ensures that the data is not spied on or tampered with by those in the middle (so it does protect against what Comcast does), but does not prevent any other sorts of attacks (e.g. the server operator adding malicious files into their own server).

> it projects against e.g. Comcast injecting JavaScript into pages from other sites.

I should add a script to detect such things then, and if it finds one, display its own message to the user, to tell the user to disable JavaScript, with instructions about how to do so.

Replacing FM radio is a huge societal mistake. Its simplicity enabled countless innovations that would and will not be possible with satellite radio. The technology (unlike analog TV) works perfectly fine for its core purpose and has numerous spinoffs (from radio clocks to OP-1 built-in radio sampler).

FM radio degraded well.

Indeed. As I understand it, *BSD users are currently left out of wildcard certs from Let's Encrypt. HN runs behind an nginx proxy because the forum software doesn't support HTTPS.

What is the issue with *BSD and LE wildcard certs? Would be interesting to hear more about that.

https://certbot.eff.org/lets-encrypt/opbsd6-other

Certbot is just one of many ACME clients. AFAICT acme.sh can do wildcard certs, and it’s not dependent on Bash.

https://github.com/acmesh-official/acme.sh

What? OpenBSD works just fine.

There are a few certbot clients for openbsd, at least. I’m using one that was written in bash with httpd, and I think they added a new one to the base image. Using the script was a bit annoying because I had to install bash from ports.

As on my Linux and Synology machines, the bash script has broken once or twice because it’s against modern best practices to define and stick with stable protocols.

Sometimes I think it would be easier to rewind to the 90’s web and build a sane ecosystem on top of that. Every aspect of the web that I interact with has gotten worse in the last decade.

(Also, HN’s is using a non-wildcard cert from digicert, at least according to my web browser).

I was responding to OP regarding non-trivial, which, I dare say, your reply agrees with. I mean, geez, you've resorted to Bash in OpenBSD.

The Arc Language app that this forum runs on doesn't support HTTPS, so wherever the cert comes from, accessing the site is through a reverse proxy.

Well, that was before they added acme-client, which works out of the box, more or less:

https://man.openbsd.org/acme-client.1

I chose the bash client over the python client because I didn’t want to use pip to pull unvetted software from randos on the Internet. (Also, I hate python, and eliminating use cases for it makes me happy.)

Anyway, the bash script is still quite popular, and is extremely reliable. Since I used it, they eliminated the bash dependency, and now it is unix shell compliant:

https://github.com/acmesh-official/acme.sh

I would definitely use it in the future if I was configuring a Linux box to renew certificates.

The breakages I encountered were all on the Let’s Encrypt side, and broke all the clients, including the official one.

Anyway, it has been trivial to use Let’s Encrypt with OpenBSD for many years.

In my searching, I had not come acress acme.sh and I am not aware of using acme-client for wild card certs.