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.
|... | To activate these security features, you need to obtain a digital | certificate. Certificates are issued by independent certification | authorities (CAs).� Any encryption scheme which relies on a third party seems fundamentally flawed to me. You are relying on organization A to tell you that person B is who he says he is, when it is highly likely that the only relationship A has with B is that B has paid A some money. But then, what would I know, I is just a UI designah. | <http://mozilla.org/mailnews/specs/security/images/AcctSet1.gif> |... | <http://mozilla.org/mailnews/specs/security/images/AcctSet2.gif> As usual in Mozilla, this panel uses far too many group boxes. Group boxes should only be used in exceptional cases, where you need to separate a particular group of settings from the rest of the panel to avoid confusion. This panel would be quicker to scan, and more aesthetically pleasing, without them. For example: | | +-Encryption & Signing------------------------------------------+ | | | | | [ ] Use encryption when sending messages | | | ( ) Always (Send is disabled unless certificates for all | | | recipients are available) | | | ( ) If possible (messages are sent without encryption if | | | certificates for all recipients are not available) | | | | | | [ ] Digitally sign messages | | +---------------------------------------------------------------+ This would be better as: | | [/] Digitally sign outgoing messages | | Encrypt outgoing messages: | ( ) Only when I choose `Encrypt' | (*) Whenever all recipients have certificates | ( ) Always (insist on certificates for all recipients) This design is quicker to scan, and it reduces the annoying repetition of `certificates for all recipients are [not] available'. Furthermore, it cuts the average number of clicks for setting these prefs from 1.50 to 1.17. (This naively assumes equal probability of any combination of settings; but unequal probabilities would only affect the size of the improvement, they would not affect the fact that my design is more efficient.) The other group boxes can be disposed of in a similar fashion. |... | 3. News | | Encryption is not available for news accounts. The mockup shows that this unavailability of encryption is indicated by hiding the encryption controls at the top of the panel. There is a problem with this, however. The constant repetition of the words `Server Settings, Copies & Folders, Addressing, Offline & Disk Space, Secure Messages', in the category listbox of the Account Settings dialog, is a tell-tale sign of the wrong GUI control being used. In this case a 1.5-dimensional tree is being used to show categories which are actually two-dimensional (account * topic). This will likely be solved, once I get around to filing the bug, by using an option menu for accounts and tabs for the categories. Whichever controls are used, the point is that users will be able to stay on the same category while rapidly switching between accounts, to compare the settings in the same category for multiple accounts. The shifting of almost every control in this panel between news accounts and non-news accounts, however, would severely disrupt this. Even with the current method of switching between categories, changing the position of almost every control in the panel between accounts is unnecessarily inconsistent. This could be solved either by disabling the encryption controls instead of hiding them, or by including the signing and encryption controls at the bottom of the panel instead of the top. |... | * Status bar shows a "broken pen" icon indicating signing is turned | off. The broken pen looks rather non-obvious to me, and for the majority of users -- who never signed their messages, and would therefore have this icon in every message composition window they ever opened -- it would tend to be subconsciously insulting of their writing abilities. Perhaps you could consider a more obvious and/or less alarming icon, such as a pen or thumbprint with a red line through it. I agree with Peter Trudelle that there should be Sign and Encrypt buttons in the Toolbar, and that the Status Bar should concentrate on indicating status. |... | 3. Send Encrypted - Certs for Some Recipients & Not for Others | -"Always Encryption" |... | * The Send button is disabled and contains the "open lock" icon. The | message cannot be sent. This may not be this is the best approach, since if the user goes to click Send in the first place it's likely that they would not know why it is not available. I'm not sure of the best way to solve this problem yet, but I know that a multi-paragraph tooltip isn't it. |... | <http://mozilla.org/mailnews/specs/security/images/Options1.gif> Given the small number of items in the `Options' menu, and the clear grouping of the encryption items, there's no real need to make them a submenu. |... | 2. With An Attachment | | Feedback in envelope area. Encryption and/or signed icons displayed as | appropriate. The position of the encryption and signed icons appears completely random. And their placement directly under the `Attachments:' heading makes them look like they might be attachments. |... | F. Forwarding and Replying to Messages | | This section not yet discussed. That's what this thread is for, presumably. | Only forward as attachment allowed? |... | There is value in knowing whether the original message was signed, but | it can only be done by keeping the original message intact together | with it's signature. This can only be accomplished if the original | message is delivered as an attachment. However, users may wish to edit | the message before sending it, which requires the message to be | inline. If the original message is inline, no statement can be made as | to whether it was originally signed. So, if you want to include proof that the original message was signed, you forward it. If you prefer to make inline comments, you reply to it instead. If you're replying, you're (almost always) doing so to the sender of the original message, so there is no need to say `this message came from you'. (`I know it did, I was the one who sent it!') Finally, general notes about the spec: * There seems no good reason to separate the `Open Issues' section at the beginning and the `Issues' section at the end. * Many lists in the spec contain empty items at the end, and the table arrangement at the beginning is very strange. I suggest avoiding the use of FrontPage 4.0 when writing future specs. That's all for now -- Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing <http://mozilla.org/>
