Peter Trudelle wrote: > I would expect typical use of encryption to be on a per-message basis, > rather than 'always' or 'if possible'.
Most S/MIME users of Communicator did indeed select encryption on a per-message basis. This design gives users that same ability by clicking on the lock icon to close it. But some Communicator users wanted to encrypt as much mail as possible. To accomplish this goal, they set the encryption pref to encrypt all emails. If the client had all available certs, the message was encrypted. If the client did not have all the necessary certs, it presented the user with a warning that said "Turn off encryption and send the message anyway?". These users thought this message was annoying. They asked for a "best effort mode". This design attempts to address this request, while at the same time preserving the per-message functionality. My guess is that a large percentage of secure mail users will opt for the "encrypt if possible" mode since it does not require any additional work or thinking. On my corporate intranet with an LDAP server, all my intranet-bound mail will be encrypted with no extra effort. Only a few users insist on encrypting all emails, but they do exist. > I doubt that turning the lock's > shackle to closed is discoverable enough for it to be sufficient as the > main means to encrypt a single message. I'm also not clear on how this > button would behave if you didn't have the needed certs. This pencil and lock icons behave much like the "online" switch to the right. They indicate the user's intended mode without guaranteeing anything. You may try to set the online switch to online, but there's no guarantee that you'll be able to access web resources. You might not be connected to a network. Likewise, clicking the lock icon to close it indicates your intention to encrypt the message. It does not tell you if you'll succeed. You can look at the Send button for that information. > Would the > shackle return to open after you clicked it? Yes. Like the online switch, it goes between two states. In this case: locked and unlocked. > Is the shackle even > sufficient as an indicator? (I know I have trouble seeing it in the > spec, less so in the current product) Do you have trouble see it because it's small, or because it's off in the corner? > Finally, using it to set > encryption would seem to preclude using it as an informational "show > security info" as is now done in other content areas. This is a good observation. One difference between the lock icon on a web page and the lock icon in the mail compose window is that in the latter there isn't much information to report. In Communicator, clicking the lock icon in mail compose would tell you (a) if you could sign the message and (b) if you could encrypt the message. This design shows both without having to click. > Did you consider adding a nice, big, fat toolbar button, or other > obvious separate affordance for this instead of overloading the lock icon? Communicator has the toolbar security button as you mention. That makes it very visible, but it requires that you click on it before you can change your signing or encrypting settings on that message. Outlook has big Sign and Encrypt icons in their toolbar. That takes up more space, but is much more clear for per-message settings. We did talk about that type of design. However, the other icons in the task bar perform functions (e.g. Send the message, open the address book, etc.) and the sign/encrypt icons show the user's preferences. Other such prefs are shown under Options (e.g. Priority and MIME settings). It didn't seem to belong there on the toolbar. I personally like the idea, and in fact it would help improve the discoverability of the feature. Jennifer may have additional comments on this question. -Bob > > Peter > > Jennifer Glick wrote: > >> Draft spec now posted here: >> http://www.mozilla.org/mailnews/specs/security/ >> >> Please post comments to the mail-news and crypto newsgroups. >> > -- Bob Lord Director, Security Engineering Netscape Communications Corp. PKI Home Page: http://www.mozilla.org/projects/security/pki/
