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