--- a/user-interface-safety.html Mon Mar 04 21:24:29 2013 -0800
+++ b/user-interface-safety.html Mon Mar 25 14:04:44 2013 -0700
@@ -219,7 +219,7 @@
<p>A <dfn id="embedding-source-list">embedding source list</dfn> follows the ABNF and parsing rules defined for <a href="http://www.w3.org/TR/CSP/#source-list">source-list</a> (see [[!CSP]] section 3.22) with the following new productions:
-<pre>embedding-keyword-source = "'self'" / "'top-only'" / "'deny'"
+<pre>embedding-keyword-source = "'self'" / "'deny'"
embedding-source-expression = host-source / embedding-keyword-source
embedding-source-list = *WSP [ embedding-source-expression *( 1*WSP embedding-source-expression ) *WSP ]
</pre>
@@ -254,11 +254,9 @@
<p>If the directive-value contains the embedding-keyword-source <code>'self'</code>, <strong>ancestors</strong> are in the same origin as the protected resource.</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 the <a href="#security-considerations">Security Considerations</a>.</p>
<section id="multiple-host-source-values" class=informative>
<h4>Multiple Host Source Values</h4>
-<p class="issue" title="Inline Security Considerations?">Does this belong here or in a policy author security considerations section?</p>
<p>Multiple <code>host-source</code> values are allowed primarily to enable scenarios involving embedded application compoments that are multiple levels below the top-level browsing context.</p>
@@ -551,6 +549,110 @@
makePayment();
};</pre>
</section></section>
+
+
+<section>
+<h2>Script Interfaces</h2>
+
+<p class="issue" title="Pending CSP 1.1 Details">Is expressing these in terms of "partial" interfaces and dictionaries or as new types that extend the basic CSP 1.1 types the correct way to do this?</p>
+
+<p>If associated with a Content Security Policy 1.1 or later implementation, the User Interface Security Directives include
+the following script interfaces:</p>
+
+<section>
+ <h4><code>SecurityPolicyViolationEvent</code> Events</h4>
+
+ <dl title="[Constructor(DOMString type, optional UISecurityPolicyViolationEventInit eventInitDict)] partial interface SecurityPolicyViolationEvent : Event" class="idl">
+ <dt>readonly attribute DOMString blockedEventType</dt>
+ <dd>Refer to the <a href="#report-uri"><code>blocked-event-type</code></a> property of violation reports for a description of this property.</dd>
+
+ <dt>readonly attribute bool touchEvent</dt>
+ <dd>Refer to the <a href="#report-uri"><code>touch-event</code></a> property of violation reports for a description of htis property.</dd>
+
+ <dt>readonly attribute DOMString pointerType</dt>
+ <dd>Refer to the <a href="#report-uri"><code>pointer-type</code></a> property of violation reports for a description of this property.</dd>
+
+ <dt>readonly attribute long pointerHeight</dt>
+ <dd>Refer to the <a href="#report-uri"><code>pointer-height</code></a> property of violation reports for a description of this property.</dd>
+
+ <dt>readonly attribute long pointerWidth</dt>
+ <dd>Refer to the <a href="#report-uri"><code>pointer-width</code></a> property of violation reports for a description of this property.</dd>
+
+ <dt>readonly attribute long deviceHeight</dt>
+ <dd>Refer to the <a href="#report-uri"><code>device-height</code></a> property of violation reports for a description of this property.</dd>
+
+ <dt>readonly attribute long deviceWidth</dt>
+ <dd>Refer to the <a href="#report-uri"><code>device-width</code></a> property of violation reports for a description of this property.</dd>
+
+ <dt>readonly attribute long blockedEventClientX</dt>
+ <dd>Refer to the <a href="#report-uri"><code>blocked-event-client-x</code></a> property of violation reports for a description of this property.</dd>
+
+ <dt>readonly attribute long blockedEventClientY</dt>
+ <dd>Refer to the <a href="#report-uri"><code>blocked-event-client-y</code></a> property of violation reports for a description of this property.</dd>
+
+ <dt>readonly attribute DOMString blockedTargetID</dt>
+ <dd>Refer to the <a href="#report-uri"><code>blocked-target-id</code></a> property of violation reports for a description of this property.</dd>
+
+ <dt>readonly attribute DOMString blockedTargetXPath</dt>
+ <dd>Refer to the <a href="#report-uri"><code>blocked-target-xpath</code></a> property of violation reports for a description of this property.</dd>
+ </dl>
+
+ <dl title="partial dictionary SecurityPolicyViolationEventInit" class="idl">
+ <dt>DOMString blockedEventType</dt>
+ <dd>Refer to the <a href="#report-uri"><code>document-uri</code></a> property of violation reports for a description of this property.</dd>
+
+ <dt>bool touchEvent</dt>
+ <dd>Refer to the <a href="#report-uri"><code>touch-event</code></a> property of violation reports for a description of htis property.</dd>
+
+ <dt>DOMString pointerType</dt>
+ <dd>Refer to the <a href="#report-uri"><code>pointer-type</code></a> property of violation reports for a description of this property.</dd>
+
+ <dt>long pointerHeight</dt>
+ <dd>Refer to the <a href="#report-uri"><code>pointer-height</code></a> property of violation reports for a description of this property.</dd>
+
+ <dt>long pointerWidth</dt>
+ <dd>Refer to the <a href="#report-uri"><code>pointer-width</code></a> property of violation reports for a description of this property.</dd>
+
+ <dt>long deviceHeight</dt>
+ <dd>Refer to the <a href="#report-uri"><code>device-height</code></a> property of violation reports for a description of this property.</dd>
+
+ <dt>long deviceWidth</dt>
+ <dd>Refer to the <a href="#report-uri"><code>device-width</code></a> property of violation reports for a description of this property.</dd>
+
+ <dt>long blockedEventClientX</dt>
+ <dd>Refer to the <a href="#report-uri"><code>blocked-event-client-x</code></a> property of violation reports for a description of this property.</dd>
+
+ <dt>long blockedEventClientY</dt>
+ <dd>Refer to the <a href="#report-uri"><code>blocked-event-client-y</code></a> property of violation reports for a description of this property.</dd>
+
+ <dt>DOMString blockedTargetID</dt>
+ <dd>Refer to the <a href="#report-uri"><code>blocked-target-id</code></a> property of violation reports for a description of this property.</dd>
+
+ <dt>DOMString blockedTargetXPath</dt>
+ <dd>Refer to the <a href="#report-uri"><code>blocked-target-xpath</code></a> property of violation reports for a description of this property.</dd>
+ </dl>
+ </section>
+ <section>
+ <h4>SecurityPolicy</h4>
+
+ <p>Let the <dfn>active CSP policies</dfn> be the set of CSP policies
+ the user agent is currently enforcing for the associated
+ document.</p>
+
+ <dl title="partial interface Security Policy" class="idl">
+ <dt>readonly attribute bool inputProtection</dt>
+ <dd>A boolean representing <code>or</code> of whether
+ the <code>input-protection</code> directive is present or implied in
+ each of the <a href="#dfn-active-csp-policies">active CSP
+ policies</a>.</dd>
+
+ </dl>
+ </section>
+
+</section>
+</section>
+</section>
+
<section id="heuristic" class=informative>
<h2>Input Protection Heuristic</h2>
<section>
@@ -632,12 +734,6 @@
If in report-only mode, set the <code>unsafe</code> property of the event been handled to <code>true</code> and let the event processing continue. Otherwise, prevent the event from reaching its target. Create and send a violation report if a valid report-uri has been specified.
</li>
</ol>
-</section>
-</section>
-<section>
-<h2>Script and META Tag Interfaces</h2>
-
-<p class="issue" title="Pending CSP 1.1 Details">Need to define forward-compatible language here for 1.1 updates.</p>
</section>
<section>
@@ -716,20 +812,15 @@
}
}</pre>
</section></section>
-<section id="security-considerations">
+<section id="security-considerations" class=informative>
<h2>Security Considerations</h2>
-<p>The <code>'top-only'</code> keword with the <code>frame-options</code> directive is provided for compatible behavior with the X-Frame-Options header, but it may allow attacks to be mounted if a trusted context embeds an untrusted context, because that untrusted context may itself then re-embed a resource from the same origin as the trusted context.</p>
-<p>
-For example, if a resource X at origin A allows untrusted content Y from origin B to be displayed in an iframe, Y may itself create another iframe embedding resource Z from origin A.</p>
-<p>
-A <code>frame-options</code> policy check applied to Z with a value of <code>'self' 'top-only'</code> would succeed if X was the topmost frame, but this would still allow the untrusted content Y to attack Z. This attack is most likely in the case when the sandbox attribute of an iframe is used to contain untrusted context. Such sandboxed content could still mount clickjacking attacks on content in the parent origin with <code>'top-only'</code>. Checking all <strong>ancestors</strong> would prevent this attack.</p>
<p><code>frame-options</code> provides deterministic protections within a single browsing window, but may not provide full protection in environments where multiple browser windows may overlap and be programmatically 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>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 heuristic 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>
-</section><section>
+</section><section class=informative>
<h2>Implementation Considerations</h2>
<p>The policy and intent of the user always takes precedence over the policy
@@ -769,19 +860,24 @@
potential infereference from <a href=#accessibility>accessibility technologies</a></p>
<p>While this document describes a mechanism for resource authors to opt-in to
-User Interface Security protections, user agents MAY choose to opt-in all resources
+User Interface Security protections, user agents MAY choose to opt-in resources
to <code>input-protection</code> by default, or provide users with an option
-to enable such protections for all resources.</p>
+to manually enable such protections.</p>
-<p>In support of enabling default protection, user agents MAY, with appropriate
+<p>If a user agent or user chooses to apply input protection in the absence of
+an explicit directive, violations SHOULD NOT cause a violation report to be
+generated, even if the resource supplied a Content Security Policy with a
+<code>report-uri.</code></p>
+
+<!--<p>In support of enabling default protection, user agents MAY, with appropriate
user consent and privacy protections, gather large-scale data on when the
heuristic would have been triggered, if it had been enabled, for various values
of the configurable hint parameters. Such data would allow the user agent to
determine what default settings can provide broad protection with an acceptable
rate of false positives, and perhaps to build a compatibility opt-out list of
-sites or resources to further reduce the false positive rate.</p>
+sites or resources to further reduce the false positive rate.</p>-->
-<section id="accessibility">
+<section id="accessibility" class=informative>
<h3>Accessibility Technologies</h3>
<p>Certain classes of accessibility technologies such as
screen readers will provide strong defenses against many classes
@@ -816,7 +912,7 @@
</section>
-</section><section>
+</section><section class=informative>
<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 measures in the application might include requiring completion of a CAPTCHA [[CAPTCHA-Wikipedia]] or responding to an out-of-band confirmation when the UI Security 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 Security heuristics. To be able to do this effectively, it is likely necessary 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>