RE: ACTION-389: Error levels?

Okay, I think I agree with you about this example.  I have no idea how
frequently certificate status is unavailable.  I would certainly put SSCs in
bucket one due to their prevalence, and if certificates with unknown status
are as prevalent, they certainly belong there too.

serge

-----Original Message-----
From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org] On
Behalf Of Stephen Farrell
Sent: Monday, February 18, 2008 1:38 PM
To: Serge Egelman
Cc: W3C WSC Public
Subject: Re: ACTION-389: Error levels?



I think I like the 3 categories, but would put lack of
cert status info into bucket 1 since its often not
available.

Would also be interested in more examples - I guess the
concern would be that one of the buckets might overflow
which'd devalue the categorisation.

S.

Serge Egelman wrote:
> Well, the idea is to create three buckets of risks:
> 
> 1) Things that *could* be bad, but we really don't have sufficient
evidence
> 
> 2) Things that are *likely* bad, but we're not absolutely positive so we 
> can't block the page outright.  More importantly, this category exists 
> because we don't want to habituate users to the most severe warnings by 
> showing them in situations where there are likely to be false positives 
> (e.g. determinations made solely by heuristics or when not enough 
> information is known, but there is sufficient information to raise 
> concern).
> 
> 3) Things that are *known* to be bad.  These warnings appear only when a 
> real threat has been identified.  These warnings must not be shown when 
> there is a chance of false positives, as this will habituate the users 
> to these warnings and they will become useless in all other cases.
> 
> Thus, I think that heuristics and a CRL which can't be located would 
> both fall into the middle category.  These are both things that should 
> raise some concern, however we cannot be confident that something bad is 
> going to happen.
> 
> 
> serge
> 
> Stephen Farrell wrote:
>>
>>
>> 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 23:15:24 UTC