Many changes, preparing for FPWD.
authorbhill@L-SJN-00530327.corp.ebay.com
Mon, 10 Sep 2012 17:04:05 -0700
changeset 5 b60afa40a19e
parent 4 25bb022cd7bc
child 6 5606233e4ede
Many changes, preparing for FPWD.
user-interface-safety.html
--- a/user-interface-safety.html	Sun Jul 01 20:16:50 2012 -0700
+++ b/user-interface-safety.html	Mon Sep 10 17:04:05 2012 -0700
@@ -1,15 +1,16 @@
 <!DOCTYPE html>
 <html>
-  <head>
-    <title>User Interface Safety Directives for Content Security Policy</title>
-    <meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
-      <!--
-      === NOTA BENE ===
-      For the three scripts below, if your spec resides on dev.w3 you can check them
-      out in the same tree and use relative links so that they'll work offline,
-      -->
-    <script src='js/respec.js' class='remove'></script>
-    <script class='remove'>
+<head>
+  <!--link href="http://www.w3.org/StyleSheets/TR/W3C-ED" rel="stylesheet" type="text/css" charset="utf-8"-->
+  <title>User Interface Safety Directives for Content Security Policy</title>
+  <meta http-equiv="content-type" content="text/html; charset=UTF-8">
+  <!--
+  === NOTA BENE ===
+  For the three scripts below, if your spec resides on dev.w3 you can check them
+  out in the same tree and use relative links so that they'll work offline,
+  -->
+  <script src='http://www.w3.org/Tools/respec/respec-w3c-common' class='remove' async></script>
+  <script type="text/javascript" class="remove">
       var respecConfig = {
         // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
         // Member-SUBM
@@ -49,7 +50,7 @@
         editors:  [
           { name: "Giorgio Maone", url: "mailto:g.maone@informaction.com",
             company: "Invited Expert", companyURL: "" },
-          { name: "Lin-Shung Huang", url: "mailto:linshung.huang@sv.cmu.edu",
+          { name: "David Lin-Shung Huang", url: "mailto:linshung.huang@sv.cmu.edu",
             company: "Carnegie Mellon University", companyURL: "http://www.cmu.edu/" },
           { name: "Brad Hill", url: "mailto:bhill@paypal-inc.com",
             company: "PayPal Inc.", companyURL: "https://www.paypal.com/" },
@@ -81,616 +82,784 @@
         // Team Contact.
         wgPatentURI:  "http://www.w3.org/2004/01/pp-impl/49309/status"
       };
-    </script>
-  </head>
-  <body>
-    <section id="abstract">
-      <p>
-        This document defines a directive for the Content Security Policy 1.0
-        mechanism used to declare a set of input protections for a web
-        resource's user interface.
-      </p>
-      <p>
-        The document also defines a set of heuristics for Web user agents to
-        implement these input protections and a reporting mechanism for when
-        they are triggered.
-      </p>
-    </section>
-    <section id="sotd">
-      <!-- <p>Portions of the technology described in this document were developed
-      as part of the X-Frame-Options header.</p> -->
-      <p>
-        Portions of the technology described in this document were developed
-        and implemented in the ClearClick module of the Mozilla Firefox add-on
-        NoScript.
-      </p>
-      <p>
-        This document uses the syntax and mechanism of the Content Security
-        Policy 1.0 and defines a new directive to convey user interface safety
-        policy.
-      </p>
-      <p>
-        In addition to the documents in the W3C Web Application Security
-        working group, the work on this document is also informed by the work
-        of the <a href="http://tools.ietf.org/wg/websec/">IETF websec working
-        group</a>, particularly that working group's requirements document: <a
-        href="http://tools.ietf.org/id/draft-hodges-websec-framework-reqs">
-        draft-hodges-websec-framework-reqs</a>.
-      </p>
-    </section>
-    <section class="informative">
-      <h2>Introduction</h2>
-      <p>
-        This document defines User Interface Safety directives for Content
-        Security Policy 1.0, a mechanism web applications can use to mitigate
-        some of the risks of User Interface (UI) Redressing vulnerabilities
-        that can lead to fraud actions not intended by the user.
-      </p>
-      <p>
-        Content Security Policy is a declarative policy that lets the authors
-        (or server administrators) of a web application restrict from where an
-        application can load resources. The intent and implementation of the
-        directive defined in this document differs in that respect from other
-        directives defined in CSP 1.0. A user agent may implement the
-        directives of CSP 1.0 independently from the directives in this
-        specification, but the policy conveyance mechanism for the directives
-        in this specicification is described in CSP 1.0. Application authors
-        should transmit the directives in this specification as part of a
-        single, complete Content Security Policy, as indicated by that
-        specification.
-      </p>
-      <!-- <p>
-        Content Security Policy (CSP) is not intended as a first line of
-        defense against content injection vulnerabilities. Instead, CSP is
-        best used as defense-in-depth, to reduce the harm caused by content
-        injection attacks.
-      </p> -->
-      <p>
-        In some UI redressing attacks (also known as clickjacking), a
-        malicious web application presents a user interface of another web
-        application in a manipulated context to the user, e.g. by partially
-        obscuring the genuine user interface with opaque layers on top, hence
-        tricking the user to click on a button out of context.
-      </p>
-      <p>
-        Existing anti-clickjacking measures including frame-busting codes and
-        X-Frame-Options are fundamentally incompatible with embeddable
-        third-party widgets, and insufficient to defend against timing-based
-        attack vectors.
-      </p>
-      <p>
-        The User Interface Safety directive provides a new mechanism to allow
-        web applications to enable heuristic input protections for its user
-        interfaces on user agents.
-      </p>
-      <p>
-        To mitigate UI redressing, for example, a web application can restrict
-        that a user interface element should be fully visible for a minimum
-        period of time before a user input can be delivered.
-      </p>
-      <p>
-        The User Interface Safety directive can often be applied to existing
-        applications with few or no changes, but the heuristic hints supplied
-        by the policy may require considerable experimental fine-tuning to
-        achieve an acceptable error rate.
-      </p>
-      <!-- <p>This specification obsoletes X-Frame-Options.
-      Resources may supply an X-Frame-Options header in addition to
-      a Content-Security-Policy header to indicate policy to user agents
-      that do not implement the directives in this specification.  A user
-      agent that understands the directives in this document should ignore
-      the X-Frame-Options header, when present, if User Interface Safety directives
-      are also present in a Content-Security-Policy header. This is to allow 
-      resources to only be embedded if the mechanisms described in
-      this specification are enforced, and more restrictive X-Frame-Options
-      policies applied otherwise.</p> -->
-    </section>
-    <section id="conformance">
-      <p>
-        Requirements phrased in the imperative as part of algorithms (such as
-        "strip any leading space characters" or "return false and abort these
-        steps") are to be interpreted with the meaning of the key word
-        ("MUST", "SHOULD", "MAY", etc) used in introducing the algorithm.
-      </p>
-      <p>
-        A conformant user agent is one that implements all the requirements
-        listed in this specification that are applicable to user-agents.
-      </p>
-      <p>
-        A conformant server is one that implements all the requirements listed
-        in this specification that are applicable to servers.
-      </p>
-      <section>
-        <h3>Terminology</h3>
-        <p>
-          This section defines several terms used throughout the document.
-        </p>
-        <p>
-          The term <dfn>security policy</dfn>, or simply <dfn>policy</dfn>,
-          for the purposes of this specification refers to either:
-          <ol>
-            <li>a set of security preferences for restricting the behavior of
-            content within a given resource, or</li>
-            <li>a fragment of text that codifies these preferences.</li>
-          </ol>
-        </p>        
-        <p>
-          The security policies defined by this document are applied by a user
-          agent on a <em>per-resource representation basis</em>. Specifically,
-          when a user agent receives a policy along with the representation of
-          a given resource, that policy applies to <em>that resource
-          representation only</em>. This document often referes to that
-          resource representation as the <dfn>protected resource</dfn>.
-        </p>
-        <p>
-          A server transmits its security policy for a particular resource as
-          a collection of <dfn>directives</dfn>, such as <code>default-src
-          'self'</code>, each of which controls a specific set of privileges
-          for a document rendered by the user agent. More details are provided
-          in the <a href="#directives">directives</a> section.
-        </p>
-        <p>
-          A directive consists of a <dfn>directive name</dfn>, which indicates
-          the privileges controlled by the directive, and a <dfn>directive
-          value</dfn>, which specifies the restrictions the policy imposes on
-          those privileges.
-        </p>
-        <p>
-          The term <dfn>origin</dfn> is defined in the Origin specification.
-          [<em><a
-          href="http://tools.ietf.org/html/draft-ietf-websec-origin">ORIGIN</a></em>]
-        </p>
-        <p>
-          The term <dfn>URI</dfn> is defined in the URI specification. [[!URI]]
-        </p>
-        <p>
-          The <code>&lt;script&gt;</code>, <code>&lt;object&gt;</code>,
-          <code>&lt;embed&gt;</code>, <code>&lt;img&gt;</code>,
-          <code>&lt;video&gt;</code>, <code>&lt;audio&gt;</code>,
-          <code>&lt;link&gt;</code>, <code>&lt;frame&gt;</code> and
-          <code>&lt;iframe&gt;</code> elements are defined in the HTML5
-          standard. [[!HTML5]].
-        </p>
-        <p>
-          The <code>&lt;applet&gt;</code> element is defined in the HTML 4.01
-          standard. [[!HTML401]].
-        </p>
-        <!-- <p>The <code>@font-face</code> CSS rule is defined in the CSS Fonts Module Level 3 standard.
-        [[!CSS3-FONTS]]</p>
-        <p>The <code>XMLHttpRequest</code> object is defined in the <code>XMLHttpRequest</code>
-        standard. [[!XMLHTTPREQUEST]]</p>
-        <p>The <code>EventSource</code> object is defined in the <code>EventSource</code>
-        standard. [<em><a href="http://dev.w3.org/html5/eventsource/">EVENTSOURCE</a></em>].</p> -->
-        <p>
-          The Augmented Backus-Naur Form (ABNF) notation used in this document
-          is specified in RFC 5234. [[!ABNF]]
-        </p>
-        <p>
-          The following core rules are included by reference, as defined in
-          [<em><a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">ABNF
-          Appendix B.1</a></em>]: <code>ALPHA</code> (letters),
-          <code>DIGIT</code> (decimal 0-9), <code>WSP</code> (white space) and
-          <code>VCHAR</code> (printing characters).
-        </p>
-        <p>
-          The OWS rule is used where zero or more linear whitespace octets
-          might appear. OWS SHOULD either not be produced or be produced as a
-          single SP. Multiple OWS octets that occur within field-content
-          SHOULD either be replaced with a single SP or transformed to all SP
-          octets (each octet other than SP replaced with SP) before
-          interpreting the field value or forwarding the message downstream.
-        </p>
-<pre>
-OWS            = *( SP / HTAB / obs-fold )
+  </script>
+</head>
+
+<body>
+
+<section id=abstract>
+<p>This document defines directives for the Content Security Policy
+mechanism to declare a set of input protections for a web resource's user
+interface, defines a non-normative set of heuristics for Web user agents to
+implement these input protections, and a reporting mechanism for when they are
+triggered. </p>
+</section>
+
+<section id=sotd>
+<p>This is the First Public Working Draft of the User Interface Safety Directives for
+Content Security Policy.
+[<cite><a class="bibref" rel="biblioentry" href="#bib-RFC2119">CSP</a></cite>]
+
+<p>Portions of the technology described in this document were originally
+developed as part of <code>X-Frame-Options</code> 
+[<cite><a class="bibref" rel="biblioentry" href="#bib-RFC2119">XFRAMEOPTIONS</a></cite>], 
+the ClearClick module of the Mozilla Firefox add-on NoScript, 
+[<cite><a class="bibref" rel="biblioentry" href="#bib-RFC2119">CLEARCLICK</a></cite>] 
+and in the InContext system implemented experimentally in Internet Explorer 
+[<cite><a class="bibref" rel="biblioentry" href="#bib-RFC2119">INCONTEXT</a></cite>]. </p>
+
+<p>In addition to the documents in the W3C Web Application Security working
+group, the work on this document is also informed by the work of the <a
+href="http://tools.ietf.org/wg/websec/">IETF websec working group</a>,
+particularly that working group's requirements document: <a
+href="http://tools.ietf.org/id/draft-hodges-websec-framework-reqs">draft-hodges-websec-framework-reqs</a>.
+</p>
+
+ 
+
+
+</section><section class=informative>
+<h2>Introduction</h2>
+
+<p>This document defines User Interface Safety directives for Content Security
+Policy, a mechanism web applications can use to mitigate some of the risks
+of User Interface (UI) Redressing  
+[<cite><a class="bibref" rel="biblioentry" href="#bib-RFC2119">UI-REDRESS</a></cite>]
+and Clickjacking [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC2119">UI-REDRESS</a></cite>]
+vulnerabilities that can lead to fraudulent actions not intended by the user. </p>
+
+<p>Content Security Policy (CSP) is a declarative policy that lets the authors (or
+server administrators) of a web application restrict from where an application
+can load resources.  This document defines directives to restrict display of
+or user interactin with a resource when it is in an embedded context.
+A user agent may implement the core directives of CSP independently from the
+directives in this specification, but this specification uses the
+policy conveyance and reporting mechanisms described in CSP. 
+The intrepretation 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> [<em><a
+href="http://tools.ietf.org/html/draft-ietf-websec-origin">ORIGIN</a></em>]
+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>
+
+<p>In some UI Redressing attacks (also known as Clickjacking), a malicious web
+application presents a user interface of another web application in a
+manipulated context to the user, e.g. by partially obscuring the genuine user
+interface with opaque layers on top, hence tricking the user to click on a
+button out of context. </p>
+
+<p>Existing anti-clickjacking measures including frame-busting
+[<cite><a class="bibref" rel="biblioentry" href="#bib-RFC2119">FRAMEBUSTING</a></cite>]
+ codes and <code>X-Frame-Options</code> are fundamentally incompatible with embeddable third-party
+widgets, and insufficient to defend against timing-based attack vectors. </p>
+
+<p>The User Interface Safety directives encompass the policies defined in <code>X-Frame-Options</code> 
+and also provide a new mechanism to allow web applications to enable heuristic 
+input protections for its user interfaces on user agents. </p>
+
+<p>To mitigate UI redressing, for example, a web application can request that
+a user interface element should be fully visible for a minimum period of time
+before a user input can be delivered. </p>
+
+<p>The User Interface Safety directive can often be applied to existing
+applications with few or no changes, but the heuristic hints supplied by the
+policy may require considerable experimental fine-tuning to achieve an
+acceptable error rate. </p>
+
+<p>This specification obsoletes <code>X-Frame-Options</code>. Resources may supply an
+<code>X-Frame-Options</code> header in addition to a Content-Security-Policy header to
+indicate policy to user agents that do not implement the directives in this
+specification. A user agent that understands the directives in this document
+SHOULD ignore the <code>X-Frame-Options</code> header, when present, if User Interface
+Safety directives are also present in a Content-Security-Policy header. This is
+to allow resources to only be embedded if the mechanisms described in this
+specification are enforced, and more restrictive <code>X-Frame-Options</code> policies
+applied otherwise.</p>
+
+</section><section id=conformance>
+<p>Requirements phrased in the imperative as part of algorithms (such as "strip
+any leading space characters" or "return false and abort these steps") are to
+be interpreted with the meaning of the key word ("MUST", "SHOULD", "MAY", etc)
+used in introducing the algorithm. </p>
+
+<p>A conformant user agent is one that implements all the requirements listed
+in this specification that are applicable to user-agents. Treatment of
+the <code>input-protection</code> directive values are at the discretion of the 
+user agent.</p>
+
+<p>A conformant server is one that implements all the requirements listed in
+this specification that are applicable to servers. </p>
+<section>
+<h3>Terminology</h3>
+
+<p>This section defines several terms used throughout the document. </p>
+
+<p>The term <dfn>security policy</dfn>, or simply <dfn>policy</dfn>, for the
+purposes of this specification refers to either: </p>
+<ol>
+  <li>a set of security preferences for restricting the behavior of content
+    within a given resource, or</li>
+  <li>a fragment of text that codifies these preferences.</li>
+</ol>
+
+<p>The security policies defined by this document are applied by a user agent
+on a <em>per-resource representation basis</em>. Specifically, when a user
+agent receives a policy along with the representation of a given resource, that
+policy applies to <em>that resource representation only</em>. This document
+often referes to that resource representation as the <dfn>protected
+resource</dfn>. </p>
+
+<p>A server transmits its security policy for a particular resource as a
+collection of <dfn>directives</dfn>, such as <code>default-src 'self'</code>,
+each of which controls a specific set of privileges for a document rendered by
+the user agent. More details are provided in the <a
+href="#directives">directives</a> section. </p>
+
+<p>A directive consists of a <dfn>directive name</dfn>, which indicates the
+privileges controlled by the directive, and a <dfn>directive value</dfn>, which
+specifies the restrictions the policy imposes on those privileges. </p>
+
+<p> An <dfn>ancestor</dfn> is any resource between the protected resource and the 
+top of the window frame tree; for example, if A embeds B which embeds C,
+ both A and B are ancestors of C. If A embeds both B and C,
+B is not an ancestor of C, but A still is.</p>
+
+<p>The term <dfn>origin</dfn> is defined in the Origin specification. [<em><a
+href="http://tools.ietf.org/html/draft-ietf-websec-origin">ORIGIN</a></em>] </p>
+
+<p>The term <dfn>URI</dfn> is defined in the URI specification. [[!URI]] </p>
+
+<p>The <code>&lt;iframe&gt;</code>, <code>&lt;object&gt;</code>,
+<code>&lt;embed&gt;</code>, and <code>&lt;frame&gt;</code>
+elements are defined in the HTML5 standard.
+[[!HTML5]]. </p>
+
+<p>The <code>&lt;applet&gt;</code> element is defined in the HTML 4.01
+standard. [[!HTML401]]. </p>
+<!-- <p>The <code>@font-face</code> CSS rule is defined in the CSS Fonts Module Level 3 standard.
+[[!CSS3-FONTS]]</p>
+<p>The <code>XMLHttpRequest</code> object is defined in the <code>XMLHttpRequest</code>
+standard. [[!XMLHTTPREQUEST]]</p>
+<p>The <code>EventSource</code> object is defined in the <code>EventSource</code>
+standard. [<em><a href="http://dev.w3.org/html5/eventsource/">EVENTSOURCE</a></em>].</p> -->
+
+<p>The Augmented Backus-Naur Form (ABNF) notation used in this document is
+specified in RFC 5234. [[!ABNF]] </p>
+
+<p>The following core rules are included by reference, as defined in [<em><a
+href="http://tools.ietf.org/html/rfc5234#appendix-B.1">ABNF Appendix
+B.1</a></em>]: <code>ALPHA</code> (letters), <code>DIGIT</code> (decimal 0-9),
+<code>WSP</code> (white space) and <code>VCHAR</code> (printing characters).
+</p>
+
+<p>The OWS rule is used where zero or more linear whitespace octets might
+appear. OWS SHOULD either not be produced or be produced as a single SP.
+Multiple OWS octets that occur within field-content SHOULD either be replaced
+with a single SP or transformed to all SP octets (each octet other than SP
+replaced with SP) before interpreting the field value or forwarding the message
+downstream. </p>
+<pre>OWS            = *( SP / HTAB / obs-fold )
                ; "optional" whitespace
 obs-fold       = CRLF ( SP / HTAB )
-               ; obsolete line folding
-</pre>
-      </section>
-    </section>
-    <section>
-      <h2 id="sec-directives">Directives</h2>
-      <p>
-        This section describes the content security policy directives
-        introduced in this specification.
-      </p>
-      <!-- <section>
-        <h3><code>embed-ancestors</code></h3>
+               ; obsolete line folding</pre>
 
-        <p><em>TODO:</em> Coordinate with the <a
-        href="http://tools.ietf.org/wg/websec/">IETF websec Working
-        Group</a>.</p>
+<p class="issue">How to define <code>source-expression</code>, <code>host-source</code>,
+etc. that may have different definitions depending on version of CSP?  Basically, how
+do we reference versions of CSP that may not yet exist?</p>
 
-        <p>The <code>embed-options</code> directive indicates whether the
-        user-agent should embed the resource using a <code>frame</code>,
-        <code>iframe</code>, <code>object</code> or <code>embed</code> tag,
-        or equivalent functionality in non-HTML resources.
-        Resources can use this to avoid many UI Redressing attacks by ensuring 
-        they are not embedded into other sites.  
-        This directive replicates some of the functionality of the 
-        <code>X-Frame-Options</code> header. The syntax for the name and 
-        value of the directive are described by the following ABNF grammar:</p>
+
+</section></section><section>
+<h2 id="sec-directives">Directives</h2>
+
+<p>This section describes the content security policy directives introduced in
+this specification. </p>
+
+
+<section>
+<h3><code>frame-options</code></h3>
+
+<p>The <code>frame-options</code> directive indicates whether the
+user-agent should embed the resource using a <code>frame</code>,
+<code>iframe</code>, <code>object</code>, <code>embed</code> or <code>applet</code> tag,
+or equivalent functionality in non-HTML resources.
+Resources can use this to avoid many UI Redressing attacks by ensuring 
+they are not embedded into other sites.  
+
+The syntax for the name and value of the directive are described by the following ABNF grammar:</p>
 
 <pre>
-directive-name    = "embed-ancestors"
-directive-value   = source-list
+directive-name = "frame-options"
+directive-value = ('deny' / 'self' / 1*1&lt;host-source&gt; ['self']) / ('deny' / 'self' / 1*1&lt;host-source&gt;) 'top-only'
 </pre>
 
-        <p>Unlike policies defined in Content Security Policy 1.0, the
-        <code>embed-ancestors</code> directives is not subject to the 
-        <code>default-src</code> directive.  If this directive is not 
-        explicitly stated in the policy its value is assumed to be <code>"*"</code>.</p>
-
-        <p>If <code>'deny'</code> is present in the source-list, the resource
-        cannot be displayed in an embedded context, regardless of the origin attempting
-        to do so, and all other members of the source-list are ignored.  This
-        provides functionality equivalent to the <code>DENY</code> value of
-        the <code>X-Frame-Options header.</code></p>
-
-        <p>If <code>'deny'</code> is not present the source-list indicates
-        which origins are valid <strong>ancestors</strong> for the resource.
-        An ancestor is any resource between the protected resource and
-        the top of the window frame tree; for example, if A embeds B which 
-        embeds C, both A and B are ancestors of C. If A embeds both B and C,
-        B is not an ancestor of C, but A still is.</p>
-
-        <p>The <code>'self'</code> source indicates that content of the same-origin
-        as the protected resource may embed it.  This provides functionality
-        equivalent to the <code>SAMEORIGIN</code> value of the <code>
-        X-Frame-Options</code> header.</p>
+<p class="issue">Should we use source-expression rather than host-source here? host-source
+provides compatibility with current granularity of X-Frame-Options, but a source-expression
+will allow seamless forward-evolution to more granular expressions in CSP 1.1.</p>
 
-      </section> -->
-      <section>
-        <h3><code>input-protection</code></h3>
-        <p>
-          The <code>input-protection</code> directive, if present, instructs
-          the user agent to apply the heuristic UI redressing protections
-          described in <a href="">Section 4</a> to user input events, such as
-          <code>click</code>, <code>keypress</code>, <code>touch</code>, and
-          <code>drag</code>, before they are delivered to the
-          resource.
-        </p>
-        <!-- <p>
-          ISSUE: Need some optimization language here. e.g. If the resource is
-          not embedded (it is topmost in the user agent rendering context) or
-          if all <strong>ancestors</strong> are <strong>same origin</strong>
-          this token may be ignored. <em>TODO: </em>this still allows attacks
-          with multiple windows in environments where that is possible
-          (traditional desktop OS) but to defend against this the user-visible
-          screenshot would have to be defined in terms of the OS, not the user
-          agent.
-        </p> -->
+<p>Unlike policies defined in Content Security Policy, the
+<code>frame-options</code> directive is not subject to the 
+<code>default-src</code> directive. If this directive is not 
+explicitly stated in the policy its value is assumed to be <code>"*"</code>.</p>
+
+<p>If the directive-value contains the keyword-source <code>'deny'</code>, the resource
+cannot be displayed in an embedded context, regardless of the origin attempting
+to do so, and all other values in the directive are ignored.</p>
+
+<p>If the directive-value does not contain <code>'deny'</code> it may
+contain the keyword-source <code>'self'</code> alone to indicate that the 
+resource may be embedded only if all <strong>ancestors</strong> are in 
+the same origin as the protected resource.</p>
+
+<p>If the directive-value does not contain the <code>'deny'</code> keyword-source,
+a host-source value indicates an origin that is a valid 
+<strong>ancestor</strong> for the resource. No more than one additional host-source may
+be specified, with the exception of the keyword-source 'self'.  </p>
+
+<p>If the <code>'top-only'</code> keyword-source is specified, only the origin of the
+top-level browsing context is checked, not the full window frame tree of ancestors.  This
+provides compatibility with <code>X-Frame-Options</code> but may introduce vulnerabilities
+in some cases as discussed in [SECURITY CONSIDERATIONS].  When <code>'top-only'</code> is
+specified, a <code>host-source</code> may not be combined with <code>'self'</code>.
+
+
+</section>
+<!--
+<section>
+<h3><code>frame-ancestors</code></h3>
+
+<p>The <code>frame-ancestors</code> directive indicates whether the
+user-agent should embed the resource using a <code>frame</code>,
+<code>iframe</code>, <code>object</code>, <code>embed</code> or <code>applet</code> tag,
+or equivalent functionality in non-HTML resources.
+Resources can use this to avoid many UI Redressing attacks by ensuring 
+they are not embedded into other sites.  
+
+The syntax for the name and value of the directive are described by the following ABNF grammar:</p>
+
 <pre>
-directive-name    = "input-protection"
-directive-value   = "block" / "report-only"  
+directive-name = "frame-ancestors"
+directive-value = 'deny' / 'self' / 1*1&lt;host-source&gt; ['self']
 </pre>
-        <p>
-          A value of <code>block</code> indicates the user agent should not
-          deliver the input event to the resource if the input protection
-          heuristic is triggered and a violation is detected.
-        </p>
-        <p>
-          A value of <code>report-only</code> indicates the user agent should
-          deliver the input event to the resource, even if a violation is
-          detected. This directive-value lets servers experiment with policies
-          by monitoring (rather than enforcing) a policy.
-        </p>
-        <p>
-          If the <code>report-uri</code> directive is present in the policy,
-          violations detected by the input protection heuristic MUST always
-          generate a report, whether the event is blocked or not.
-        </p>
-        <p>
-          User agents SHOULD NOT prompt the user when the input protection
-          heuristic is triggered.
-        </p>
-        <!-- <p>
-          ISSUE: is it worth having a "deliver" option, or should this just
-          always be part of a report-only policy?
-        </p> -->
-      </section>
-      <section>
-        <h3><code>input-protection-hints</code></h3>
-        <p>
-          The <code>input-protection-hints</code> directive allows a resource
-          to provide hints to the <code>input-protection</code> heuristics to
-          fine-tune the error rate.
-        </p>
+
+<p>Unlike policies defined in Content Security Policy, the
+<code>frame-ancestors</code> directive is not subject to the 
+<code>default-src</code> directive. If this directive is not 
+explicitly stated in the policy its value is assumed to be <code>"*"</code>.</p>
+
+<p>If the directive-value contains the keyword-source <code>'deny'</code>, the resource
+cannot be displayed in an embedded context, regardless of the origin attempting
+to do so, and all other values in the directive are ignored.</p>
+
+<p>If the directive-value does not contain <code>'deny'</code> it may
+contain the keyword-source <code>'self'</code> alone to indicate that the 
+resource may be embedded only if all <strong>ancestors</strong> are in 
+the same origin as the protected resource.   An ancestor is any resource 
+between the protected resource and the top of the window frame tree; for example, 
+if A embeds B which embeds C, both A and B are ancestors of C. If A embeds both B and C,
+B is not an ancestor of C, but A still is.</p>
+
+<p>If the directive-value does not contain the <code>'deny'</code> keyword-source,
+a host-source value indicates an origin that is a valid 
+<strong>ancestor</strong> for the resource. No more than one additional host-source may
+be specified, with the exception of the keyword-source 'self'.  </p>
+
+<p>A Content Security Policy that includes a <code>frame-ancestors</code> directive 
+MUST NOT include a <code>frame-options</code> directive.</p>
+
+
+</section>
+
+<section>
+<h3><code>frame-options</code></h3>
+
+<p>The <code>frame-options</code> directive indicates whether the
+user-agent should embed the resource using a <code>frame</code>,
+<code>iframe</code>, <code>object</code>, <code>embed</code> or <code>applet</code> tag,
+or equivalent functionality in non-HTML resources.
+Resources can use this to avoid many UI Redressing attacks by ensuring 
+they are not embedded into other sites. 
+This directive replicates the functionality of the 
+<code>X-Frame-Options</code> header. The syntax for the name and 
+value of the directive are described by the following ABNF grammar:</p>
+
 <pre>
-directive-name    = "click-protection-hints"
-directive-value   = ["element-id" = name] ["ui-height=" num-val] ["ui-width=" num-val] ["ui-delay=" num-val] ["tolerance=" num-val]
+directive-name = "frame-options"
+directive-value = 'deny' / 'self' / 1*1&lt;host-source&gt;
 </pre>
-        <p>
-          If the policy does not contain explicit
-          <code>input-protection-hints</code> or any of the optional values
-          are absent, the user agent should apply default values as described
-          in <a href="">Section XXX</a>. A user agent MAY ignore any or all
-          values in <code>input-protection-hints</code>.
-        </p>  
-        <p>
-          <code>element-id</code> is the name of a user interface element in
-          the DOM. If the policy does not contain an explicit
-          <code>element-id</code>, the user agent should apply protection to
-          the <code>body</code> element of the resource.
-        </p>
-        <p>
-          <code>ui-height</code> is a numeric value that defines the height of
-          the user interface element to be used for performing the screenshot
-          comparision.
-        </p>
-        <p>
-          <code>ui-width</code> is a numeric value that defines the width of
-          the user interface element to be used for performing the screenshot
-          comparision.
-        </p>
-        <p>
-          <code>ui-delay</code> is a numeric value that specifies the delay
-          time, in milliseconds, used in the input protection heuristic.
-          <em>TODO: delay after display, or delay after mouseover?</em>
-        </p>
-        <p>
-          <code>tolerance</code> is a numeric value from 0-99 that defines the
-          threshold at which the screenshot comparison procedure of the input
-          protection heuristic triggers a violation. A value of 0 indicates
-          that no difference between the two images is permitted. A value of
-          99 provides little to no practical protection.
-        </p>
-        <p>
-          <em>TODO: add more options</em>
-        </p>
-      </section>
-    </section>
-    <section>
-      <h2 id="sec-api">DOM interface</h2>
-      <p>
-        This specification introduces a new attribute for the
-        <code>UIEvent</code> interface introduced in DOM Level 2.
-      </p>
-      <section>
-        <h3><code>unsafe</code> attribute for the <code>UIEvent</code> interface</h3>
-        <dl>
-          <dt>
-            <code>unsafe</code> of type <span class="idlMemberType">boolean</span>, readonly
-          </dt>
-          <dd>
-            This is a non-configurable boolean property of input event
-            objects. The value <em class="rfc2119" title="should">should</em>
-            be "true" if a violation occurred. The value <em class="rfc2119"
-            title="should">should</em> not be set unless triggered by user
-            initiated actions.
-          </dd>
-        </dl>
-        <p>
-          The <code>unsafe</code> attribute allows web applications to monitor
-          and immediately respond to suspect violations, even in the
-          <code>report-only</code> mode. Applications may also use this
-          interface for capability detection. For example, a web application
-          may monitor user inputs on a payment button element like this:
-        </p>
-        <pre class="example">
-document.getElementById('payment-button').addEventListener("click", function(eventObj) {
+
+<p>Unlike policies defined in Content Security Policy, the
+<code>frame-options</code> directive is not subject to the 
+<code>default-src</code> directive. If this directive is not 
+explicitly stated in the policy its value is assumed to be <code>"*"</code>.</p>
+
+<p>If the directive-value contains the keyword-source <code>'deny'</code>, the resource
+cannot be displayed in an embedded context, regardless of the origin attempting
+to do so, and all other values in the directive are ignored. This
+provides functionality equivalent to the <code>DENY</code> value of
+the <code>X-Frame-Options header.</code></p>
+
+<p>If the directive-value does not contain <code>'deny'</code> it may
+contain the keyword-source <code>'self'</code> to indicate that the 
+resource may only be embedded if the top-level browsing context is in the
+same origin as the protected resource.  This provides functionality equivalent
+to the <code>SAMEORIGIN</code> value of the <code> X-Frame-Options</code> header.</p>
+
+<p>If the value of source does not contain the <code>'deny'</code> keyword-source,
+a single additional host-source indicates that the resource cannot be displayed in
+an embedded context unless the top-level browsing context is in the specified host-source origin. 
+No more than one additional host-source may be specified. This provides functionality equivalent to the 
+<code>ALLOW-FROM</code> value of the <code>X-Frame-Options</code> header.</p>
+
+<p>A Content Security Policy that includes a <code>frame-options</code> directive 
+MUST NOT include a <code>frame-ancestors</code> directive.</p>
+
+</section> 
+-->
+
+<section>
+<h3><code>input-protection</code></h3>
+
+<p>The <code>input-protection</code> directive, if present, instructs the user
+agent to apply the heuristic UI redressing protections described in <a
+href="">Section 4</a> to user input events, such as <code>click</code>,
+<code>keypress</code>, <code>touch</code>, and <code>drag</code>, before they
+are delivered to the resource. </p>
+
+<p>If set as part of a <code>Content-Security-Policy</code>, triggering of
+the hueristic should cancel delivery of the UI event to the target and
+cause a violation report to be sent.  If set as part of a 
+<code>Content-Security-Policy-Report-Only</code>, triggering of the heuristic 
+should result in the event being delivered with the <code>unsafe</code> 
+attribute on the <code>UIEvent</code> set to <code>true</code>
+and cause a violation report to be sent.</p>
+</p>
+<!-- <p>
+ISSUE: Need some optimization language here. e.g. If the resource is
+not embedded (it is topmost in the user agent rendering context) or
+if all <strong>ancestors</strong> are <strong>same origin</strong>
+this token may be ignored. <em>TODO: </em>this still allows attacks
+with multiple windows in environments where that is possible
+(traditional desktop OS) but to defend against this the user-visible
+screenshot would have to be defined in terms of the OS, not the user
+agent.
+</p> -->
+<!--
+<pre>directive-name    = "input-protection"
+directive-value   = "block" / "report-only" </pre>
+
+<p>A value of <code>block</code> indicates the user agent should not deliver
+the input event to the resource if the input protection heuristic is triggered
+and a violation is detected. </p>
+
+<p>A value of <code>report-only</code> indicates the user agent should deliver
+the input event to the resource, even if a violation is detected. This
+directive-value lets servers experiment with policies by monitoring (rather
+than enforcing) a policy, or to take action higher in the application stack,
+for example, by increasing the fraud risk score of a transaction that triggers
+a violation report. </p>
+
+<p>If the <code>report-uri</code> directive is present in the policy,
+violations detected by the input protection heuristic <em class="rfc2119"
+      title="must">must</em> always generate a
+report, whether the event is blocked or not. </p>
+
+<p>User agents SHOULD NOT prompt the user when the input protection heuristic
+is triggered. </p>
+<p>
+ISSUE: is it worth having a "deliver" option, or should this just
+always be part of a report-only policy?
+
+</p>
+</section>
+<section>
+<h3><code>input-protection-hints</code></h3>
+-->
+<p>The optional directive values allow resource authors to provide hints to 
+the heuristic to improve accuracy.  </p>
+
+
+<p class="issue">BWH: Consolidated the previous <code>input-protection</code> and
+<code>input-protection-hints</code> directives here.  <code>input-protection</code>
+previously just had "block" and "report-only" options, which are covered by the 
+two different types of CSP header already, without introducing new keyword-sources.
+</p>
+<p class="issue">
+Also removed setting of <code>unsafe</code> attribute from the enforced directive
+because the event should be cancelled.  Do we want to raise another type of event
+or allow a callback to be specified when an action is blocked?
+</p>
+
+<pre>directive-name    = "input-protection"
+directive-value   = ["element-id=" name] ["ui-height=" num-val] ["ui-width=" num-val] ["ui-delay=" num-val] ["tolerance=" num-val]</pre>
+
+<p>If the policy does not contain a value for this directive
+or any of the optional values are absent, the user agent should apply default
+values as described in <a href="">Section XXX</a>. A user agent MAY ignore any
+or all values in <code>input-protection</code>. </p>
+
+<p><code>element-id</code> is the name of a user interface element in the DOM.
+If the policy does not contain an explicit <code>element-id</code>, the user
+agent should apply protection to the <code>body</code> element of the resource.
+</p>
+
+<p><code>ui-height</code> is a numeric value that defines the height of the
+<!--user interface element-->viewing area to be used for performing the screenshot comparision.
+</p>
+
+<p><code>ui-width</code> is a numeric value that defines the width of the 
+<!--user interface element-->viewing area to be used for performing the screenshot comparision. </p>
+
+<p><code>ui-delay</code> is a numeric value that specifies the delay time, in
+milliseconds, used in the input protection heuristic.</p> 
+
+<p class="issue">Delay after display, or delay after mouseover?</p>
+
+<p><code>tolerance</code> is a numeric value from 0-99 that defines the
+threshold at which the screenshot comparison procedure of the input protection
+heuristic triggers a violation. A value of 0 indicates that no difference
+between the two images is permitted. A value of 99 provides little to no
+practical protection. </p>
+
+</section>
+
+<section>
+<h3><code>report-uri</code></h3>
+<p class="issue">Review this section to ensure that privacy violations
+do not occur - is any of this information not normally available to
+the DOM of an embedded resource?</p>
+
+<p>The <code>report-uri</code> directive specifies a URI to which the
+user agent sends reports about policy violation. 
+
+<p>The syntax for the name and value of this directive and the
+algorithm to prepare a report are described 
+by Content Security Policy. [REF - fwd compatible]</p>  
+
+<p>The core Content Security Policy specification provides directives to
+rectrict from where external content may be loaded.  As such, violation
+reports include a <dfn>blocked-uri</dfn> key/value pair that specifies the
+attempted resource load that was blocked by the policy.</p>
+
+<p>As this is not applicable to the directives in this document, the
+following additional steps MUST be added to the algoritihm defined in
+Content Security Policy to <em>prepare a violation report</em>:</p>
+
+</p>In step 1, when preparing the JSON object <em>violation-object</em>,
+add the following keys and values to the <dfn>csp-report</dfn>: [RFC4627]</p>
+
+<p>If the violation is of the <code>frame-options</code> directive, add the
+following keys and values:</p>
+
+<ul><dl>
+	<dt>ancestor-chain</dt>
+	<dd>An ordered array containing all <code>host-source</code> 
+	<dfn>ancestors</dfn> of the protected resource.  </dd>
+	<p class="issue">Do not modify this to <code>source-expression</code> even if the directive is changed to reflect this, except from the same origin, otherwise information disclosure vulnerability.</p>
+</dl></ul>
+
+<p>If the violation is of the <code>input-protection</code> directive, add
+the following keys and values:</P>
+
+<ul><dl>
+	<dt>blocked-event-type</dt>
+	<dd>The <code>type</code> attribute of the <code>UIEvent</code> that was blocked by policy.</dd>
+
+	<dt>touch-event</dt>
+	<dd>A <dfn>boolean</dfn> indicating whether the event blocked by policy was a <dfn>Touch Event</dfn> [REF].</dd>
+
+	<dt>client-height</dt>
+	<dd>The <code>document.documentElement.clientHeight</code> property
+	as defined in <em>TODO</em>.</dd>
+
+	<dt>client-width</dt>
+	<dd>The <code>document.documentElement.clientWidth</code> property
+	as defined in <em>TODO</em>.</dd>
+
+	<dt>blocked-event-client-x</dt>
+	<dd>The <code>clientX</code> attribute of the <code>UIEvent</code> that was blocked by policy, if set.</dd>
+
+	<dt>blocked-event-client-y</dt>
+	<dd>The <code>clientY</code> attribute of the <code>UIEvent</code> that was blocked by policy, if set.</dd>
+
+</dl></ul>
+
+<p class="issue">What standard defines these attributes?</p>
+
+<p>If the target of an <code>UIEvent</code> which triggers an <code>input-protection</code> violoation has an explictly-set <code>id</code> attribute:
+
+
+<ul><dl>
+	<dt>blocked-target-id</dt>
+	<dd>The <code>id</code> attribute of the DOM Element that a violating
+	<code>UIEvent</code> targeted.</dd>
+</dl></ul>
+
+<p>Otherwise, if the target element does not have an explicit <code>id</code> attribute:
+
+<ul><dl>
+	<dt>blocked-target-xpath</dt>
+	<dd>An XPath [REF] expression that returns the target <code>Element</code> of the <code>UIEvent</code>
+	that was blocked by policy. <em>TODO: describe the algorithm to do this here</em></dd>
+</dl></ul>
+
+
+</section>
+
+
+</section><section>
+<h2 id="sec-api">DOM interface</h2>
+
+<p>This specification introduces a new attribute for the <code>UIEvent</code>
+interface introduced in DOM Level 2. </p>
+<section>
+<h3><code>unsafe</code> attribute for the <code>UIEvent</code> interface</h3>
+<dl>
+  <dt><code>unsafe</code> of type <span class="idlMemberType">boolean</span>,
+  readonly </dt>
+    <dd>This is a non-configurable boolean property of input event objects. The
+      value <em class="rfc2119" title="should">should</em> be "true" if a
+      violation occurred. The value <em class="rfc2119"
+      title="should not">should not</em> not be set unless triggered by user initiated
+      actions. </dd>
+</dl>
+
+<p>The <code>unsafe</code> attribute allows web applications to monitor and
+immediately respond to suspect violations in the <code>report-only</code>
+mode. Applications may also use this interface for capability detection. For
+example, a web application may monitor user inputs on a payment button element
+like this: </p>
+<pre class="example">document.getElementById('payment-button').addEventListener("click", function(eventObj) {
   if ("unsafe" in eventObj) {
     if (eventObj.unsafe == true) {
       return reportUnsafeOrShowDialog();
     }
   }
   makePayment();
-};
-        </pre>
-      </section>
-    </section>
-    <section>
-      <h2>Input Protection Heuristic</h2>
-
-      <section class="informative">
-        <p>This section is non-normative. The algorithm described here can be implemented mostly in terms of
-        HTML5 constructs, but requries the ability to monitor and intercept actions in the rendering of a
-        resource and delivery of events to that resource.  User agents may apply equivalent protections
-        using means more optimized for their implementation details, may ignore recommendations where
-        the browsing environment eliminates certain classes of attack, (e.g. cursor sanity check in a
-        touch-only environment) or may implement some features in terms of the underlying operating system
-        or platform rather than directly in the user agent.</p>
-
-        <h3>Algorithm Description</h3>
-
-        <ol>
-          <li><strong>Listener registration</strong> - Register a "global" capturing event listener
-          for mouse button, tapping, keyboard, drag &amp; drop and focus events, which must be 
-          guaranteed to run before any other event handler of the same kind and therefore be able 
-          to prevent any event from being handled by the content, if needed.
-
-          <em>CBC: in order to guarantee the "first to process' event listener requirement 
-            and reduce registration overhead, ClearClick adds its listener to the 
-            Mozilla-specific DocShell object which is the immediate container of the 
-            topmost DOM window per any given tab. A crossbrowser approach likely to 
-            work is registering the listener on the topmost DOM window itself before 
-            any script has a chance to run.</em>
-          </li>
-
-          <li><strong>Fast-track bypass</strong> - Whenever the listener is called,
-          check whether the event target or its owner document are flagged as
-          "unlocked". If either is, return early.
-    
-           <em>CBC: ClearClick uses an expando property to flag DOM nodes and
-           windows, relying on a feature of Mozilla's chrome-exposed DOM
-           wrappers which prevents content from seeing or tamper with expando
-           properties set by privileged code. Other browsers may require
-           different procedures to safely annotate documents and other DOM
-           nodes. Furthermore, this and most of the remaining steps assume our
-           listener can examine and manipulate any DOM node or window
-           independently from its origin, bypassing SOP. This privilege should
-           be granted by the listener having being registered by privileged
-           (browser extension) code.</em>
-           </li>
-
-            <li><strong>Parent chain check</strong> - Check whether the event target is either
-            a child of a nested document or a plugin content element (EMBED, APPLET or OBJECT). 
-            If it is not, or it is an embedded document belonging to a same-site parent chain
-            (i.e. it and all its parents are from the same origin), flag the document as 
-            "unlocked" and return. Notice that the original Clickjacking demo by Hansen &amp; 
-            Grossman worked despite the Flash content being served same-site: since plugins 
-            may follow type-specific origin policies, we never return early at
-            this stage when interacting with plugin content, even if embedded same-site.</li>
-  
-            <li><strong>Rapid fire check</strong> - Check whether the previous event we had
-            observed was the same type on a document from a different origin, happened within
-            the past 800ms (quarantine time). If it was, we assume a "Rapid fire" attack 
-            (e.g. the user has been tricked into repeatedly click on the same or a predictable
-            location in a fast succession while the document gets changed under his mouse pointer)
-            : halve the quarantine time and go to step 8. If next interaction happens with a 
-            different document, the quarantine time will be reset.</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 an possibly attacker-provided bitmap: if it has, 
-            go to step 7. This provides protection against "Phantom cursor" attacks, also known 
-            as "Cursorjacking".</li>
+};</pre>
+</section></section>
+<section>
+<h2>Input Protection Heuristic</h2>
+<section class=informative>
+<p>This section is non-normative. The algorithm described here can be
+implemented mostly in terms of HTML5 constructs, but requries the ability to
+monitor and intercept actions in the rendering of a resource and delivery of
+events to that resource. User agents may apply equivalent protections using
+means more optimized for their implementation details, may ignore
+recommendations where the browsing environment eliminates certain classes of
+attack, (e.g. the cursor sanity check in a touch-only environment) or may implement
+some features in terms of the underlying operating system or platform rather
+than directly in the user agent.</p>
 
-            <li><strong>Obstruction check</strong> - By using an offscreen HTML 5 canvas element, 
-            we take two reasonably sized (300x200 on average, but growing or shrinking depending 
-            on document's inherent size and viewport constraints and hints provided by the
-            <code>ui-height</code> and <code>ui-width</code> properties of <code>
-            input-protection-hints</code>) screenshots of the region centered around the DOM 
-            element which is about to receive the event: one from its owner document's 
-            "point of view" (unobstructed by definition), 
-            the other from the topmost window's. In the plugin content case, we ensure the former
-            "screenshot" contains the element itself only. If the number of the pixels which are 
-            different between the screenshots don't exceed a certain configurable tolerance rate 
-            (default 18%, or as set by the <code>tolerance</code> property of 
-            <code>input-protection-hints</code>), return. Otherwise we tentatively assume the 
-            DOM element our user is interacting with has been obstructed or obscured by a 
-            UI Redressing attempt.  
+<h3>Algorithm Description</h3>
+<ol>
+  <li><strong>Listener registration</strong> - Register a "global" capturing
+    event listener for mouse button, tapping, keyboard, drag &amp; drop and
+    focus events, which must be guaranteed to run before any other event
+    handler of the same kind and therefore be able to prevent any event from
+    being handled by the content, if needed. <em>CBC: in order to guarantee the
+    "first to process' event listener requirement and reduce registration
+    overhead, ClearClick adds its listener to the Mozilla-specific DocShell
+    object which is the immediate container of the topmost DOM window per any
+    given tab. A crossbrowser approach likely to work is registering the
+    listener on the topmost DOM window itself before any script has a chance to
+    run.</em> </li>
+  <li><strong>Fast-track bypass</strong> - Whenever the listener is called,
+    check whether the event target or its owner document are flagged as
+    "unlocked". If either is, return early. <em>CBC: ClearClick uses an expando
+    property to flag DOM nodes and windows, relying on a feature of Mozilla's
+    chrome-exposed DOM wrappers which prevents content from seeing or tamper
+    with expando properties set by privileged code. Other browsers may require
+    different procedures to safely annotate documents and other DOM nodes.
+    Furthermore, this and most of the remaining steps assume our listener can
+    examine and manipulate any DOM node or window independently from its
+    origin, bypassing SOP. This privilege should be granted by the listener
+    having being registered by privileged (browser extension) code.</em> </li>
+  <li><strong>Parent chain check</strong> - Check whether the event target is
+    either a child of a nested document or a plugin content element (EMBED,
+    APPLET or OBJECT). If it is not, or it is an embedded document belonging to
+    a same-site parent chain (i.e. it and all its parents are from the same
+    origin), flag the document as "unlocked" and return. Notice that the
+    original Clickjacking demo by Hansen &amp; Grossman worked despite the
+    Flash content being served same-site: since plugins may follow
+    type-specific origin policies, we never return early at this stage when
+    interacting with plugin content, even if embedded same-site.</li>
+  <li><strong>Rapid fire check</strong> - Check whether the previous event we
+    had observed was the same type on a document from a different origin,
+    happened within the past 800ms (quarantine time). If it was, we assume a
+    "Rapid fire" attack (e.g. the user has been tricked into repeatedly click
+    on the same or a predictable location in a fast succession while the
+    document gets changed under his mouse pointer) : halve the quarantine time
+    and go to step 8. If next interaction happens with a different document,
+    the quarantine time will be reset.</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 an
+    possibly attacker-provided bitmap: if it has, go to step 7. This provides
+    protection against "Phantom cursor" attacks, also known as
+  "Cursorjacking".</li>
+  <li><strong>Obstruction check</strong> - By using an offscreen HTML 5 canvas
+    element, we take two reasonably sized (300x200 on average, but growing or
+    shrinking depending on document's inherent size and viewport constraints
+    and hints provided by the <code>ui-height</code> and <code>ui-width</code>
+    properties of <code>input-protection-hints</code>) screenshots of the
+    region centered around the DOM element which is about to receive the event:
+    one from its owner document's "point of view" (unobstructed by definition),
+    the other from the topmost window's. In the plugin content case, we ensure
+    the former "screenshot" contains the element itself only. If the number of
+    the pixels which are different between the screenshots don't exceed a
+    certain configurable tolerance rate (default 18%, or as set by the
+    <code>tolerance</code> property of <code>input-protection-hints</code>),
+    return. Otherwise we tentatively assume the DOM element our user is
+    interacting with has been obstructed or obscured by a UI Redressing
+    attempt. 
     
-            <em>CBC: the screenshots are taken by using the
-            CanvasRenderingContext2D.drawWindow() method11, which is a
-            Mozilla-proprietary extension of the HTML 5 Canvas API available
-            to privileged code only, allowing the content of DOM windows to be
-            drawn on a canvas surface exactly as rendered on the screen. The
-            rest of this phase relies on cross-browser canvas features,
-            instead, such as pixel grabbing and data URL serialization.</em>
-            </li>
-        </ol>
-
-      </section>
-    </section>
-
-    <section>
-      <h2>Examples</h2>
-      <p><em>XXX TODO</em></p>
-      <section class="informative">
-        <h3>Sample Policy Definitions</h3>
-
-        <p>This section provides some sample use cases and accompanying security policies.</p>
+    <p><em>CBC: the screenshots are taken by using the
+    CanvasRenderingContext2D.drawWindow() method11, which is a
+    Mozilla-proprietary extension of the HTML 5 Canvas API available to
+    privileged code only, allowing the content of DOM windows to be drawn on a
+    canvas surface exactly as rendered on the screen. The rest of this phase
+    relies on cross-browser canvas features, instead, such as pixel grabbing
+    and data URL serialization.</em></p>
 
-        <p><strong>Example 1:</strong> A server wishes to load resources only
-        form its own origin:</p>
-
-        <pre>Content-Security-Policy: default-src 'self'</pre>
-
-        <p><strong>Example 2:</strong> An auction site wishes to load images
-        from any URI, plugin content from a list of trusted media providers
-        (including a content distribution network), and scripts only from a
-        server under its control hosting sanitized ECMAScript:</p>
-
-        <pre>Content-Security-Policy: default-src 'self'; img-src *;
-                         object-src media1.example.com media2.example.com *.cdn.example.com;
-                         script-src trustedscripts.example.com</pre>
-
-        <p><strong>Example 3:</strong> Online banking site wishes to ensure that all of the content
-        in its pages is loaded over TLS to prevent attackers from eavesdropping on insecure content
-        requests:</p>
+   
+   </li>
+</ol>
+</section></section>
+<section>
+<h2>Script Interfaces</h2>
 
-        <pre>Content-Security-Policy: default-src https: 'unsafe-inline' 'unsafe-eval'</pre>
-      </section>
-
-      <section class="informative">
-        <h3>Sample Violation Report</h3>
-
-        <p>This section contains an example violation report the user agent
-        might sent to a server when the protected resource violations a sample
-        policy.</p>
+<p class="issue"> Should we define 1.1 compatible script interfaces, or only 
+	recommend checking the presence of the <code>unsafe</code> attribute?</p>
 
-        <p>In the following example, a document from
-        <code>http://example.org/page.html</code> was rendered with the
-        following CSP policy:</p>
+</section>
+<section>
+<h2>Examples</h2>
 
-<pre>default-src 'self'; report-uri http://example.org/csp-report.cgi</pre>
+<section class=informative>
+<h3>Sample Policy Definitions</h3>
 
-        <p>The document loaded an image from
-        <code>http://evil.example.com/image.png</code>, violating the
-        policy.</p>
+<p>This section provides some sample use cases and accompanying security
+policies.</p>
 
+<p><strong>Example 1:</strong> A resource wishes to block delivery of UI events
+to the DOM element with the id of "submitButton" and suggests a 15% tolerance
+threshold for determining obstruction of the element within a 200 by 200 pixel window:</p>
+<pre>Content-Security-Policy: input-protection element-id=submitButton tolerance=15
+                         ui-height=200 ui-width=200</pre>
+
+<p><strong>Example 2:</strong> An resource wishes to receive reports when the
+UI Safety heuristic is triggered for any element in the <code>&lt;body&gt;</code>
+:</p>
+<pre>Content-Security-Policy-Report-Only: input-protection;
+                                     report-uri https://example.com/csp-report?unique_id=XKSJ9KAAHJDK9928KKSJEQ</pre>
+
+<p><strong>Example 3:</strong> A resource wants to react to potential clickjacking
+directly, without sending a report, so it sets a report-only header but does not 
+specify a report-uri. When a <code>UIEvent</code> is sent, the <code>unsafe</code>
+attribute will still be set when the heuristic is triggered:</p>
+<pre>Content-Security-Policy-Report-Only: input-protection</pre>
+</section>
+<section class=informative>
+<h3>Sample Violation Report</h3>
+
+<p>This section contains an example violation report the user agent might sent
+to a server when the protected resource violations a sample policy.</p>
+
+<p>In the following example, a document from
+<code>http://example.org/page.html</code> was rendered with the following CSP
+policy:</p>
+<pre>input-protection; report-uri https://example.org/csp-report.cgi?unique_id=12345</pre>
+
+<p>A <code>click</code> violated the policy.</p>
 <pre>{
   "csp-report": {
     "document-uri": "http://example.org/page.html",
     "referrer": "http://evil.example.com/haxor.html",
-    "blocked-uri": "http://evil.example.com/image.png",
-    "violated-directive": "default-src 'self'",
-    "original-policy": "default-src 'self'; report-uri http://example.org/csp-report.cgi"
+    "blocked-event-type": "click",
+    "blocked-event-client-x": "325",
+    "blocked-event-client-y": "122",
+    "touch-event": "false",
+    "client-width": "600",
+    "client-height": "700",
+    "blocked-target-id": "makePaymentSubmit",
+    "blocked-target-xpath": <em>TODO</em>,
+    "ancestor-chain": <em>TODO</em>,
+    "violated-directive": "input-protection",
+    "original-policy": "input-protection; report-uri https://example.org/csp-report.cgi?unique_id=12345"
   }
 }</pre>
-
-      </section>
-    </section>
-
-    <section>
-      <h2>Security Considerations</h2>
-
-    </section>
-
-    <section>
-      <h2>Implementation Considerations</h2>
-
-      <p><em>XXX TODO</em></p>
-  
-    </section>
-
-    <section>
-      <h2>Implementation Considerations for Resource Authors</h2>
-  <p><em>XXX TODO</em> suggestions on back-end anti-fraud here and use of unique, per-transaction report-uris with information about 
-  targets encoded, and use of report-only to collect possible fraud data without blocking transactions.
-  </p>
-    </section>
-
-    <section>
-      <h2>IANA Considerations</h2>
-
-      <p>The permanent message header field registry (see [<a
-      href="http://tools.ietf.org/html/rfc3864">RFC3864</a>]) should be updated
-      with the following registrations:</p>
+</section></section>
+<section>
+<h2>Security Considerations</h2>
+<p>This document specifies two embedding policy mechanisms: <code>frame-ancestors</code> 
+and <code>frame-options</code>.</p>
 
-      <section>
-        <h2>Content-Security-Policy</h2>
-
-        <p>Header field name: Content-Security-Policy</p>
-
-        <p>Applicable protocol: http</p>
-
-        <p>Status: standard</p>
-
-        <p>Author/Change controller: W3C</p>
-
-        <p>Specification document: this specification (See <a
-        href="#content-security-policy-header-field"><code>Content-Security-Policy</code>
-        Header Field</a>)</p>
-      </section>
+<p>The <code>frame-options</code> directive verifies only the top-level browsing context,
+not all <strong>ancestors</strong> of a protected resource.  The <code>frame-options</code>
+directive provides exact compatibility with <code>X-Frame-Options</code>, but may allow
+additional vulnerabilities as compared to <code>frame-ancestors</code>.  
+For example, if a resource at origin A allows untrusted content from origin B
+to be displayed in an iframe, (perhaps using the <code>sandbox</code> attribute)
+that embedded content
+may itself embed more content from origin A.  Because it does not check ancestors,
+a <code>frame-options</code> policy value of 'self' would allow this, even though the immediate 
+embedding context of the resource is hostile, and B might be able to attack A.
+</p>
 
-      <section>
-        <h2>Content-Security-Policy-Report-Only</h2>
-
-        <p>Header field name: Content-Security-Policy-Report-Only</p>
-
-        <p>Applicable protocol: http</p>
-
-        <p>Status: standard</p>
+<p>Both <code>frame-ancestors</code> and <code>frame-options</code> provide deterministic protections within a single browsing window, but may not provide full protection in environments where multiple browser windows may overlap and be programatically closed or moved by malicious content.  These directives SHOULD be deployed in concert with <code>input-protection</code> to provide additional protection in such environments.</p>
 
-        <p>Author/Change controller: W3C</p>
+<p>UI Redressing and Clickjacking attacks rely on violating the contextual and temporal integrity of embedded content.  Because these attacks target the subjective perception of the user and not well-defined security boundaries, the hueristic protections afforded by the <code>input-protection</code> directive can never be 100% effective for every interface. It provides no protection against certain classes of attacks, such as displaying content around an embedded resource that appears to extend a trusted dialog but provides misleading information.<p>
 
-        <p>Specification document: this specification (See <a
-        href="#content-security-policy-report-only-header-field"><code>Content-Security-Policy-Report-Only</code>
-        Header Field</a>)</p>
-      </section>
-    </section>
-  </body>
+
+
+</section><section>
+<h2>Implementation Considerations</h2>
+
+<p>Many UI Redressing and Clickjacking attacks rely on exploiting specific features of user agents, such as repositioning of the browsing window, hiding or creating fake cursors, and script-driven scrolling and content repositioning.  Not all attacks apply to all user agents in all contexts.  User agents are free to optimize or not implement suggested heuristics when they do not apply, for example:
+<ul>
+	<li>Cursor integrity in a touch-only environment</li>
+	<li>Drag and drop protections for user agents where 
+	<code>drag</code> is not a supported event type</li>
+	<li><code>ui-width</code> and <code>ui-height</code> values that exceed the
+	capabilities of the browsing environment</li>
+</ul>
+
+<p>Some resource owners may specify a restrictive policy forbidding embedding in
+user agents that only understand <code>X-Frame-Options</code> but be more 
+permissive with user agents that implement UI Safety directives.  User agents
+that are aware of but choose not to implement any of the hurestics in this
+document MAY still ignore <code>X-Frame-Options</code> when
+presented in combination with UI Safety directives in a Content-Security-Policy.
+For example, a browsing environment that deliberately chooses not to implement 
+UI Safety features because they interfere with assistive technologies SHOULD NOT deny
+users access to resources on this account.  User agents taking this stance SHOULD
+implement the <code>unsafe</code> attribute of the <code>UIEvent</code> interface
+as this may be interrogated by client applications doing feature detection.</p>
+
+<p>In environments that support multiple, overlapping browser windows, attacks
+may be mounted by positioning a target window under another, instructing the
+user to double click, and closing the obstructing window with the first click.
+[<em>TODO: ref Jackson et al. paper here</em>]  In such environments user agent
+implementers may wish to use a native operating system screenshot facility to
+calculate the user's view for the <strong>obstruction check</strong> phase of
+the heuristic.</p>
+
+</section><section>
+<h2>Implementation Considerations for Resource Authors</h2>
+
+<p>When possible, resource authors SHOULD make use of violation reports and the <code>unsafe</code> attribute to apply additional security measures in the application or during back-end processing.  Real-time meaures in the application might include requiring completion of a CAPTCHA [<em>REF</em>] or responding to an out-of-band confirmation when the UI Safety heuristic is triggered.  Example back-end measures might include increasing a fraud risk score for individual actions that trigger or targets accounts/resources that frequently trigger UI Safety hueristics.  To be able to do this effectively, it is likely necesssary to encode into the <code>report-uri</code> a unique identifier that can be correlated to the authenticated user and the action they are taking.</p>
+
+</section><section>
+<h2>IANA Considerations</h2>
+
+<p>This document does not define new message headers and uses the existing grammar
+of the Content-Security-Policy and Content-Security-Policy-Report-Only headers, so
+no updates to the permanent message header field registry (see [<a
+href="http://tools.ietf.org/html/rfc3864">RFC3864</a>]) are required.
+</section></section></body>
 </html>