ACTION-570: Dynamic content

Trying to capture the points about dynamic content...  Please suggest  
improvements to both wording and content.

> 8.7 Dynamic content might change security properties


> This specification is expressed in terms of the fundamentally static  
> indicators of existing browser security user interfaces.

> These indicators tend to assume that the security properties "of a  
> page" will not change in a significant way once it has finished  
> loading (whatever that might mean in detail). Strictly speaking,  
> this assumption is flawed:  Dynamic pages can load scripts and data  
> at any time and from any source (using techniques like the insertion  
> of script tags into the DOM at run time); the effect may very well  
> be that a page that was retrieved from a secure Web site with an  
> Augmented Assurance certificate could at some point be under the  
> control of scripts that are retrieved insecurely.   This  
> specification does not prescribe any specific user interaction in  
> this kind of situation.

> There must be some kind of way out of here, said the joker to the  
> thief.


> This specification also does not cover user interactions for cross- 
> site XMLHttpRequest invocations that encounter TLS related errors.   
> In the same-origin case, the XMLHttpRequest specification  
> specifically mandates that an error be returned to the web  
> application if TLS negotiation fails for any reason.  This behavior  
> is reasonable, since the same-origin nature of the request implies  
> that the user agent has retrieved the surrounding page from a URI  
> reference with the same scheme (http, https) and domain name;  
> therefore, whatever decisions were made at the time the page was  
> loaded can be leveraged without further user interaction, and the  
> web application itself will be in best position to enable recovery  
> in those edge cases where the negotiation fails.

> However, in situations in which the target of the request does not  
> fulfill the same-origin constraint, but has authorized the request  
> using a mechanism such as [CORS], there may be no recent interaction  
> that could be leveraged in the same way.  This situation, too, is  
> not handled in a well-defined way.

(CORS is the new name of the "access-control" specification.  Writing  
this, I wonder whether the right thing to do is to actually start a  
conversation with webapps about this point.)

--
Thomas Roessler, W3C  <tlr@w3.org>