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

external refs imp-notes

Notes on implementing non-local URI references and resource documents

State:

RAISED

Product:

SVG 2

Raised by:

Doug Schepers

Opened on:

2008-10-13

Description:

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

]]

Related Actions Items:

No related actions

Related emails:

1. Agenda, June 03 2009 SVG WG telcon (from ed@opera.com on 2009-06-02)
2. Agenda May 27 2009 SVG WG telcon (from ed@opera.com on 2009-05-26)
3. Re: Notes on implementing non-local URI references and resource documents (ISSUE-2124) (from schepers@w3.org on 2008-10-13)
4. ISSUE-2124 (external refs imp-notes): Notes on implementing non-local URI references and resource documents [SVG Core 2.0] (from sysbot+tracker@w3.org on 2008-10-13)

Related notes:

No additional notes.

Display change log