W3C home > Mailing lists > Public > public-html@w3.org > January 2008

Re: img issue: should we restrict the URI

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Sat, 26 Jan 2008 12:52:51 +0100
To: public-html@w3.org
Message-Id: <200801261252.52011.Dr.O.Hoffmann@gmx.de>

Boris Zbarsky wrote:
> Dr. Olaf Hoffmann wrote:
> > At least img is noted as a typical use case for SVG content for more than
> > 6 years, see:
> > SVG 1.0:
> > http://www.w3.org/TR/2001/REC-SVG-20010904/concepts.html#UsageOptions or
> > 1.1: http://www.w3.org/TR/SVG11/concepts.html#UsageOptions
> Yes.... what did I write to contradict this?

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)


> 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. 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...
But this might be one reason more to use always the same program
module and different names only as aliases at least for the
technical aspect of the implementation.

> > And to have the same functionality for only different named elements
> > simplifies the situation somehow - suspicious content can be anywhere
> Right now, linking to an untrusted image using <img> is not a security
> problem for a website.  Linking using <object> is.  Changing this is not
> something that is either feasible or, in my opinion, desirable.
> -Boris

I think, this is more user-agent tradition, not something really logical for
authors or users. Since it is not specified for example in HTML4, that
any format must be supported for img (or object), currently it is anyway
optional, whether JPEG, PNG, GIF, SVG etc are displayed or not, but if they
are displayed, it can be expected, that an embedded document has the same
behaviour as a standalone document, everything else looks like an error, 
an implementation gap or an inconsistent behaviour (an exception is of 
course the size of the display).
Does HTML4 mention, that one of img or object has to be used to ensure
specific security assumptions? If not, current authors have no chance to
understand the current implementation gap. Does the HTML5 draft 
mention this usage as typically intended for security issues? If not, readers
of the draft will not unterstand surprising restrictions or even the existence
of such specific elements.

Another problem of embedded documents (both for img or object) indeed
is, that for example SVG documents 'eat' events. This could be solved with
an attribute similar to the CSS/SVG property (presentation attribute)
pointer-events optimised for HTML use cases (a element around img 
or object, what about key-events etc?). Then the control about the 
desired behaviour is left to the author of the embedding document.
The author should know much better, what the desired behaviour is, not
the user-agent or the working group or myself or anyone else.
This is a solution applicable for other elements too like video, then the 
author can decide too, whether an interactive video-(container)-format
might receive events or the surrounding a element, simulating a button 
with a time dependent appearance or something like this.
This is more effective as to invent new elements like 'obj', 'vid' etc to
get the same effect with additional elements.
Received on Saturday, 26 January 2008 12:03:45 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:29 UTC