Re: ACTION-389: Error levels?

Text looks good, but I think more/other examples would help.

In particular I'd not equate "missing CRL" with "phishing
heuristic triggered," but I guess we can discuss that sometime,

S.

Serge Egelman wrote:
> 
> 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.
> 
>

Received on Monday, 18 February 2008 18:33:28 UTC