Re: [Proposal] New Guideline 6 checkpoints (APIs, Infoset, DOM)

Al,

I think that developers will not want to leave a hole open for programmatic 
access to secure information.  They can provide a secure API, but I don't 
think this will work unless we have a spec available to show them now.  I 
don't think it is part of the current DOM requirements, but if it is then I 
with draw my suggestion.  I don't think we should require more information 
be provided through the API than what the user would get through the 
standard user interface.   You can always do more.

Jon

At 09:24 AM 5/21/2002 -0400, Al Gilman wrote:
>At 10:40 AM 2002-05-20, Jon Gunderson wrote:
> >6.5Programmatic access to user agent user interface controls.(P1)
>
> >a. I think for the read requirement we also need a security clause to 
> say that what is available through the read access is the same 
> information that is available to the user through the user interface.  So 
> for example a password box that shows asterisks to the user through the 
> user interface, would also be the same content as a programmatic read.
>
>We should not add this.  The value waiting to be submitted should not be 
>obscured in the API access to the content.   However the [asterisks] 
>should be present in the access to as-rendered content.  The password or 
>equivalent should be marked as security sensitive.  This is accoplished by 
>the element name in the infoset.  It is the responsibility of the AT, the 
>co-routine receiving the API access, to handle it safely for the security 
>sensitivity that it has.  But what is "safely" depends on the delivery context.
>
>A user using an earphone to receive their audio readout and suppressing 
>speaker output has probably created sufficient physical security so that 
>the echo of this field need not be obscured.
>
>The default binding of the interaction defines the initial point for 
>adaptation, but not the reference definition of the interaction.  The 
>reference definition is what the application needs from the user to get on 
>with doing the user's bidding.  One changes the interaction as little as 
>possible to achieve what is needed, but in the context of what does get 
>changed, the interaction should be fully optimized.  Optimized for 
>usability, not just closeness to the default binding.
>
>  http://lists.w3.org/Archives/Public/www-archive/2001Nov/0069.html
>
>We should not be left in the position of forcing the perpetuation of a 
>usability problem under circumstances where the security rationale is not 
>valid.
>
>Al
>
>
>
> >Jon
> >
> >
> >[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0090

Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
MC-574
College of Applied Life Studies
University of Illinois at Urbana/Champaign
1207 S. Oak Street, Champaign, IL  61820

Voice: (217) 244-5870
Fax: (217) 333-0248

E-mail: jongund@uiuc.edu

WWW: http://www.staff.uiuc.edu/~jongund
WWW: http://www.w3.org/wai/ua

Received on Tuesday, 21 May 2002 10:49:24 UTC