Re: ACTION-389: Error levels?

Thanks Serge.  I've taken a stab at your material and just committed
a totally new section 6 to the editor's draft.  I've made some
changes: Material that's common to all has moved into 6.4.1; I've
tried to do the usual "for visual user agents" dance; I've tried to
abstract from the English language ("word meaning danger" and
phrasings like that; also, I replaced the "no more than 12 words" by
a more fuzzy "must be brief").

Note that there is not even a definitive strawman yet when what
should occur; I'll do that when I'm through editing chapter 5.

   Web Security Context: Experience, Indicators, and Trust
   Editor's Draft 29 February 2008
   $Revision: 1.171 $ $Date: 2008/02/29 15:58:12 $

   http://www.w3.org/2006/WSC/drafts/rec/#error-handling
  
Here's the current text; editor's notes formatted as quoted text:

   6.4 Error handling and signalling
   
>   Please refer to the following entries in the Working Group's wiki
>   for background information: CertErr

   6.4.1 Common Error Interaction Requirements
   
   Error signalling that occurs as part of primary chrome SHOULD be
   phrased consisely when using natural language.
   
   Primary chrome error messages MUST NOT include technical jargon.
   They SHOULD NOT refer the user to enter the destination site that
   caused the error, e.g., to provide feedback or obtain assistance.
   For error messages that interrupt the user's flow of interaction,
   user agents SHOULD enable the user to easily return to the user
   agent state prior to initiation of the last user interaction that
   led to the error signal.
   
   For advanced users, error interactions SHOULD have an option for
   advanced users to request a detailed description of the condition
   that caused the interaction to occur.

   6.4.2 Notifications and Status Indicators
   
   Notifications and status indicators are used 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 in which the risk level mayv ary based on user
   preference.
   
   For visual user agents, notifications and status indicators MUST be
   displayed in the user agent'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 include a
   succinct textual description of their meaning.
   
   Notifications and Status Indicators MUST be used to signal the
   following situations:
   
>   link back to section 5
   
   Notifications and Status Indicators SHOULD be used to signal the
   following situations:
   
>   link back to section 5

   6.4.3 Warning/Caution Messages
   
   Warning / Caution messages 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. These warnings SHULD be used if the likelihood of danger is
   present, but cannot be confirmed.
   
   Warning / Caution messages MUST interrupt the user's current task,
   such that the user must acknowledge the message.
   
   For user agents with a visual user interface, headings of these
   warnings MUST include words meaning "caution" or "warning". The
   headings of these warnings MUST be the locus of attention.
   
   Warning / Caution messages MUST provide the user with distinct
   options how to proceed (i.e., these messages MUST NOT lead to a
   situation in which the only option presented to the user is to
   dismiss the warning 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 interaction. 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., a hyperlink, secondary window, etc) if the options cannot be
   understood.
   
   Warning / Caution messages MUST be used to signal the following
   situations:
   
>   Link back to section 5. Examples from Serge were OCSP server
>   unresponsive, phishing heuristics triggered, CRL can't beloaded.
   
   Warning / Caution messages SHOULD be used to signal the following
   situations:
   
>   Link back to section 5.


   6.4.4 Danger Messages
   
   Danger Messages MUST be used when there is a positively identified
   danger to the user (i.e., not merely a risk).
   
   The interactions communicating these messages MUST be designed such
   that the user's task is interrupted.
   
   For visual user agents, these interactions MUST be presented in a
   way that makes it impossible for the user to view or interact with
   the destination web site that caused the danger situation to occur.
   The headings of these warnings MUST include a word meaning "danger."
   The heading MUST be the locus of attention.
   
   Danger Message signalling MUST be used in the following situations:
   
>   Link back to section 5; Serge suggests blacklisted downloads,
>   revoked certs, etc.
   
   Danger Message signalling SHOULD be used in the following situations:
   
>   Link back to section 5.

Regards,
-- 
Thomas Roessler, W3C  <tlr@w3.org>






On 2008-02-18 08:50:48 -0800, Serge Egelman wrote:
> From: Serge Egelman <egelman@cs.cmu.edu>
> To: W3C WSC Public <public-wsc-wg@w3.org>
> Date: Mon, 18 Feb 2008 08:50:48 -0800
> Subject: Re: ACTION-389: Error levels?
> List-Id: <public-wsc-wg.w3.org>
> X-Spam-Level: 
> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by
> 	milter-greylist-2.0.2 (jabba.geek.haus [192.168.11.20]); Mon, 18 Feb 2008
> 	11:50:59 -0500 (EST)
> Archived-At: <http://www.w3.org/mid/47B9B768.901@cs.cmu.edu>
> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.6
> 
>
> 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 Friday, 29 February 2008 16:07:40 UTC