1046799 - Include an option to manually configure email accounts without SSL

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[Beatriz Rodríguez [:brg]]

This issue had been raised during certification in some countries.
They are asking for a way to manually configure a mail account without SSL (clear text support).

Other mail clients allow users to set this parameter while FxOS not.

Comment 1

[Albert [:albert]]

Attachment: Patch

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 8470774 [details]
Patch

User data/privacy/(account-)security concerns need to be understood and addressed before we could consider any specific implementations.  Please see bug 824533 comment 4 onwards for a brief discussion of the user data/privacy concerns.  It's also worth consulting bug 874346 which, although dealing with invalid SSL certificates, still covers some of the many bad things that could happen if a user accessed their mail server over an effectively insecure network.  This case would simply be worse.

I'll ping the data privacy team and raise the issue with email product management at our weekly meeting tomorrow.

I'm definitely interested in hearing what you think the trade-offs are here and how we can avoid situations where users blindly try settings until their mail account works, and as a side-effect, end up completely compromising their security.

Comment 3

[Albert [:albert]]

I understand your security concerns and I am totally agree with you, however I think that mentioned security issues regarding plain sockets should be addressed by email providers.

As a Firefox OS user I don't like that email app doesn't let me to use plain connection if I want to use unsecured server for some reason while other mobile systems allow it. Above all, more important than my personal opinion, is the fact that this is a certification blocker. What do you think if I request UX collaboration in order to warn the user when trying to use plain sockets?

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

The email UX owner, Juwei, will be present at the team meeting tomorrow and I have pinged the data privacy team.

The primary security threat here, just like with certificate exceptions, is an attacker with network control managing to convince a user whose mail server provides SSL/TLS security to configure their account to use no/bad security.  Users whose providers don't provide SSL/TLS support are obviously in a bad situation for which the only real solution is to pick a better provider.

For example, as a hypothetical attacker operating a malicious wi-fi access point or a (rather more illegal) fake cell tower I could choose to cause all attempts to contact the Mozilla-hosted ISPDB or valid connections to the user's server to fail.  Assuming the user is using "example.com" for mail, the attacker waits for an access to "www.example.com" or some other non-https domain (maybe for a search engine) or bad DNS query to direct the user to a fake support site that tells the user to disable SSL.

One of the better ways to help avoid this scenario is to have the ISPDB or our on-device autoconfig database say "yes, we know that domain example.com doesn't have security".  Or for our current canonical example, for "vtr.net".  While we're not particularly able to update the email app in the field (although as a carrier, you could let us do that), we are able to update the mozilla-hosted ISPDB as we hear about new domains experiencing such problems.

But in terms of manual config, if we allow user override, yes, I absolutely think we would want some UX to help inform the user of the risk they are exposing themselves to.  A relevant question to "certification blocker" is what version you are tracking this as a cert blocker against.  I don't think we can land new strings on v2.0, which is a problem unless whoever this is a cert blocker for is handling localization and is willing to accept new strings.

(Note that in regards to the patch, our rationale for not localizing SSL is not appropriate to "plain".  Plain is not quite a protocol, but more significantly techno-gibberish is okay when it doesn't matter if the user understands it.  It does matter in this case.  More pedantically, in the email world, plain is ambiguous and more likely to be correlated to non-HTML mails rather than unencrypted connections (text/plain versus text/html).  Cleartext is the more correct technical term, though regrettably many people do mix plaintext/cleartext, including myself at times.  But that means nothing to users, so we would need that string to be "unencrypted" as well as an explanation of the ramifications to the user since "unencrypted" is likely opaque to a significant portion of users as well.)

A related question for me is, what is the formal requirement that is not being satisfied and what are the formal security requirements that may interact with it?  For example, on vtr.net, there is an insecure http://webmail.vtr.net/ that the user can use to insecurely access their email.  Is that sufficient to satisfy requirements?

Comment 5

[Juwei Huang[:juwei]]

Attachment: [Email] Configure email without SSL.pdf

Spec attached.
In UX perspective,  I think a warning text can help users to know what will happen without SSL. So my suggestion would be showing a dialog box after users configure security without SSL.

The warning string can be:

"You are about to use this account without security certification.
It may cause uncertain risk to your email."

Feel free to correct me if there's any better idea to describe it :)

Comment 6

[Albert [:albert]]

Attachment: Preview

Comment 7

[Albert [:albert]]

(In reply to Juwei Huang from comment #5)
> Created attachment 8479756 [details]
> [Email] Configure email without SSL.pdf
> 
> Spec attached.
> In UX perspective,  I think a warning text can help users to know what will
> happen without SSL. So my suggestion would be showing a dialog box after
> users configure security without SSL.
> 
> The warning string can be:
> 
> "You are about to use this account without security certification.
> It may cause uncertain risk to your email."
> 
> Feel free to correct me if there's any better idea to describe it :)

There is a problem with your proposal, you want to show the warning popup when the user clicks the ok button of the 'select' but there is no listener for such event. I tried to show the popup when 'onchange' event is fired with the desired value, then the popup is shown behind the selector options panel and becomes visible when the user click 'ok'. However the popup has an absolute position and the header bar changes the color, what seems starnge. See attachment.

What do you think if I launch the warning when the user clicks 'next' in the 'ManualSetup' screen?

Comment 8

[Juwei Huang[:juwei]]

Hi Albert, 
Is it possible to show the pop-out window after users tap on ok? 
I know currently we apply the selection immediately while user tapping on the value, so I think that's the reason the pop-out window is shown behind the value selector and change the colour of status bar.

I think for long-term plan, it would be not a problem. In our new building block design, the ok button will no longer exist but replaced by a cancel button. When users tap on one selection on value selector, it will be applied immediately and jump back to previous screen. So in this case, once users tap on "None" then the value selector would disappear and the pop-out window would show up.

However, in current stage, we still keep the "ok" button. So I'm wondering if it's possible to show the pop-out window after users tap on ok?

I considered about your suggestion, but if we do so,  users cannot regret it and change the value back at the moment since they already tap on "next" and the pop-out window only inform them about it. The reason I put the pop-out window right after users select the security plan is because they may found that it's dangerous and can change the value back again.

So I still suggest to pop out the window after users tap on ok on value selector.

Let me know your thought, thank you :)

Comment 9

[Albert [:albert]]

(In reply to Juwei Huang from comment #8)
> Hi Albert, 
> Is it possible to show the pop-out window after users tap on ok? 
> I know currently we apply the selection immediately while user tapping on
> the value, so I think that's the reason the pop-out window is shown behind
> the value selector and change the colour of status bar.
> 
> I think for long-term plan, it would be not a problem. In our new building
> block design, the ok button will no longer exist but replaced by a cancel
> button. When users tap on one selection on value selector, it will be
> applied immediately and jump back to previous screen. So in this case, once
> users tap on "None" then the value selector would disappear and the pop-out
> window would show up.
> 
> However, in current stage, we still keep the "ok" button. So I'm wondering
> if it's possible to show the pop-out window after users tap on ok?
> 
> I considered about your suggestion, but if we do so,  users cannot regret it
> and change the value back at the moment since they already tap on "next" and
> the pop-out window only inform them about it. The reason I put the pop-out
> window right after users select the security plan is because they may found
> that it's dangerous and can change the value back again.
> 
> So I still suggest to pop out the window after users tap on ok on value
> selector.
> 
> Let me know your thought, thank you :)

As said in comment 7, can't listen for events in 'ok' button. So I see three options:

1) Launch a warning using an alert. When the user clicks the 'plain' option an alert popup is launched with the message, once the alert ok button is clicked the alert and the select are closed. The main problem with this approach is that alert title and button can't be customized. See alert attachment to see the flow.

2) Create a new confirm dialog with nested elements, the father element should have the same background color as the menu in order to have the same statusbar color. Then if 'plain' is clicked the dialog is showed and if another option is selected it should be hid. This option can accomplish your wireframe flow but it is dirty and tricky, I have my doubts about getting positive review...

3) Use a 'custom select', some kind of radio button with a ok button. Hard to maintain when look & feel changes..

IMHO option 1 is the best approach, overall because this is just a warning and it is simple.

What do you think?

Comment 10

[Albert [:albert]]

Attachment: Alert

Comment 11

[Albert [:albert]]

Attachment: Patch v2

Added warning popup

Comment 12

[Albert [:albert]]

Juwei I provide a patch implementing a simplification of the proposed option 2. It implements the flow of your wireframes.

Comment 13

[Albert [:albert]]

Attachment: Preview v2

Comment 14

[Andrew Sutherland [:asuth] (he/him)]

Thanks for the patch, :albert and extra thanks for the screenshots!  I've been a little swamped today still, but should be able to get to this tomorrow or Friday.  I may need to hand portions off to :jrburke for the more UI implementationy bits.  I think we're also going to end up folding in insecure ActiveSync to this foot-gun mechanism since we've got a similar request in bug 1065832 and arguably ActiveSync users equally deserve the right to choose to get their email accounts compromised.

I do think we need to revisit the strings, but that is a somewhat separable concern (although still a prerequisite to landing).  This needs copywriting support and security support, so I'm needinfoing :matej (copywriting) and :freddyb (the security engineer assigned to the email app).  I propose the following, but we'll want to wait for :matej and :freddyb to coment first before making any changes:

- Change PLAIN to "Unauthenticated and unencrypted".
- Change the spiel to:  "Without an SSL/TLS connection we will be unable to verify that we are talking to your real mail server.  Anyone listening to the cellular or wi-fi networks will be able to see your passwords, the contents of the emails you receive, and the contents of the emails you send.  This could allow them complete access to your account, including sending emails as if they were you or using your account without your knowledge."

I would like to also consider that we maybe include a blurb and URL like: "You are strongly advised to switch to an email provider that provides authenticated and encrypted connections for your security.  There are multiple free options available, and they usually also provide better features.  You can find more at https://support.mozilla.org/advocacy-link-that-does-not-exist."  Since a custom card is being used right now, we should be able to add a hyperlink without too much trouble.


I realize there are probably multiple phrasing problems with that, but the key ideas are:
- We won't be able to tell if we're talking to the real server or some random sketchy person in a trenchcoat
- The user's privacy is toast.  Anyone who can see what is traversing the network will see the user's password and emails.  Leveraging this level of insecurity into complete account ownage is trivial.  The only good news is that it's usually very illegal to eavesdrop on the cellular network and at least an order of magnitude harder to do so.  But it's a meaningless order of magnitude; it just means that a precocious 8-year old needs to get their parents to buy them some readily available software-defined radio hardware/etc.etc/.

A relevant idea that probably can't be expressed is that although some servers support things like CRAM-MD5, that's meaningless for our purposes.  Any server that's so poorly run so as to not have valid TLS certificates is not likely to support CRAM-MD5, so we can't require that.  Also ActiveSync just uses basic auth, so that's also not happening either.

Comment 15

[Frederik Braun [:freddy]]

I am onboard with this approach from a high-level perspective, as long as we keep the warning language clear, strong and simple. I like how the existing browser security dialogs for cert errors require more than one click and contain a button that explicitly contains the word "unsafe".
But I'm sure Matej will find a good way to phrase it.

I have also looked at the code and it looks OK to me (assuming the text will change).

Comment 16

[Juwei Huang[:juwei]]

Comment on attachment 8487235 [details]
Preview v2

Hi Albert, I also checked the patch and it looks good to me.

In general, I agree with you that this method may not clean for coding. Yet as I said in previous status, the new building block will change the behaviour so I'm ok with the alternate solution you provided. Thank you for your thoughtful work!

As for the string Andrew suggest, I think it's a good idea to provide a hyperlink for users to understand more about the risk of security type if we have such link already. However, for the string on the confirm window, I suggest we keep it not-too-long & provide enough warning to users. I'm also thinking that an alert icon might enhance the severity, yet it depends on how much time do we have because designing an icon needs time.

Let me know your thought!

Comment 17

[Matej Novak [:matej]]

Unfortunately this is a bit beyond my technical understanding, but here are some revisions to the copy in comment 14. Hopefully they make sense:

"Without an SSL/TLS connection, it's not possible to verify your mail server. Other people may be able to see your passwords and the contents of the emails you send and receive. They could even gain complete access to your account and send emails as if they were you without your knowledge."

"For your security, you are strongly advised to switch to an email provider that offers authenticated and encrypted connections. There are multiple free options available. Learn more at https://support.mozilla.org/advocacy-link-that-does-not-exist."

Comment 18

[Andrew Sutherland [:asuth] (he/him)]

:jsavage, since the email app is now doing direct links to sumo, I think we have another one here.  More details in previous comments.  The flow I'm envisioning is (and noting that I'm willing to help provide the long-form text, or at least a first draft):
- Recap of the scary risks, mention of elaboration further down the page.
- Brief mention of the fact that it's possible the user's server does support encryption and it's just that different settings might need to be used, like trying a different domain name.  This might be a place to link out to searchable forums or some other peer support thing if we have community that could help users find their correct settings.  And advise the users to contact their ISP to both ask and/or evangelize for actually supporting internet security standards at least a teensy eensy bit.
- An explanation of the options the user has to switch to a better mail server provider for free while still being able to receive email at their current address.  Specifically, gmail (and probably many others) will let you make it so they pull mail from your old account into your new account.  An explanation of why this is secure would be included.  (Evil people need to snoop between Google and the user's mail server instead of between the user and their mail server, which is a significantly different level of effort.)
- A little more details on the risk profile.  Basically elaborating that it's possible for nefarious people to eavesdrop on wi-fi and cellular data connections despite them both attempting to offer encryption.  I try and drop some links to wikipedia there, hopefully links that are translated to other languages too.

:jsavage, my question for you is:
- Does this seem sane?  Both having this support page and the level of stuff I suggest we put on there?  We would ideally want this localized to all of our Firefox OS languages since we'd be directly linking.  I don't want to be a jerk to the localizers in terms of volume of content; I think I can keep the technical-terms limited to things like encryption and authentication so it's not like trying to translate a technical manual.
- Is linking to gmail/friends okay, and how does that impact localization?  Is it okay if I'm just lazy and stick with gmail?  There are some other options where their server implementations are significantly worse and Google really is my best recommendation for these people.  The only downside to Google in most cases would be that they are (largely?) subject to US laws (depending on how Microsoft's case against the government goes currently).  We could let localizers suggest local ISPs offering free mail that support import, but I certainly won't have the bandwidth to vet that at scale.
- Do I need to do anything special to make a page with a stable URL?  And/or can you create a stub for me if it's not obvious how to do that.

Comment 19

[Joni Chan]

:asuth, I think this is reasonable. We'd be okay with use Gmail as a default and letting the localizers know that they can suggest other providers that they've vetted.

I don't have the technical expertise to write about this intelligently, so a first draft that I can revise would be great. Here's the URL: https://support.mozilla.org/kb/how-switch-secure-email-provider-firefox-os. Does the title and URL capture what we want the article to say?

It's a wiki, so please feel free to add your text to that page, or email it to me directly. I've placed the page in the "Admin" category, so it's not visible in search results - only through the URL.

Comment 20

[Jack Liu]

Dear Vance,

This bug blocks Claro Guatemala, its exchange server only support http access.

It's appreciated mozilla land patch on 1.3 as soon as possible.

Thanks!

Comment 21

[Frederik Braun [:freddy]]

(In reply to Joni Savage from comment #19)
> :asuth, I think this is reasonable. We'd be okay with use Gmail as a default
> and letting the localizers know that they can suggest other providers that
> they've vetted.

Excuse the possible bike shed, but I think we should not suggest any provider. May we link to a list and say that people should look for an SSL-capable provider instead? There are many lists out there, e.g. https://en.wikipedia.org/wiki/Comparison_of_webmail_providers

Comment 22

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

(In reply to Jack Liu from comment #20)
> Dear Vance,
> 
> This bug blocks Claro Guatemala, its exchange server only support http
> access.
> 
> It's appreciated mozilla land patch on 1.3 as soon as possible.
> 
> Thanks!

Hi Jack -

Since 1.3 branch is now EOL, I don't think we can ever land anything onto that. So when the patch is ready, you need to cheery-pick the patch into your 1.3 code base(not sure if this is doable...ni Andrew to comment)

Hi Andrew -

TCL needs to have this bug fixed in order to sell Sora devices(Fire C)in Guatemala with carrier Cario, do you think is it possible for TCL to cheery pick the patch once it lands on master?

Thanks

Comment 23

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Frederik Braun [:freddyb] from comment #21)
> Excuse the possible bike shed, but I think we should not suggest any
> provider. May we link to a list and say that people should look for an
> SSL-capable provider instead? There are many lists out there, e.g.
> https://en.wikipedia.org/wiki/Comparison_of_webmail_providers

If we can find a list that better matches what we're going for, I think it would be great to link to such a list.

The counterpoint is that I do think it's important for us to avoid overwhelming the user with hard-to-make choices.  Specifically, if the user is coming to the email app to access their email and then we're suggest they make a choice by reviewing a 17 columns by 22 rows table that is 5 screens tall by 4.5 screens wide on my Tarako v1.3t device (slight better on v2.1+ since we lose the footer toolbar), that seems like we're biasing them towards just saying accepting no security.

I think what we want from a list is, in order of priority (and having actual support of TLS being a prerequisite):

1) The ability for the user to keep their existing email address by having the server supporting ongoing message import.  GMail definitely supports this as documented at https://support.google.com/mail/answer/21289?hl=en and I'm sure there are others that support similar things.

2) Locale coverage.  http://hg.mozilla.org/gaia-l10n indicates we have 76 that are conceivably supported.  Checking last-modified stamps and looking a bit more suggests there's really only 67 languages.  The table lists GMail supporting 71 locales and Outlook.com supporting an impressive 106 locales.  The next-closest is Yahoo with 27 locales.

3) General security / user-privacy behaviour and inherent motivations.  For pushback, I'm pretty impressed with Yahoo's recently more-public lawsuits against PRISM and Microsoft's recent lawsuit about jurisdiction over foreign user-data on foreign servers.  For op-sec I'm very impressed with Google's efforts to encrypt their inter-data-center traffic and their longstanding efforts to encrypt email data at-rest with the encryption keys stored on physically disparate servers.  Everyone working to use opportunistic TLS (especially sticky once-seen) is great.

   For motivations, it is nice to be able to know or predict what the actual cost to the user is of free email.  For example, we do not expect Google to sell out their user profiles to other companies or let other companies take a peek at the data simply because Google is a juggernaut whose ad-auction model is built on not sharing that information.  For other free mail providers it's good to both have explicit policies that state they don't mine for ads, won't mine for ads, won't let random third parties put "traffic analysis" boxes in places that can sniff unencrypted SMTP/other, and for there to be binding clauses about changes in these policies so that the things can't unilaterally be changed (given that email addresses are sticky).


If we take it as a given that most users in this situation aren't going to want make their own analytic spreadsheet, I think our best options are some combination of:

- A simple decision-based work-flow that filters the options based on questions like: "Are you willing to pay for your email in order to avoid having your email be mined for advertising purposes?", "How do you feel about where your email is hosted: I don't care; I don't want want my data to reside in the US; I don't want my email to be operated by companies headquartered in the US; I want my data hosted in my own country", uh, and maybe that's it?  Note that if payment enters the picture, we might have to confirm the user actually is able to pay the company.  For example, Fastmail.fm only takes Visa/MasterCard/AmEx/PayPal which might disqualify them in certain markets, although that might already correlate with the locales they support.

- Provide a randomly ordered, possibly limited set of choices.  For example, if we think 10 choices are equally good, randomly pick 3 in a random order and present them with a "and 7 other good choices..." hyperlink at the bottom.

Wikipedia is a great place for likely very accurate lists, but this seems more like an EFF thing (it lines up with https://www.eff.org/who-has-your-back-government-data-requests-2014 somewhat).  Maybe we could partner with them on such a project?  I'll drop [e-mail] an email now to see what they think / if they have any ideas.

Comment 24

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 8487217 [details] [review]
Patch v2

James Burke has volunteered (or been pressured by me, either one :) to review the patch for implementation (but not content) purposes.  Content-wise the next steps are for the patch to be updated to what Matej provided, and we do want to go with the link to the SUMO url created.

I am taking (initial) authorship responsibility of the page and I'll ask for feedback here and editing help.  The EFF did route my query to one of their senior technologists and we'll see where that goes, but that's not blocking since any changes will happen on the SuMo page.

Comment 25

[James Burke [:jrburke]]

Attachment: GitHub pull request

I started to give feedback on the review, but realized I was suggesting things that may have been a bit experimental, and may have been harder to digest in timely manner, so I went ahead and tried some things and resulted with a fresh pull request.

I started with the pull request from acperez (and credit acperez in the commit message), but then rebased on current master (the setup flow has changed noticeably with the introduction of oauth for gmail), converted to using a ConfirmDialog, then tried fitting in the suggested text.

The suggested text by :matej in comment 17 was a bit too big to fit, so I made a shot at condensing it. Also, after further discussion with :asuth in IRC, opted for "Unencrypted (insecure)" for the select box option, due to space constraints, particularly once the item is selected.

I also did the "Learn More" link as a button in the confirm dialog, to gain some extra space for the text.

I will upload an image capture of the flow with the wording, and ask for review by the parties previously involved.

Flipping code review to :asuth. That is what you get for me asking to help! :) I may need to adjust the unit test, and depending on feedback, the wording, but otherwise, think the code approach is good.

Comment 26

[James Burke [:jrburke]]

Attachment: unencrypted.png

Current flow as implemented in my pull request. See my previous comment about needing to condense some of the wording to fit in the dialog box.

The images are from the upper left, flowing to upper right, then continuing on the bottom left. The "How to switch to a secure email provider on Firefox OS" is the wiki page, and is not filled out yet. It can be filled out later, and :asuth will be looking at that. 

I am just showing that the jump works, and is done as a view activity to the main browser, outside the email app. The last image in the sequence shows the text spacing on a hamachi-type of screen size.

I will needinfo the people involved in the flow and text crafting to make sure this approach still works for them.

Comment 27

[Frederik Braun [:freddy]]

Thanks for making "Learn more" the highlighted default.
Maybe they should change places with "learn more" on the right?

Comment 28

[Juwei Huang[:juwei]]

Thanks James for the screenshots!

Yet even when James shorten the text, it still looks very long....

I think the main purpose is to warn users that their account information is insecure without SSL protection. We can make the sentence shorter, a long article may lost the point we try to convey to users.
How about just keeping the first line
"Insecure Option!"
"Other people maybe able too see your passwords, the contents of the emails you send and receive, and control your account."
"Learn More" "I Understand"

And "I understand" should be on the right side since it's the main action to leave the dialog. Hopefully people would understand the risk at the first time when they see the dialog text. "Learn more" is an option that they could get further information. So I think "Learn more" should be keep on the left.

Comment 29

[Frederik Braun [:freddy]]

(In reply to Juwei Huang from comment #28)
> And "I understand" should be on the right side since it's the main action to
> leave the dialog. Hopefully people would understand the risk at the first
> time when they see the dialog text. "Learn more" is an option that they
> could get further information. So I think "Learn more" should be keep on the
> left.

I understand your reasoning, but I want to explicitly break with this pattern. Observe how HTTPS errors do this too. If you go to https://example.com/ in Firefox or Chrome, the most highlighted default button is "Get me out of here" (Firefox) and "Back to Safety" (Chrome).

The reason is to get the attention beyond the typical partially unconscious flow of hitting buttons that say "Next", "Yes" or "OK".

Comment 30

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Juwei Huang from comment #28)
> How about just keeping the first line
> "Other people maybe able too see your passwords, the contents of the emails
> you send and receive, and control your account."

This removes the sentence that says "There are multiple, free email providers that offer more secure, encrypted connections."

I think it's helpful to keep this sentence because it suggests that pressing "learn more" may actually lead to a solution that improves the situation and addresses things rather than just being a page of techno-babble that informs but doesn't do anything.

> And "I understand" should be on the right side since it's the main action to
> leave the dialog. Hopefully people would understand the risk at the first
> time when they see the dialog text.

I'm with :freddyb on this.  If people are tapping something based on muscle memory, we want it to be the safe/learning option.  Granted, they will have to push "I understand" to escape from the dialog eventually, but anything we can do to help them improve their horrible email-situation is important.  And in the event they want to hit "learn more" but succumb to muscle memory and his the lower-right button, we do have the issue that it's going to be hard for them to get back to the dialog, so better to have muscle memory work in our favor there too.

Comment 31

[Matej Novak [:matej]]

Sorry for the delay in responding. I have to admit I got a little lost in this. Is there new copy for me to review?

Comment 32

[Juwei Huang[:juwei]]

Hi Matej,
Here's the phrase we are talking about:
"Insecure option!"
"Other people maybe able too see your passwords, the contents of the emails you send and receive, and control your account. There are multiple, free email providers that offer more secure, encrypted connections."
The dialog will pop out when users select "Unencrypted" in account security setting.
Please also refer to attachment https://bug1046799.bugzilla.mozilla.org/attachment.cgi?id=8491091

From my perspective, I think it's indeed to inform users the option is taking risk to their account, but I prefer a shorter sentence.

Hi Frederik & Andrew,
I know both of your concern. I don't mind we explain more to users as long as the phrase is short and clear. A long phrase is not helpful because it's easy get lost in such a long sentence. 
As for "Learn more" button, I still suggest to put on the left side. I know users are going to do a horrible option, but leading them to "learn more" is not really help them to actual "fix" the problem. On the contrary, tapping on "I understand" can lead them back to settings and change the security option immediately. So I still consider "I understand" is the primary option which should be on the right side.

Comment 33

[Matej Novak [:matej]]

(In reply to Juwei Huang from comment #32)
> Hi Matej,
> Here's the phrase we are talking about:
> "Insecure option!"

"Insecure" is technically correct, but sounds odd in this usage. Is there another way to word this warning? Could it be something like "Are you sure?"


> "Other people maybe able too see your passwords, the contents of the emails
> you send and receive, and control your account. There are multiple, free
> email providers that offer more secure, encrypted connections."

Small change here:

"Other people may be able to see your passwords and emails or control your account. There are multiple, free email providers that offer more secure, encrypted connections."

Comment 34

[James Burke [:jrburke]]

Attachment: insecure-wording.png

Here is a screenshot of the flame and hamachi that shows the latest text suggestions, and what I believe to be the current state of feedback. 

I believe the new wording gives the dialog more space, and the Learn More is still on the left, but highlighted as the "recommended" option, base on Juwei's last comment.

Asking ni? for the people that expressed interest in this decision. This version works for me. If the feedback seems positive, then I will ping :asuth for dev review. 

For ease of reference, here is the text version:

Are you sure?
--

Other people may be able to see your passwords and emails or control your account.

---

There are multiple, free email providers that offer more secure, encrypted connections.

Comment 35

[Frederik Braun [:freddy]]

Looks OK.
I guess Juwei made a good point in comment 32, saying that the "I understand" button doesn't really continue setting up an account but just gets the user back to the account setup panel.

Comment 36

[Matej Novak [:matej]]

Looks good to me.

Should "I understand" be something like "Continue anyway" instead?

Comment 37

[James Burke [:jrburke]]

For me, "I understand" works better, as it is harder for the user to just quick scan for a "Continue" or "OK" or "Next", and makes them think about it a bit more, and evaluate each button option more.

Comment 38

[Juwei Huang[:juwei]]

Looks also good to me, thank you James and all :)
And I think we probably don't need the line between the sentences.

Comment 39

[James Burke [:jrburke]]

I fixed the unit test, by removing the unit test change. The test would open a new card, but the cards infrastructure has not been set up, because it is a unit test where a single card has been instantiated on its own. So, in summary, I do not think the test was appropriate as a unit test given the inter-dependence on the card infrastructure and another card.

As to the line above the second paragraph, that is a style from the /shared CSS, so the best fix for that would be a shared style fix, outside the scope of this ticket.

I also reopened the pull request, due to the mass closing done for general gaia test cleanup.

So I think this pull request is ready for final dev review. As this is not a release blocker, I expect review to take longer, since we have other higher priority things in the fix queue at the moment.

Comment 41

[Ralph Daub [:rdaub]]

For tracking purposes -
A user is requesting this feature in the SUMO forums: https://support.mozilla.org/en-US/questions/1028650

- Ralph

Comment 42

[Stephany Wilkes]

Andrew, please let me know what we need to do to get this review? moving to review+. Trying to update some 2.2 estimates around this and if it's done, all the better. Thanks!

Comment 43

[Beatriz Rodríguez [:brg]]

This had been blocked for a while, is there anyone else who can take care of the review? I know everyone is busy but this work seems to be almost done, the feature is requested by partners and customers are waiting for it.

Comment 44

[Andrew Sutherland [:asuth] (he/him)]

Comment 42 was addressed offline; this isn't actually blocked on review, this is blocked on writing the sumo page and de-bitrotting the patch.  The sumo page is considered an integral part of the solution to informing users to the extreme risks of choosing the given option.  There may also need to be a legal/privacy review that occurs following; there's hypothetically an active ping out to legal/privacy about this already via other channels, but I'll follow it up with an explicit needinfo.

The good news is that since most everything else was de-prioritized for v2.2, I can get to this this week!  Because of the holidays and the other reviews actual landing may not occur until after the new year.  However, that should still leave us well within the v2.2 time window.

Comment 45

[James Burke [:jrburke]]

I updated the pull request targeted for review to be up to date/rebased over latest gaia master.

Comment 46

[Nancy]

(In reply to James Burke [:jrburke] from comment #45)
> I updated the pull request targeted for review to be up to date/rebased over
> latest gaia master.

Hi,James,

Does the patch support v2.0 and v1.3 ?

Thanks

Comment 47

[James Burke [:jrburke]]

The patch only supports 2.2/master. Other branches would need specific patches because the code layout and structure changed signficantly in 2.2 vs the other branches.

Comment 48

[Nancy]

(In reply to James Burke [:jrburke] from comment #47)
> The patch only supports 2.2/master. Other branches would need specific
> patches because the code layout and structure changed signficantly in 2.2 vs
> the other branches.

Hi,James,

With the patch, could Email app connect to the exchange server that security certificate is invalid ?

Comment 49

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Nancy from comment #48)
> With the patch, could Email app connect to the exchange server that security
> certificate is invalid ?

Invalid certificates are a different issue that are to be addressed at a system level.  However there is an existing workaround for exchange servers with invalid certificates; an exception can be added by browsing to the exchange server using the web browser app and accepting the invalid certificate.  (Noting that it's a fundamentally risk operation unless you check the fingerprint and the fingerprint comes from a still-safe hash algorithm like SHA2, or the key is checked in its entirety.)

Comment 50

[James Burke [:jrburke]]

:jsavage, I have done a first pass at filling out the contents of the wiki page pointed to in the pull request, happy to have it reviewed for support norms:
https://support.mozilla.org/en-US/kb/how-switch-secure-email-provider-firefox-os

Comment 51

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 8491088 [details] [review]
GitHub pull request

Thanks for rebasing this (again! :) and the excellent first draft on the text.  And :albert thanks for all the original work on the patch!

I did a pass on the sumo page to try and be specific about the threats/risks and also include a link to the gmail support page about importing mail from one's existing account.  Unfortunately it does seem to have been a non-trivial increase in text.  I added some more headers to try and visually offset that and consolidate some other stuff, but it's possible some of that stuff might need to go down in footnotes or the like.  I am not wed to anything, but do think it's important for our risks to be somewhat concrete so it's not just a case of the provider saying "we are secure, you can trust us" and us saying "it's not secure, you can trust us".

Ideally I'd like to get the sumo page stamped so it's showing some/any text before we uplift (and maybe land) rather than the no-op placeholder text right now.

Comment 52

[Joni Chan]

Sorry for the delay. I was out last week. The SUMO page is published and ready to go. It's not localized yet, but I'll send it to our L10N teams.

Comment 53

[James Burke [:jrburke]]

Merged in master:
https://github.com/mozilla-b2g/gaia/commit/1c91c05b18af61f37da8e16e2d4beac5ffdb89f9

from pull request:
https://github.com/mozilla-b2g/gaia/pull/24151

Comment 54

[James Burke [:jrburke]]

Comment on attachment 8491088 [details] [review]
GitHub pull request

This request is for for 2.2. If a version earlier than that desires uplift, that would likely need a specialized patch:

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
New feature, desired for 2.2 by partner

[User impact] if declined:
User will not be able to configure an email account that uses non-TLS/SSL connections.

[Testing completed]:
Tested on flame device.

[Risk to taking this patch] (and alternatives if risky):
Ideally all servers would have secure connection options, and this change would not be needed, but that is not what has been seen in practice. Bug has security discussion around this, and the warning page with SUMO option was the result.

As far as stability risks to existing gaia code/behaviors, very low. Unencrypted connections are supported by the base layers, this was more about exposing the option to use them.

[String changes made]:
Contains new strings for the unencrypted options and for the warning dialog.

Comment 55

[bhavana bajaj [:bajaj]]

(In reply to Beatriz Rodríguez [:brg] from comment #0)
> This issue had been raised during certification in some countries.
> They are asking for a way to manually configure a mail account without SSL
> (clear text support).
> 
> Other mail clients allow users to set this parameter while FxOS not.

CAn you please help with some testing around this as you reported the issue ? Thanks!

Comment 56

[Ryan VanderMeulen [:RyanVM]]

v2.2: https://github.com/mozilla-b2g/gaia/commit/dc8624f71faa3df41d8a0defa1dc9ecf7654bdae

Comment 57

[Brogan Zumwalt [Inactive]]

Issue verified fixed on Flame 2.2 and Flame 3.0

In manual email account setup the option to have an unencrypted account is present as a third option. When unencrypted method is selected, the user recieves expected warning message with option to "Learn more" or confirm by selecting "I understand"

Device: Flame 2.2
BuildID: 20150122002808
Gaia: 237008137f6d72b9cad25ff4faff14ff2c40ac63
Gecko: 4a90da67661e
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 37.0a2 (2.2)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Device: Flame 3.0 Master
Build ID: 20150122010203
Gaia: 917b6c36717fddc6e71ffc1ec249633c8044c93c
Gecko: 34e2d2bd7ec4
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0