Closed Bug 1319119 Opened 5 years ago Closed 5 years ago
Turn on Insecure Password Warning in Firefox Release
+++ This bug was initially created as a clone of Bug #1301772 +++ This bug is to move the Insecure Password Warning (in the URL bar) to release from beta. (follow-on from Bug #1301772) Because the change is relatively low risk (from a user perspective), particularly now that Chrome will also be shipping something similar in January, we feel like we are in a good place to move to release. The stronger UI (in context, which is a number of the child bugs under Bug #1217142) will go through some testing (via Heartbeat) first to ensure it does as intended. The strategy for getting more developers to move to HTTPS is as follows: - Do a Heartbeat study on how users would perceive the in-context insecure password UI - Publish the results of that study, targeted at developers (encouraging them to move to HTTPS) and a description of the changes that are coming - Roll out this (more minor) change in v51 - In a future release, roll out the in-context UI changes
[Tracking Requested - why for this release]: This bug requires a pref change that will have to be uplifted to Firefox 51 (Nightly->Aurora->Beta). It requires flipping this to true for release - security.insecure_password.ui.enabled http://searchfox.org/mozilla-central/source/browser/app/profile/firefox.js#1217
Posted the site compatibility doc for developers: https://www.fxsitecompat.com/en-CA/docs/2016/insecure-password-input-warning-will-be-enabled-by-default/
Comment on attachment 8821648 [details] [diff] [review] Bug1319119.patch Review of attachment 8821648 [details] [diff] [review]: ----------------------------------------------------------------- ::: browser/app/profile/firefox.js @@ +1219,1 @@ > pref("security.insecure_field_warning.contextual.enabled", false); Nit: it's not just http pages, it's any insecure login fields Nit: in-content How about: // Warning shown in autocomplete popups for insecure login fields
Attachment #8821648 - Flags: review?(MattN+bmo) → review+
I moved the comment to bug 1217152, to avoid any conflicts. Carrying over r+. I'll mark this checkin needed, and it needs to make it all the way up to beta 51.
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/39b68f145d7c Show degraded security UI for HTTP pages with password fields in release. r=MattN
Comment on attachment 8821697 [details] [diff] [review] Bug1319119-12-23-16B.patch Approval Request Comment [Feature/Bug causing the regression]: https://bugzilla.mozilla.org/show_bug.cgi?id=1304224 [User impact if declined]: We won't be able to warn users about insecure login pages in Firefox 51, as planned/scheduled [Is this code covered by automated tests?]: Yes - http://searchfox.org/mozilla-central/source/browser/base/content/test/general/browser_insecureLoginForms.js [Has the fix been verified in Nightly?]: Yes, its been turn on in Nightly for a year. [Needs manual test from QE? If yes, steps to reproduce]: No [List of other uplifts needed for the feature/fix]: Uplift to aurora 52 and beta 51. [Is the change risky?]: No risk to tahe codebase/quality. This changes user experience though, because now we will show a lock with a strikethrough on HTTP pages with password fields in release (and not just in beta, aurora, and nightly). But that change of UX is intended. [Why is the change risky/not risky?]: It is just a pref change. The pref was enabled in beta, and now it will be enabled everywhere. [String changes made/needed]: No
Comment on attachment 8821697 [details] [diff] [review] Bug1319119-12-23-16B.patch Looks like this was tested and verified in beta 50 and aurora 51, in bug 1301772. OK to uplift this patch to beta to turn on the pref for release. This should land in beta 11 next week. Andrei, can your team test and verify the behavior next week ?
hi gerry, this bug has a pending request to be considered in the release notes for firefox 51. we could link to this article on sumo: https://support.mozilla.org/kb/insecure-password-warning-firefox or https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-over-http-please/
(In reply to [:philipp] from comment #13) > hi gerry, this bug has a pending request to be considered in the release > notes for firefox 51. > we could link to this article on sumo: > https://support.mozilla.org/kb/insecure-password-warning-firefox or > https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-over-http-please/ See also bug 1330152 comment 2
Added to the release notes using "A warning is displayed when a login page does not have a secure connection" as wording
I managed to reproduce this issue on Firefox 50.1.0, under Windows 10x64. The warning is correctly displayed on Firefox 51.0, Firefox 52.0a2 (2017-01-20), Firefox 53.0a1 (2017-01-20). Tests were performed under Windows 10x64, Mac OS X 10.12, Ubuntu 16.04x64.
Hi there! I have had a go at documenting the new password security features on MDN. Please let me know if the below pages make sense, or if I have got version numbers (etc.) wrong. I was a bit unsure in a couple of places. I've updated the insecure passwords page to mention the new features, and given it a general style and edit: https://developer.mozilla.org/en-US/docs/Web/Security/Insecure_passwords I've added notes to the reference pages https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/password https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/password#Browser_compatibility (Note that the browser compat table entries have only been put on the specific input/password page, as I thought they'd just get lost in the general input page (that page is a mess anyway, and needs updating at some point) I've added a note to the password section on our form element type tutorial: https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms/The_native_form_widgets#Password_field I've added notes to the relevant Firefox release notes. The cross out lock in the address bar has been mentioned in the Firefox 51 release notes: https://developer.mozilla.org/en-US/Firefox/Releases/51#Security While the in-context warning and disabled autofill have been mentioned in the Firefox 52 release notes: https://developer.mozilla.org/en-US/Firefox/Releases/52#Security
Thanks Chris! From a very quick read this looks correct to me. Note that the screenshots under https://developer.mozilla.org/en-US/docs/Web/Security/Insecure_passwords#Web_Console_Messages are out of date since the identity block and the DevTools look a bit different now. Thanks for the help!
Thanks Chris, I updated the screenshots that Johann mentioned but wasn't sure how to delete the old screenshot attachments. I also added a note to https://developer.mozilla.org/en-US/docs/Web/Security/Insecure_passwords clarifying that all ancestor frames have to also be secure. i.e. an HTTPS login form inside a frame on an HTTP document isn't secure. I wasn't sure how to say this without too much jargon. In general I think we should be careful not only only talk about the security of the document the form is in.
(In reply to Matthew N. [:MattN] (behind on bugmail; PM if requests are blocking you) from comment #19) > Thanks Chris, > > I updated the screenshots that Johann mentioned but wasn't sure how to > delete the old screenshot attachments. > > I also added a note to > https://developer.mozilla.org/en-US/docs/Web/Security/Insecure_passwords > clarifying that all ancestor frames have to also be secure. i.e. an HTTPS > login form inside a frame on an HTTP document isn't secure. I wasn't sure > how to say this without too much jargon. In general I think we should be > careful not only only talk about the security of the document the form is in. Thanks a lot Matt (and thanks to Johann for pointing out the screenshots!) I think your description was pretty good (I just tweaked it slightly). If there are other details you feel are needed, feel free to write out some quick notes for me to wordsmith.
Implementation is incorrect, see https://bugzilla.mozilla.org/show_bug.cgi?id=1354549
You need to log in before you can comment on or make changes to this bug.