Re: Forwarded feedback on WSC FPWD from Don Norman

Thanks Tyler.

Replying to the notes from Don (whereever he might be): 

> All the use cases you provide are for potential rogue sites, which fool
> the user into accepting them.

All the use cases are not just malfeasance. As a single example, scenario 
1 in section 6.5 is not. 

> 
> In my experience, there is also the problem of over-caution.

And in certain phishing studies as well. I would appreciate any pointers 
to anything in wsc-usecases that needs to be amended or added to make sure 
the issue of over-caution is appropriately included in this stage. For 
example, I read over the goals just now, and I didn't see anyplace that 
assumed we were only dealing with ensuring caution when warranted. But 
perhaps there are other places. 

> 3B, below, is one of the many problems because people do not understand
> the architecture of compute and web applications and confuse the
> messenger with the message.
> 
> If they use Internet Explorer for activities, they identify the activity
> (mail, banking) with the browser and do not understand that the actual
> service is hosted somewhere in the cloud, so any browser yields the same
> result.
> 
> --
> I myself have tried to tell banks that their legitimate emails look
> identical to scams, and if the respond at al, it is to assure me that
> they would never do anything wrong.   That wasn't my point. My point is,
> illegitimate emails often look legitimate. Therefore, legitimate emails
> look illegitimate.  How is the recipient to know?  Why do legitimate
> emails still have clickable URLs?
> 
> ====================
> 
> 1. The legitimate financial institution sends out a legitimate note
> stating that some action is required.  Jane, the recipient, knows not to
> trust such legitimate-looking documents, and immediately deletes it,
> without acting.

We're explicitly a Web WG. This is a pure mail use case. As such, I 
believe it to be out of charter. There has been robust discussion (before 
the WG was chartered) on the dangers of dividing up the phishing problem, 
but the truth of the matter is, that's how standards work. Goal 2.7 
addresses this. 

> 
> 2. A window pops up on the screen stating that an important security
> update is now available. The message is legitimate (e.g., it is a
> Microsoft standard message). Henry wonders why his various malware
> detectors didn't stop it, but immediately closes the window.  Over the
> months, his system falls further and further behind in security updates.

This is a pure OS use case, so again, out of charter. 

> 
> 3A. Helen proudly tells her spouse that using Microsoft tried to fool
> her into using a bank site, so she isn't using Microsoft anymore but
> instead is using Firefox to do her banking.  (Confusion between the
> browser and the financial institution)

The issue this raises seems to also be covered by 9.1, 9.2, and 9.3 of 
wsc-usecases. And this does not seem phrased as a scenario. 


> 
> 3B. Helen is concerned though. Microsoft is how she reads her mail, and
> now she doesn't know what to do. She doesn't trust Microsoft mail
> anymore. What should she do?  (Because she reads her web-based email
> through a particular browser, she identifies the email service with the
> browser)
> 

This one doesn't seem phrased as a scenaio. Perhaps it's related to 2.7 
(if she won't use a browser, some other mechanism will get to her). If 
it's pure email, it's out of charter. 

I don't mean to dismiss the concerns and discussion at all. I am having 
trouble working them into the structure of wsc-usecases, or figuring out 
what would need to change in that structure if they're not integrated 
appropriately, according to the charter, to determine what, if any, 
followup there should be: 

http://www.w3.org/2005/Security/wsc-charter