In order to provide feedback to users that try to login when login fields are hosted over http, we want to show a contextual message when the login field is focused that explains to users that their login and password could be compromised.

Here we will have to consider interaction with Password Manager if the user has a saved password on an HTTP page. How do we steal focus? How do we focus on the autocomplete UI for Password manager, etc.

Initial prototype of proposed design: https://invis.io/8A4NGNKQK Suggest investigating if we can let users check for an https version by opening a new tab with an https version of the url like shown here: https://www.dropbox.com/s/nq5rrn2jydgpam7/state%202b.png?dl=0

invision prototype is linked in comments section

Nice and quick work Aislinn!

Added some comments to the InVision page.

I'll defer to shorlander on visual design, but I agree it should match some existing UI. How sophisticated should the warning be? If there is both a username and password field, should it only show on the first one that is given focus? When the user dismisses the warning, should it be remembered? (there is engineering cost if yes) Will this warning be shown to localhost sites too?

(In reply to Ryan Feeley [:rfeeley] from comment #6) > Will this warning be shown to localhost sites too? We don't want to show to localhost sites, even though we do today: https://bugzilla.mozilla.org/show_bug.cgi?id=1217133

(In reply to Ryan Feeley [:rfeeley] from comment #6) > I'll defer to shorlander on visual design, but I agree it should match some > existing UI. > > How sophisticated should the warning be? If there is both a username and > password field, should it only show on the first one that is given focus? > > When the user dismisses the warning, should it be remembered? (there is > engineering cost if yes) > > Will this warning be shown to localhost sites too? Ideally this only shows one time for initial focus of the login or password field but not both. Will chat with the eng team to see how feasible this is.

Final wireframes are here: https://invis.io/8A4NGNKQK Suggest investigating if we can let users check for an https version by opening a new tab with an https version of the url like shown here: https://www.dropbox.com/s/nq5rrn2jydgpam7/state%202b.png?dl=0

Another question: if I use a 3rd party password manager that autofills for me, what is the experience? I'm guessing on first attempt the warning will appear on the username field and has to be dismissed forcing the user to try again. Make sense?

(In reply to Ryan Feeley [:rfeeley] from comment #10) > Another question: if I use a 3rd party password manager that autofills for > me, what is the experience? I'm guessing on first attempt the warning will > appear on the username field and has to be dismissed forcing the user to try > again. Make sense? The trigger is focusing of the form field so if the 3rd party focuses it to auto-fill or the user focuses it to manually enter in something we show the dialogue.

Matt, Mike, and I had a couple questions on the design here during a meeting yesterday- https://mozilla.invisionapp.com/share/8A4NGNKQK#/screens/110083709. We were wondering why we have 2 separate dropdown boxes (insecure password warning and password manager autocomplete UI). We could potentially use 1 box with the insecure password warning at the top. But, on further reflection, I lean towards Aislinn's 2 box model, even if it requires a little more implementation work. In the 2 box model, the insecure password warning is distinct from password manager autocomplete UI. User receives it on focus and it only disappears when user clicks X or hits escape. If the warning comes up while the user is selecting their username, they may just ignore it and quickly select their username. (Though, conversely it could be argued that they would also ignore the first box and X out if it quickly.) The 2 box model warning appears on both the username and the password field, so if we are on a page where the username is prepopulated, the user will still get the warning. Because we need it to appear on the password field (which currently doesn't have autocomplete UI), we'd have to make the second box anyway, even if we added it to the autocomplete UI for the username field. (Unless of course we add autocomplete UI to the password field before we get to this bug.) Also, if we go with the 1 box model, we would have to change when the autocomplete UI for usernames comes up to be on first focus (instead of second focus, as it is today). Which is okay with me. Using the 1 box model seems to have a few more dependencies then using the 2 box model, which we could do right away and pref on for dev edition. Aislinn may be able to provide more reasons why she choose a 2 box model. Thanks!

You said it yourself - its to keep it distinct in appearance and behavior from the auto-fill/saved passwords UI. Also, guessing for users that don't have saved passwords it provides feedback that would not show if it was built into the passwords UI?

(In reply to agrigas from comment #13) > You said it yourself - its to keep it distinct in appearance and behavior > from the auto-fill/saved passwords UI. > Also, guessing for users that don't > have saved passwords it provides feedback that would not show if it was > built into the passwords UI? We would make sure to show it for users who don't use password manager or don't have saved passwords for that domain. It just wouldn't have anything under the insecure password message. But it sounds like you prefer the 2 box model, so we will go with that. Thanks!

Using two boxes will create an interdependency between the autocomplete popup and the warning as I assume we wouldn't want to show both overlapping. Using the existing dropdown avoids that complexity. There is no need to take shortcuts at this point so IMO so we should have the warning at the top of autocomplete which means eventually fixing bug 376668 and bug 1289913. If people want to push for 2 distinct boxes then all of the keyboard, mouse and focus interactions should be defined and I think it will be apparent that it's very complex/fragile unless it's implemented as part of the autocomplete popup.

(In reply to Matthew N. [:MattN] from comment #15) > Using two boxes will create an interdependency between the autocomplete > popup and the warning as I assume we wouldn't want to show both overlapping. > Using the existing dropdown avoids that complexity. > > There is no need to take shortcuts at this point so IMO so we should have > the warning at the top of autocomplete which means eventually fixing bug > 376668 and bug 1289913. > > If people want to push for 2 distinct boxes then all of the keyboard, mouse > and focus interactions should be defined and I think it will be apparent > that it's very complex/fragile unless it's implemented as part of the > autocomplete popup. A few questions - if the warning did overlap the existing dropdown for users with saved passwords would that be easy to implement? If so, we may want to test it out because it may not look that bad and would provide the focus on the warning before the dropdown contents in the way the two box approach does. Second, in an approach that had the warning in the dropdown - what would happen for users that have no saved passwords? We would still show the dropdown on field focus? Third, if we did the warning in the dropdown - how much styling control do we have to make it pop out from the list of saved passwords. The list itself makes it easy to overlook the warning since it most likely will just look like another row element and the styling won't call much attention to it is my concern...

(In reply to agrigas from comment #16) > (In reply to Matthew N. [:MattN] from comment #15) > > Using two boxes will create an interdependency between the autocomplete > > popup and the warning as I assume we wouldn't want to show both overlapping. > > Using the existing dropdown avoids that complexity. > > > > There is no need to take shortcuts at this point so IMO so we should have > > the warning at the top of autocomplete which means eventually fixing bug > > 376668 and bug 1289913. > > > > If people want to push for 2 distinct boxes then all of the keyboard, mouse > > and focus interactions should be defined and I think it will be apparent > > that it's very complex/fragile unless it's implemented as part of the > > autocomplete popup. > > A few questions - if the warning did overlap the existing dropdown for users > with saved passwords would that be easy to implement? If so, we may want to > test it out because it may not look that bad and would provide the focus on > the warning before the dropdown contents in the way the two box approach > does. Yes, I think that would be easy to implement. Definitely easier than having two boxes and avoiding them both being open at the same time. > Second, in an approach that had the warning in the dropdown - what would > happen for users that have no saved passwords? We would still show the > dropdown on field focus? Yes, this was already answered by tanvi in comment 14 so that's why I didn't bring it up again. > Third, if we did the warning in the dropdown - how much styling control do > we have to make it pop out from the list of saved passwords. The list itself > makes it easy to overlook the warning since it most likely will just look > like another row element and the styling won't call much attention to it is > my concern... We should be able to style it however we want. It may be slightly easier if we stick to an image in the left column and some text beside it but I think we'll want multi-line text in which case we'll be doing custom styling anyways and we can do whatever we want. We're already adding a custom footer for saved passwords which is different than a normal row[1]. This would basically be a custom header that appears in certain conditions. [1] https://reviewboard.mozilla.org/r/64630/file/320/

(In reply to Matthew N. [:MattN] from comment #17) > (In reply to agrigas from comment #16) > > (In reply to Matthew N. [:MattN] from comment #15) > > > Using two boxes will create an interdependency between the autocomplete > > > popup and the warning as I assume we wouldn't want to show both overlapping. > > > Using the existing dropdown avoids that complexity. > > > > > > There is no need to take shortcuts at this point so IMO so we should have > > > the warning at the top of autocomplete which means eventually fixing bug > > > 376668 and bug 1289913. > > > > > > If people want to push for 2 distinct boxes then all of the keyboard, mouse > > > and focus interactions should be defined and I think it will be apparent > > > that it's very complex/fragile unless it's implemented as part of the > > > autocomplete popup. > > > > A few questions - if the warning did overlap the existing dropdown for users > > with saved passwords would that be easy to implement? If so, we may want to > > test it out because it may not look that bad and would provide the focus on > > the warning before the dropdown contents in the way the two box approach > > does. > > Yes, I think that would be easy to implement. Definitely easier than having > two boxes and avoiding them both being open at the same time. > > > Second, in an approach that had the warning in the dropdown - what would > > happen for users that have no saved passwords? We would still show the > > dropdown on field focus? > > Yes, this was already answered by tanvi in comment 14 so that's why I didn't > bring it up again. > > > Third, if we did the warning in the dropdown - how much styling control do > > we have to make it pop out from the list of saved passwords. The list itself > > makes it easy to overlook the warning since it most likely will just look > > like another row element and the styling won't call much attention to it is > > my concern... > > We should be able to style it however we want. It may be slightly easier if > we stick to an image in the left column and some text beside it but I think > we'll want multi-line text in which case we'll be doing custom styling > anyways and we can do whatever we want. We're already adding a custom footer > for saved passwords which is different than a normal row[1]. This would > basically be a custom header that appears in certain conditions. > > [1] https://reviewboard.mozilla.org/r/64630/file/320/ Ok - my preference would be a second box that overlapped the existing password drop-down but if that is significantly more work to implement then we can just restyle the existing drop-down header row...

(In reply to Ash Grigas from comment #18) > Ok - my preference would be a second box that overlapped the existing > password drop-down but if that is significantly more work to implement then > we can just restyle the existing drop-down header row... I spoke to Matt about this and it does seem like a 2 phased warning would be a lot more complicated to implement. Philipp, can you modify this mockup? https://mozilla.invisionapp.com/share/8A4NGNKQK#/screens/110083709 We'd have two potential flows: * User doesn't have a password saved for that domain; in that we would just have State 1 and State 2. * User does have a password saved for that domain; in that case we would have a State 3 that included the insecure message as the first entry in the drop down. * I think state 2b is the case where there is no username field, but just a password field. Also, do we want to add a Learn More link here? There is one in the Control Center, but requires a few clicks to get to. Reopening, since we are revisiting a few things here.

Please see comment 19. Thanks!

I don't have write access to that Invision project unfortunately (and I can't find where I can change that), so this is slightly improvised. I'm assuming that this is the kind of state that is missing, right?

Thanks for the mockup Philipp! Yes, I was imagining something like this, but still have a bunch of questions/thoughts: * What does the x do? Maybe we should remove it here. Some users might think it closes the whole autocomplete UI, which it doesn't. * If we remove the X, we may not need to color code the warning in grey and the drop down in white (you may be able to use the same color). Up to you - depends on what looks better visually. * Should we add a Learn More link?

(In reply to Tanvi Vyas [:tanvi] from comment #22) > * What does the x do? Maybe we should remove it here. Some users might > think it closes the whole autocomplete UI, which it doesn't. Didn't think so far, my bad. I removed the x, assuming that the warning will disappear when a user unfocuses the text field. > * If we remove the X, we may not need to color code the warning in grey and > the drop down in white (you may be able to use the same color). Up to you - > depends on what looks better visually. It makes sense to style it differently since the message is qualitatively different from the other items in that list. So let's keep the gray background. > * Should we add a Learn More link? Was going back and forth on this, but it probably makes sense.

Thanks Philipp! One more question... Assume a form has a username and password field. Assume the user doesn't have passwords stored in the password manager. The user enters their username and see's the warning message. They continue to type "Username". Then they go to the password field and begin to type their password. Should the password field also show the warning? On one hand, that is the more sensitive piece of information. On the other, the password field is sometimes filled in without the user having to interact with it (i.e when the user has a login saved and autocompletes their username). So we could say that the warning appears on the password field unless the user has a saved login for that page. If the user has one or more saved logins, the warning appears on the username field. This does get confusing though, both from an implementation standpoint and from a user experience standpoint. Without consider the above question, here are some details on what I think different cases would look like based on the attachment you provided: 1) If the user has saved passwords for the insecure domain, show the insecure message followed by the list of usernames in the username field. 2) If the user does not have saved passwords for the insecure domain, show the insecure message as the user types into the username field. 3) If there is no username field (just password field), show the insecure message as a drop down to the password field as the user types their password. Thanks!

Answering in reverse order here... (In reply to Tanvi Vyas [:tanvi] from comment #24) > 1) If the user has saved passwords for the insecure domain, show the > insecure message followed by the list of usernames in the username field. > 2) If the user does not have saved passwords for the insecure domain, show > the insecure message as the user types into the username field. > 3) If there is no username field (just password field), show the insecure > message as a drop down to the password field as the user types their > password. I think we can show the warning on both fields. So if the user has the username field focused, we show it there; if the user has the password field focused we show it there. Worst case is that the user gets to see the warning twice. So regardless of what field the user focuses and regardless of whether or not something has been autofilled, we would always show the warning (with an optional list of usernames for saved logins).

Should it be "This connection is not secure"?

(In reply to Ryan Feeley [:rfeeley] from comment #26) > Should it be "This connection is not secure"? Should we ask Matej for copywrite review?

Thanks Philipp! So it sounds like this is the final design https://bug1217150.bmoattachments.org/attachment.cgi?id=8791926 (pending copy) with the following notes: 1) The warning should appear if the user focuses on the username field. The warning should appear if the user focuses on the password field. 2) If the user has one or more saved logins for the insecure domain, the warning will show on top of the list of potential usernames/passwords the user could choose.

Another thought... in Bug 1189618, we are restyling the design of the autocomplete UI to include a key - https://bug1189618.bmoattachments.org/attachment.cgi?id=8641502 Should this key always appear? In the insecure page case, will we show the struck through lock and warning, followed by the key and usernames?

(In reply to Ryan Feeley [:rfeeley] from comment #26) > Should it be "This connection is not secure"? Yeah, it's a bit odd. I took this wording from an older mockup without really questioning it. Adding Michelle for copy review. (In reply to Tanvi Vyas [:tanvi] from comment #28) > Thanks Philipp! > > So it sounds like this is the final design > https://bug1217150.bmoattachments.org/attachment.cgi?id=8791926 (pending > copy) with the following notes: > > 1) The warning should appear if the user focuses on the username field. The > warning should appear if the user focuses on the password field. > > 2) If the user has one or more saved logins for the insecure domain, the > warning will show on top of the list of potential usernames/passwords the > user could choose. /signed :) (In reply to Tanvi Vyas [:tanvi] from comment #29) > Another thought... > in Bug 1189618, we are restyling the design of the autocomplete UI to > include a key - > https://bug1189618.bmoattachments.org/attachment.cgi?id=8641502 > > Should this key always appear? In the insecure page case, will we show the > struck through lock and warning, followed by the key and usernames? I'll defer to Ryan on that one. If we do show the key, then we should also align the text in the security warning to form a line with the text below.

Copy can be discussed in the copy bug https://bugzilla.mozilla.org/show_bug.cgi?id=1307316

The key issues are being discussed in bug 1189618 so removing Ryan's needinfo here.

Aislin or Philipp, Can you provide more details on this UX - https://bug1217150.bmoattachments.org/attachment.cgi?id=8791926. Specifically, do you know the exact color you'd like to use or have the dimensions. Sean Lee (who is implementing the design) is asking in https://bugzilla.mozilla.org/show_bug.cgi?id=1217162#c9.

(In reply to Tanvi Vyas [:tanvi] from comment #33) > Aislin or Philipp, > Can you provide more details on this UX - > https://bug1217150.bmoattachments.org/attachment.cgi?id=8791926. > Specifically, do you know the exact color you'd like to use or have the > dimensions. Sean Lee (who is implementing the design) is asking in > https://bugzilla.mozilla.org/show_bug.cgi?id=1217162#c9. I commented on that bug with some more specifics.

I notice the following possible issues related to Insecure contextual message UX and functionality: 1. The Insecure contextual message appears as a Username/Password drop-down suggestion. 2. The Insecure contextual message is selectable and clickable. - i acknowledge that this and the above point 1 were discussed over - but I think that if something is clickable, it should do something - maybe on click open the learn more section that was dismissed bug 1217150? 3. The Insecure contextual message in some cases obstruct the password field. -> maybe move it in the left side of the login forms? something like http://imgur.com/a/cFqgi ? 4. The insecure contextual message cannot be dismissed. I think we should take into account that if users visit a http login site multiple times they might acknowledge the security concern and there should be an option for them to dismiss it.

Ryan, could you take a look at comment 35, maybe at items 1-3? (4 could well go into enhancement area so late into the cycle)

> 1. The Insecure contextual message appears as a Username/Password drop-down suggestion. I'm unclear what you mean here. > 2. The Insecure contextual message is selectable and clickable. - i acknowledge that this and > the above point 1 were discussed over - but I think that if something is clickable, it should > do something - maybe on click open the learn more section that was dismissed bug 1217150? Being discussed in 1319176. I've presented 3 options for UX. > 3. The Insecure contextual message in some cases obstruct the password field. -> maybe move > it in the left side of the login forms? something like http://imgur.com/a/cFqgi ? Unfortunate side effect of dropdowns, but it should be fine as long as it goes away. I'll see if we can test shorter copy strings. > 4. The insecure contextual message cannot be dismissed. I think we should take into account > that if users visit a http login site multiple times they might acknowledge the security > concern and there should be an option for them to dismiss it. Something for the future. If we allow them to dismiss it, we arguably have to store that preference somewhere in their profile, and allow them to remove that preference, and possibly Sync it alongside other preferences.

Thanks Ryan for clarification. Meanwhile, I've also talked to :mattN and :tanvi, and to sum up: -items 1 and 3 - Insecure warning is expected to affect the user experience in order to make them notice the warnings and to push websites to move their login forms towards https; -item 2 is discussed in bug 1319176; -for item 4 I will create an enhancement bug (if there's none already created) Due to the above, setting the status of this bug back to resolved fixed, since all the reasons for reopening it are now clarified or handled in different issues.