Jennifer Glick wrote: > > Kai Engert wrote: > > >>Jennifer Glick wrote: >> >> >>>Updated Security spec based on having a security Toolbar button in Mail >>>Compose. The Toolbar security icon seems the best way to go since it >>>makes the feature more discoverable without disturbing the attachment >>>area. >>> >>>http://www.mozilla.org/mailnews/specs/security/ >>> >>I like the new spec, especially, that the status bar is no longer used >>to configure what the user wants to do. I think that's the right decision. >> >>-- >> >>A 2: I think we can not use this version, because of the dual key >>requirement, therefore A 1 looks as the one to go with. >> >>If we had more space, I could imagine a third version. Similar to >>version 1, but with a checkbox. That checkbox could say "use same >>certificate for both encryption and signing". When checked, it would >>disable the widgets for configuring the second certificate. By default, >>that option were be checked. >> >>-- >> >>While I really like the wording in the preference dialogs from section >>A, I have a minor suggestion for B: >> >>I think the menu label in the compose window "always encrypt" is >>potentially misleading. >> >>While the word "always" makes sense in the global preference, I think it >>confuses a user who edits a single message. The user might think that >>the global option is changed, which it is not. >> >>I also suggest that we could try to avoid the word encryption in the >>weakest option (where we don't use encryption), and to only use positive >>statements, avoding the word "no". >> >>So what about: >>- Send in clear >>- Encrypt if possible >>- Force encryption >> > > I agree that "Always Encrypt" in the per message menu could be confusing. What > about "Require Encryption"? Prefs could use that wording as well. > > I don't think users will understand what "Send in Clear" means though. > > >> >>I also want to suggest to change the order of the three menu items as I >>arranged them above. That way, we have an order of strength in the menu. >>The strongest option is at the bottom, the weakest at the top, and the >>somewhat secure option is in the middle. >> > > Sounds good. > > >> >>-- >> >>B a: You ask in italics, whether the menu items should be disabled until >>something is configured. I don't think we should do it that way, because >>having the items always enabled encourages users to try the setting out, >>allowing them to discover security. I like the idea of appearing help >>texts when a feature is accessed for the first time. We could use it >>here, too. >> > > Yes, would be nice if we can do this. > > >> >>Kai >> > Jennifer,
If I have a choice of default value of "No encryption", "Encrypt if possible" and "always encrypt" the selection is fine. The same with signed, no sign I choose "No encryption" and "no signing" as default. If I need to sign, ecrypt och sign&Encrypt a message then my prefered selection would be sign, encrypt or sign&encrypt (via meny choices) I can't really see what "encrypt if possibly" means when I composing the message, I think that choice is a default setting and not a per message setting. The wording can change (as the discussion goes on), but still the "encrypt if possible" on a per message setting is redundant (either you want it encrypted or not). Maybe there can be a messagebox telling "that not all adresses can received encrypted, do you want to send it anyway" /Lars
