SVG uploading - Wikitech-l

23 Mar 2005

Hi,

After participating in several discussions about SVG on the wikis, it 
appears that SVG uploading is currently impossible by design.  As I 
understand it, the uploading of SVG is disabled because of concerns about 
SVG containing malware.

I have written an SVG sanitizer that detects (and removes, although this 
may not be useful) the presence of script tags in SVG.  It still requires 
some fine-tuning to match the requirements of the wikis, so I am inquiring 
to find out what those requirements actually are.

Some background: SVG is a form of XML.  The SVG specification describes a 
number of features, including vector art, animation, inclusion of external 
resources, and scripting.  It is also possible (and not difficult) to 
incorporate non-SVG XML inside an SVG file; individual SVG viewers may 
ignore or interpret this XML.  Some examples include metadata tags (in RDF) 
and program-specific SVG extensions.

In Wikipedia, there are a few diferent things we might wish to do with SVG:

* Simply store it for upload/download to provide diagrams (such as 
http://commons.wikimedia.org/wiki/Image:Thermal_reactor_diagram.png ) with 
  accompanying source, so that they can be modified (the text translated, 
for example).

* Render it on the server to generate PNGs at any desired resolution (as is 
done, badly, with  http://en.wikipedia.org/wiki/Image:Bi-flag.svg )

* Serve it up as an image so that it can be rendered in a browser (such as 
  the non-free Adobe SVG plugin, konqueror, or the SVG-enabled version of 
Mozilla).  (This is the only option that would make any use of the 
(poorly-supported) animation and scripting capabilities of SVG).

I am suggesting only the first: simply serve it up for download.  There are 
software issues with the second (no entirely satisfactory rendering 
software exists; librsvg, batik, and inkscape are the leading free 
contenders).  The third would require more extensive software modifications 
and would only really be useful if the second worked.

The concern with this application is that the files may contain hostile 
scripts which will be run by users who download the files and attempt to 
edit them (akin to Word macro viruses).  (I know of no current SVG editor 
that implements any form of scripting).

The questions that need to be answered before SVG upload could be 
re-enabled are:

* What non-SVG content may an SVG file contain?  Metadata is common (for 
example in the openclipart library of PD SVG files), as are 
program-specific extensions.  If undesired non-SVG content is found, should 
it be removed, or should the file be rejected? (Users of CorelDraw (for 
example) may find it difficult to persuade CorelDraw to produce a pure SVG 
file).

* Is it sufficient to remove all scripting elements from an SVG file?  (are 
external resources a concern? animations?)  Should files containing 
scripting elements have them removed, or should the files be rejected?

It would also be necessary for someone with experience with the Mediawiki 
software to figure out how to integrate an SVG sanitizer with the software.

Discussions of SVG support and its desirability:

The original post to this mailing list in which Brion VIBBER announced that 
he had disabled SVG:
http://mail.wikipedia.org/pipermail/wikitech-l/2004-September/025467.html

I asked about SVG support; a bad workaround was suggested; vague allusions 
to security problems were made; a workaround was suggested:
http://commons.wikimedia.org/wiki/Commons:Village_pump_archive-11#SVG

[[en:User:KrisK]] asked about SVG support; I noted it was disabled; Brion 
VIBBER gave a partial answer about why it was disabled.
http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28policy%29#raster_vs_…

A recent version of my SVG sanitizer script:
http://en.wikipedia.org/wiki/User:Aarchiba/SVG_sanitizer

In summary: What are the criteria for re-enabling SVG support?  There is 
increasing demand for it, and it can be effectively sanitized.

Thanks,
Andrew