1. Title : Email account is displayed without asking password (not secured) when the SIM/USIM is changed. 2. Precondition : One or more email accounts registered in Email Client 3. Tester's Action : Go to Email -> check email accounts -> Switch off Phone -> Change the SIM/USIM -> Switch on the phone -> Open Email client -> It is displaying accounts without asking for a password 4. Detailed Symptom (ENG.) : Email account is displayed without asking password when we change the SIM 6. Expected : Two types of expectations -. If the account is deleted, new registration screen should be displayed -. If the account is preserved, the screen for password should be displayed 7. Reproducibility: Y 1) Frequency Rate : 100% 8. Gaia revision : a03f7b532e9998e646d55f93a0fc03a04d7ca7d9
The implication of this bug seems to be that the SIM is either used for credential storage or is involved in the protection of the credentials (via contribution of deterministic entropy to an encryption key?). Is this something that SIM cards support, or is it something other e-mail apps/phone apps would traditionally do on their own, idiomatically? We don't have credential storage yet but are hoping to implement it soon, so if it's a SIM thing, it would be good for us to take that into account.
Not supported in V1.1
Is the goal to eventually support this? If so, we should probably just leave this bug open and mark it as an enhancement. Otherwise, if this is a requested feature that's not being implemented, it WONTFIX (if we will never implement the feature, ever, which does not seem to be the csae) or INVALID (which you had set it to before) are probably the right choices.
We need to support this issue, hence reopening it. To decide on the scenario for this issue, planning to consider the below points 1. SIM card change event to notify the Email application 2. Credential storage with encryption in the email application to verify when the SIM is changed. Andrew, Please suggest the things that we need to consider in this situation and also UX for the same. We should also consider the scenario of deleting the existing accounts (assume phone was lost/theft, sim is replaced)
This sounds like a new feature, so adding feature keyword, and flagging arog, the product manager for email for input. This does seem to be a bit larger feature, and probably needs more product definition first from the product side. Given that and that asuth is on PTO at the moment, taking him off the needsinfo and putting arog on instead. As an end user though, I would want to call out that when traveling I have enjoyed just switching sim cards and still keeping all the data setup on my phone stable (email/contacts), so if this was an actual feature that lands, seems like it would need some nuance to support users that travel and want to keep their data.
To clarify, :psingapati and I discussed this on IRC last night. 1 and 2 from comment 4 are basically alternate ways to get the UX effect requested in comment 0. Approach 1 amounts to creating fake security or a policy-based defense against very incompetent attackers. The credentials and all of the mail for the account would still be accessible; all we'd be doing is misleading users into thinking things are more secure than they are. Thunderbird has something sort of like this. You can password protect an account, but the password does absolutely nothing. I think we categorically would never want to do this. Approach 2 involves implementing platform keychain support, which is bug 877535. This is a good idea in general, although unless the passwords are physically stored in the SIM card or are encrypted with effectively secret keying material from the SIM of sufficient entropy, it's still fake security again. (Although it would be fake security that could later be upgraded into real security.) I agree with :jrburke that in general, I don't want any of my data keyed off of my SIM card. So I think the system implementation of keychain support would need to support choice of using any available SIM card protection in addition to other, more general computing encryption, like utilizing NSS's master password mechanism based on the (ridiculously weak) lock screen PIN, or preferably, via a stronger password/keyphrase that must be entered according to some policy. Note that there's also bug 877648 about adding a password manager for the browser. That's a different thing, but any implementation to support that probably would move us in the direction of having improved system support.
For security issue, it is a good suggestion to have some security check process when SIM is switched. But don't forget this could mean user needs to set and memorise one more password that may rarely be used (which means can easily forget). Plus echo to James and Andrew's opinion that as a user if switching SIM for traveling reason it maybe a hazel to key in password when switch SIM. It is a new feature, UX can help on this when a general direction is set. And one question, is email the only app considering to have this security check?
To Clarify a point here, the request is, "to validate with the actual password of any account that is configured in the email app".So if there are multiple accounts configured, user can validate with password of any one of the account. It is not required to have one more new password for authentication.
In general we should be encouraging the user to set a device password to enhance the over-all security of the phone and to provide some data security in the case a phone is stolen. In regard to this bug specifically; unless where it is required, applications on the phone should not be influenced by a change of SIM. Email is no exception to this and I see no reason why performing a SIM swap should effectively invalidate a users account credentials. Moreover, there a several reasons why we would explicitly NOT want to do this, several of which have already been highlighted in previous comments. Lets leave this at a feature request for the time being, but without additional data points describing why this is needed I am not a proponent of implementing.
Created attachment 8365010 [details] [diff] [review] Bug_832914_Email_SIM_Change.patch proposed patch as per comment#4.
Created attachment 8376171 [details] Bug_832914_Email_SIM_Change_with_BuildConfig Proposed Patch: Attached File contains the Email SIM change patch with build configuration enabled. It also contains the FxOS device screenshots for this feature
In response to Adam's comment 9 and further discussions offline, this is not a feature that we will add to FxOS for the time being. We may reconsider this at a later stage if we see more use cases or solid data to support the need for this.
Adding customisation flag as it is OEM's own feature and not to be landed into FxOS trunk.