Did you know that there are still valid use cases for devices that have less 512kb of ram that can be access over http?

I did. I work with these, time permitting. For these devices we have a range of options, including having the central station support plain HTTP, or having a special legacy mode in the browser. These devices should not hold back HTTPS adoption on the web.

Edit: I bet there are 1000x more IE6 users, than users of these devices. Shall we support IE6 until every single of it's users upgrade?

We're not talking about some JS framework but about an established internet protocol. If I want I can spend time and still support IE6 users, and no browser will prevent me from doing that. That's not the case with this proposal.

I've worked on this kind of device. You can rarely use them directly anyway, you need some kind of reverse-proxy/caching to use them otherwise they will crash if to many people are connecting on it directly. Anyway, these kind of device are rarely connected to the outside world so on the worst case, HTTP is still not a problem on an internal network.

I work with them every day, and the point of having HTTP server is not to allow many people to connect to them but one person, or script to do it once in a blue moon without a need to install any software. If HTTP is removed from browsers, this will simply not be possible anymore

Look, you are clearly a minority (developer who works with HTTP-enabled limited RAM devices). Why should we hold back the progress of the web to cater to your very specific use case? Why should my grandmother be subjected to phishing attacks and injected ads because your situation would be slightly inconvenienced by dropping plain HTTP from popular browsers?

Also, you are a developer. I am sure we can figure out some way for developers to re-enable plain HTTP in some hidden settings. That way people like you and me can continue to do what we do, while the rest of the web users are enjoying the benefits of being more secure by default.

Why should my embedded system have to support unnecessary functionality? Just so your grandmother is safer from phishing attack?

I'm a developer, but my clients are not.

Nobody is asking your embedded systems to support unnecessary functionality. At worst, you are going to have to one time go to about:config and change enable_plain_http from 0 to 1. Then for you life goes on as before. Is that too much to ask for much greater security for everyone involved?

Just like I can disable javascript? Oh wait, I can't! Does having ftp support in firefox affect anyone's security? Getting rid of HTTP will in best case make people think that they are more secured, that's all. Most of the malware that is active today propagates not because HTTP is unsecure, but because we made the web an Advertisement Delivery System. Malware now attacks browsers, through Flash, Javascript and Java.. first fix this before you start working on getting rid of an established protocol.

Once again, telnet was an established protocol, yet we got rid of it. I am sure people presented passionate arguments in favor of keeping telnet forever, saying that there are other threats on the Internet.

Getting rid of HTTP will make people more secure. It will ensure that basically all sites people visit will be protected by a trusted cert.

Note that nobody is talking about installable malware here. We are talking about protecting the web. For example, if your connection to news.ycombinator.com is protected by HTTPS, this makes it that much more difficult for the NSA to spy on you, or for me to insert a goatse into the content while you are at work, and I am sitting in the next office over form you.

> Once again, telnet was an established protocol, yet we got rid of it.

No we didn't. Telnet is still pervasive as a communications protocol, partly because of its simplicity and partly because of its momentum. This is particularly true in the realm of embedded devices; even rather-modern enterprise-grade HP printers (for example) open up a Telnet port for terminal-driven configuration by default.

The analogy doesn't seem close to me. The problem with telnet is that it was used for connections intended to be authenticated, but they were authenticated very poorly, by sending a cleartext login/password. That is easy to compromise, so it needed to be replaced with a better authentication method. If telnet were normally used without any authentication at all, e.g. only for guest-type access to BBSs, then the case to replace it would have been much weaker.

The analogous case might be if you're doing plaintext password authentication over HTTP. I agree that for that use-case you should switch to HTTPS.

I wholeheartedly disagree. Any content should be delivered over an encrypted channel because any content site can be used to launch an attack on the user os site owner if the data in transit can be tempered with. Passwords and session keys are just a small subset (though admittedly a valuable one) of the stuff you may go after. For example, do you want the FBI putting you on a tracking list because you googled something they consider suspicious just out of curiosity? Do you want a rival of yours messing with how your resume you publish on your personal site is presented to Google or potential employees. Do you want to read man pages that tell you how to run commands over an unauthenticated connection? Do you want Pillsbury to double the amount of their ingredients you need for a chicken pot pie? There is almost no use case where content should remain unprotected.

Apple.com is a great example of this. It's served over plain HTTP, and likes to http://store.apple.com. Can I intercept that link and send you to http[s]?://store.appl.com or http[s]://store.apple.con? I can then grab your credit card. Heck, I could process your order so you won't even know something went wrong. Or how would it look if suddenly people started getting a goatse instead of the latest video of Jony Ivy tilting his head to the side?

Then your issue is with sites that host content on http, and the solution is to address the content hosts—not deprecate a protocol. Besides, If you can MITM http then you can probably do the same for DNS, so https doesn't really solve the attack vector you mention.

Finally, Read this thread for use cases for http. They may not apply for you, but are sufficient that I think we can keep http around for awhile longer.

There are no use cases where HTTP is more capable than HTTPS. There are some hurdles in dropping HTTP, but HTTPS is a strict improvement for almost all cases. The only argument I can see for plain HTTP is legacy devices that no longer receive updates. For these, a UI similar to the self-signed cert warning will work.

My problem is that we still allow plain HTTP. That should never be the case, just like we should not use telnet for remote server access.

DNS hijacking is a problem. It is a problem at a different layer of the system. Just because that layer is vulnerable, does not mean that we should leave a gaping security hole at a different layer. I don't buy the argument that we must have perfect security or no security. Besides, there are ways to mitigate the DNS hijacking issue, such as the HSTS header.