Closed
Bug 1319119
Opened 8 years ago
Closed 8 years ago
Turn on Insecure Password Warning in Firefox Release
Categories
(Firefox :: Security, defect, P1)
Tracking
()
VERIFIED
FIXED
Firefox 53
People
(Reporter: pdol, Assigned: tanvi)
References
Details
(Keywords: dev-doc-complete, site-compat, Whiteboard: [fxprivacy])
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
tanvi
:
review+
lizzard
:
approval-mozilla-aurora+
lizzard
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
+++ 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
Updated•8 years ago
|
relnote-firefox:
--- → ?
Keywords: dev-doc-needed
Assignee | ||
Comment 1•8 years ago
|
||
[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
tracking-firefox51:
--- → ?
Comment 3•8 years ago
|
||
Posted the site compatibility doc for developers: https://www.fxsitecompat.com/en-CA/docs/2016/insecure-password-input-warning-will-be-enabled-by-default/
Assignee | ||
Updated•8 years ago
|
status-firefox52:
--- → affected
Updated•8 years ago
|
Assignee | ||
Comment 4•8 years ago
|
||
Attachment #8821648 -
Flags: review?(MattN+bmo)
Comment 5•8 years ago
|
||
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+
Assignee | ||
Comment 6•8 years ago
|
||
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.
Attachment #8821648 -
Attachment is obsolete: true
Attachment #8821697 -
Flags: review+
Assignee | ||
Updated•8 years ago
|
Keywords: checkin-needed
Pushed by tvyas@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/39b68f145d7c
Show degraded security UI for HTTP pages with password fields in release. r=MattN
Keywords: checkin-needed
Assignee | ||
Comment 8•8 years ago
|
||
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
Attachment #8821697 -
Flags: approval-mozilla-beta?
Attachment #8821697 -
Flags: approval-mozilla-aurora?
Comment 9•8 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 53
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 ?
Flags: needinfo?(andrei.vaida)
Attachment #8821697 -
Flags: approval-mozilla-beta?
Attachment #8821697 -
Flags: approval-mozilla-beta+
Attachment #8821697 -
Flags: approval-mozilla-aurora?
Attachment #8821697 -
Flags: approval-mozilla-aurora+
Comment 11•8 years ago
|
||
bugherder uplift |
Comment 12•8 years ago
|
||
bugherder uplift |
Comment 13•8 years ago
|
||
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/
Flags: needinfo?(gchang)
Comment 14•8 years ago
|
||
(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
Comment 15•8 years ago
|
||
Added to the release notes using "A warning is displayed when a login page does not have a secure connection" as wording
Comment 16•8 years ago
|
||
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.
Status: RESOLVED → VERIFIED
Comment 17•8 years ago
|
||
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
Flags: needinfo?(pdolanjski)
Keywords: dev-doc-needed → dev-doc-complete
Comment 18•8 years ago
|
||
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!
Comment 19•8 years ago
|
||
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.
Comment 20•8 years ago
|
||
(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.
Reporter | ||
Updated•8 years ago
|
Flags: needinfo?(pdolanjski)
Comment 21•8 years ago
|
||
incorrect |
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.
Description
•