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

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

From: Dirk Schulze <dschulze@adobe.com>
Date: Mon, 8 Apr 2013 08:51:36 -0700
To: Anne van Kesteren <annevk@annevk.nl>
CC: Bjoern Hoehrmann <derhoermi@gmx.net>, "public-fx@w3.org" <public-fx@w3.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <BCE75E6D-6F7C-45CE-89FE-F5443A06077D@adobe.com>

On Apr 8, 2013, at 8:02 AM, "Anne van Kesteren" <annevk@annevk.nl> wrote:

> On Mon, Apr 8, 2013 at 3:50 PM, Dirk Schulze <dschulze@adobe.com> wrote:
>> WebKit supports CSS Masking and SVG Masking, both with the mask property, just that the one for CSS Masking is prefixed. CSS Masking does not support SVG Masking yet and the other way around. There is no security bug, nor will there be one with the suggested interpretation of url(). I do not even see how it would harm the web platform today nor in the future. It just affects the url() function allowing us to combine SVG and CSS in a lot more places then just Masking. It allows a lot more possibilities on all CSS properties like taking SVG gradients and patterns as input on the background and border property. It allows fill and stroke properties to take CSS image values (which the SVG WG resolved already). It allows CSS exclusions to reference SVG shapes and CSS images.
>> 
>> At the end I think it does not harm the web, it extends the possibilities.
> 
> I don't really think you're answering any questions here. If WebKit is
> shipping, how is the "suggested interpretation of url()" relevant?

It is not today for WebKit. mask and -webkit-mask are two different properties. That is why it doesn't matter today.

> 
> Whether the harm is great or not we can judge in hindsight. However,
> it seems pretty clear to me that having a different fetching model
> based upon the fragment identifier in the URL, which exists exactly
> nowhere in the platform today, is not ideal and will lead to a great
> deal of confusion.
> 
> What I could see working: You keep the default "tainted cross-origin"
> model for url() but do nothing special for fragment identifiers. If
> the fetched resource is an image, it being CORS cross-origin does not
> matter. If it is a mask, it does. You then add a way to enable CORS
> requests using e.g. fetch(url, crossorigin) or some such similarly to
> how HTML enabled a couple of elements to do just that.

I agree, this was and still is my preferred way. To interpret the downloaded resource. However, it was a direct request of Mozilla to differ at parse time before downloading.

Greetings
Dirk

> 
> 
> --
> http://annevankesteren.nl/
Received on Monday, 8 April 2013 15:52:21 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:01 UTC