- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Wed, 10 Apr 2013 01:25:00 +1200
- To: Anne van Kesteren <annevk@annevk.nl>
- 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>, Daniel Holbert <dholbert@mozilla.com>
- Message-ID: <CAOp6jLZtuSjAOq7O=sLy6WDU2KHTx0-9P0tF7tY_vLmHyUe_8g@mail.gmail.com>
On Wed, Apr 10, 2013 at 1:15 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > 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. > On the contrary, I find it very plausible that Web developers might add SVG as a supported format without knowing 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.) > That is a good point. I think we didn't consider that, and that may mean it's just not safe to host uploaded SVG images at all currently, at least not without severe sanitization. Needs more thought than I can give it tonight. > 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). > That's an option, but again it doesn't escape the need to make breaking spec changes to resolve the existing requirements. We need to think about whether it's possible and a good idea to remove the no-external-loads restriction on SVG images. Don't want to be hasty and expose a security issue :-). Rob -- q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"
Received on Tuesday, 9 April 2013 13:25:30 UTC