This looks like a duplicate of bug 1179961.

This is just a user story bug to track work. No work will be done in this bug.

(In reply to Marco Mucci [:MarcoM] from comment #0) > Created attachment 8639531 [details] > Warning for password on non-secure connection.jpg Is this enabled in current Nightly?

(In reply to Paul Silaghi, QA [:pauly] from comment #3) > Is this enabled in current Nightly? Yes. Some new outlets are already covering this and people are tweeting. Posted the site compatibility document for Web developers: https://www.fxsitecompat.com/en-US/docs/2015/non-https-sites-containing-login-form-will-be-marked-insecure/

> Some new outlets are already covering this and people are tweeting. s/new/media/

Moving the keywords over Bug 1179961.

Tanvi, you mentioned that there is a bug that holds this on Nightly - which bug is that? I'd like to make sure we don't ship this on Fennec if it's not ready - I didn't realize that this feature had a Nightly flag on it, oops. Also, I've noticed that there are a lot of websites where there isn't even a password in the "View source" that trigger this - this is very true of any webcomics that have a Disqus login (which pops up a separate https window for logging in). e.g., http://www.headlessbliss.com/comic/page-96#disqus_thread Is this expected, and if it is, is there some way we can scale this back? I think over-firing is pretty bad in this case, because it erodes the impact of this signal.

(In reply to Chenxia Liu [:liuche] from comment #7) > Tanvi, you mentioned that there is a bug that holds this on Nightly - which > bug is that? I'd like to make sure we don't ship this on Fennec if it's not > ready - I didn't realize that this feature had a Nightly flag on it, oops. Hi Chenxia, Sorry, this all happened kind of last minute. Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1217156 adds a pref for insecure password warnings. It is restricted to Nightly right now. I want to turn it on in Developer Edition soon but need two bugs fixed first to avoid warning fatigue by developers: https://bugzilla.mozilla.org/show_bug.cgi?id=1217766 - don't warn for pdf.js https://bugzilla.mozilla.org/show_bug.cgi?id=1217133 - don't warn for localhost I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1221206 to turn the feature on for dev edition. > > Also, I've noticed that there are a lot of websites where there isn't even a > password in the "View source" that trigger this - this is very true of any > webcomics that have a Disqus login (which pops up a separate https window > for logging in). > > e.g., http://www.headlessbliss.com/comic/page-96#disqus_thread > > Is this expected, and if it is, is there some way we can scale this back? I > think over-firing is pretty bad in this case, because it erodes the impact > of this signal. The warning appears if there is a password field anywhere on the page or in its subframes, even if it is hidden. This bug was proposed to change that behavior: https://bugzilla.mozilla.org/show_bug.cgi?id=1216802 And this was also filed to show some more context when the user is actually about to enter into the password field: https://bugzilla.mozilla.org/show_bug.cgi?id=1217150 https://bugzilla.mozilla.org/show_bug.cgi?id=1217162 For mobile, I think you should also turn the pref off for everything but nightly and uplift. Please let me know if you have any other questions. Thanks Chenxia!

I think the key point is that this is a HOSTING problem, not a software problem. Typically the maintainers of Disqus, Joomla or whatever Web software do not have any control over whether http or https is used on client installations, so there nothing to be gained by saying their software is insecure. It is neither secure nor insecure in this context, because it is not the service component at fault. The webhost is the service component lacking security. I guess CMS authors could include a trap which prevents their software being run on non-https connections, but doing so would be a foot-shooting exercise.