- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Sat, 26 Jan 2008 12:52:51 +0100
- To: public-html@w3.org
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