Note thread in last month's archive:
http://lists.w3.org/Archives/Public/public-webapi/2006Mar/thread.html#msg312
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.
Still agreed on that level.
But I want to challenge your security concern a bit more (as I concurrently
discuss with Chaals and Robin about a joint telecon).
Al Gilman wrote:
* Why in the DOM?
<quote
cite="http://lists.w3.org/Archives/Public/public-webapi/2006Mar/0316.html";>
[Jonas, Maciej]
Actually, my main question is not why the these functions are needed,
but why they are needed in the DOM API.
</quote>
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.
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.
However, exposing these functions to web pages does not sound like
it is a requirement to you, is that correct? 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.
I don't think so.
What you are suggesting sounds to me as though we would protect
security holes in event listeners by security-by-obscurity.
I think this is an unproductive line of investigation, or an
inappropriate security policy. Not a good place to set up one's
defences.
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.
On the other hand, anyone who has the capacity to post a new
listener, a new handler, with the DOM, has a need to inspect the
listener population to make sure that there is nothing already there
that they are breaking by the new listener that they inject. This
capability to add listeners dynamically is available in the
in-the-page sandbox and in fact is used a lot.
If we have security concerns, they need to be addressed at the
level of what a script or other DOM subscriber can *do* and not
in terms of what they can discover they can do.
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.
Al
/ Jonas
