> Let's Encrypt [...] Netlify [...] GitHub Pages [...] your hosting provider [...] Cloudflare

Those are exactly the kind of third-party services the GP was talking about.

> if you're into managing your own server

One of the core advantages of having a personal server has always been that you can keep it entirely off the internet and run it without any involvement of third-party services. That is not anymore possible. Like, I now need to purchase a domain name and set up infrastructure to fulfill Let's Encrypt's challanges, just so I can serve a page on my LAN.

Not to mention people who can't obtain certs due to geopolitics or the inability to enter a legal agreement with the ISRG.

I understand why letsencrypt is needed and what problem it's trying to solve, but forcing international dependencies on a small number of select entities is not the way to go about solving them.

I can't help but feel saddened when see one of the greatest monuments to human ingenuity, a global decentralized network, get dismantled like this.

You can use HTTP instead of HTTPS or you can use a self-signed cert.

Often, this doesn't even work for small projects:

- HTTP have no access to a significant part of web APIs added in the last years - and they will be blocked from all APIs that are being added in the future.

- Self-signed certs show security warnings that are deliberately confusion and discouraging to click through and will likely become even more so in the future. Show those to other people is no option.

In my opinion this doesn't fall under the "it's only on my LAN and a super small project" category. If you LAN is a company then you should be able to deploy a custom CA to your clients and sign your certs. If it's only your small side project you personally work on, then just trusting the cert locally works out too. If people don't want to use third party providers, they have to do some of the work on their own. That's nothing new (at least to me).

A small, personal project does not mean that the developer is the only person that uses it. Servers can also be used by friends, family, roommates, etc for which installing and managing custom CAs is a hassle.

I do agree that using Self-signed certs and clicking through security warnings is possible - however, is being made deliberately tedious (e.g. Chrome will forget that you accepted the cert after a while). It also seems to me that this part is actively discouraged by browser vendors, so I'm honestly not sure how long it will stay open.

Self-signed certificates are also unpredictable to do API requests to because no accept UI is shown for such requests.

> That's nothing new (at least to me).

It absolutely is. With HTTP, you could simply run a local web server and have everything interested point their browser towards it - and everything worked. This is not possible anymore unless you want to make recurring payments for a domain and accept that you need an internet connection.

And this is exactly why SSL everywhere is a really, really, bad idea. (Plus the problems of IoT server certs, mentioned above...)

I understand the rationale behind https-everywhere and I believe it's absolutely necessary for the web at large. The problem of network attackers is certainly real.

However, a side-effect (intentional or not) is that the web is turned into a sort of app store: Either you belong to the platform or you don't, and whether or not you do is decided by third parties. (Who, btw, are not even bound by any kind of public mandate - they are simply private, profit-driven companies)

I also don't think the stated security advantages always make sense: Let's Encrypt will serve network attackers just as easily as legitimate customers. Meanwhile it will lead to a lot of stuff being exposed on the internet than would be necessary otherwise. We also force devices that simply should expose a local web interface to have a cloud service. I don't see how this makes anything more secure.

I guess what I'd want is simply a way to designate a device as "trusted" locally, without depending on third-party services, internet connectivity or anything else and without anything expiring. A way that should be encouraged to be used by non-techical users as well.

Yeah, right - and risk the wrath of your clients when they ask you why their shiny new website can't be accessed because it doesn't implement HTTPS. Face it, folks, the golden age of the internet is long past. Now we have to jump through a bewildering array of "security" hoops just to host a ing web page.

I was replying to someone who was complaining about what to do on "my LAN," no mention was made of clients. HTTPS isn't "security" with sarcasm quotes, it's actual security, it really does what it's supposed to do.

>So I don't really understand what you're talking about,

That's because you didn't finish reading my post.

>Expect to eventually be unable to host a visitable or indexable website without relying on at least one third party service in the near future.

You mean like how it has been for decades ?

You have always needed at minimum hosting, SSL and domain service providers.

You definitely didn’t need, and most sites didn’t use SSL a decade ago.

DNS you always needed.

1) no.

2) There are multiple organizations running DNS and the general consensus is that there shouldn’t be a single organization running it (except ICANN which is generally careful to delegate the root and TLDs to other organizations.)

3) Just because you have one bad thing doesn’t mean it’s ok to have two.

Not strictly necessary, but convenient. All browsers I know of allow you to browse to an IP address.

Well, I tried to respond to GP with a tongue in cheek link of an IP address to lmgtfy or Wikipedia on DNS or something, but every site I tried checked the Host header, (I assume) so it didn't work.

This shouldn't be downvoted. I distinctly remember browsing websites by their addresses.

You mean besides the fact that you need an ISP?

NO! Two big reasons, among many others: 1) These are unnecessary third-party entanglements, allowing anyone to be slienced within a year simply by refusing to renew their certificates. 2) It's the 21st century, very soon, most servers will not have administrators - smart IoT devices, if we want them to use SSL/TLS, need certificates. If you think updating these certs on regular servers is a PITA, try it on a an embedded device that has very limited or intermittent Internet access, if it's even connected to the public internet at all!

It’s not the price that’s concerning; it’s having external dependancies.