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

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

From: Charles McCathieNevile <chaals@opera.com>
Date: Tue, 11 Apr 2006 01:28:25 +0200
To: "Al Gilman" <Alfred.S.Gilman@ieee.org>, "Jonas Sicking" <jonas@sicking.cc>
Cc: "WebAPI WG" <public-webapi@w3.org>, wai-liaison@w3.org
Message-ID: <op.s7tfhnqnwxe0ny@pc031.coreteam.oslo.opera.com>

On Mon, 10 Apr 2006 20:00:22 +0200, Al Gilman <Alfred.S.Gilman@IEEE.org>  

> But I want to challenge your security concern a bit more.
>> Al Gilman wrote:
>>> * Why in the DOM?

>>> 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.

>> 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.

The DOM is indeed similar - because it comes from a W3C spec, not a per-UA  
per-platform special case for access to the document. It isn't required  
that access to the UA conrol be by the DOM, although that is an option,  
and it may be what Firefox effectively does.

>> That said, I am not happy about exposing these functions to web pages  
>> due to privacy and security concerns.
>> ... Remember that EventListeners are not limited to ones added by the  
>> web page...
>> However, exposing these functions to web pages does not sound like it  
>> is a requirement to you, is that correct?

As I understand it, that actually is the case.

>> 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.

We do indeed want an accessibility API, and UAAG is worded in such a way  
as to allow this either to be via a DOM-based API for a particular user  
agent, or via platform-specific APIs. Unfortunately there is currently  
still a mess of choices although there are efforts to try and bring  
platform-specific APIs closer to each other in an effort to make this  

I don't think we need to give web page authors access to that - either in  
finding out what there is, or in letting them fire events to particular  

Page authors often ask for some API call to find out if, for example, a  
screen reader is running. Flash actually implemented this, but then went  
around recommending that people not use it because it just doesn't work -  
it's like trying to find out if there is a mouse, when what there really  
is happens to be a piece of software that enables a user to emulate many  
mouse events through a set of voice controls...

>> 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.

> As I understand it, anyone with DOM2 access can fire any event. If
> there is a listener for that event, any script operating in the "in
> the page" sandbox can fire an event that will execute the behavior
> of that listener.
> So nobody, including the browser, has any business implementing
> sensitive functions (that could be exploited as security holes) as
> event listeners in the DOM.

Hmm. Anyone who does do that should be implementing firewalling so that  
things don't travel that can create security holes. This is not rocket  
science in practice - a very simple example are the pop-up blockers that  
will allow a pop-up when a user clicks a link, but will not allow a script  
to create a popup arbitrarily.

> Malware authors can learn offline what listeners to attack if there
> are holes there. They don't need to rely on what they can
> discover conveniently in real time in the current page.

True enough...



Charles McCathieNevile                     chaals@opera.com
   hablo español  -  je parle français  -  jeg lærer norsk
      Peek into the kitchen: http://snapshot.opera.com/
Received on Monday, 10 April 2006 23:29:13 UTC

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