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

[Dirk Schulze]

On Sep 13, 2013, at 10:43 AM, Anne van Kesteren <annevk at annevk.nl> wrote:

> On Fri, Sep 13, 2013 at 9:27 AM, Dirk Schulze <dschulze at adobe.com> wrote:
>> So, I wonder how that behavior could be described.
> 
> I think you'd have a mode switch and maybe a wrapper for Fetch that
> only calls it for data and blob URLs. It seems like you don't really
> want to invoke Fetch at all for SVG as image.

If Fetch is not just fetching external (as not in the current document) then we still need it for SVG. References within the same document must still work.

> Do scripts even execute
> in that context? How do you get blob URLs?

In WebKit and Blink you can't execute any script anywhere in an SVG document. I am not sure about Gecko but this is the feedback I got. Maybe someone from Mozilla can answer this. 

> 
> I suppose we could have a mode for that in Fetch too, but it seems
> really SVG specific so I'm not sure that's warranted.
> 

Yes, it is quite SVG specific. I am fine with just dealing with it in SVG as long as possible. And I think it is not possible without changing the fetching on the requesters like <img>. (This is the case for CSS as well btw, which can reference SVG images - different topic.)

> 
>> 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"?
> 
> This sentence doesn't make sense. At least the "otherwise" clause in
> it. I'm not sure "single security origin" makes sense either as I
> think you don't want to do any fetching whatsoever. If something does
> a fetch, you want to return network error immediately and don't even
> attempt to make a connection as that could leak information. So SVG
> resources should have a "locked down flag" and when it's set "SVG
> fetch" or whatever you end up calling the wrapper will return "network
> error" rather than invoking "fetch" unless the URL's scheme is about,
> blob, or data I suppose.

So first, for the first case (before "otherwise") there is nothing that needs to be changed. Fetch and HTML already cover that.

The second case would indeed need a flag like "locked down flag". This would just allow fetching of resources in the same document, dataURLs (with lock down for the content of dataURL) and possibly blob URLs.

The requester needs to set this "lock down flag". So ideally it would be specified by the Fetch specification. Legacy fetching (used for image fetching) would set this flag by default. In this case no other specification but Fetch and CSS would need to change.

Greetings,
Dirk


> 
> 
> -- 
> http://annevankesteren.nl/