W3C home > Mailing lists > Public > public-webapi@w3.org > March 2006

Re: in defence of listener discovery (ISSUE-32, ACTION-84)

From: Al Gilman <Alfred.S.Gilman@IEEE.org>
Date: Fri, 31 Mar 2006 07:43:26 -0500
Message-Id: <p06110404c0520015426e@[]>
To: Jonas Sicking <jonas@sicking.cc>
Cc: WebAPI WG <public-webapi@w3.org>, wai-liaison@w3.org

At 1:33 AM -0800 3/30/06, Jonas Sicking wrote:
>Hi Al,
>It is excellent that we are getting some communication going between 
>our groups. I hope we can work something out that we can all be 
>happy with.

Yes, I think we have reduced this to the point where we can roughly
agree that there are some upside and some downside potentials, here.

Could be some real-time cross-participation may be in order. I mean
guesting in one another's calls, for example.

>Al Gilman wrote:
>>* Why in the DOM?
>>[Jonas, Maciej]
>>Actually, my main question is not why the these functions are needed,
>>but why they are needed in the DOM API.
>>Per the User Agent Accessibility Guidelines, a compliant user agent
>>is one that supports the W3C Document Object Model. The reason is
>>this is the one API which the W3C controls for which we can prescribe
>>interoperability with W3C content. It is from this API that the user
>>agent can map secondary API to the DOM or to which the AT can access
>>directly for interoperability. Both Home Page Reader, Freedom
>>Scientific's JAWS, and the Fire Vox talking web browser all interact
>>with the DOM to provide their assistive technology solution.
>>It is the DOM that is responsible for getting an event handled by the
>>right handler. So it is the DOM that should tell you what that
>>handler will be, so that [usability cardinal rule] "the response of
>>the system to user action is predictable" when the application is
>>operated through a changed profile of input and output modalities.
>I think my question still stands. Why do these applications, like 
>JAWS and Fire Vox, use the DOM? Since they are external programs and 
>don't run in the sandbox of the web page, they should have full 
>access to the full set of APIs that the UAs expose where the DOM 
>usually is just a small subset.
>Is the reason perhaps that it is easy for these tools to use the DOM 
>since it is an API that is similar across all UAs? This certainly 
>sounds like a valid reason to me if it is the case.

Yes, that is a motivation that matters here.  Not necessarily to the exclusion
of all other issues, of course.

>That said, I am not happy about exposing these functions to web 
>pages due to privacy and security concerns. If the web page can 
>query which EventListeners are registered, and in the future even 
>enumerate and query them for information, it could find out 
>information about the user that the user might not necessarily want 
>to give out to every site he/she goes to. Remember that 
>EventListeners are not limited to ones added by the web page. The UA 
>itself could very well be adding EventListener to parts of the web 
>page itself. This is certainly the case in Firefox where both 
>Firefox itself and various extensions installed will add 
>EventListener to parts of the DOM.

I think this may take deeper examination than asynchronous email will 
support (in a timely fashion).

But a few thoughts:

I don't think that exposing the listeners that the UA adds discloses 
anything more to the server
or malware host than the shipping code of the UA discloses.

But yes, if you can sniff for listeners and discover Jaws, you can 
suspect the owner has
rather little vision.

Sniffing for listeners could compete with scanning for open ports in 
exploitable-hole discovery.


If Jim Ley's tactic is already available to malware, aren't we 
closing the barn door
after the horse is gone, if we deny this functionality to the AT programs?

>However, exposing these functions to web pages does not sound like 
>it is a requirement to you, is that correct?

I will have to check with our developers if and how much this is needed.

>  If that is the case, but you still want an API defined to access 
>this information, maybe we could define a separate API specifically 
>for accessibility tools that DOM implementations don't necessarily 
>have to expose to web pages.
>If we did that I think we would have much greater freedom in adding 
>functions since there would be virtually no concern about security, 
>and the API could be defined with an entirely different set of users 
>in mind (writers of accessibility tools, rather than web developers).
>Does that sound like a good solution.

A layered API with more available to installed code and less to
scripts in the page could perhaps meet the UAAG objectives, here.

There still might be some powers reserved to the host browser

It has to be integrated so the document viewed and manipulated
from either view is the same document.  One of the reasons that
AT are *not* using the DOM more is that the DOM and the screen
don't present the same document too often, given the level
of 'repair' processing that supports HTML in browsers.  With the Mobile
interest in a valid DOM, we're taking fresh hope.

I think I might also wonder if this security concern may roll into
the "access control task force" seeking appropriate authorization

It is a pity we don't have the declarative XBL tools in hand today.
If all we were doing was switching a handler from only expecting a
mouse event to also responding to keyboard or voice, where the
keyboard and voice drivers were trusted [installed] code, we might
not be seeing a problem, here.

>/ Jonas

Received on Friday, 31 March 2006 12:43:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:20 UTC