ACTION-111: Provide guidance on efficient enforcment of display-time

In the current draft http://www.w3.org/TR/UISafety/ the paragraph devoted to this matter are the following two:

5.1 Preparation
[...]
Display changes tracking - whenever a repaint occurs in the topmost window or in one of its descendants, create a record containing a weak reference to the document causing the repaint, the screen coordinates of the regions being repainted and a timestamp detailing when the repaint occurred, and add this record to a screen-global list named "Display Changes List". Records older than the maximum value for input-protection's display-time can be discarded on update.

5.2 UI Event handling

Timing attacks countermeasure - check whether the "Display Change List" contains any record younger than the input-protection's display-time value, whose repainted regions intersect with the protected UI elements and whose repaint-causing document is different than the protected one. If this is true, hinting at a recent change in the way the protected UI is displayed, with causes external to the UI itself (e.g. an overlapping element in an ancestor document or a floating window being suddenly moved away), assume a timing attack is happening [...]

These, of course, are non-normative and based on my own experience about trying to provide a similar protection *within the limitations of a Firefox extension*, i.e. hacking around very limited APIs such as the MozAfterRepaint event. I'm pretty sure user agent implementers, having direct access to the OS-provided facilities and directly managing their own display lists, reflows and so on, are in a much better position to figure out the most efficient strategy for enforcing this feature in an optimized way. Therefore I believe we can either poll the browser vendors' expert (developers of the layout/gfx components, I guess) for generally valid hints (if any), or leave the specification as it is and let each browser vendor figure out what works best for his own specific implementation.