Re: [filter-effects][css-masking] Move security model for resources to CSP

On Thu, May 30, 2013 at 10:26 AM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Thu, May 30, 2013 at 6:48 AM, Dirk Schulze <dschulze@adobe.com> wrote:
>
>> Maybe CSS and SVG should specify exactly that: No load of any external
>> resources of an SVG file loaded as image. Exclusions of the restrictions
>> can be specified later after more investigations.
>>
>
> If we do that, we prevent unification of "SVG image loads" and "SVG
> external resource document loads". Which is a desirable thing, to enable
> unifying "-webkit-mask" and SVG "mask" without hacks that make the load
> type dependent on a guess of whether you're referring to an SVG mask or an
> SVG image.
>
> My latest thought on this is that maybe we should just change SVG external
> resource document loads to work like SVG image loads --- those external
> documents get no access to external resources of their own. On the face of
> it, this is a pretty bad compatibility break, but maybe it's OK since
> Webkit/Blink don't support SVG external resource document loads at all!
>

Note that if we do this, we'll need to continue to apply an origin check
when filter/mask/clip/use/pattern etc refer to an element in an external
document, at the time they use the element. Anne, can we make regular image
loads record presence of an Access-Control-Allow-Origin header if the
server sends one, without causing the load to fail if it happens to be
cross-origin with no header?

Even if the spec allows it, that's going to be a pain to implement for us
since there's currently no notion of delaying CORS-enabled origin checks in
our code.

Rob
-- 
q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq
qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq
qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq
qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q
qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq
qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"

Received on Wednesday, 29 May 2013 23:35:43 UTC