--- a/user-interface-safety.html Mon Mar 25 15:42:01 2013 -0700
+++ b/user-interface-safety.html Fri Oct 18 23:51:13 2013 +0000
@@ -43,7 +43,7 @@
// if you want to have extra CSS, append them to this list
// it is recommended that the respec.css stylesheet be kept
- extraCSS: ["css/respec.css"],
+ //extraCSS: ["css/respec.css"],
// editors, add as many as you like
// only "name" is required
@@ -91,6 +91,7 @@
"CLEARCLICK" : "G. Maone <a href=\"http://noscript.net/downloads/ClearClick_WAS2012_rv2.pdf\"><cite>ClearClick: Effective Client-Side Protection Against UI Redressing Attacks</cite></a>. (Work in progress.) URL: <a href=\"http://noscript.net/downloads/ClearClick_WAS2012_rv2.pdf\">http://noscript.net/downloads/ClearClick_WAS2012_rv2.pdf</a>",
"UIREDRESS" : "M. Zalewski <a href=\"http://code.google.com/p/browsersec/wiki/Part2#Arbitrary_page_mashups_(UI_redressing)\"><cite>Browser Security Handbook, part 2</cite></a>. URL: <a href=\"http://code.google.com/p/browsersec/wiki/Part2#Arbitrary_page_mashups_(UI_redressing)\">http://code.google.com/p/browsersec/wiki/Part2#Arbitrary_page_mashups_(UI_redressing)</a>",
"FRAMEBUSTING" : "Boneh, et al. <a href=\"http://seclab.stanford.edu/websec/framebusting/\"><cite>Busting frame busting: a study of clickjacking vulnerabilities at popular sites</cite></a>. URL: <a href=\"http://seclab.stanford.edu/websec/framebusting/\">http://seclab.stanford.edu/websec/framebusting/</a>",
+"MEDIACAPTURE":"D. Burnett, A. Bergkvist, C. Jennings and A. Narayanan <a href=\"http://www.w3.org/TR/mediacapture-streams/\"<cite>Media Capture and Streams</cite></a>. W3C Working Draft (Work in progress.) URL: <a href=\"http://www.w3.org/TR/mediacapture-streams/\">http://www.w3.org/TR/mediacapture-streams/</a>",
"INCONTEXT" : "Lin-Shung Huang, et al. <a href=\"https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final39.pdf\"><cite>Clickjacking:Attacks and Defenses</cite></a> published in the 21st USENIX Security Symposium Proceedings. URL: <a href=\"https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final39.pdf\">https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final39.pdf</a>","SELECTORS4" : "Elika J. Etemad. <a href=\"http://www.w3.org/TR/2011/WD-selectors4-20110929/\"><cite>Selectors Level 4.</cite></a> 29 September 2011. W3C Working Draft. (Work in progress.) URL: <a href=\"http://www.w3.org/TR/2011/WD-selectors4-20110929/\">http://www.w3.org/TR/2011/WD-selectors4-20110929/</a>","POINTER-EVENTS" : "Jacob Rossi and Matt Brubeck. <a href=\"http://www.w3.org/TR/pointerevents/\"><cite>Pointer Events.</cite></a> 19 February 2013 W3C Working Draft. (Work in progress.) URL: <a href=\"http://www.w3.org/TR/pointerevents/\">http://www.w3.org/TR/pointerevents/</a>", "CAPTCHA-Wikipedia" : "Wikipedia <a href=\"http://en.wikipedia.org/wiki/CAPTCHA\"><cite>CAPTCHA</cite></a> from Wikipedia. URL: <a href=\"http://en.wikipedia.org/wiki/CAPTCHA\">http://en.wikipedia.org/wiki/CAPTCHA</a>", "CLICKJACKING-Unresolved" : "Lin-Shung Huang and Collin Jackson. <a href=\"https://docs.google.com/document/pub?id=1hVcxPeCidZrM5acFH9ZoTYzg1D0VjkG3BDW_oUdn5qc\"><cite>Clickjacking Attacks Unresolved.</cite></a> Carnegie Mellon University, 06 July 2011. URL: <a href=\"https://docs.google.com/document/pub?id=1hVcxPeCidZrM5acFH9ZoTYzg1D0VjkG3BDW_oUdn5qc\">https://docs.google.com/document/pub?id=1hVcxPeCidZrM5acFH9ZoTYzg1D0VjkG3BDW_oUdn5qc</a>","CSP11" : "A. Barth, D. Veditz and M. West <a href=\"https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html\"><cite>Content Security Policy 1.1</cite></a>. W3C Editors' Draft. (Work in progress.) URL: <a href=\"https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html\">https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html</a>"
}
@@ -125,7 +126,7 @@
<p>Content Security Policy (CSP) is a declarative policy that lets the authors (or server administrators) of a web application restrict the behavior of a document, e.g. the origins where it can load its resources from or the ways it can execute scripts. This document defines directives to restrict the presentation or the interactivity of a resource when its interaction with the user may be happening in an ambiguous or deceitful context due to the spatial and/or temporal contiguity with other content displayed by the user agent. </p>
-<p>A user agent may implement the core directives of CSP independently from the directives in this specification, but this specification requires the policy conveyance and reporting mechanisms described in CSP. The interpretation of terms imported into this document from CSP may vary depending on the version implemented by the user agent. For example, a <code>source-expression</code> in Content Security Policy 1.0 is at the granularity of an <dfn>origin</dfn> [[!ORIGIN]] but may be more granular in future versions of the core Content Security Policy. </p>
+<p>A user agent may implement the core directives of CSP independently from the directives in this specification, but this specification requires the policy conveyance and reporting mechanisms described in CSP. The interpretation of terms imported into this document from CSP may vary depending on the version implemented by the user agent. For example, a <code>source-expression</code> in Content Security Policy 1.0 is at the granularity of an <code>>origin</code> [[!ORIGIN]] but may be more granular in future versions of the core Content Security Policy. </p>
<p>Application authors SHOULD transmit the directives in this specification as part of a single, complete Content Security Policy, as indicated by that specification. </p>
@@ -443,10 +444,10 @@
<dd>The <code>pointerType</code> value of a <dfn>Pointer Event</dfn> [[POINTER-EVENTS]].</dd>
<dt>pointer-height</dt>
- <dd>The <code>height</code> value of a <dfn>Pointer Event</dfn> [[POINTER-EVENTS]].</dd>
+ <dd>The <code>height</code> value of a <code>Pointer Event</code>.</dd>
<dt>pointer-width</dt>
- <dd>The <code>width</code> value of a <dfn>Pointer Event</dfn> [[POINTER-EVENTS]].</dd>
+ <dd>The <code>width</code> value of a <code>Pointer Event</code>.</dd>
<dt>device-height</dt>
<dd>The <code>device-height</code> property as defined in [[!CSS3-MEDIAQUERIES]].</dd>
@@ -509,8 +510,13 @@
return(xpath);
}
</pre>
-
-
+Documents may be dynamically constructed and change structure in response to user
+interaction or other events, so an unambiguous XPath expression in the context of the current
+state of the DOM may not be unambiguous to the content author. To avoid this confusion,
+resource authors SHOULD include an <code>id</code> attribute for all elements of interest
+and user agent implementers MAY include any additional information in the XPath they feel
+may help disambiguate the blocked target, including class names and id attributes of
+ancestors.
</section>
@@ -553,8 +559,6 @@
<section>
<h2>Script Interfaces</h2>
-<p class="issue" title="Pending CSP 1.1 Details">Is expressing these in terms of "partial" interfaces and dictionaries or as new types that extend the basic CSP 1.1 types the correct way to do this?</p>
-
<p>If associated with a Content Security Policy 1.1 [[CSP11]] or later implementation, the User Interface Security Directives include
the following script interfaces which extend the experimental functinality defined therein: <a href="https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#script-interfaces--experimental">https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#script-interfaces--experimental</a></p>
@@ -735,6 +739,115 @@
</ol>
</section>
+
+<section id="alt_heuristic" class=informative>
+<h2>Alternate Heuristic</h2>
+<p>Some user agents use a strategy for hit testing and delivering
+UI events involving multiple composited layers managed on a GPU.
+This alternative heuristic describes one possible implementation
+strategy for the input-protection directive in this architecture that
+may be a better fit than the standard heuristic.</p>
+
+<p>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 subunits
+through message passing, without implying any particular implementation details
+such as locality to a thread, OS-level "processes" 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 immediately respond to, e.g. 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 that is
+consistent with this multi-process, compositing architecture.
+</p>
+
+<p>If a resource is being loaded in a <code>frame</code>, <code>iframe</code>,
+<code>object</code>, <code>embed</code> or <code>applet</code> context
+specifies an <code>input-protection</code> directive, apply the following steps:
+
+<ol>
+<li><strong>Tracking protected hit test rectangles:</strong> 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 events must be checked for safety. 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.
+</li>
+
+<li><strong>(Optionally) Put the protected areas into a backing store / composited
+layer:</strong> To avoid the expense of having to re-layout and re-paint
+protected regions during the <strong>obstruction check</strong>, it may make sense
+to designate and place these regions into their own backing store or composited
+layer which can serve as a cached <strong><em>control image</em></strong>.
+</li>
+
+<li><strong>Hit testing in the compositor:</strong> When an event is received, check
+whether it is on any layer and then walk the layer hierarchy checking the
+protected hit test rectangles on every layer. If there is a hit, continue this heuristic.
+Otherwise, exit this heuristic and event processing proceeds as normal.
+</li>
+
+<li><strong>Timing attacks countermeasure</strong> check whether the "Display
+Change List" contains any record younger than the <code>input-protection display-time</code>
+value, whose repainted regions intersect with the protected regions <em>and</em>
+whose repaint-causing document is <em>different</em> 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 and jump to <strong>Violation management</strong>.
+</li>
+
+<li><strong>Cursor sanity check:</strong> 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 <strong>Violation management</strong>. This provides
+protection against "Phantom cursor" attacks, also known as "Cursorjacking".
+</li>
+
+<li><strong>Obstruction check:</strong> Compare two sets of pixels: the
+<strong><em>control image</em></strong> is the protected region as if it was
+rendered alone, unobstructed by pixels originating from any other document
+context. If the protected regions were placed into their own backing store /
+composited layer, this should be readily available, although the pixels may
+need to be read back from the GPU to perform a comparision. The <strong><em>user image
+</em></strong> represents the same area as the <strong><em>control image</em>
+</strong> in the outermost document's coordinate system and contains the final
+set of common pixels for the fully rendered page. The <strong><em>control
+image</em></strong> can be acquired through operating system APIs or from the
+compositor for the outermost document context.
+These images are compared, and if the differences are below the
+<code>tolerance</code> threshold associated with the <code>input-protection</code>
+directive, proceed to deliver the event normally, otherwise proceed to
+<strong>Violation management</strong>. If portions of the <strong><em>control
+image</em></strong> are clipped by the root view port in the outermost
+document's coordinate system or otherwise occluded, all such pixels must be
+considered not to match.
+</li>
+
+ <li><strong>Violation management</strong> -
+ If in report-only mode, set the <code>unsafe</code> property of the event been
+ handled to <code>true</code> and let the event processing continue. Otherwise,
+ prevent the event from reaching its target. Create and send a violation report
+ if a valid report-uri has been specified.
+</li>
+
+ <p class="note">
+ <em>Implementation note</em>: Optimized and potentially cross-platform
+ implementations of screen and cursor capturing and monitoring
+ regions for invalidation may be available as part of e.g. screen-
+ sharing functionality through getUserMedia() [[MEDIACAPTURE]] or other
+ remote desktop-type functionality available in certian user agents,
+ e.g. the ScreenCapturer interface in Chromium.
+ </p>
+
+</ol>
+</section>
<section>
<h2>Examples</h2>