- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Tue, 9 Apr 2013 14:15:40 +0100
- 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>
Dropping it twice, that is ;-) ---------- Forwarded message ---------- Date: Tue, Apr 9, 2013 at 2:05 PM Subject: Re: [filter-effects][css-masking] Move security model for resources to CSP On Tue, Apr 9, 2013 at 1:24 PM, Robert O'Callahan <robert@ocallahan.org> wrote: > Basically, many Web sites accept uploaded images and expect those images to > be self-contained and not be able to trigger further loads. Violating this > assumption creates several kinds of potential problems. See > https://bugzilla.mozilla.org/show_bug.cgi?id=628747. But this also requires websites to enable support for SVG in the first place. And contrary to bitmap image formats, SVG resources must be labeled with a correct MIME type. It seems somewhat unlikely that both of those would be in place without the site also knowing about what SVG can do. Furthermore, people could be tricked into loading the SVG resource directly! (It's not something you want to host same-origin for instance, whereas hosting a PNG same-origin is always fine.) > AFAIK the only major difference in the way SVG images and SVG external > resource documents are processed is that SVG images can't do external loads. > (We disable scripting and enable animation in both.) That's a pretty big > difference though! > > We disable native theming in SVG images but not SVG external resource > documents, so that authors can't get the pixel data of native themes, but > that's obscure and probably unimportant. Maybe loading subresources should be an option for the API initiating the fetch so they can explicitly opt into the lifting restrictions we have put in place (whether we should have those restrictions in the first place; not sure). -- http://annevankesteren.nl/
Received on Tuesday, 9 April 2013 13:16:12 UTC