W3C home > Mailing lists > Public > public-fx@w3.org > April to June 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 07:54:35 +0100
Message-ID: <CADnb78gzQP0gXGursDHgu5Owpcy_JJ86sx0SF8R=XSRhVWYQVQ@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, 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 7:37 AM, Robert O'Callahan <robert@ocallahan.org> wrote:
> Sure, we can introduce new CSS syntax to force resource loads to take one
> path or another. But that doesn't resolve the conflicting requirements:
> 1) mask: url(foo.svg#mask) needs to be a CORS-enabled fetch, processed as an
> external resource document
> 2) background-image: url(foo.svg) needs to be non-CORS-enabled fetch,
> processed as a regular image load
> 3) mask-image: url(foo.svg) needs to behave just like background-image
> 4) 'mask' is shorthand for 'mask-image'
> If we have to treat url(foo.svg) and url(foo.svg#mask) identically, then we
> have to break one of the above requirements. Pick one.

You say "needs to be". Does that mean there's wiggle room given
current implementations? As I said before, they could all use "tainted
cross-origin" as fetching model and for returned mask resources that
means they will not work if marked CORS cross-origin. If you want
untainted mask resources you'd have to use new syntax that opts into
the "CORS" fetching model which gives you CORS same-origin resources
or a network error.

Received on Tuesday, 9 April 2013 07:01:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:45 UTC