Re: Announcement: Last Call WD of SVG 1.1 Second Edition

On Thu, Feb 3, 2011 at 1:02 AM, Erik Dahlstrom <ed@opera.com> wrote:

> That depends on what "raster image" means to you, since that's what the
> pointer-events section you refer to has requirements on. I would say that
> <image xlink:href="foo.svg"> is not a raster image, whereas for example
> <image xlink:href="foo.png"> is. It would be simpler if the additional
> requirements were dropped, which would make both of these cases behave in a
> consistent manner.
>

Sure, we could declare that SVG images don't get the raster-image behavior
for pointer-events. That would be a bit unfortunate though, it'd be useful
to allow pointer events to go through transparent parts of SVG images.


>  Some things happened since my last message. For one thing, we implemented
>> <img src="foo.svg"> in Firefox and discovered security and privacy issues
>> if
>> you let foo.svg load resources cross-origin or maybe even let it load
>> resources from the same origin! So we're only allowing data: URLs in there
>> for now :-(. So my proposed attack is blocked by that.
>>
>
> Could you describe these security and privacy issues in more detail? Are
> they issues stemming from CSS, HTML, SVG or a combination?


Hmm, I thought jwatt or heycam might have brought them up already.

Basically the problems are with sites that let you upload images. With SVG
images you can construct an image that contains an <image> pointing to a
resource on your server. Now, even after uploading that SVG image to a site,
you can track views of that image. This is a new capability --- the existing
image formats we support can't do this. It's not clear if sites that would
want to host SVG images are prepared for this.

You can block cross-origin loads but you have to be careful about open
redirectors --- you have to make sure that redirects aren't followed. It
seemed safer and easier to restrict SVG images to be completely
self-contained in Firefox 4, just like other images.

One thing to consider here is whether it's worth defining different
Content-Types for "fully self-contained image" and "image possibly
containing remote references" (and figure out which one you want to be the
default). This would let servers choose whether to support
non-self-contained images.

No, because we don't support pointer-events:visiblePainted or anything
>
>> equivalent.
>>
>
> And that's never going to change? In light of what you write below it seems
> people want that functionality.


Indeed, I want it to change.

I think at this point we could implement pointer-events:visiblePainted for
all images without creating any information leaks. Later we could probably
relax the restrictions on SVG images a bit.

Rob
-- 
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]