W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2013

Re: Fetching contexts

From: Adam Barth <w3c@adambarth.com>
Date: Sun, 23 Jun 2013 10:46:56 -0700
Message-ID: <CAJE5ia-DGHt9Aq9+QFjz2EE_vZABwRJ0H6NB6gQePa943+j=Ow@mail.gmail.com>
To: Dirk Schulze <dschulze@adobe.com>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, Anne van Kesteren <annevk@annevk.nl>, Gordon Hemsley <me@gphemsley.org>, WebAppSec WG <public-webappsec@w3.org>
On Sun, Jun 23, 2013 at 10:19 AM, Dirk Schulze <dschulze@adobe.com> wrote:
> On Jun 23, 2013, at 9:52 AM, Adam Barth <w3c@adambarth.com> wrote:
>> On Sun, Jun 23, 2013 at 8:17 AM, Dirk Schulze <dschulze@adobe.com> wrote:
>>> On Jun 23, 2013, at 5:57 AM, Boris Zbarsky <bzbarsky@MIT.EDU> wrote:
>>>> On 6/23/13 1:03 AM, Adam Barth wrote:
>>>>> It depends on how you load SVG.  If you use <img src="foo.svg">, then
>>>>> it's covered by the img-src directive.  If you use <iframe
>>>>> src="foo.svg">, then it's frame-src.  If you use <object
>>>>> data="foo.svg">, then it's object-src.
>>>> We're talking specifically about SVG resource documents, not any of
>>>> those.  So filter(url) and company.
>> Oh, sorry.  I misunderstood the context.
>>> I think it makes absolutely sense to to use style-src here. Of course we need to define the fetching for these resources. The SVG WG decided that the SVG Integration spec will take care of it. A lot of work is still needed on this spec and help / suggestions are more than welcome.
>> It looks like WebKit and Blink treat SVGDocumentResource (which I
>> assume is our implementation name for SVG resource documents) as
>> img-src.  We could change that potentially, of course, but that's one
>> data point.
> WebKit/Blink don't match SVGDocumentResource to one of the ways of fetching yet. It depends who creates/references the resource.

I'm not sure what you mean by the above, but, concretely, the
SVGDocumentResource case in CachedResourceLoader::canRequest calls


That means SVGDocumentResource is controlled by img-src, at least in
this implementation.

Received on Sunday, 23 June 2013 17:47:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:33 UTC