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: Fri, 25 Jan 2008 18:48:04 +0100
To: public-html@w3.org
Message-Id: <200801251848.04869.Dr.O.Hoffmann@gmx.de>

Boris Zbarsky wrote:
> Dr. Olaf Hoffmann wrote:
> > I think, these problems show mainly, that the img element
> > of html is outdated since the object element was introduced.
>
> The two have very different behavior from a security perspective.  In
> particular, the content of an <img> is guaranteed to be static content in
> the sense that it won't run JavaScript (though I do wonder how Opera's SVG
> and Safari's PDF handling play there; I would hope they disable JavaScript
> when embedding SVG and PDF via <img>).  <object> carries no such security
> guarantee; quite the contrary.
>
> Now this guarantee is not spelled out in the HTML4 specification, of
> course. But it has been provided by all UAs for a number of years now, and
> it's widely relied on by content.
>
> In fact, it would make a lot of sense to specify this guarantee in HTML5...
>
> -Boris

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

Therefore it is no surprise, that an advanced general purpose browser starts
to implement this, even if the img element is not the best choice for authors.

Scripting was always a problem, inside HTML too for several reasons. 
Obviously it gets even more interesting, if a plugin is used to display
something, having its own scripting support and security holes.
But typically the user can simply decide to switch scripting on or off in
general or in specific areas - or if this is not possible to use another
program. Or the user can use an advanced operating system to avoid
too much damages due to security holes in programs interpreting content
from the internet. 
And to have the same functionality for only different named elements
simplifies the situation somehow - suspicious content can be anywhere
and if a security problem is fixed for one of them, it should be fixed for
all of them, because the names are only aliases for the same module
of a program...
Received on Friday, 25 January 2008 17:53:17 UTC

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