Re: ACTION-315: Widget URI scheme thoughts

As a follow-up from trashing this through with Josh, the one open  
issue is navigation of iframes:  Assume a widget frames a resource  
that is retrieved from the Web.  Would navigation of that iframe have  
to go through the manifest based indirection or not?


The sense in our conversation was that it should *not* go through that  
indirection, but that that would probably have the potential to cause  
some surprises.

The basic behavior would be that the manifest is only used for  
resolution of URI references that have the widget instance's unique  
origin; anything else would bypass the manifest mechanism.


The other point would be HTTP POST (from forms): The manifest  
mechanism is right now scoped to the *retrieval* of resources.

Form posts, XMLHttpRequest and other mechanisms are out of scope,  
therefore, standard HTML behavior (e.g., going out on the network)  
would apply.  The synthetic origin approach seems to lead to the  
intended results in terms of security policy as far as the discussion  
between Josh and myself was concerned; I understand that Josh has some  
ideas about writing POST-like handlers in JavaScript, but that would  
be another extension.

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







On 26 Feb 2009, at 13:23, Thomas Roessler wrote:

> Getting back to the URI scheme discussion, here's a strawman  
> proposal that's inspired by the Widget case, where scripting and  
> navigation add a few more complexities.  I'll be interested in  
> seeing Marcos, Arve and Josh shoot this one down. :)
>
> Specifically, we need to say:
>
> - how to dereference a URI reference that occurs within a widget  
> resource, and for which the identified resource is included within  
> the widget package
>
> - what the base URI property is for any DOM created from a resource  
> within a widget package
>
> - what the origin is for any DOM created by the Widget. (e.g., for  
> cross-frame scripting)
>
> The critically important point here is that we separate the Origin  
> consideration from the identification and retrieval of resources in  
> the package.
>
> Design assumptions:
>
> - we can synthesize origins to be globally unique identifiers (as  
> HTML5 does)
> - we have unique identifiers resources within the package.  
> Typically, these will look filesystem path like, but for the  
> purposes of this proposal, they're opaque identifiers, and totally  
> depend on the package format.
>
> Proposal:
>
> 1. The manifest is turned into a generic indirection tool that can  
> aim inside the widget.  For each resource (identified by absolute  
> URI), the following properties are defined:
>
>  - Content-Type
>  - Parameters for said Content-Type
>  - identifier for the packaged file that includes a representation  
> of this resource
>
> E.g.:
>
>   <Resource Identifier="http://www.w3.org/">
>     <ContentInfo Type="text/html">
>       <Parameter Name="charset">iso-8859-1</Parameter>
>       <Parameter Name="foo">bar</Parameter>
>     </ContentInfo>
>     <Representation>/www.w3.org/Overview.html</Representation>
>   </Resource>
>
> Or:
>
>   <Resource Identifier="http://www.w3.org/">
>     <ContentInfo Type="text/html">
>       <Parameter Name="charset">utf-8</Parameter>
>       <Parameter Name="foo">bar</Parameter>
>     </ContentInfo>
>     <Representation>L3d3dy53My5vcmcvT3ZlcnZpZXcuaHRtbAo</ 
> Representation>
>   </Resource>
>
> Or:
>
>   <Resource Identifier="http://www.w3.org/">
>     <ContentInfo Type="text/html">
>        <Parameter Name="charset">windows-1251</Parameter>
>     </ContentInfo>
>     <Representation>\SITES\CONSORTIUM\ROOT</Representation>
>   </Resource>
>
> ;-)
>
> (As an aside, note that it might be important to have an extension  
> point for content type specific parameters here.)
>
> 2. When a widget is instantiated, a new globally unique identifier  
> is coined for that instance, at run time. Whenever a resource is  
> retrieved through the manifest indirection, this globally unique  
> identifier is used to construct the relevant origin, not the URI  
> that was used to identify the resource.  (This effectively turns  
> each widget instance into a trust domain of its own within HTML's  
> security model, but only includes those resources in that domain  
> that are packaged up.)
>
> 3. When a widget navigates to a resource, then the base URI is the  
> URI that was used to *identify* this resource.
>
>
> In the example above, that would mean that no matter what the  
> packaging format does, the base URI will be "http://www.w3.org/",  
> and relative URI references will be resolved relative to it.
>
> Note that this proposal would require:
>
> 1. Making the manifest mandatory.
> 2. Mild changes to the packaging spec (in particular, the start file  
> needs to be identified by absolute URI, e.g., htp://..., and through  
> the manifest mechanism, to give an initial base URI)
>
>
> It will be an important security consideration to note that the  
> manifest-driven resource retrieval MUST NOT leak outside the context  
> of the widget engine.
>
> Thoughts? Feedback?
> --
> Thomas Roessler, W3C  <tlr@w3.org>
>
>