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

Ian, I like this note but think the example is bad because it is
normative today to follow the practice of masking in the at because that
is what is provided to the user anyway.  If we can come up with a better
eample though such as for instance, document security being prohibitive
to at, that would be good.

----- Original Message -----
From: "Ian B. Jacobs" <ij@w3.org>
To: "Jim Ley" <jim@jibbering.com>
Cc: <w3c-wai-ua@w3.org>
Sent: Wednesday, May 22, 2002 2:25 PM
Subject: Re: [Proposal] New Guideline 6 checkpoints (APIs, Infoset, DOM)


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

Received on Wednesday, 22 May 2002 18:11:34 UTC