- From: Serge Egelman <egelman@cs.cmu.edu>
- Date: Mon, 18 Feb 2008 08:50:48 -0800
- To: W3C WSC Public <public-wsc-wg@w3.org>
Here's the proposed text (I know it could use some work, but this is a first pass), though I'm not sure which section to put it in: Browser security indicators MUST fall into one of the following categories: 1) Notifications/Status Indicators a) WHAT: warnings/indicators that are displayed in the browser's persistent primary chrome. These indicators MUST NOT force user interaction (e.g. forcing the user to click a button to continue the primary task). They MUST be located in the browser's chrome and include a succinct textual description of their meaning. b) WHEN: the browser cannot accurately determine a security risk based on the current security context information available. These indicators SHOULD also be used for situations where the risk level may vary based on user preference. 2) Warning/Caution Messages a) WHEN: these MUST be used when the system has good reason to believe that the user may be at risk based on the current security context information, but a determination cannot positively be made (e.g. CRL cannot be located, OCSP server unresponsive, phishing heuristics triggered). These warnings SHOULD be used if the likelihood of danger is present, but cannot be confirmed. b) WHAT: these warnings MUST be designed to interrupt the user's current task, such that the user must acknowledge the warning. The headings of these warnings MUST include the words "warning" or "caution," and they MUST NOT include technical jargon, or be longer than a dozen words. The headings of these warnings MUST be the locus of attention, and the warning SHOULD have an option for advanced users to request a detailed description of the warning condition. These warnings MUST provide the users with options on how to proceed (i.e. the warnings MUST NOT use a single option to dismiss the warnings and continue). The options presented on these warnings MUST be descriptive to the point that their meanings can be understood in the absence of any other information contained in the warning. These warnings SHOULD include one recommended option, and a succinct text component denoting which option is recommended. In the absence of a recommended option, the warning MUST present the user with a method of finding out more information (e.g. hyperlink, secondary window, etc.) if the options cannot be understood. 3) Danger Messages a) WHAT: These warnings MUST be designed such that the user's task is interrupted, and the user is unable to view or interact with the destination website. The headings of these warnings MUST include the word "danger," and they MUST NOT include technical jargon, or be longer than a dozen words. The heading MUST be the locus of attention, and the warning SHOULD have an option for advanced users to request a detailed description of the warning condition. b) WHEN: these MUST be used when there is a positively identified danger to the user (i.e. not merely risk). Examples include websites or software downloads that have been blacklisted (i.e. positively identified), revoked certificates, etc. -- /* PhD Candidate Carnegie Mellon University "Whoever said there's no such thing as a free lunch was never a grad student." All views contained in this message, either expressed or implied, are the views of my employer, and not my own. */
Received on Monday, 18 February 2008 16:51:18 UTC