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

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" <[email protected]>
>>
>>>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 ([email protected])   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: [email protected]

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