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

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.


--
http://annevankesteren.nl/

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