- From: Jon Gunderson <jongund@uiuc.edu>
- Date: Wed, 22 May 2002 13:52:22 -0500
- To: Jim Ley <jim@jibbering.com>
- Cc: w3c-wai-ua@w3.org, ij@w3.org
Jim, Thank you for your comments. Let's discuss this as part of Issue #528 [1] Would you be able to come to the meeting UA meeting tomorrow? Thanks, Jon [1] http://www.w3.org/WAI/UA/issues/issues-linear-cr2.html#528 At 02:25 PM 5/22/2002 -0400, Ian B. Jacobs wrote: >Jim Ley wrote: >>"Jon Gunderson" <jongund@uiuc.edu> >> >>>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 withdraw 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. >> >>The value of the password element is already exposed in DOM 0 (and >>later), the asterixing is purely visual, it's often also misleading to >>user/developers that it is in some way more secure than other form >>elements, when it is not. I think it would be more useful to expose the >>value rather than the asterix's or blobs that are used now - it doesn't >>introduce any new security holes, and the information is not secure. >>For genuine secure information, that may be different, but do we have >>any? > >I agree with Al Gilman (and perhaps Jim as well) >that security issues should be addressed at another >layer than the layer of functionality we are requiring >in Guideline 6. > >UAAG 1.0 mentions security issues in section 1.3 [1]: > > "Security. This document does not address security issues that may > arise as a result of these requirements. For instance, > requirements that software be able to read and write content and > user interface information through APIs raise security issues. See > the section on restricted functionality and conformance." > >Perhaps we should not consider the lack of explicit security >measures a limitation of UAAG 1.0 but rather an explicit feature >of UAAG 1.0, and explain our expectations. > >It's standard practice for RFCs to include a "Security Considerations" >section. What do people think about a section in >UAAG 1.0 that says something like this: > ><new> >Security Considerations > >Some of the requirements of UAAG 1.0 (e.g., communication through >APIs, allowing programmatic read and write access to content >and user interface control, etc.) have security implications. >This document assumes that user agent developers will address >security concerns through underlying security mechanisms, and >that other features, including features required by UAAG 1.0, >will be built above the security infrastructure. Consequently, >there are no "exceptions for security reasons" explicit in >UAAG 1.0 requirements. > >Consider the example of a form control that allows the user to >enter a password. Graphical user agents commonly mask >mask characters typed in a password entry control, for example >by displaying the characters as asterisks. The user >agent should not communicate asterisks to assistive technologies, >but instead use legitimate security mechanisms such as encryption >so that, for example, only trusted assistive technologies have access to >what the user typed. > >Appropriate behavior by the user agent (particularly with respect to >security) depends very much on the user's context. For instance, hiding >passwords visually with asterisks meets the needs of users in a crowded >environment, but is not critical when one is alone in a room. Similarly, >passwords should not be broadcast over a loudspeaker, but could very well >be spoken through an earphone and pose no security risk. > >Include links here to XML-Signature Syntax and Processing >http://www.w3.org/TR/xmldsig-core/ >and XML Encryption Syntax and Processing >http://www.w3.org/TR/xmlenc-core/ ></new> > > - Ian > >P.S. This will help us address issue 528 [2]. > >[1] http://www.w3.org/TR/2001/CR-UAAG10-20010912/uaag10#limitations >[2] http://www.w3.org/WAI/UA/issues/issues-linear-cr2.html#528 >-- >Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs >Tel: +1 718 260-9447 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 Wednesday, 22 May 2002 14:51:45 UTC