User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.75 Safari/537.36 Steps to reproduce: Chrome v62 now shows a Not Secure warning for any user input on HTTP pages whilst Firefox only shows this for cc/password fields. A site has already been found trying to exploit this by presenting a password input field as a text field with a font set to make it look like a password field: https://twitter.com/troyhunt/status/925462678516019200 Actual results: User is not informed about insecure nature of input on HTTP pages. Expected results: Firefox should warn users about any input on a HTTP page.

Confirmed in Nightly 58 x64 20171030103605 de_DE @ Debian Testing. STR 1. open http://www.shopcambridge.ca/ 2. click on the user icon on the top right corner 3. there is an http:// login form without any warning

It does seem reasonable to consider extending the current warning to either: * any HTTP page with free-form text input (i.e., textarea, input type=text, type=password, or any other form inputs that take entered text), or * any HTTP page with form submission and it's perhaps worth trying to extend to match the set of cases that Chrome warns on. It could perhaps even be extended to pages that process key events or text input events (although in that case it's less clear where to show the warning). However, it's worth noting that pages have nearly arbitrary ability to work around this sort of thing. The web platform has primitives that allow rebuilding things like text inputs (probably with many bugs) and form submission. So sites that really want to avoid the warning will always be able to do so, as long as the warning doesn't warn for all uses of HTTP. So I think this warning needs to be seen as encouragement to switch to HTTPS, and not as a reliable security indicator.

Marking moco-confidential to avoid drive-by comments.

We should file a public bug for the concept of "mark insecure for all inputs", without the links to this particular website. Then we can dupe this over that.

What not secure warning are we talking about? The in-context warning or the one in the identity block (next to the urlbar)? I'll operate under the assumption that we're talking about the former and close this as WONTIFX based on the precedent set in bug 1345400. dbaron already states the primary reason in comment 2. This is a cat-and-mouse game and extending this warning more and more leads us down the dangerous path of annoying and spamming our users. It's important to understand, this warning is very in-your-face and has an extremely strong effect on both users and website owners. Currently, public opinion seems to be in our favor and blame tends to get shifted on website owners (though we got our fair share of reports of people switching to IE because "the site is secure there"). We should not give people reason to say Firefox is overzealous and annoying. I think that constant alert hurts our cause much much more than a few bad sites that work around this (and make for amusing Twitter posts, admittedly). Because of its strong effect, this warning is a web compatibility issue and should be considered similarly to disabling features on HTTP. I would like to live in a world where we can effectively disable inputs on HTTP but we're not there yet. Let's focus on moving forward with putting a warning sign in the identity block for all insecure websites (bug 1310447), even without any kind of input. Since we're currently aiming to do that (we're rolling out experiments around it) it doesn't seem very useful to keep a bug open for showing the identity block warning for any input type, either, since that will just get overridden soon(TM). Also, can't we just restrict comments on this bug instead of making it moco-private?

> Also, can't we just restrict comments on this bug instead of making it moco-private? Yes, we can, and imo we should. Kit, any objections?

(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #6) > Kit, any objections? None at all! I just marked it private based on a request from #firefox on Slack. Restricting comments sounds like the better thing to do here, though I don't think I have permission to set that flag. Would you mind doing that?