Re: img issue: should we restrict the URI

Boris Zbarsky wrote:
> Dr. Olaf Hoffmann wrote:
> > If the authors are different and the author of the embedding document
> > does not like the behaviour of the SVG document
>
> You're assuming the author of the embedding document has any idea what's
> inside the SVG.
>
> Say the embedding document is MySpace.  The author of the embedding
> document is MySpace.  The image is inserted by a MySpace user.  The author
> of the SVG might be that user or someone else.  All MySpace wants to do is
> not allow that SVG to steal cookies.

Sounds more like a security problem of the cookie method or of the
concept used by MySpace, not much related to the SVG document.
Could be a security problem of the script language itself, not of the
general concept of having scripts inside an embedded document.
To disable the scripting in the SVG by the viewer only hides
some consequences but does not remove the causes of the problem.


....

>
> > 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 seem to recall something about a "Don't break the web" design principle?
>

If current behaviour is not useful at all, it is obviously a good idea to 
start to do it better. 
And in many discussions I have seen so many pages broken by current
behaviour by browsers that I have to say: Currently we have already 
a broken web (at least for HTML+CSS) - and if it is the principle to keep 
it broken in the near future it is not really possible to choose a wrong
decision. In the worst case it will get better within some years with 
good decisions and if nasty things are fixed now and not in ten years 
or never.

>
> Or viewed another way, all the UAs who're implementing SVG in <img> are
> disabling scripting.  Have you stopped to wonder why?  If the spec doesn't
> allow this, can it become a REC?
>

I have switched off scripting by default, therefore I cannot see a difference.
However if there is a difference for users/authors with scripting switched
on, this is an implementation gap, maybe related to security problems of
the browser, but this does not change the basic fact of an incomplete
(or unsecure?) implementation.

> > I never tried, because from my point of view the construction of img in
> > HTML4 is outdated
>
> Then why exactly do you care what behavior is specified for <img>, exactly?
>  You keep using <object>, and live with the security issues.
>

If there is audio, video in the draft, there should be for sematical reasons
an image/img element with the same functionality as object too and some
other elements with a semantically useful name, but the same functionality
to embed other documents. object could be an element to use, if there is
no element with a better name. This could be similar to div or span. 
Maybe this was already the concept intended in HTML4, but for historical
reasons they did not manage to complete it - there is a new chance in HTML5
to have a better realisation of this concept. If the chance is lost in HTML5
we have to wait for HTML6 or XHTML2...
And the incomplete concept in HTML4 caused already a lot of surprising
results with different media in the real existing web ;o)

Received on Tuesday, 29 January 2008 17:15:41 UTC