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

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

From: Anne van Kesteren <annevk@annevk.nl>
Date: Tue, 9 Apr 2013 14:14:53 +0100
Message-ID: <CADnb78itgSTwWJVSdjBbMFKZ4GjfJ_8194OBRLexmWsj+itN=Q@mail.gmail.com>
To: 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>
My apologies for dropping the list.

---------- Forwarded message ----------
Date: Tue, Apr 9, 2013 at 12:02 PM
Subject: Re: [filter-effects][css-masking] Move security model for
resources to CSP

On Tue, Apr 9, 2013 at 11:54 AM, Robert O'Callahan <robert@ocallahan.org> wrote:
> The remaining problem is "processed as an external resource document" vs
> "processed as a regular image load". For security reasons we restrict SVG
> image documents severely: in particular they may not trigger any kind of
> external load (e.g. images) of their own.

Could you explain this reason? Why can it not inherit the tainting
from the resources it fetches? (You'd have to wait for all
subresources to load before you expose it as loaded.)

> On the other hand, SVG external
> resource documents are treated more leniently; they may load external images
> and other (same-origin) SVG external resource documents. I don't think we
> could maintain this distinction with your proposal. We can't relax the
> constraints on SVG image documents, so we'd have to severely restrict SVG
> external resource documents loaded via url(). They aren't currently used
> much (Webkit doesn't support them at all) so we could do that, but it would
> mean altering the SVG spec in incompatible ways and there might be content
> that breaks.

I'd be interested in hearing the constraints.

> And I'd really want to try implementing it before committing to this
> approach, since there might be lurking problems.

That is totally fair.

Received on Tuesday, 9 April 2013 13:15:22 UTC

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