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 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. -- 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. Kai
