[whatwg] Checkboxes that control other checkboxes

[Fred Andrews]

> Date: Thu, 22 Nov 2012 11:23:19 +0100
> From: derernst at 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