For the corporate web RSS and HTTP are dead. But as a non-corporate human person I'll be sure to keep RSS and HTTP alive on my webservers.
HTTP-over-TLS works fine across all "versions" of HTTP, HTTPS has been supported by browsers since 1994; over half a decade before RSS was even a thing.
Your criticisms of HTTPS seem more targeted at HTTP3, but that's actually a separate topic (HTTP3 may be HTTPS-only in practice but that's not the specific aspect you're critiquing).
RSS/Atom also work fine over HTTPS.
HTTPS does not even work on devices from 5 years ago.
After non-removeable batteries, SSL/TLS implementations have been the single largest headache when you want to keep using a device for more than a couple of years.
Expecting network-connected clients to work securely without software updates for even a few months these days though isn't really possible, but that's down to the externalities of the world and has nothing to do with spec design.
One may argue that the problem is essentially unavoidable because the alternative is untenable (delivering any sort of communication without both encryption and authentication to ensure the veracity of the data) but that doesn't make the observation any less true. https is in fact a pain in the ass and introduces a lot of overhead and grief and shortened the useful life of countless things, relative to the time before https.
This is one of those many cases on the internet where people make an unfounded statement and then just move on as if it's accepted as true. How does the mechanism not change the fact???
The mechanism in this case is outdated software; upgrading or changing the software on the device makes the device operable (you absolutely can install modern TLS on Windows XP, alternatively you could also install a modern OS on most devices that came with Windows XP). That fact seems to make the mechanism extremely relevant in whether the device is operable.
Compare HTTP. Or even IPv4, which still works to this day, with the same software & hardware combination.
The only aspect of HTTPS that isn't backward compatible in the way you're talking about is, effectively, the algorithms keeping up with modern attack vectors. That's not an aspect of HTTPS the spec, it's an aspect of the arms race in network security. So pinning this issue on HTTPS is odd.
The reason you can't use outdated software to connect to modern servers isn't due to protocol design, it's due to threat actors.
What other definition there is? A protocol that has absolutely no backward compatibility, not even with itself, and by design, is "built to last"? Or that a protocol that is frequently rewriting its core algorithms in its base specs is "built to last" ?
> That's not an aspect of HTTPS the spec, it's an aspect of the arms race in network security.
It is an aspect of the spec. There is literally no HTTPS without SSL/TLS. If there was, you could have an argument there, but: the very definition of HTTPS is "HTTP + SSL".
Really, there is no color. Ethernet, IP, HTTP still allow an unmodified client from 25 years ago to work with practically full functionality. HTTPS does not. Whether this is because HTTPS has more ambitious goals (which it obviously has), or whether the designers were smoking something better, or because computer security requires an arms race (that's another debate), the effective result is that HTTPS is not built to last.
Everything you build on top of it will require continuous rearchitecturing every couple of years. And I'm not talking about changing some certificates or the like. I am talking spec changes. I'm talking most of the algorithms having changed significantly.
Or maybe TLS 1.3 will be the good one this time. Who knows.
This is largely not true, if you want to talk to today's servers.
Unlike HTTP, SSL is not cross-compatible with older versions.
I would be happy to be proven wrong.
And that is about as mainstream a device as you can get.
It hasn't received patches in 10 years, so having it connected to the internet at all is a bigger problem than it's lack of tls1.3 support.
General-purpose browsing is a whole different matter. I wouldn't advise anyone to do that unless on a patched, up to date and supported machine.
A working MITM TLS stripping proxy deployed on a trusted server would be a better solution, but such options were complicated to deploy.
Using a pre-set list of servers with many sites is not easy, because they'd use CDNs and such.
So basically you can only use it for your 'own' websites and then you can control crypto on server side.
Either way though, I do personally think it's fairly reasonable for server admins to maintain webservers that target "General-purpose browsing" without also having to include support for odd individual long-tail edge-cases of people running restrictively firewalled instances of outdated insecure OSes.
> I do personally think it's fairly reasonable for server admins to maintain webservers that target "General-purpose browsing" without also having to include support for odd individual long-tail edge-cases
That's a good point
Many enjoy and find comforting the older OSes they're used to.
Research even shows that reliving sensory experiences from a younger age can have a measurable positive effect on a person's physiology and health.
I think the general trend of sacrificing everything to so-called security, which in reality just means being owned by the root certificate holders, all several hundred of them, and all their employees and affiliates, even for low-risk and low value targets, like someone who wants to blog with IE3, is overrated and stupid and will be disposed off once we feel more sure of the security of our underlying network...
HTTP/1x != Windows XP.
Advocating for older specs doesn't mean advocating for old insecure implementations.
If we imagine the HTTP+plaintext at one extreme, and HTTP+TLSv$latest at the other, a whole bunch of specs in the middle have effectively died out because nobody deploys them any more.
Therefore, it's unfair to claim that "HTTP-over-TLS works fine across all versions of HTTP" (because it doesn't, unless you also support modern crypto), or that "HTTPS has been supported by browsers since 1994" (because the 1994 HTTPS is not even partly forwards-compatible with the 2022 HTTPS).
E.g. today SSL/TLS almost universally means TLS 1.2 or 1.3. The SSL specs are no longer accepted by practically any server.
Not all older specs are worth advocating for.
Security is unfortunately an arms race, which means that broadly speaking software-updates are important for anything network-connected. Using old hardware is thankfully still possible, but the idea of expecting a 12-year-old piece of software to securely connect you to the internet today is disconnected from the reality of the threat landscape we live in.
It'd be like saying Firefox is deprecating JSON because it doesn't have a nice viewer for it...
HTTP/2? Sure HTTP/1.1? Not a chance. It's too widespread and too valuable, and the floor is too low. Unless Google starts a singular effort against it and manages to pull in the other big cos while avoiding the ire of the liberal states, which seems unlikely.
I think as the nostalgia/retro factor kicks in, it will become cool again to support "Any Browser".
A few common questions about this are:
Security exploits: Yes, you do have to do this on a safe network, but at least over where I am, the Internet is safe enough for me to visit un-malicious websites, perhaps using a VM.
The difficulty of it: It's moderately difficult, but quite doable, with certain constraints combined with progressive enhancement.
(HTTP/1.0 browsers are slightly more difficult to support, because you need a dedicated IP address, as there is no Host: header yet. Netscape 1.x, IE 1.x and 2.x, Mosaic are quite usable if you can get this set up.)