Re: Notes on implementing non-local URI references and resource documents

Hello Boris,

thanks for the great feedback, some comments inline.

On Mon, 13 Oct 2008 18:24:22 +0200, Boris Zbarsky <bzbarsky@mit.edu> wrote:

>
> Here are some notes on my experience with implementing non-local URI
> references and resource documents (as defined in SVG 1.1 section 5.3.1
> [1]).  There are some lose ends remaining that require coordination with
> the working group and other vendors, and I would be very interested in
> hearing the working group's position on those issues.
>
> 1) Nothing in the specification seems to define what sorts of files can
> be used as the targets of non-local references.  In particular, it's not
> clear whether the targeted files must be image/svg+xml or whether
> they're allowed to be application/xml, say.  In the absence of normative
> requirements here, what Gecko implements is that any time the non-local
> reference points to an entity that we would parse with the XML parser we
> go ahead and parse it and create a DOM (modulo next bullet point).  The
> entity being referenced can thus be image/svg+xml, text/xml,
> application/xml, application/xhtml+xml, etc, etc.

Opera also allows xml formats for references of this kind.

> 2) There is no indication in the specification of what should happen
> when the HTTP response for a non-local reference URI is a 404 with an
> image/svg+xml (or other XML type) entity body.  Gecko's implementation
> treats this (and in fact any HTTP response that makes it out of the HTTP
> implementation with a status code that is not 2xx) as equivalent to a
> non-XML response.

In Tiny 1.2 it's defined to be an 'invalid IRI', and the handling of such IRI:s are defined per element. Usually it means the element that had the reference isn't rendered.

> 3) There is no indication in the specification that resource documents
> (which are not thus named anywhere that I can find) are to only be
> loaded once per primary document.  I assumed that this is the desired
> behavior based on SVG Tiny 1.2 2008-09-15 draft, section 14.1.6 [2].

Are you referring to[7]:
"The conceptual model is that each resource document is loaded only once; if the same resource document is referenced multiple times directly or indirectly by the same primary document, that resource document is only retrieved and processed one time."

This might need some more work, since I don't think this is fully accurate for e.g <animation> elements since they are supposed to be full independent documents. It depends on what "processed" means in this context however. For example if one had two <animation> elements referencing the same IRI then I would expect these to produce two independent documents that both acted as if they were a top-level document, wrt script processing etc.

> 4) There is no indication in the specification as to what size should be
> used for the canvas of the resource documents. Perhaps this never
> affects rendering and thus doesn't matter; I can't tell for sure that
> this is the case, especially where foreignObject is involved.  Gecko
> currently sets the canvas size to 0x0.

Do you while loading and processing the resource document, or when rendering the resource document as part of the main document? The svg spec should define what viewport to use for the latter case, or in some cases there may not be one (e.g for some <use> constructs).

> 5) To reduce attack surface, Gecko does not execute scripts in resource
> documents at the present time.  We're not convinced that we want to
> change this at any point in the foreseeable future.  We do plan to
> implement non-Turing-complete declarative animation in resource documents.

It probably makes sense to apply some form of access control in a future spec, similar to what's being done to <iframe> elements in HTML5 with @sandbox.

> 6) To reduce the risk of inadvertent information leakage, Gecko
> currently does not allow linking to resource documents across origins.
> The security check performed is the same as that for XMLHttpRequest (so
> does not take document.domain into account).  We do plan to make this
> check subject to Access-Control [3] to allow a server to export SVG
> resource documents for use by other sites.

Is this information leakage any different from someone using e.g <iframe>?

Opera currently allows cross-domain references in svg, but applies restrictions on trying to access the DOM of those documents, similar to how <iframe> is handled.

> 7) It's not clear to me from section 5.6 [4] whether event handler
> attributes on elements in a subtree pointed to by a <use> should be
> cloned onto the instance tree, but it's certainly what Gecko does right
> now. 

Sort of, but there is one crucial difference:

"If event attributes are assigned to referenced elements, then the actual target for the event will be the SVGElementInstance object within the "instance tree" corresponding to the given referenced element."

Have SVGElementInstance:s been implemented in gecko?

> It's further unclear which script context said event handlers
> should execute in; currently in Gecko they execute in the context of the
> primary document. 

I think the SVGElementInstance:s are in the primary document, while the actual referenced elements are in a resource document. Opera doesn't allow access to the actual nodes if the resource and primary documents have different domains.

> This means that a <use> can effectively import
> scripts from the referenced document into the primary document scope.

Hmm...do you mean for the case when a <use> references a tree that contains a <script>? I don't think scripts are imported to the primary document by use, they're executed only in the document context that they're in.

> While we're enforcing same-origin restrictions this is not a problem,
> but when we move to Access-Control we will continue to enforce a hard
> same-origin restriction on <use> to mitigate this attack scenario.

That depends on whether <use> imports <script> into the primary document or not, no?

> 8) Once we move to Access-Control, it's not clear how the "only load it
> once" behavior should work, since it becomes entirely possible for a
> primary document at origin A to load a resource at origin B and a
> resource at origin C, with the resource at B also loading the resource
> at C, while the server at C allows the load from A but not from B.  We
> would therefore like to coordinate our implementation of Access-Control
> here with other vendors and with the working group.

Yes, this is something we should continue discussing.

> The SVG 1.2 Tiny 2008-09-15 draft [5] addresses issue 3 above, but the
> other issues I list seem to still be present.  Furthermore, it
> introduces a table of restrictions [6] some of which do not make much
> sense to me as general restrictions for desktop browsers. 

Some of the restrictions are there to subset what was already allowed in SVG 1.1.

> In
> particular, I see no need to restrict externally referenced <use> or
> <animation> in subtrees referenced by <use>.  I see no sane way to
> enforce "the referenced fragment must not contain scripting". 

Agreed, the "must not contain scripting" thing is bogus, I've read that more as an authoring requirement rather than as an UA requirement.

> I see no reason to forbid external references to fill and stroke.

For an SVG 1.1 UA of course not, since it was already allowed.

> Looking forward to some spec clarifications and a discussion about the
> security issues,

Yes, we'll try to address this in more detail when SVG Tiny 1.2 is done.

Cheers
/Erik

> [1]
> http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#uriReferenceDefinition
> [2]
> http://www.w3.org/TR/2008/WD-SVGMobile12-20080915/linking.html#externalReferences
> [3] http://www.w3.org/TR/access-control/
> [4]  http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#UseElement
> [5] http://www.w3.org/TR/2008/WD-SVGMobile12-20080915/
> [6]
> http://www.w3.org/TR/2008/WD-SVGMobile12-20080915/linking.html#ReferenceRestrictions

[7] http://dev.w3.org/SVG/profiles/1.2T/publish/linking.html#externalReferences

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Tuesday, 14 October 2008 07:26:11 UTC