Even more interesting: In the current Firefox nightly inputs with `type="password"` on insecure origins are being marked explicitly as insecure. This also includes common anti patterns such as loading an iframe from a secure origin on an insecure page.
There's a screenshot of this on my latest blog post[1] and another article[2] on this topic.
I am very happy to see browser vendors pushing for HTTPS adoption and forcing the hands of developers. Further highlighting poor security like this also means that users are made aware and can opt out of using websites with poor security practices.
There is (of course) a Tumblr site for sites that do this[0]
I found a bunch of local websites including utilities and email providers that do this[1] and seem completely unaware of the risk. Emailing them to explain the problem didn't help much as the vast majority simply ignored me. Hopefully this will make it into all the mainstream browsers soon because not protecting sensitive data with HTTPS is really inexcusable in 2016. It's not like it costs a lot of money to do.
Yeah, mine is a shameless copy of the Plaintext Offenders Tumblr (http://plaintextoffenders.com/) which I've known about for years, but I wish I had spotted the HTTP Shaming one earlier as I would have saved myself time and submitted the local sites there instead. Oh well.
I really love what plaintextoffenders is trying to do, but i've lost all confidence in it.
Most of the sites on there are because of things like they will email you a temporary password forcing you to change it on first login. Digital ocean has a big red banner because if you don't provide a private key, they send you a randomly generated root password for new servers you make.
FFS apple.com is on their list because someone SENT IN an email with their username and password for their phone on it, and they replied with a "work authorisation" letter that included the message they sent it...
The old plan was to enable it in Fx 44 (the one that was just released). But a couple of bugs caused a delay and it was pushed back. It was just enabled in nightly/dev builds [0], so Fx 46 will probably have it.
AFAIK and contrary to what others have said, there's no plan to enable this in a release version of Firefox anytime soon. There are too many affected sites and most average users would probably just start ignoring the crossed out lock or get scared and use some other browser.
It's in dev edition / aurora because those aren't "release" builds, and the security.insecure_password.ui.enabled default value depends on a RELEASE_BUILD ifdef. So no, it won't automatically be enabled when current aurora moves to beta.
I was under the impression that it worked like an Alpha and the intention is for features in it to eventually end up in stable unless critical problems are found in them?
This is usually true but not in this case. Or if you want to put it this way, the anticipated critical problem is that this UI would confuse average end users and thus we won't enable it for them.
Loading an iframe over http is at least not going to expose the users password to a passive attacker. I would really hate if we repeated the error whereby sites signed with non root ca keys got marked with a big scary error, because it wasn't as secure as it could be.
There's a screenshot of this on my latest blog post[1] and another article[2] on this topic.
I am very happy to see browser vendors pushing for HTTPS adoption and forcing the hands of developers. Further highlighting poor security like this also means that users are made aware and can opt out of using websites with poor security practices.
1: https://hugotunius.se/2016/01/24/how-browser-vendors-are-pus...
2: https://www.fxsitecompat.com/en-CA/docs/2015/non-https-sites...