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

On Apr 6, 2013, at 12:59 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Fri, Apr 5, 2013 at 8:19 PM, Dirk Schulze <dschulze@adobe.com> wrote:
>> Ok, that would be all references (by url() function) to something else than an CSS Image for CSS Masking and Filter Effects. That can be detected on parse time.
> 
> Why? Scripts change that, no? What about the URLs in the SVG resources
> these url()s can fetch?

I am not sure if we talk about the same thing.

First, I limit the term resource to references to <mask>, <filter> and <clipPath> elements by fragment identifiers. SVG would extend these by further elements like <linearGradient>, <radialGradient>, <pattern>, <color> and so on. JavaScript or other references are explicitly not part of the resource definition here and need different considerations.

I mean mask-image: url(…);. In CSS Masking the URI could be an CSS Image or a reference to a resource. Accepted resources are just <mask> elements and the URI must have an fragment identifier for the previously named property. The existence of a fragment identifier decides if we have strict rules, or use the same rules as for images (which do not have restrictions to the origin).

How can scripts change that? I mean obviously scripts can change the computed value of 'mask-image', in which case the CSS parser validates the URI anyway and decides again if it is a resource or an image.

Resources in resources would need similar considerations.

> 
> 
>> Reading the http://fetch.spec.whatwg.org spec, it seems that is what it tries to do. Is there something need on CSS Masking and Filter Effects? When do you think http://fetch.spec.whatwg.org can be referenced normatively? What should these spec do in the meantime?
> 
> First of all, you need to make sure that from whatever point you fetch
> a resource (and that cannot be a blanket statement encompassing url()
> in general, as it's also used for identifiers by mistake) you invoke
> the fetch algorithm. For now I suppose you could try to prepare all
> CSS specifications for that eventuality so they all at least refer to
> a common algorithm for "obtaining a resource".

This seems to be quite big change to the current model:

> 
> Then from what I understood with the problems with filters and masks
> is that you need to keep track of all those resources fetches and if
> one turns out to be tainted, the whole thing is.

Not necessarily. I would need to check what Firefox does, but my understanding is that just tainted resources are not used. If a resource for instance has further resources (2nd level or up references), then these might be tainted and then not used. The first level resource could still be used.

For images, there are no restrictions on resources at all. Images are considered to not harm the user here. That is why it is important to differ between a resource and an image before executing any step after parsing, since it affects the further considerations.

> That seems like
> something you can define. And given that CSS is not using CORS yet
> (see below) I think that means that anything cross-origin is tainted
> (now you probably should make an exception for data and blob URLs
> unless they are the result of a redirect, also see the Fetch draft).
> 
> Then you need to decide what fetching policy you want for resources.
> E.g. background-image:url() uses the "tainted cross-origin" (see
> Fetch) as does <img> etc. To use CORS <img> requires an opt-in, <img
> crossorigin>. Similarly you might want something like that in CSS.
> E.g.
> 
> background-image:fetch(url(), policy)
> 

So yes, it seems like this is not just a task for CSS Masking and would affect all CSS specifications with URI references.

> where policy is some set of keywords TBD (I'm happy to help out).
> 
> Now on my end I'm working on a number of things, but one of my goals
> for this quarter is to get Fetch 80% done, which basically means that
> known outstanding issues are resolved.
> 
> 
>>> (I explained this before in a SVG WG meeting at Adobe in Seattle.)
>> 
>> According to the logs, you just attended one day [1][2][3]. I couldn't find a discussion about references and resource handling but maybe the minutes are incomplete. I was not in this meeting for myself.
> 
> Seems that might have been outside of the minutes then :-( Hopefully
> the above helps.

I understand.

Greetings,
Dirk

Received on Saturday, 6 April 2013 16:17:09 UTC