Re: img issue: should we restrict the URI

Boris Zbarsky wrote:
> Dr. Olaf Hoffmann wrote:
> > It is not noted, that this has influence on the interpretation of the SVG
> > and I think, it should not have influence. The interpretation should
> > depend on the content of the SVG document of course, not on the embedding
> > document, else the author would have written another SVG document ;o)
>
> You're assuming the author of the SVG document and the author of the
> embedding document are the same.  This is a bad assumption.
>
In general I note it, if I assume something specific. The SVG document
has an author and the embedding (X)HTML document has an author, 
not important, whether it is the same or not.
The author of the SVG document created his document with some 
assumptions (hopefully indeed realised in such a way, that the
functionality and the purpose is still available without scripting, else
the document has no functionality or purpose at all).
If the authors are different and the author of the embedding document
does not like the behaviour of the SVG document, it is in general a good
idea not to embed it at all and to write another one or just to use an
a element to reference it as a bad example. In all cases the behaviour
of the embedded document should not depend on the embedding
document. If the embedded document tries to manipulate the embedding
document with scripting is a different problem, because then obviously
the behaviour for a standalone document is different anyway as for
the same document embedded somewhere. In such a special case
I see no problem if the author of the embedding document can restrict
the behaviour somehow. 

> >> We're not talking about the user.  Running script in images would make
> >> _websites_ vulnerable, not users.
> >
> > If it depends on img or object, this looks like a bad
> > design/interpretation of the img element, if a website is more vulnerable
> > with an image inside img as with an image inside object.
>
> It might be a bad design, but it's extremely common.
>

I know a lot of nasty, quite common things, but the quantity of
nasty things is in general no reason, not to do it better ;o)


> > I think, there were already some
> > security or at least stability problems with illformed JPEGS (don't know
> > details anymore) too in more than one browser...
>
> You're once again confusing user security and website security.
>
> The security issue here is that just because a website allows users to post
> images it might not actually want to allow them to run script.  If images
> can run script, this becomes a problem.

Obviously such a problem already existed before HTML was invented, for
example PostScript is a nice possibility to create images and already the
name indicates, that such images may contain script like content, therefore
it is not realy a surprise that image formats exist, that contain scripting,
flash can be seen as another image format with scripting abilities, 
currently maybe no one tried to use/implement it for img, but if it is done
for SVG, it is maybe useful for some authors for flash too.
I personally do not need scripting in images, but this is my personal
opinion only, other authors may find a way to use it to increase the
pleasure for the audience or to create alternative displays of the image
to improve accessibility of the content.


....

>
> > Another problem of embedded documents (both for img or object) indeed
> > is, that for example SVG documents 'eat' events.
>
> The point is that an SVG document embedded via <img> should not do this. 
> Are there UAs that support SVG in <img> and have the SVG "eat" events?
>

I never tried, because from my point of view the construction of img in
HTML4 is outdated at least for other formats than PNG or JPEG (or maybe GIF),
I never used it for other formats.

> For <object>, a solution that dispatches events to the parent document
> might be a good idea, not just for SVG but also for HTML, etc.
>
> > Then the control about the
> > desired behaviour is left to the author of the embedding document.
>
> That's a reasonable approach, yes.  So I could be open for a way to have an
> SVG linked in via <img> but with scripting enabled, perhaps. But by default
> it should be disabled.
>
> -Boris

To find some useful default value, maybe dependent on the element is of
course something helpful for authors. This is more the question, what the
most reasonable use case is. This applies too for other media containers
like video (maybe canvas too?). However with such an attribute it is simple
to switch for authors to the desired behaviour, a better approach than to
provide yet another element. Because currently the HTML5 draft does
not have features like declarative animation/interactivity for such 
attributes, the behaviour remains static, but this may change, if something
like timesheets from SMIL gets implemented in some viewers to get it
even more useful in advanced applications.

Received on Tuesday, 29 January 2008 13:56:43 UTC