- From: Giorgio Maone <g.maone@informaction.com>
- Date: Sun, 10 Feb 2013 21:05:55 +0100
- To: Web Application Security Working Group <public-webappsec@w3.org>
Ragarding UI security's "display-time", http://www.w3.org/TR/UISafety/ just says: <SNIP> 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 [...] </SNIP> These notes are, of course, 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, reflow 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' experts (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. Thoughts? Many thanks! -- G
Received on Sunday, 10 February 2013 20:06:19 UTC