W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2013

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

From: Anne van Kesteren <annevk@annevk.nl>
Date: Fri, 13 Sep 2013 09:43:25 +0100
Message-ID: <CADnb78iGxPOhS+V0xB441s=mJmYbcq8-E8fLy=fgJy3STgfjMA@mail.gmail.com>
To: Dirk Schulze <dschulze@adobe.com>
Cc: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>
On Fri, Sep 13, 2013 at 9:27 AM, Dirk Schulze <dschulze@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. Do scripts even execute
in that context? How do you get blob URLs?

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.


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


-- 
http://annevankesteren.nl/
Received on Friday, 13 September 2013 08:43:51 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:09 UTC