> There's simply no excuse for not providing an encrypted connection.

Its use in every situation (ie, browsing a website dedicated to reviews on salt shakers), might not be necessary and could cause an affect similar to the overuse of antibacterial soap. :p

It will also prevent older computers from accessing the web as ssl standards evolve, which is kind of a shame.

It might not be "necessary" for a website dedicated to salt shakers, but if I can provide my users privacy when reading my site(unencrypted DNS notwithstanding), why wouldn't I? It should be a common courtesy. While I'm browsing the web, I should expect that nobody but the host can tell what it is that I'm doing.

> It will also prevent older computers from accessing the web as ssl standards evolve, which is kind of a shame.

At what point should an older computer no longer work with the current web? Eventually there's going to be a breaking change. A computer old enough that its browser can't be updated is probably vulnerable to all sorts of browser-based attacks.

There are situations where http is wanted, the best example are public WiFi networks. Showing another big warning for non-https sites would scare the users more than it currently does with them visiting a https site the first time they're on a public WiFi.

Hold the phone. Public WiFi is where you want your connection to be encrypted at all times. A WiFi login page should be encrypted without scaring the user just because its certificate is self-signed. Beyond that, any connection that is encrypted on public WiFi is better than one with no encryption. I don't care if I'm looking at pictures of dogs and cats; it's not the business of other people on my network to sniff my activity and see exactly what I'm reading, even if they can see my DNS activity. Users aren't in control of whether a site supports HTTPS, thus it's a courtesy, given the ease it takes in implementing HTTPS, that even "innocent" web services do so.

I do agree that encryption is especially required on public WiFi networks. But WiFi login pages error because they mitm your current, encrypted connection. Your proposal would additionally add an error in a case where the user especially chose a http site to not receive a error because they're getting mitm-led. I never had any wifi login page that used a self signed certificate.

Then providers of public wifi need to stop using a MITM to provide wifi access. This is an opportunity for better technology to be developed or implemented or made easier to implement or whatever.

HTTPS is not easy to set up unless you happen to be using a system that does it automatically via LetsEncrypt, which is fairly rare. And I don't know how you think you can use HTTPS without a certificate.

> HTTPS is not easy to set up unless you happen to be using a system that does it automatically via LetsEncrypt, which is fairly rare. And I don't know how you think you can use HTTPS without a certificate.

What I meant is that you can use a self-signed certificate, which is takes seconds go create. Some server software will even do it for you if I remember correctly. If this is too had for someone to implement, then they really have no business building web apps.

In a world where unencrypted connections are scary and an encrypted but self-signed connection is treated like HTTP connections currently are(not scary), it only makes sense for people to support HTTPS. There's nothing inherently hard about implementing an HTTPS service beyond one extra initial step.

Beyond that, there's LetsEncrypt, and services like AWS will take care of creating signed certificates for you; I imagine they aren't the only infrastructure host that does this.

Let's encrypt isn't difficult to set up at all. Like, at all at all. Not even a smidge. A fifth grader can do it after reading a simple tutorial.