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 <[email protected]>
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 <[email protected]>
