[whatwg] Fetch SVG images with No CORS tainted cross-origin

Dirk Schulze dschulze at adobe.com
Fri Sep 13 01:27:37 PDT 2013


If I understand HTML <img> fetching and the fetch spec right. The default behavior on image fetching is No CORS with the mode tainted cross-origin.

For the example: <img src="image.svg">

and image.svg:

	<image xlink:href="http://otherdomain.com/image.svg">

In this case the image.svg would be fetched with basic fetch and tainted cross-origin. But the image inside this image would also be loaded as basic fetch tainted cross origin. Right?

For various reasons (as described in Mozilla bug 628747[1]). We do not want to have image load further _external_ resources.

WebKit, Blink and Gecko allow dataURLs and Gecko allows blobs as resources. I couldn't find a specification for that in the Fetch specification. WebKit and Blink call that "single security origin". If the SVG was fetched as an image resource, it is not allowed to fetch other resources with the described exception above.

So, I wonder how that behavior could be described. Sadly it is not always the same behavior. If the SVG image is referenced by an <object>, <embed> or <iframe>, it does not count as "image" anymore but as a document and it can fetch resources again. For my use case of <mask> and <filter> the SVG WG resolved to have the same fetching mechanisms and restrictions as for SVG as "images".

To summarize. We have two kind of possibilities of fetching in SVG:

SVG with "single security origin": The SVG is not allowed to fetch any external resources. References in the same document and dataURLs, blobs are allowed.
SVG "as document": Allowed to fetch resources with No CORS - But: possibly CORS enabled  depending on the referencing element (<object>, <embed> or <iframe>).

Would it be possible to define it that way? If the former named elements, then use the fetching mechanism defined by these elements. Otherwise use "single security origin"? Could Fetch define "single security origin"?


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=628747

More information about the whatwg mailing list