Why HTTP without encryption and self-signed sertificates are OK Encryption is important. It is used to make sure that no-one eavesdrops the data transmission or injects something like ads or malicious scripts into the content. However, there still are, and always will be, valid reasons to also allow the use of HTTP without encryption. 1) There are many different levels of protocols, and HTTP is only one of them. Modern computer networking is based on something called "protocol stacking". Basically there are many different protocols acting as a payload to another protocol. Usually under HTTP there is at least two other protocols, TCP and IP. When we are encrypting a HTTP connection, we are only adding one more protocol (TLS) between the HTTP and TCP protocols. When connecting to the internet required calling the ISP with a modem, it was possible to encrypt the whole call - that way every protocol in the stack, including TCP/IP, became encrypted. With a completely encrypted protocol stack the HTTP protocol doesn't need TLS to prevent man-in-the-middle attacks, if the server also has (and it probably will have) a trusted connection to the public internet and the route of the packages between the server and the user's ISP is known. Although with modern internet connections it is unusual to have the whole protocol stack encrypted, some users may still have a completely encrypted protocol stack. In these cases it is completely acceptable to use unencrypted HTTP at least for accessing static content. 2) The route of packages is sometimes known to be safe. Often the route of the packages is also completely known (for example in intranets), and sometimes in these cases, there is even no routing to the public internet available, which makes it impossible to update the root certificates easily. Using TLS in these conditions can be troublesome. 3) Are we encrypting a wrong protocol? Adding an encryption with a certificate to the protocol stack doesn't automatically improve security. We have to understand what is the confidential data that we want to encrypt, and in what level of the protocol stack should the encryption be so that it prevents any unauthorized people from seeing the confidential data. For example, modern instant messaging platforms like Discord, Facebook, Snapchat etc. encrypt the connection between the client and the server and therefore falsely advertise themselves as "secure". However there is no end-to-end encryption, and anyone who has an access to the server can also see the messages - and this includes not only the administrators of the messaging platform but also any national intelligence agencies and other often malicious actors. The correct way to do it is to encrypt the messages (or whatever payload is transmitted between the clients) in the sender's client and then decrypt them in the receiver's client. That way the server cannot see the unencrypted content. That's also what end-to-end encryption means. Encrypting a wrong protocol without a proper reason may at best only create more overhead and consume more bandwidth and CPU time than is needed, but at worst it may create a false sense of security. 4) Self-signed certificates are normally safe, and malicious sites these days usually have "trusted" certificates. There used to be a time when malicious websites usually didn't have encryption at all, or if they had, their certificate was self-signed. Let's Encrypt changed that. Now every malicious site has a certificate that appears trusted, and there will soon be a need of having different levels of "trust", where free-of-charge certificates like the ones from Let's Encrypt will become essentially untrusted. This is a problem that cannot be solved. Self-signed certificates used to be considered fine, but now every mainstream browser shows a scary warning before entering a site with such certificate. The same will happen to the certificates from Let's Encrypt and then it will again be impossible to get a trusted certificate for free. However, there is nothing wrong with self-signed certificates as long as the browser actually shows the relevant information (the public key etc.) so that the user can make sure that the other end of the connection really is what it claims to be. When used properly, self-signed certificates are actually safer than certificates from Let's Encrypt. Showing the user nonsensical warnings like "Someone is trying to steal your credit card information!!!!11" only creates confusion and misconceptions about security. Phishing websites also did not have lookalike domains before unicode characters were allowed in domain names. That itself is much more dangerous problem than having no encryption, because it is harder to notice. 5) Allow using the site with retro hardware. People are using the internet with old hardware for variety of reasons. Some do it for fun, and some do it because they cannot afford a newer, more modern device. Continually imposing new technical requirements for accessing the site may be discriminating against these people. Sometimes the server itself can also be archaic hardware (for example a Commodore 64 or a 486 PC) for reasons. The server and/or the client computer can also sometimes have a completely homebrew software stack that is not capable of doing modern encryption. 6) Let the user decide. By convention the TCP port 80 is used to serve non-encrypted content and the port 443 is used to serve the content encrypted via TLS. There is no valid reason to change this. Web browsers, and in many cases also servers, should respect the user's choice.