--- a/user-interface-safety.html	Mon Nov 05 07:48:43 2012 -0500
+++ b/user-interface-safety.html	Wed Nov 07 12:36:34 2012 -0500
@@ -14,7 +14,7 @@
       var respecConfig = {
         // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
         // Member-SUBM
-        specStatus: "FPWD",
+        specStatus: "ED",
 
         // the specification's short name, as in http://www.w3.org/TR/short-name/
         shortName:  "User Interface Safety",
@@ -157,8 +157,10 @@
 
 <p>Existing anti-clickjacking measures including frame-busting
 [<cite><a class="bibref" rel="biblioentry" href="#bib-XXX">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>
+ codes and <code>X-Frame-Options</code> cannot be used to protect resources that
+are intended to be embedded by arbitrary origins, and  are insufficient to 
+defend against timing-based attacks involving multiple windows instead of multiple
+frames. </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 
@@ -769,27 +771,25 @@
 </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>
+<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.  Checking all <strong>ancestors</strong> would prevent this attack.</p>
 
-<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>
-
-<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 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><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>
 <h2>Implementation Considerations</h2>