Closed Bug 1216802 Opened 9 years ago Closed 8 years ago

Detect when password elements are visible on a page

Categories

(Firefox :: Security, defect, P3)

44 Branch
defect

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox44 --- affected

People

(Reporter: tanvi, Unassigned)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [fxprivacy])

Attachments

(1 file)

Should we show degraded UI when a password field is not visible on a page? For example, go to http://www.nytimes.com/ and you see the degraded UI (lock with strike through). The user may have no intention of logging in and may not ever click on the login button on the top right[1]. So why are we bothering them with this struck through lock? On the other hand, assume the user see's the globe in the url bar. Then they decide to login and click the login button. They are focused on completing the action of logging in. They see an overlay (not a page reload just the overlay) and focus on that and type their username and password. If we wait to change the globe to a stuck-through lock at that point, we are probably too late. Is there a way we can tell if a password field is visible? These are the tips I received[2]. [1] The login button on the top right is actually a display:none div on the page. [2] https://developer.mozilla.org/en-US/docs/Web/API/Document/elementFromPoint document.getElementById('password-field').getBoundingClientRect().bottom is 0 when the field isn't visible, and it's some other number when it is (and that number _should_ be <= document.documentElement.clientHeight). Also check visibility, display elements, and opacity.
Attached image Password Insecure Icon
Using a mockup from the New York Times.
I think this is a pretty complicated proposal, both because there are a ton of weird edge cases and to do that, we would need to have some kind of new UI to indicate what is happening when the password field does come into the viewport. I don't think any of our users are trained to look for the URL lock icon except for when the page is immediately loaded. Perhaps we could put the insecure icon on the password field itself, with some kind of warning (not a popup) indicating that entering in a password would be insecure? I'd love to combine this with disabling the ability of Javascript to read keypresses or the value of the password fields, but that would likely cause significant page breakage at this point. So something like this on the top, when clicking on a password field: http://brampitoyo.github.io/fx-untrusted-connection/untrusted-connection-warning-ui.png And something like the Password Insecure Icon attachment the password field itself.
If we did go with the warning banner route, I think it should display that warning as soon as they click on *any* field in the <form> element that contains the password <input>, and not just when the click on the password field itself.
Blocks: 1217142
Thanks for your input April. For the mock on the attached patch, I too experimented with something like that years ago. The problem was that sometimes it would end up on top of placeholder text, or on top of an icon the website may have put in, or cover part of the password "***" as the user was entering their password. We are discussing adding more contextual feedback and have a couple bugs filed for it: https://bugzilla.mozilla.org/show_bug.cgi?id=1217150 https://bugzilla.mozilla.org/show_bug.cgi?id=1217162
Whiteboard: [fxprivacy] [triage]
Priority: -- → P3
Whiteboard: [fxprivacy] [triage] → [fxprivacy]
Since my understanding is that this UI will be targeted at developers and only on Nightly+DevEdition (hopefully that's filed), I think this bug should be WONTFIX since it's reporting a real problem even if not visible as those hidden fields can still get autofilled.
Blocks: 1221206
No longer blocks: 1221206
Blocks: 1216897
No longer blocks: 1217142
Blocks: 1188121
Blocks: 1217142
No longer blocks: 1188121
Blocks: 1240829
No longer blocks: 1216897
We're going to do contextual feedback on the field (bug 1217162) and since I think most users won't notice the address bar warning I think some false positives are fine compared to the complexity of implementing this bug.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: