[randallu]

They have a lot of tables which are (depending on the browser) interpreted by OS functions, so if there was a buffer overflow bug in the OS font code then you could exploit it with a webfont.

Most (all? Not sure about Safari) use the "OpenType Sanitizer" on all webfonts, which parses and validates all of the tables and all of the offsets contained within them. http://code.google.com/p/ots

[pyre]

Is this really any more of a risk than the code that parses and renders the SVG? Or the PNG for that matter (there have been issues with image libraries in the past)?

[fit2rule]

There is some weight in the argument. It goes like this:

a) font-file, indexed set of glpyhs. A glyph is any set of line primitives that is associated with the symbol. We load the file of 'sub-routines to draw', and index it .. stupidly .. with some font_glyph_array[]. Which we then index, according to keycode-translation-{NSA-insert}-pipeline.

ahem

b) SVG. SVG is 'pure math', in that the glyphs and bitmaps aren't there, but rather the CPU is going to be asked to calculate things. For this reason, 'most SVG rendering libs are crap' is true, because SVG is intended to be turned into whatever is useful for your CPU, before then being re-rendered for the next frame. Of course this takes a lot of time .. but at least it prevents buffer sploits.

Hmm.

What I like about SVG is that for every id="" there is to be found, there could be a unique 'identifier' to the application, at the user level, that abstracts the <g>. So, if I want a 'button', I just wrap everything up in <g id="button">, and off we go. Of course, ymmv, and probably I'm not trawling the DOM per-frame, like you're supposed to, but hey: its a button that can be immediately Cut-/_Pasted by the designer, and I don't have to think about it.

So SVG serves the purpose of every graphics file-format, ever, which is to stop the Designer and the Programmer from actually having to talk to each other.