Request destination for SVG documents

[yoavweiss]

It's unclear what destination value should be used for SVG documents and different browsers seem to be doing different things, at least when it comes to CSP.

https://svg-discrimination.glitch.me/csp.html is loading fine in Chrome and Safari (as long as img-src: 'self' is there), but the SVG is blocked in Firefox.

At the same time, because SVG document resources are internally represented differently than images in Chromium, an as value of "image" for preloads is a mismatch for SVG documents.

Looking at Fetching the document over in SVG-land doesn't mention destination at all.

We should decide what the destination be, and then align spec and implementations on it.
My personal vote would be for a brand new destination (e.g. "svg" or "svg-document"), to make it easier to explain to developers which CSP or as values control these loads.

[yoavweiss]

Another point to consider: the SVG document, when loaded using a <use> tag, doesn't seem to be able to run script, so maybe an "image" destination is the right call (and the Chromium implementation would have to somehow deal with that SVG documents are images too).

/cc @yutakahirano @mikewest

[annevk]

It would be interesting to know why they are a separate type in Chromium.

@ckerschb do you know what Firefox does here and why?

[mikewest]

I guess I don't know why we'd want them to be distinct destinations. Why distinguish it as an SVG? image seems fine. Likewise, the CSP behavior seems like a bug in Firefox: img-src seems like it should control SVGs just like <img>.

[yoavweiss]

I thought we may want another destination when I wasn't sure if these SVGs can run script, but looks like they can't. So, I'm fine with aligning them as an "image" destination and aligning Chromium's implementation to deal with that when it comes to preload. (I'm not sure if ResourceType::kSVGDocument is something we can get rid of, but that would be the cleanest...)

[annevk]

I think we should figure out why ResourceType::kSVGDocument is a thing first. If it only exists for non-web consumers, I agree we should go with image, but otherwise...

[Rob--W]

Coincidentally I recently looked into why svg subresource requests (e.g. in <use href>) are classified as "other" rather than "image" in Firefox, at https://bugzilla.mozilla.org/show_bug.cgi?id=1624471#c5. I'm not authorative here, but I would think that "image" makes more sense in this case than "other" or "document".

[yoavweiss]

Here are Chromium's code search results for kSVGDocument.
From brief scanning I think it's mostly impacting a couple of error messages, but not much more than that...

It also seems Chromium is explicitly translating it to an "image" destination

[evilpie]

I am changing Firefox (bug 1773976) to treat CSS filter: url("foo.svg#bar") and SVG <use> as "image", primarily because we were running into web-compatibility issues with CSP img-src not applying to these SVG loads.

Could this be codified? I think there is currently no WPT for this behavior.

[yoavweiss]

^^ @noamr

[longsonr]

Another point to consider: the SVG document, when loaded using a <use> tag, doesn't seem to be able to run script, so maybe an "image" destination is the right call (and the Chromium implementation would have to somehow deal with that SVG documents are images too).

/cc @yutakahirano @mikewest

While neither use, nor image will run script within <script> tags.

• use will run javascript event handlers but image will not.
• use can load external references e.g. other use elements but image cannot load any external references.
• use must be same domain as the loading content but image need not be.