Philipp and Aislinn have designed a mockup for the Contextual Warning on Insecure Password Fields in bug 1217150: https://bug1217150.bmoattachments.org/attachment.cgi?id=8791926 We need to get final copy on the string. It currently says: This site is not secure. Your login and password could be seen by others. A few questions: Is this string okay as is? Does it need to be changed? Who should be ping for help with copy? Thanks!

NI Michelle for copy input.

This site is not secure and may allow others to access your user name and password.

Will this feature go thru legal review? If not, LMK and I will run the text past Marshall and Elvin.

(In reply to mheubusch from comment #2) > This site is not secure and may allow others to access your user name and > password. Does this imply that the "site" may allow others to access your username and password? The site isn't going to give away this access, but because the connection is poor/insecure, the connection is susceptible to eavesdropping and man in the middle attacks. Should we try and capture this nuance? The control center currently says: main panel: Logins entered on this page could be compromised. subpanel: The login information you enter on this page is not secure and could be compromised. You can test out the control center on Nightly, Dev Edition, and Beta by visiting this test page: http://people.mozilla.org/~tvyas/password/password_test2.html (In reply to mheubusch from comment #3) > Will this feature go thru legal review? If not, LMK and I will run the text > past Marshall and Elvin. There is currently no legal review planned for this feature.

Thanks for providing that explanation, Tanvi! I can move this to IRC if it requires further discussion, but does one of the below better capture this? 1. The connection to this site is not secure, so any information you share, including your user name and password, may not be safe. OR 2. This connection is not secure. It may not be safe to share your user name and password. OR 3. This connection is not secure. Your user name and password could be compromised. I prefer the "may not be safe" versions because they state the issue (safety) instead of the action (compromised).

(In reply to mheubusch from comment #5) > Thanks for providing that explanation, Tanvi! I can move this to IRC if it > requires further discussion, but does one of the below better capture this? > > > 1. The connection to this site is not secure, so any information you share, > including your user name and password, may not be safe. > I would avoid talking about other information, because this warning will show up specifically on username and password fields. > OR > > 2. This connection is not secure. It may not be safe to share your user > name and password. > > OR > > 3. This connection is not secure. Your user name and password could be > compromised. > This may lead the user to believe their username and password could already be compromised (which is also true). But the point we want to make is that if the user enters the username and password now, it could be compromised. So maybe something like: This connection is not secure. Usernames and passwords entered here could be compromised. OR This connection is not secure. Usernames and passwords entered here could be exposed. I will ping you on irc.

I spent 90 minutes with Mike Conley to discuss a few approaches. This is where we landed. This initial sketch tries to reuse existing UI from our Control Center. We documented a lot of the interactions, and felt that this approach provides the most protection for users who use the keyboard to fill the login without looking at their screen, but still provides keyboard accessibility. Engineering-wise, Mike felt that this approach is attainable. Thoughts?

What was the thinking regarding a Learn More link? I see one wasn't included. Is the lack of key icons beside the logins the long term plan or just demonstrating if we do the contextual warning first? I really hope we don't end up requiring a button click to reveal logins as we're getting in the way of the user's task and our data showed something like 35%+ of login forms are affected.

This bug is actually for the string. The UX bug 1217150. In that bug, Philipp has a final design - https://bugzilla.mozilla.org/attachment.cgi?id=8791926, https://bugzilla.mozilla.org/show_bug.cgi?id=1217150#c30 - and the only open questions were: 1) What is the final copy - this bug. 2) How this would interact with the key icon proposed in bug 1189618. Ryan's UI is a little different that Philipp's. We need to come to some consensus on what we want, and fast because Sean has already started implementation of this UX in bug 1217162. I propose we: 1) start off with Philipp's UI in Firefox 52- https://bugzilla.mozilla.org/attachment.cgi?id=8791926. 2) continue working with Michelle on this bug for final copy 3) Wait on the key icon bug 1189618. We can work on that in Firefox 53+ after figuring out the right UI (include the key, include another icon, or keep things how they are with no icon). 4) File a followbug to discuss Ryan's proposal here that includes an additional click to get to the saved logins. I believe this is similar to Chrome's proposal. It may be better to start off with something easier to use (Philipp's UI) and progressively make it harder to use (Ryan's UI) as more sites move off of HTTP logins.

Hi Tanvi - My recommendation for copy in Philipp's design is: This connection is not secure. Logins entered here could be compromised.

(In reply to mheubusch from comment #10) > Hi Tanvi - My recommendation for copy in Philipp's design is: > > This connection is not secure. Logins entered here could be compromised. That sounds great! Thanks Michelle!

Updated with Michelle’s copy and included key icons from FFOS emoji set. > What was the thinking regarding a Learn More link? I see one wasn't included. I wasn't aware that Philipp/Aislinn were actively on this when Mike and I were asked for input. I don't believe that a hyperlink belongs for keyboard accessibility reasons, and it's uncommon for the autocomplete dropdown of a browser's text input. > Is the lack of key icons beside the logins the long term plan > or just demonstrating if we do the contextual warning first? I'm not certain of longer term plans. I was just attempting to address the contextual warning now. I have updated it with what key icons could look like. A proper design spec will require more time than I have this week. > I really hope we don't end up requiring a button click > to reveal logins as we're getting in the way of the user's task > and our data showed something like 35%+ of login forms are affected. We're trying to include for those who use the keyboard and don't look at the screen. They focus on a username field, put their eyes to their keyboard, enter a username character, down arrow to select and enter to submit. Mike and I figured that this was one way to make sure the warning was understood. It also appears to follow Chrome's approach. I'm not available this week, so I'll defer to the others for follow-ups.

(In reply to Ryan Feeley [:rfeeley] from comment #12) > Created attachment 8799132 [details] > http-logins.png > > Updated with Michelle’s copy and included key icons from FFOS emoji set. > > > What was the thinking regarding a Learn More link? I see one wasn't included. > > I wasn't aware that Philipp/Aislinn were actively on this when Mike and I > were asked for input. I don't believe that a hyperlink belongs for keyboard > accessibility reasons, and it's uncommon for the autocomplete dropdown of a > browser's text input. > > > Is the lack of key icons beside the logins the long term plan > > or just demonstrating if we do the contextual warning first? > > I'm not certain of longer term plans. I was just attempting to address the > contextual warning now. I have updated it with what key icons could look > like. A proper design spec will require more time than I have this week. > > > I really hope we don't end up requiring a button click > > to reveal logins as we're getting in the way of the user's task > > and our data showed something like 35%+ of login forms are affected. > > We're trying to include for those who use the keyboard and don't look at the > screen. They focus on a username field, put their eyes to their keyboard, > enter a username character, down arrow to select and enter to submit. Mike > and I figured that this was one way to make sure the warning was understood. > It also appears to follow Chrome's approach. > > I'm not available this week, so I'll defer to the others for follow-ups. Why can't we just go forward with mock #4 from the left shown above as the approach used for on focus. Show the warning and the saved logins under it?

(In reply to Ash Grigas from comment #13) > Why can't we just go forward with mock #4 from the left shown above as the > approach used for on focus. Show the warning and the saved logins under it? I agree that's what we should do for now.

(In reply to Matthew N. [:MattN] (behind on requests) from comment #14) > (In reply to Ash Grigas from comment #13) > > Why can't we just go forward with mock #4 from the left shown above as the > > approach used for on focus. Show the warning and the saved logins under it? > > I agree that's what we should do for now. I agree as well, except minus the key icons. I think we should move Ryan's design changes to the insecure password warning to a followup bug (specifically, requiring a separate click to reveal the saved logins, so that users that look at the keyboard instead of the screen still see the warning). We can see how users interact with the warning in Firefox 52, and then decide on enhancing the design with Ryan's changes after that. For the key icons, I'm worried that mixing the key icon with the strikethrough lock is confusing. I can bring this up in the bug that adds the keys (bug 1189618) and we can followup on that there. Per mconley, I don't think we will land the key bug in Firefox 52 anyway, so it is something we can resolve for Firefox 53+. The "View Saved Logins" footer is also part of bug 1189618. This means that the design that should be implemented in bug 1217162, is still the same as what Philipp and Aislinn spec'ed in bug 1217150. Since Ryan's design here is an enhancement of that plus part of the design for bug 1189618. The bugs and designs are getting a bit confusing, so I'm sorry if this is unclear. Feel free to ask for clarification. This bug is still supposed to be the copy bug for the string, which has been resolved in comment 10 and 11 by Michelle.

(In reply to mheubusch from comment #10) > Hi Tanvi - My recommendation for copy in Philipp's design is: > > This connection is not secure. Logins entered here could be compromised. We have the final string, so closing this bug.

I want to observe that all warnings don't contain hints for non power user what to do. If someone doesn't know https this warning might not help. I'd suggest adding a hint like "Try accessing this page <a href="https://link to the page">using a secure connection</a>." But this will fail when the login form posts to another page than the form is placed. Should I open a new issue on that or do you know if there is already one for that?

(In reply to sedrubal from comment #17) > I want to observe that all warnings don't contain hints for non power user > what to do. If someone doesn't know https this warning might not help. I'd > suggest adding a hint like "Try accessing this page <a href="https://link to > the page">using a secure connection</a>." But this will fail when the login > form posts to another page than the form is placed. Thanks for the suggestion, but this is not as trivial as it seems: - We only have a limited amount of space and only a single click target that we reserve for the support article that should hopefully help non-power users. (If not, we need to improve the article and we rely on community members to help out and give feedback on that. So feel free to chime in). - In the likely case that the site doesn't support HTTPS, the user experience is getting worse since they will get a certificate error, which is probably even harder to understand. Even if the site supports HTTPS there is no guarantee that it will work the same way as the HTTP site. - As you already observed, this message is just plain wrong if the form action is insecure but the site is over HTTPS.