Security

WebApps ⇨ DOM3Events ⇨ Security

It will be useful to have a section on Security Considerations for DOM3 Events.

Björn Höhrmann has the following suggestions, based on a previous version of the specification:

 This appendix discusses security considerations for DOM Level 3 Events
 implementations. The discussion is limited to security issues that
 arise directly from implementation of the event model, APIs and events
 defined in this specification. Implementations typically support other
 features like scripting languages, other APIs and additional events
 not defined in this document; these features constitute an unknown
 factor and are out of scope of this document. Implementers should
 consult the specifications of such features for their respective
 security considerations. 
 
 Many of the event types defined in this specification are dispatched
 in response to user actions. This allows malicious event listeners to
 gain access to information users would typically consider
 confidential, e.g., typos they might have made when filling out a
 form, if they reconsider their answer to a multiple choice question
 shortly before submitting a form, their typing rate or primary input 
 mechanism. In the worst case, malicious event listeners are able to
 capture all user interactions and submit them to a third party through
 means, while not defined in DOM Level 3 Events, generally available in
 DOM implementations. 
 
 In DOM implementations that support facilities to load external data,
 events like the ev:error event can provide access to sensitive
 information about the environment of the computer system or network;
 an example would be a malicious HTML document that attempts to embed a
 resource on the local network or the localhost on different ports; an
 embedded DOM application could then listen for ev:error and ev:load
 events to determine which other computers in a network are accessible
 from the local system or which ports are open on the system to prepare
 further attacks. 
 
 An implementation of DOM Level 3 Events alone is generally
 insufficient to perform attacks of this kind and the security 
 considerations of the facilities that possibly support such attacks
 apply. For conformance with this specification, DOM implementations
 may take reasonable steps to ensure that DOM applications do not get
 access to confidential or sensitive information, for example, they may
 choose to dispatch no ev:load events to nodes that attempt to embed
 resources on the local network. 

In addition, this might need to say something about canDispatch in the
context of ISSUE-11 (there may be specific circumstances where the
implementation can generate an event type but a given application will
not be able to have its listeners invoked; in that case, it might be
desirable that canDispatch returns 'false'; I haven't fully though that
out yet though).

More importantly it needs to discuss the dangers of allowing DOM 
applications to synthesize event types and dispatch them. For example,
an implementation might disallow normal DOM access to a file upload
control so you cannot put a file path into the control and .submit(),
but it might be possible to simulate keypresses and mouse movemenets
to achieve the same effect. While mitigated in some implementations,
this needs to be discussed there.

Related concerns include the ability to change cancelable and bubbling
behavior, an implementation might expect a specific event type to not
bubble, but an malicious application might make it bubble, thereby
disrupting the implementation in some way. In a similar way, it might be
possible to disrupt the event flow in other unexpected way, e.g. in a
cooperative environment where multiple DOM applications have to inter-
act with each other.

It would also be good to split the text into some subsections, having
a full appendix with just a text blurb as above isn't particularily
readable or beautiful...