ISSUE-2124 (external refs imp-notes): Notes on implementing non-local URI references and resource documents [SVG Core 2.0]

ISSUE-2124 (external refs imp-notes): Notes on implementing non-local URI references and resource documents [SVG Core 2.0]

http://www.w3.org/Graphics/SVG/WG/track/issues/2124

Raised by: Doug Schepers
On product: SVG Core 2.0

Boris Zbarsky
<http://lists.w3.org/Archives/Public/www-svg/2008Oct/0114.html>:
[[
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.

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.

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].

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.

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.

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.

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.  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.  This means that a <use> can effectively import 
scripts from the referenced document into the primary document scope. 
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.

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.

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.  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".  I see no 
reason to forbid external references to fill and stroke.

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

[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

]]

Received on Monday, 13 October 2008 16:48:21 UTC