- From: Fred Andrews <fredandw@live.com>
- Date: Thu, 22 Nov 2012 14:13:45 +0000
- To: Markus Ernst <derernst@gmx.ch>
- Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>, Timo Beermann <timo.beermann@googlemail.com>
> Date: Thu, 22 Nov 2012 11:23:19 +0100 > From: derernst@gmx.ch ... > Maybe, instead of adding that kind of functionalities to form elements, > it might be worth thinking of a different way. E.g., define a set of > scripting actions that are considered as very useful for UIs, and have > no security issues, and let UAs execute that kind of scripts even if > scripting is actually disabled, or let UAs offer a user setting such as > "Allow only useful form actions" or whatever. Supporting scripts that can implement a rich UI with reduced security risk is of interest to the work of the W3C PUA CG and some options have been proposed, see: http://www.w3.org/community/pua/wiki/Draft If the sharing of state accessible via the DOM and APIs is seen as a security risk then scripts that can modify input buttons need to have very restricted access to the DOM and APIs otherwise they could implement a UI redressing attack on the input buttons - for example disabling buttons to discriminate against users or changing the buttons to leak state when the form is submitted. If the buttons are being used purely for operations within the UA then they could be controlled by script in a context restricted from access to outgoing communication channels (the PUA Private Context). A prototype proxy implementing these restriction shows that many rich website UI elements can still operate under such restrictions. If the buttons are part of an outgoing form then placing them in a context without JS enabled would seem to be the simplest approach to protect the DOM and API security. One option being explored is to allow a restricted 'web worker' style context to have some limited access to page elements, and since this worker does not have general DOM access the risk of leaking state is reduced. For example, the check box could have a declarative attribute that defines a message to post to a worker when it changes, and the controlled checkbox could have a declarative attribute that defines a message listener that can change the element. The form UI logic and would be implemented in the worker. Another alternatively is to place the form in an iframe with JS disabled, but with a declarative extension that allows the form state to be posted to the worker upon a change in the checkbox or other defined state changes. The worker could implement the form state logic and post back new iframe content with the controlled buttons enabled or disabled as necessary. The worker is effectively a local web server using messages to receive requests and send responses. An advantage to this approach is that the form could have a fallback URL so that a server could implement the logical even if the UA does not support JS. If targeting UAs without JS then a polyfill is not an option for backwards compatibility and so forms would still need a fallback for legacy UAs. Have you though how this might work? Perhaps include an 'update' button in the webpage design that posts the form to the server? cheers Fred
Received on Thursday, 22 November 2012 14:28:11 UTC