Re: ACTION-389: Error levels?

fixed

On 2008-02-29 12:55:55 -0500, Mary Ellen Zurko wrote:
> From: Mary Ellen Zurko <Mary_Ellen_Zurko@notesdev.ibm.com>
> To: tlr@w3.org
> Cc: W3C WSC Public <public-wsc-wg@w3.org>
> Date: Fri, 29 Feb 2008 12:55:55 -0500
> Subject: Re: ACTION-389: Error levels?
> X-Spam-Level: 
> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.6
> 
> Two typos.
> 
> 6.4.2 - "the risk level mayv ary based "
> 
> 6.4.3 - "These warnings SHULD be used "
> 
> I remain good with the content. 
> 
> 
> 
> From:
> Thomas Roessler <tlr@w3.org>
> To:
> Serge Egelman <egelman@cs.cmu.edu>
> Cc:
> W3C WSC Public <public-wsc-wg@w3.org>
> Date:
> 02/29/2008 11:02 AM
> Subject:
> 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.
> > */
> >
> >
> 
> 
> 
> 

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

Received on Friday, 29 February 2008 20:35:30 UTC