--- 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:g.maone@informaction.com",
company: "Invited Expert", companyURL: "" },
- { name: "David Lin-Shung Huang", url: "mailto:linshung.huang@sv.cmu.edu",
- company: "Carnegie-Mellon University", companyURL: "http://sv.cmu.edu/" },
- { name: "Brad Hill", url: "mailto:bhill@paypal-inc.com",
- company: "PayPal Inc.", copanyURL: "https://www.paypal.com/" },
+ { name: "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/" },
],
// 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><script></code>, <code><object></code>, <code><embed></code>,
<code><img></code>, <code><video></code>, <code><audio></code>,
@@ -210,7 +212,7 @@
<p>The <code><applet></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 & 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 &
- 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 & 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 &
+ 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>