Fixing typos and making ReSpec.js work
authorDavid Lin-Shung Huang <linshung.huang@sv.cmu.edu>
Sun, 10 Jun 2012 23:55:06 -0700
changeset 1 2f0839da87bd
parent 0 6834f5e73e7b
child 2 60d5f3433636
Fixing typos and making ReSpec.js work
user-interface-safety.html
--- a/user-interface-safety.html	Sun Jun 10 16:42:02 2012 -0700
+++ b/user-interface-safety.html	Sun Jun 10 23:55:06 2012 -0700
@@ -3,12 +3,12 @@
   <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 src='http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js' class='remove'></script>
     <script class='remove'>
       var respecConfig = {
           // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
@@ -35,24 +35,24 @@
           // previousMaturity:  "WD",
 
           // if there a publicly available Editor's Draft, this is the link
-          //edDraftURI:           "http://dvcs.w3.org/hg/uisafety/raw-file/tip/uisafety.dev.html",
+          edDraftURI:           "http://dvcs.w3.org/hg/user-interface-safety/raw-file/tip/user-interface-safety.html",
 
           // if this is a LCWD, uncomment and set the end of its review period
           // lcEnd: "2009-08-05",
 
           // 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:             ["http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css"],
 
           // editors, add as many as you like
           // only "name" is required
           editors:  [
               { name: "Giorgio Maone", url: "mailto:[email protected]",
                 company: "Invited Expert", companyURL: "" },
-              { name: "David Lin-Shung Huang", url: "mailto:[email protected]",
-                company: "Carnegie-Mellon University", companyURL: "http://sv.cmu.edu/" },
-	      { name: "Brad Hill", url: "mailto:[email protected]",
-		company: "PayPal Inc.", copanyURL: "https://www.paypal.com/" },
+              { name: "Lin-Shung Huang", url: "mailto:[email protected]",
+                company: "Carnegie Mellon University", companyURL: "http://www.cmu.edu/" },
+              { name: "Brad Hill", url: "mailto:[email protected]",
+                company: "PayPal Inc.", companyURL: "https://www.paypal.com/" },
           ],
 
           // authors, add as many as you like. 
@@ -85,31 +85,34 @@
   </head>
   <body>
     <section id="abstract">
-    <p>This document defines a directive for the Content Security Policy 1.0 mechanism
-      to allow Web application developers to declare a set of protections for a web resource 
-      to help prevent malicious obscuring or re-contextualizing of the resource's user interface
-      when it is displayed in an embedded context.
-
-      The document also defines a set of heuristics for Web user agents to implement these
-      protections and a reporting mechanism for when they are triggered.
-      </p>
+      <p>This document defines a directive for the Content Security Policy 1.0
+      mechanism to allow Web application developers to declare a set of
+      protections for a web resource to help prevent malicious obscuring or
+      re-contextualizing of the resource's user interface when it is displayed
+      in an embedded context.
+    
+      The document also defines a set of heuristics for Web user agents to
+      implement these 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
+      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>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 anti-clickjacking policy.</p>
+      <p>This document uses the syntax and mechanism of the Content Security Policy 1.0
+      and defines a new directive to convey anti-clickjacking 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">
@@ -117,7 +120,7 @@
 
       <p>This document defines new directives for Content Security Policy 1.0
       to allow applications to mitigate some of the risks of User Interface 
-      Redressing vulnerabilities that can lead to fraud.<p>
+      Redressing vulnerabilities that can lead to fraud.</p>
 
       <p>Content Security Policy is a declarative policy that lets the authors
       (or server administrators) of a web application restrict from where
@@ -149,7 +152,7 @@
       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. 
+      policies applied otherwise.</p>
     </section>
 
     <section id="conformance">
@@ -169,22 +172,21 @@
 
         <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> 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>.
+        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
@@ -200,7 +202,7 @@
         <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 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>,
@@ -210,7 +212,7 @@
         <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.
-        [[!CSS3FONT]]</p>
+        [[!CSS3-FONTS]]</p>
 
         <p>The <code>XMLHttpRequest</code> object is defined in the <code>XMLHttpRequest</code>
         standard. [[!XMLHTTPREQUEST]]</p>
@@ -235,7 +237,7 @@
         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>
+        field value or forwarding the message downstream.</p>
 
 <pre>
 OWS            = *( SP / HTAB / obs-fold )
@@ -260,126 +262,125 @@
         href="http://tools.ietf.org/wg/websec/">IETF websec Working
         Group</a>.</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>
+        <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>
 
 <pre>
 directive-name    = "embed-ancestors"
 directive-value   = source-list
 </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>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>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 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>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>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>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>
 
       </section>
+    </section>
 
-      <section>
+    <section>
         <h3><code>click-protection</code></h3>
 
-	<p>The <code>click-protection</code> directive, if present,
-        instructs the user agent to apply the heuistic clickjacking
-	protections described in <a href="">Section XXX</a> to click
-	and drag-and-drop events delivered before they are delivered
-	to the resouce in an embedded context.
-	</p>
+        <p>The <code>click-protection</code> directive, if present,
+              instructs the user agent to apply the heuistic clickjacking
+        protections described in <a href="">Section XXX</a> to click
+        and drag-and-drop events delivered before they are delivered
+        to the resouce in an embedded context.</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>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    = "click-protection"
 directive-value   = "block" / "deliver"  
 </pre>
 
-	<p>A value of <code>block</code> indicates the user agent should
-	not deliver the event to the resource if the click protection
-	heuristic is triggered.</p>
-
-	<p>A value of <code>deliver</code> indicates the user agent should
-	deliver the event to the resource, even if the click protection
-	heuristic is triggered.</p>
+        <p>A value of <code>block</code> indicates the user agent should
+        not deliver the event to the resource if the click protection
+        heuristic is triggered.</p>
 
-	<p>If a report-uri is present, triggering of the click protection
-	heuristic MUST always generate a report, whether the event is
-	delivered or not.</p>
+        <p>A value of <code>deliver</code> indicates the user agent should
+        deliver the event to the resource, even if the click protection
+        heuristic is triggered.</p>
 
-	<p>User agents SHOULD NOT prompt the user when the click protection
-	heuristic is triggered.</p>
+        <p>If a report-uri is present, triggering of the click protection
+        heuristic MUST always generate a report, whether the event is
+        delivered or not.</p>
 
-	<p>ISSUE: is it worth having a "deliver" option, or should this
-	just always be part of a report-only policy?</p>
+        <p>User agents SHOULD NOT prompt the user when the click 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>click-protection-hints</code></h3>
 
-	<p>The <code>click-protection-hints</code> directive allows a
-        resource to provide hints to the <code>click-protection</code>
-	heuristics for greater accuracy.	
+        <p>The <code>click-protection-hints</code> directive allows a resource
+        to provide hints to the <code>click-protection</code> heuristics for
+        greater accuracy.</p>
 
 <pre>
 directive-name    = "click-protection-hints"
 directive-value   = ["tolerance=" num-val] ["viewport-height=" num-val] ["viewport-width=" num-val] ["ui-delay=" num-val] 
 </pre>
 
-	<p>If the policy does not contain  explicit <code>click-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>click-protection-hints</code>.</p>
-	
-	<p><code>tolerance</code> is a numeric value from 0-99 that defines the
-	threshold at which the screenshot comparision procedure triggers the
-	click protection heuristic.  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>If the policy does not contain  explicit <code>click-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>click-protection-hints</code>.</p>
+  
+        <p><code>tolerance</code> is a numeric value from 0-99 that defines the
+        threshold at which the screenshot comparision procedure triggers the
+        click protection heuristic.  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><code>viewport-height</code> is a numeric value that defines the height of
-	the viewport to be used for performing the screenshot comparision.<p>
-
-	<p><code>viewport-width</code> is a numeric value that defines the width of
-	the viewport to be used for performing the screenshot comparision.<p>
+        <p><code>viewport-height</code> is a numeric value that defines the height of
+        the viewport 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 click protection heuristic.</p>
+        <p><code>viewport-width</code> is a numeric value that defines the width of
+        the viewport to be used for performing the screenshot comparision.</p>
 
-	<p><code>protected-id</code> <em>???</em> does it make sense to allow protections to apply
-	to a named element in the DOM, instead of a viewport window?</p>
+        <p><code>ui-delay</code> is a numeric value that specifies the delay time, in 
+        milliseconds, used in the click protection heuristic.</p>
 
+        <p><code>protected-id</code> <em>???</em> does it make sense to allow protections to apply
+        to a named element in the DOM, instead of a viewport window?</p>
 
       </section>
 
@@ -387,95 +388,98 @@
       <h2>Click 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>
+        <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>
 
-		<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>
+        <h3>Algorithm Description</h3>
 
-		<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".
+        <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.
 
-		<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>viewport-height</code> and <code>viewport-width</code> properties of <code>
-		click-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>click-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>
+          <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>viewport-height</code> and <code>viewport-width</code> properties of <code>
+            click-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>click-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>
     <section>
       <h2>Examples</h2>
 
@@ -522,7 +526,7 @@
         <code>http://evil.example.com/image.png</code>, violating the
         policy.</p>
 
-        <pre>{
+<pre>{
   "csp-report": {
     "document-uri": "http://example.org/page.html",
     "referrer": "http://evil.example.com/haxor.html",
@@ -534,22 +538,26 @@
 
       </section>
     </section>
+
     <section>
       <h2>Security Considerations</h2>
-      <section>
-      </section>
+
     </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>
+      <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>