Re: ACTION-570: Dynamic content

Do we need an explicit ref to the XHR spec? I think so. 

I would like to add the following to the second paragraph:
Businessman they drink my wine
Plow men dig my earth 

What would the conversation we start with web apps be, around CORS? Tell 
them we're logging the issue, that they own the problem, and that we're 
happy to consult? I'd be good with that. 


          Mez





From:
Thomas Roessler <tlr@w3.org>
To:
public-wsc-wg@w3.org (WSC WG public)
Date:
03/27/2009 10:58 AM
Subject:
ACTION-570: Dynamic content
Sent by:
public-wsc-wg-request@w3.org



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>