Intent to implement and ship: CORS in svg

759 views
Skip to first unread message

Erik Dahlström

unread,
Apr 29, 2015, 4:22:07 AM4/29/15
to blink-dev.chromium.org
Contact emails
e...@opera.com

Spec
https://svgwg.org/svg2-draft/struct.html#UseElementCrossoriginAttribute
https://svgwg.org/svg2-draft/script.html#ScriptElementCrossoriginAttribute
https://svgwg.org/svg2-draft/embedded.html#ImageElementCrossoriginAttribute


Summary
This change enables CORS in svg, and adds 'crossorigin' attributes,
following the same pattern as in html. For <use> elements the default is
"No CORS", meaning that both client and server needs to opt in for the
crossorigin fetch to succeed. For the <script> and <image> elements the
default is to allow crossorigin fetches since content would otherwise
break, however, it's possible to control the information transmitted with
the request by using the 'crossorigin' attribute.

The patch will not really change anything for <image> and <script>, apart
from exposing the 'crossorigin' attribute on the corresponding IDL
interfaces.

Note that since svg uses the (html) script and imageloaders internally,
partial support for the 'crossorigin' attribute in <script> and <image> is
already shipping (and probably has been for quite some time).


Motivation
Without this it's not possible to use crossorigin content in <use>
elements, which is sometimes desirable, see http://crbug.com/470601.

A fairly common pattern is reusing parts of an svg file with <use>
elements, and that is currently limited to same origin resources. With the
change it will become possible to serve a page from "a.com" that uses a
resource from "b.com", like this:

<svg>
<use xlink:href="https://b.com/some.svg#some-id" crossorigin="anonymous"
/>
</svg>

Note that the server "b.com" is also required to send a suitable
"Access-Control-Allow-Origin" header with the response, otherwise the
fetch will be blocked.

For the other elements the motivation is mostly to align with the html
<script> and <img> elements.


Compatibility Risk
The compatibility risk for existing svg content is low since this should
not affect such content that hasn't opted in via 'crossorigin' attributes,
but the changes in IDL interfaces may potentially cause issues (though
this is unlikely).

We may regret this change if SVG2 changes how the 'crossorigin' attribute
is exposed in the IDL, assuming people have started relying on the
behaviour we've already shipped. Note however that svg2 has added the
video and audio elements from html, which have the 'crossorigin'
attribute, and the IDL change matches what those elements expose.

There's general agreement in the SVG WG that svg should use CORS. Mozilla
expressed some concerns over CORS in <use> (since gecko shares resource
documents), but indicated that those concerns could hopefully be worked
out in SVG2.

WG discussion: http://www.w3.org/2015/04/23-svg-minutes.html#item03


Ongoing technical constraints
None.


Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?
Yes.


OWP launch tracking bug?
http://crbug.com/225863


Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5760616295825408


Requesting approval to ship?
Yes.


--
Erik Dahlstrom, Web Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group

Philip Rogers

unread,
Apr 29, 2015, 5:59:31 PM4/29/15
to Erik Dahlström, blink-dev.chromium.org
LGTM

TAMURA, Kent

unread,
Apr 29, 2015, 11:15:56 PM4/29/15
to Philip Rogers, Erik Dahlström, blink-dev.chromium.org
LGTM2.

--
TAMURA Kent
Software Engineer, Google


Dimitri Glazkov

unread,
Apr 29, 2015, 11:17:03 PM4/29/15
to TAMURA, Kent, Philip Rogers, Erik Dahlström, blink-dev.chromium.org
LGTM3.

Anne van Kesteren

unread,
Apr 30, 2015, 4:12:02 AM4/30/15
to Erik Dahlström, blink-dev.chromium.org
On Wed, Apr 29, 2015 at 10:21 AM, Erik Dahlström <e...@opera.com> wrote:
> This change enables CORS in svg, and adds 'crossorigin' attributes,
> following the same pattern as in html. For <use> elements the default is "No
> CORS", meaning that both client and server needs to opt in for the
> crossorigin fetch to succeed.

This doesn't make sense. What do you mean? From below it sounds like
you mean that the default mode for <use> is "same-origin", and that
you want to allow "cors".


> For the <script> and <image> elements the
> default is to allow crossorigin fetches since content would otherwise break,
> however, it's possible to control the information transmitted with the
> request by using the 'crossorigin' attribute.

This also doesn't make sense.


> The patch will not really change anything for <image> and <script>, apart
> from exposing the 'crossorigin' attribute on the corresponding IDL
> interfaces.

That seems bad. For <script> the feature that crossorigin provides is
better error handling. For <image> the feature it provides would be
reading the image data through <canvas>, though I'm not sure you can
draw an <image> at the moment.


> There's general agreement in the SVG WG that svg should use CORS. Mozilla
> expressed some concerns over CORS in <use> (since gecko shares resource
> documents), but indicated that those concerns could hopefully be worked out
> in SVG2.

It seems bad to me that SVG's processing model with regards to
fetching and security is still not defined in detail. At some point I
made an attempt with Dirk at defining the basic building blocks, but I
don't think much came of it:

https://etherpad.mozilla.org/fixing-svg-processing


--
https://annevankesteren.nl/

Justin Novosad

unread,
May 4, 2015, 1:21:38 PM5/4/15
to Erik Dahlström, blink-dev.chromium.org
Does the implementation of this feature imply implementing security origin checking for SVG foreignObject elements? I ask because currently the code in SVGImage::currentFrameHasSingleSecurityOrigin() conservatively returns 'false' if the SVG contains a foreignObject node, which is a longstanding bug that has implications for the tainting of canvases. See: crbug.com/294129 

Philip Jägenstedt

unread,
May 5, 2015, 7:58:13 AM5/5/15
to Anne van Kesteren, Erik Dahlström, blink-dev.chromium.org
This intent already has 3 LGTMs, but before proceeding to implement it would be nice to see Anne's concerns addressed.

Taking a step back, external <use> seems like a rather strange thing in general, cross-origin or not. I am pretty far removed from SVG, so do the people who work most in core/svg/ (including ed) think the complexity of this feature is worth it? Could external <use> come in the way of any future (but plausible) simplification of <use>?

Philip


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Erik Dahlström

unread,
May 5, 2015, 11:45:58 AM5/5/15
to Anne van Kesteren, Philip Jägenstedt, blink-dev.chromium.org
On Tue, 05 May 2015 13:58:03 +0200, Philip Jägenstedt <phi...@opera.com>
wrote:

> This intent already has 3 LGTMs, but before proceeding to implement it
> would be nice to see Anne's concerns addressed.

Technically the implementation is in codereview already, but fair enough.

> Taking a step back, external <use> seems like a rather strange thing in
> general, cross-origin or not.

On basis of what web developers seem to think is natural I'd disagree that
it's strange. External <use> has been a part of SVG since version 1.0 of
the spec, and I do think that was a deliberate choice to allow urls rather
than just id values.

> I am pretty far removed from SVG, so do the
> people who work most in core/svg/ (including ed) think the complexity of
> this feature is worth it?

I'd like to hear what others think here, since it seems that external
<use> is for the most part already implemented and shipped. This intent
doesn't really add much complexity on top of that.

> Could external <use> come in the way of any
> future (but plausible) simplification of <use>?

That's a pretty open question. What (plausible) simplifications did you
have in mind?

> Philip
>
> On Thu, Apr 30, 2015 at 10:11 AM, Anne van Kesteren <ann...@annevk.nl>
> wrote:
>
>> On Wed, Apr 29, 2015 at 10:21 AM, Erik Dahlström <e...@opera.com> wrote:
>> > This change enables CORS in svg, and adds 'crossorigin' attributes,
>> > following the same pattern as in html. For <use> elements the default
>> is
>> "No
>> > CORS", meaning that both client and server needs to opt in for the
>> > crossorigin fetch to succeed.
>>
>> This doesn't make sense. What do you mean? From below it sounds like
>> you mean that the default mode for <use> is "same-origin", and that
>> you want to allow "cors".

That is indeed what I meant.

>> > For the <script> and <image> elements the
>> > default is to allow crossorigin fetches since content would otherwise
>> break,
>> > however, it's possible to control the information transmitted with the
>> > request by using the 'crossorigin' attribute.
>>
>> This also doesn't make sense.

Please be more specific.

The intent is to share behavior with how the 'crossorigin' attribute
applies to the corresponding html elements, script and img respectively.
The code is effectively already shared internally.

>> > The patch will not really change anything for <image> and <script>,
>> apart
>> > from exposing the 'crossorigin' attribute on the corresponding IDL
>> > interfaces.
>>
>> That seems bad. For <script> the feature that crossorigin provides is
>> better error handling.

Ok, and that's a bad thing for <svg:script> how exactly?

>> For <image> the feature it provides would be
>> reading the image data through <canvas>, though I'm not sure you can
>> draw an <image> at the moment.

I'm not sure why exposing an attribute that is already used internally
when fetching does any harm.

>> > There's general agreement in the SVG WG that svg should use CORS.
>> Mozilla
>> > expressed some concerns over CORS in <use> (since gecko shares
>> resource
>> > documents), but indicated that those concerns could hopefully be
>> worked
>> out
>> > in SVG2.
>>
>> It seems bad to me that SVG's processing model with regards to
>> fetching and security is still not defined in detail. At some point I
>> made an attempt with Dirk at defining the basic building blocks, but I
>> don't think much came of it:
>>
>> https://etherpad.mozilla.org/fixing-svg-processing

That document looks a little out of date, a number of these elements have
already been dropped from the svg2 spec. And I don't know what the
document tested, since there are no links to any tests, just claims about
what browsers did at some point in time.

I'd agree that clearly defined processing models for <anything> is a
generally good thing. How detailed such a model would need to be for svg I
think is up to the WG to decide, with your input ideally. That discussion
seems more suited for www...@w3.org though.

Cheers

Anne van Kesteren

unread,
May 5, 2015, 12:42:29 PM5/5/15
to Erik Dahlström, Philip Jägenstedt, blink-dev.chromium.org
On Tue, May 5, 2015 at 5:45 PM, Erik Dahlström <e...@opera.com> wrote:
> On basis of what web developers seem to think is natural I'd disagree that
> it's strange. External <use> has been a part of SVG since version 1.0 of the
> spec, and I do think that was a deliberate choice to allow urls rather than
> just id values.

However, whether CORS makes sense depends on the processing model for
<use> which I believe is still unclear...


> That is indeed what I meant.

Note that "no-cors" is something completely different.


>>>> The patch will not really change anything for <image> and <script>,
>>>> apart
>>>> from exposing the 'crossorigin' attribute on the corresponding IDL
>>>> interfaces.
>>>
>>> That seems bad. For <script> the feature that crossorigin provides is
>>> better error handling.
>
> Ok, and that's a bad thing for <svg:script> how exactly?

It's bad if exposing the attribute doesn't change anything. But it
seems that you now state that it does in fact have an effect. (The
correct one.)


--
https://annevankesteren.nl/

Philip Jägenstedt

unread,
May 6, 2015, 4:46:17 AM5/6/15
to Erik Dahlström, Anne van Kesteren, blink-dev.chromium.org, Fredrik Söderquist, Dan Sinclair, Philip Rogers, kou...@chromium.org
On Tue, May 5, 2015 at 5:45 PM, Erik Dahlström <e...@opera.com> wrote:
> On Tue, 05 May 2015 13:58:03 +0200, Philip Jägenstedt <phi...@opera.com>
> wrote:
>
>> This intent already has 3 LGTMs, but before proceeding to implement it
>> would be nice to see Anne's concerns addressed.
>
>
> Technically the implementation is in codereview already, but fair enough.
>
>> Taking a step back, external <use> seems like a rather strange thing in
>> general, cross-origin or not.
>
>
> On basis of what web developers seem to think is natural I'd disagree that
> it's strange. External <use> has been a part of SVG since version 1.0 of the
> spec, and I do think that was a deliberate choice to allow urls rather than
> just id values.
>
>> I am pretty far removed from SVG, so do the
>> people who work most in core/svg/ (including ed) think the complexity of
>> this feature is worth it?
>
>
> I'd like to hear what others think here, since it seems that external <use>
> is for the most part already implemented and shipped. This intent doesn't
> really add much complexity on top of that.

Yep, I understand that this intent won't amount to any added complexity and if those who work a lot in SVG think external <use> is good, that's fine. git log says f...@opera.com, dsin...@chromium.org, you, kou...@chromium.org and p...@chromium.org are the top contributors recently, so CC to see if anyone has feedback.


>> Could external <use> come in the way of any
>> future (but plausible) simplification of <use>?
>
>
> That's a pretty open question. What (plausible) simplifications did you have
> in mind?

Without use counters I can only guess what's plausible, but beyond external <use>, I wonder if there's any way to change <use> to be a parse-time thing only, i.e. that the resulting DOM has no SVGUseElement, just a copy of the tree it referred to. Whether or not that is feasible depends entirely on the extent to which content depends on updating or animating the subtree that <use> refers to.

Again, I trust the people who work on SVG to say if any of this makes sense, it's not something I'll work on.

Philip

Erik Dahlström

unread,
May 6, 2015, 6:47:06 AM5/6/15
to Justin Novosad, blink-dev.chromium.org
No, this intent wasn't intended to address foreignObject.

I agree that more specific security origin checks for foreignObject would
be nice, it is more complex though.

I'd be happy if someone were to attempt to implement a proper same-origin
policy for foreignObject, but I think that part needs to be worked out
before attempting to allow cross-origin there. One step at a time.


On Mon, 04 May 2015 19:21:34 +0200, Justin Novosad <ju...@chromium.org>
wrote:
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org.


Erik Dahlström

unread,
May 7, 2015, 8:22:33 AM5/7/15
to Anne van Kesteren, Philip Jägenstedt, blink-dev.chromium.org
On Tue, 05 May 2015 18:42:24 +0200, Anne van Kesteren <ann...@annevk.nl>
wrote:

> On Tue, May 5, 2015 at 5:45 PM, Erik Dahlström <e...@opera.com> wrote:
>> On basis of what web developers seem to think is natural I'd disagree
>> that
>> it's strange. External <use> has been a part of SVG since version 1.0
>> of the
>> spec, and I do think that was a deliberate choice to allow urls rather
>> than
>> just id values.
>
> However, whether CORS makes sense depends on the processing model for
> <use> which I believe is still unclear...

It is my hope that those unclear details can be worked out in the svg2
timeframe. There are already a couple of WG resolutions for <use> listed
in the editor's draft that haven't yet been written as proper spec text.

>> That is indeed what I meant.
>
> Note that "no-cors" is something completely different.

Ok, so you would recommend saying that when <use> fetches something and
'crossorigin' wasn't specified, it sets the 'force same-origin' flag
instead?

I'm looking at
http://www.w3.org/TR/html5/infrastructure.html#cors-enabled-fetch and my
reading of that is that if the 'default' flag is 'fail' and the 'mode'
flag is 'No CORS' the end result is almost the same as if the 'force
same-origin' flag was set. But the devil is probably in the details :)

>>>>> The patch will not really change anything for <image> and <script>,
>>>>> apart
>>>>> from exposing the 'crossorigin' attribute on the corresponding IDL
>>>>> interfaces.
>>>>
>>>> That seems bad. For <script> the feature that crossorigin provides is
>>>> better error handling.
>>
>> Ok, and that's a bad thing for <svg:script> how exactly?
>
> It's bad if exposing the attribute doesn't change anything. But it
> seems that you now state that it does in fact have an effect. (The
> correct one.)

Ok, good.

Anne van Kesteren

unread,
May 8, 2015, 1:35:10 AM5/8/15
to Erik Dahlström, Philip Jägenstedt, blink-dev.chromium.org
On Thu, May 7, 2015 at 2:22 PM, Erik Dahlström <e...@opera.com> wrote:
> On Tue, 05 May 2015 18:42:24 +0200, Anne van Kesteren <ann...@annevk.nl>
> wrote:
>> However, whether CORS makes sense depends on the processing model for
>> <use> which I believe is still unclear...
>
> It is my hope that those unclear details can be worked out in the svg2
> timeframe. There are already a couple of WG resolutions for <use> listed in
> the editor's draft that haven't yet been written as proper spec text.

Should you not first work out the details before complicating the
feature further?


> Ok, so you would recommend saying that when <use> fetches something and
> 'crossorigin' wasn't specified, it sets the 'force same-origin' flag
> instead?
>
> I'm looking at
> http://www.w3.org/TR/html5/infrastructure.html#cors-enabled-fetch and my
> reading of that is that if the 'default' flag is 'fail' and the 'mode' flag
> is 'No CORS' the end result is almost the same as if the 'force same-origin'
> flag was set. But the devil is probably in the details :)

I recommend writing your specification in terms of

https://fetch.spec.whatwg.org/

instead. Otherwise CSP, Mixed Content, Service Workers, Referrer
Policy, etc. are all undefined. HTML will be updated in due course.


--
https://annevankesteren.nl/

Philip Rogers

unread,
May 9, 2015, 2:28:32 AM5/9/15
to Anne van Kesteren, Erik Dahlström, Philip Jägenstedt, blink-dev.chromium.org
It's important that differences between SVG and the rest of the web platform are minimized going forward. I wasn't aware of potential issues between the use model and fetch, but Anne's concern makes sense to me. It seems reasonable to hold off on shipping this until fetch is a little further along in SVG2.

The implementation for this is straightforward and matches how this attribute works elsewhere. How do folks feel about landing this behind a runtime enabled feature flag (i.e., implement but not ship)?

Philip Jägenstedt

unread,
May 11, 2015, 7:23:27 AM5/11/15
to Philip Rogers, Anne van Kesteren, Erik Dahlström, blink-dev.chromium.org
Erik, do you think there's anything to learn about Fetch+SVG by
implementing behind a flag? If it's most a spec issue (invoking the
right Fetch algorithms in the SVG spec) with no expected impact on how
it's implemented then a flag wouldn't do much good, IMHO.

har...@gmail.com

unread,
Jun 30, 2019, 4:14:27 PM6/30/19
to blink-dev, e...@opera.com
Hello, has anything happened in the last 4 years that would allows this to proceed? Not being able to use cors together with <use> blocks some nice features such as putting svg sprite on cdn. There are already tools such as https://github.com/JetBrains/svg-mixer/tree/master/packages/extract-svg-sprite-webpack-plugin that allow creating such sprites, but they need to be on same domain. Right now we are thinking of using a proxy to get around this, but it would be nice knowing that we could eventually switch to cors instead.

Philip Jägenstedt

unread,
Jul 23, 2019, 4:56:12 AM7/23/19
to har...@gmail.com, Fredrik Söderquist, blink-dev, e...@opera.com
Hi Martin,

Starring https://crbug.com/470601 is one way to "vote" for this issue. It's assigned to +Fredrik Söderquist and the most recent development is that https://github.com/w3c/svgwg/issues/707 was filed. It looks like the WG resolved to change the spec. Fredrik, is that now blocking on the spec editors making time for it?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Fredrik Söderquist

unread,
Aug 12, 2019, 1:54:09 PM8/12/19
to Philip Jägenstedt, har...@gmail.com, blink-dev
On Tue, Jul 23, 2019 at 10:56 AM Philip Jägenstedt <foo...@chromium.org> wrote:
Hi Martin,

Starring https://crbug.com/470601 is one way to "vote" for this issue. It's assigned to +Fredrik Söderquist and the most recent development is that https://github.com/w3c/svgwg/issues/707 was filed. It looks like the WG resolved to change the spec. Fredrik, is that now blocking on the spec editors making time for it?

That and slightly more positive signals from other browser vendors I think.


/fs
Reply all
Reply to author
Forward
0 new messages