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

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

From: Anne van Kesteren <annevk@annevk.nl>
Date: Tue, 9 Apr 2013 06:43:28 +0100
Message-ID: <CADnb78gvXZOEQBvNaD3R9=__pSCcqyUwaTZ5YXxD7+0Dfe6WHA@mail.gmail.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: Dirk Schulze <dschulze@adobe.com>, "public-fx@w3.org" <public-fx@w3.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Tue, Apr 9, 2013 at 2:36 AM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
> * Anne van Kesteren wrote:
>>On Sat, Apr 6, 2013 at 10:02 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
>>Even so that would still mean CSS will have this fragment identifier
>>presence determines processing behavior bug. Clearly a new syntax
>>should have been used for masks, e.g. mask(url)...
> If that is the only change you have in mind, then for each of the these:
>   mask-image: url(...);
>   mask-image: mask(...);
>   mask-image: image(...);
>   mask-image: url(...#...);
>   mask-image: mask(...#...);
>   mask-image: image(...#...);
> you would have to define whether they are allowed and what the behavior
> is, and what `mask(...)` means for all other properties. I do not really
> see any "clear" answer to that that would lead to a better result. I can
> see an argument for disallowing `url(...)` without fragment identifier,
> if that is indeed redundant with `image(...)`, but that would not really
> address the concern as you put it above, and people do not like failure
> cases (just look at all the places where you can specify a fragment, but
> that has no effect compared to not specifying one, making it impossible
> to define more sensible behavior for fragment identifiers there "now").

In a later email I suggested not changing the fetching policy based on
the presence of a fragment identifier and having a way to opt into a
fetching policy that supports cross-origin masks instead (CORS). A way
that matches how HTML has addressed this. That would also scale better
if we introduced new types that have a CORS same-origin requirement
that do not use a fragment.

Received on Tuesday, 9 April 2013 05:43:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:32 UTC