If there's a requirement that your code needs to run for 30 years without an update then current web technology is probably the wrong choice.

Serving this over http in a secure network would be reasonable.

Serving this over https would be reasonable if you can embed a certificate with an appropriate lifetime. Which you can't.

As another user said, you own both sides of this problem so write your own client software.

If I write my own client software, that's far less likely to be the case. Writing your own is exactly the thing that you should avoid if long-term compatibility is important, sticking to open standards is a much better way to do that.

Using your own example illustrates it perfectly: if I had a 30 year old device running a Gopher server, that would be usable and I would easily be able to get a client running on a modern computer/OS - but if it needed 30 year old custom client software, then porting it would likely be a quite nasty project.

Open standards change, software changes and things move on. If you are seriously relying on anything technological working for a decade or more you're out your mind.

You need to keep up and adapt because nobody gives a crap about you or your use case. Here we see Google doing what it thinks best and you need to live with this.

However, content using CSS1 and javascript 1.0 standards (1996?) should also work in modern browsers; but I couldn't easily find any sites that actually use them and haven't been updated for the last 20+ years to test it; the sites from e.g. 1997-1999 seem to avoid it like the plague since back then you couldn't rely on CSS1 and javascript 1.0 being properly supported.

So yes, just as modern browsers support all web technologies since their very start - a CSS3 compliant browser should be compatible also with CSS2 and CSS1 (20+years old), I'm quite convinced that 20 years into future when we might have CSS 5 or 6, the current CSS3 content will also work as well. New javascript doesn't work on ancient browsers, but ancient javascript works well in modern browsers, that's a core design principle of the web standards - we build them for compatibility.

By using firefox 56? I'm not seeing the issue.

> As another user said, you own both sides of this problem so write your own client software.

Running 30 year old DOS software is a lot more painful than accessing a Gopher server. Is that really the comparison you want to make?

I don't think I'm being unreasonable here. In a closed system this should be doable.

edit: one of the reasons I think this is because we are supposed to be engineers, and other engineering disciplines do it (and their disciplines involve computes too). Consider jets and boats.

He may be an engineer, whatever that means, but still: the average joe in that position will not spend a single second on thinking if he expects the solution he's buying to work for a reasonable lifespan. He's been thrown in a project, that's all. If you force him to state a requirement on the expected lifespan, he will surely say 'Well, as long as possible seems good to me'.

Disclaimer: statistics applies here, of course some people will care, but I'm speaking about the 80%, if not more.

A 30 year old no-updates secure webserver seems almost impossible given current security research progress.

If you can get control over the computer attached to the equipment, you already won. You don't need to exploit the web server.

Then ignore the security warnings.

  Now how the hell do we create a webserver that will work reliably for the next 30 years if we have to embed SSL certificates with built-in expiration dates in the range of 1 to 3 years?

More broadly speaking, you can't rely on anything to stay the same in 30 years, in terms of infrastructure. Many companies therefore deliver both the devices themselves, as-well as the systems to control them (ie. custom laptops/tablets). More costly for everyone involved.

For internal use the answer is self-signed certificate. However I wouldn't count on web browser based software compatibility to last even 10 years. I think browser vendors at some point will decide to ditch <512-bit certs or some encryption scheme and one needs to make a cert/server upgrade. Some option may be Firefox ESR [0] requirement to ease an adoption.

Moreover browser is UI part of your solution and you need to define some requirements - this should be all right for well administrated environments. If the user for any reason upgrades/changes the browser but not your device then this is user introduced incompatibility. Your EULA should cover that. Also you should send notifications or just show some message in device panel to your customers that they need and upgrade if they want to use given browser past version X.

Customers need to learn that web means edge tech and that needs frequent upgrades. Their isolated internal network of the past e.g based on WiFi WEP would be practically a network open to bad actors today.

[0] https://www.mozilla.org/en-US/firefox/organizations/

I imagine you'll be able to flip a Chrome flag to turn it off anyway.

Over 30 years, you'll find vulnerabilities in pretty much anything; so you don't want that device on an open network anyway. But, you can put it on an isolated VLAN, configure it so that it's accessible only by that proxy and no other computers, and then all the http traffic is in the isolated part, and the users access the proxy through https.

Initial can-of-worm questions are "who's allowed to update the cert?", "how does the device authenticate the person updating it?", "what's the failure mode if an update goes wrong?", "how long shall we test the new cert-writing-module?", "will the customer even bother after the initial certs expire we install for them and instead just tell their users to flip the Chrome flag?", "how do we also update TLS and crypto libraries to support future certs or standards?"

Have you actually had clients run those html/js based devices "for 20 or 30 years" (e.g. have some running since 1997) or is this a totally hypothetical scenario?

I fully expect most of the systems that we are shipping now to be run for the next twenty years as well. Until security issues start losing customers buckets of money, they're not going to care one bit.

Heavy industry is concerned only with keeping their production lines up and running. They will do amazing and scary things if it helps them keeping production up. These people have absolutely no idea of security or even IT. They want to bolt and wire devices together so that they work. All the cool tech hidden inside is way beyond their understanding for the most part.

Sure, and there are COBOL systems running since the 70s. But I asked for such an example in web technologies. The one described above isn't.

>I fully expect most of the systems that we are shipping now to be run for the next twenty years as well.

Then don't build them on modern web technologies.

All kinds of things can change or be deprecated.

> All kinds of things can change or be deprecated.

That's cute. If you truly believe a simple declaration of deprecation will stop the use of something, I have some oceanfront property in Afghanistan to sell you.

Internally, we have a push to transition user interfaces for future products to HTML/JS over HTTP. This was sold to our management as a solution with long term stability.

You can associate public hostnames with private-range IP addresses as well, and obtain certificates for them. The main point was that the use of private, non-routable IP addresses does not imply that the network is trusted, and thus is not sufficient reason to exempt the server from securely identifying itself.

I know plenty of devices which can't be used correctly any more since SHA1 + SSLv2/SSLv3 was deprecated and they generated a CA+Cert with 512/1024 Bits.