Re: ACTION-389: Error levels?

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.
>>
>>
> 

-- 
/*
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 18:46:29 UTC