Re: [webappsec] ISSUE-53: UISecurity input-protection heuristic for composited rendering

Thanks, Brad! For what it's worth, here's my attempt to clarify which parts
of the original description in Section 6.2 are affected by compositing:

- For "timing attacks countermeasure" (the "Display Change List"),
compositing should have no impact. Essentially, we're keeping track of the
"damage rects" that already exists in the main thread of WebKit (presumably
the browser we're concerned of here).

- For "cursor sanity check", compositing has no impact. (Cursors are
independent of screenshots.)

- For "obstruction check", there are two distinct cases:
  (1) When the "user image" is taken using OS-native APIs, compositing
should have no impact. (OS can grab the final rendering.)
  (2) When the "user image" is taken by the browser, obstruction checks
will fail (as Adam pointed out) since each browsing context has no
knowledge of the final rendering. [FIXME!]

As a side benefit, I suspect that compositing might actually make
obstruction checks faster, because the "control image" could be available
as a cached layer (or tile), thus eliminating the need to render an
off-screen HTML5 canvas element.


Thanks,
David


On Thu, Oct 10, 2013 at 12:48 PM, Brad Hill <hillbrad@gmail.com> wrote:

> <hat = editor>
>
> One of the open issues on UISecurity raised by Adam Barth is that the
> input-protection heuristic is not well-suited to browsers that use
> compositing to accelerate page rendering with GPUs.  While this heuristic
> is non-normative, Adam suggested that we should supply a heuristic for this
> model.
>
> I've attempted to grok these browser internals this week, at least for
> Blink and WebKit, and below is a first attempt at such a heuristic.  I
> would definitely appreciate review from anyone who feels qualified, or is
> willing to forward it to someone who is.  I'm confident that despite my
> best efforts I have somwhere confused what happens in layout vs. draw vs.
> paint vs. composite vs. render.
>
> thanks,
>
> Brad
>
> *Alternate Input Protection Heuristic for Multi-Layer Compositing*
>
> Some user agents, in order to improve performance by taking advantage of
> specialized graphics hardware, use a strategy for hit testing and
> delivering UI events to hardware-composited layers that the basic heuristic
> does not apply well to.  This alternative *non-normative* heuristic
> describes one possible implementation strategy for the input-protection
> directive in this architecture.
>
> GPU optimized user agents typically separate the browser UI process from
> the process that handles building and displaying the visual representation
> of the resource.  (In this context the term "process" refers to any
> encapsulated subunit of user-agent functionality that communicates to other
> similar subunits through message passing, without implying any particular
> implementation details such as locality to a thread, OS-level "processe" or
> the like.)  It is typical for the browser UI process to receive user events
> such as mouse clicks and then marshal these to the render process, where
> the event is hit tested through the page's DOM, checking for event handlers
> along the way.  As an optimization the render process may communicate hit
> test rectangles back to the UI process in advance so that the UI process
> can, e.g. immediately respond to a Touch event by scrolling if the event
> target falls within coordinates for which there are no other registered
> handlers in the DOM.   A similar strategy can be used to create an
> implementation of the input protection heuristic in a manner that is
> consistent with this multi-process, compositing architecture.
>
> If a resource is being loaded in a frame, iframe, object, embed or applet
> context and specifies an input-protection directive, apply the following
> steps:
>
> 1.       *Tracking hit test rects: * Hook the creation of event handlers
> for protected events and elements and add the DOM nodes with any such
> handler to a collection. After a layout occurs, or when an event handler is
> added or removed,iterate across all DOM nodes to generate a vector of
> rectangles where such events need to be marshaled to.  If the
> input-protection applies to the DOMWindow or Document node, avoid this
> expensive process of walking the renderers and simply use the view's
> bounds, as they're guaranteed to be inclusive.
>
> 2.       *(Optionally) Put the protected areas into a backing store /
> composited layer: *To avoid the expense of having to re-layout and
> re-paint protected regions during the *obstruction check*, it may make
> sense to designate and place protected regions into their own backing store
> or composited layer which can serve as a cached *control image*. Such a
> backing store should paint the entire content of the protected region for
> this purpose, even if it is clipped by the viewport.
>
> 3.       *Hit testing in the compositor: *When an event is received,
> check whether it is on any layer and then walk the layer hierarchy checking
> the protected regions on every layer.  If there is a hit, continue the
> heuristic.  Otherwise, exit this heuristic and event processing proceeds as
> normal.
>
> 4.       *Cursor sanity check:* By querying computed-style with the
> ":hover" pseudo-class on the element (if the target is plugin content) or
> on the host frame element and its ancestors (if the target is a nested
> document), check whether the cursor has been hidden or changed to a
> possibly attacker-provided bitmap: if it has, proceed to *Violation
> management*. This provides protection against "Phantom cursor" attacks,
> also known as "Cursorjacking".
>
> 5.       *Timing check: [ I need some help here ] *Conceptually, we would
> like to track whenever a protected region must be *redrawn
> (--show-property-changed-rects,I think, is the Blink concept) *AND when
> the cause of that redraw originated from a different document context.  We
> want to trigger the heuristic if an enclosing frame overlapped the
> protected region within the specified time interval, but we don't want to
> trigger if redraws originate from within the same document context as the
> protected area. (e.g. if the button itself has a mouseover animation)  I'm
> really not sure how this part works or how to describe it in generic terms
> here.  Can we propagate the source and timing of redraw triggers to the
> protected hit test rects or our collection of DOM nodes?
>
> 6.       *Obstruction check: *Compare two sets of pixels: the *control
> image *is the protected area as if it was rendered alone, unobstructed by
> pixels originating from any other document context.  (If step 2
> optimizations were performed, this should be readily available in its own
> composited layer.)  The *user image *represents the same area as the *control
> image* in the outermost document's coordinate system and contains the
> final set of common pixels for the fully rendered page. These images are
> compared, and if the differences are below the *tolerance* threshold
> associated with the input-protection directive, proceed to deliver the
> event normally, otherwise proceed to *Violation management*. If portions
> of the *control image *are clipped by the root view port in the outermost
> document's coordinate system, all such pixels must be considered not to
> match.  [*I don't know enough to say whether the comparison can be done
> on the GPU without marshaling the pixels of the control image backing store
> back to software, or if this is even worth mentioning here…]*
>
>
>
> Notes: applying protections to the entire document (if it itself would
> consist of multiple composited layers) or using the input-protection-clip
> property may make many of these optimizations impossible, and may imposes
> performance penalties on the page, perhaps forcing it to fallback to
> all-software rendering.  We should have text warning authors of this, or
> should we simply remove those options from the spec and require
> input-protection-selectors only, to better match the internal strategies of
> modern browser rendering?
>
>
>