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)
Tracking
()
RESOLVED
WONTFIX
Tracking | Status | |
---|---|---|
firefox44 | --- | affected |
People
(Reporter: tanvi, Unassigned)
References
(Blocks 2 open bugs)
Details
(Whiteboard: [fxprivacy])
Attachments
(1 file)
47.06 KB,
image/png
|
Details |
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.
Comment 1•9 years ago
|
||
Using a mockup from the New York Times.
Comment 2•9 years ago
|
||
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.
Comment 3•9 years ago
|
||
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.
Reporter | ||
Comment 4•9 years ago
|
||
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
Updated•9 years ago
|
Whiteboard: [fxprivacy] [triage]
Updated•9 years ago
|
Priority: -- → P3
Whiteboard: [fxprivacy] [triage] → [fxprivacy]
Comment 5•9 years ago
|
||
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.
Updated•9 years ago
|
Updated•9 years ago
|
Comment 6•8 years ago
|
||
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.
Description
•