Raising to the list (Re: ISSUE-29: What are sane defaults for clipping with clipping or selectors?)

On 01/11/2012 17:57, Web Application Security Working Group Issue
Tracker wrote:
> ISSUE-29: What are sane defaults for clipping with clipping or selectors?
> 
> http://www.w3.org/2011/webappsec/track/issues/29

Seeking for answer(s) from the group's collective intelligence.

Both the input-protection-clip (
http://www.w3.org/TR/UISafety/#input-protection-clip ) and the
input-protection-selectors (
http://www.w3.org/TR/UISafety/#input-protection-selectors ) directive of
the soon-to-be-known-as UISecurity (yet known as UISafety) working draft
accept a set of four optional parameters labeled "before", "above",
"after" and "below" which are to be interpreted as
bidirectional-friendly offsets and define a clipping rectangular area
which must be entirely visible while the user interaction happens, in
order for the protection not to be triggered.

The algorithms to compute this area are different for the two directives:

1) in the input-protection-clip case, the offsets are relative to a
point: the pointer coordinates if we're filtering a mouse event or a
touch event, or the center of the focused element if we're processing a
keyboard event.
2) in the input-protection-selector case, the offset are relative to the
bounding rectangle of the element matching the dom_selector_groups
parameter which is involved in the current user interaction.

Therefore, the currently specified defaults differ too:

1) The input-protection-clip currently specifies a default of
"before=250 above=250 after=50 below=50", which is quite arbitrary but
reflects my experience with ClearClick, dealing "blindly" with unknown
web pages to be protected. In facts, these default values are skewed
toward the use case of a form submit button: we assume that to provide
some meaningful context, offsets of at least 250 pixels before (on the
left, in a LtR bidi setup) and above (on the top, in LtR) are required,
and 50 pixels on the remaining sides (after/right and below/bottom) are
needed for the button to be entirely visible (we're talking about CSS
pixels here, hence the actual size will vary with the zoom level). As I
said, this choice is quite arbitrary and empirical, and of course a web
author who wants to protect his own content has a more accurate
understanding of the content layout and can provide customized values,
or even better use the input-protection-selectors directive which is
meant to protect specific DOM elements independently of their (possibly
varying, in an elastic layout) sizes. However this issue has been raised
to decide whether these values are useful as defaults (e.g. for a
website administrator which wants to protect content whose layout varies
beyond his control) or a better choice is possible.

2) The input-protection-selectors currently specifies a default of
"before=0 above=0 after=0 below=0" which means the mandatory visible
area is collapsed to the bounding box of the DOM element matching the
CSS selectors which user is interacting with. IMHO this is a sensible
default because the most likely use case for this directive is
specifying the id or the class of the container (e.g. the form or the
fieldset) which contains both the interactive elements to be protected
(the form controls) and the context (labels or other descriptive text).

What does the list think? Can we deem these default values appropriate,
even though arbitrary (especially the input-protection-clip ones)?

Thanks
-- G

Received on Saturday, 26 January 2013 09:24:34 UTC