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_v...
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
Note : Brief howto SVG-enable Firefox on Windows at [1].
Magnus
[1] http://magnusmanske.de/wikimaps/index.php/How_to_SVG-enable_Firefox
Andrew Archibald schrieb:
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_v...
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 _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Andrew Archibald wrote:
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).
Yep. Uploading a PNG is not actually providing the editable form per GFDL. When I've uploaded a PNG I've included my email for the SVG itself should anyone want the editable version.
(Inkscape: coolest thing ever!)
- d.
David Gerard wrote:
Andrew Archibald wrote:
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).
Yep. Uploading a PNG is not actually providing the editable form per GFDL. When I've uploaded a PNG I've included my email for the SVG itself should anyone want the editable version.
(Inkscape: coolest thing ever!)
We discussed possibilities for providing the original SVG (of course these by their nature subvert wikipedia's "security"), including: post the SVG to the image description page (fine for handwritten SVG, but when a few circles and rectangles come out to 30K it's not so nice), sneak the SVG into PNG comments (can even be zipped!), or find somewhere else to post the stuff. None were very satisfactory. Neither is providing contact information; users have a tendency to disappear.
My diagrams are not exactly the Mona Lisa, but I can easily imagine wanting to translate the text...
Unfortunately, it really is possible to put scripts in SVG (it was designed to replace Flash) and someone may someday write a viewer that executes such scripts in a trusted context, so it has been Decided that SVG uploads should be disabled.
I'm trying to solve that problem.
Andrew
On Wed, 23 Mar 2005, David Gerard wrote:
Yep. Uploading a PNG is not actually providing the editable form per GFDL. When I've uploaded a PNG I've included my email for the SVG itself should anyone want the editable version.
Strictly speaking, that's not a problem whith the GFDL: you are uploading and distributing a PNG, and the license applies to that image, not to the SVG. If instead you are redistributing someone else's SVG, then the GFDL requires you to put the SVG itself for download.
Alfio
Alfio Puglisi wrote:
On Wed, 23 Mar 2005, David Gerard wrote:
Yep. Uploading a PNG is not actually providing the editable form per GFDL. When I've uploaded a PNG I've included my email for the SVG itself should anyone want the editable version.
Strictly speaking, that's not a problem whith the GFDL: you are uploading and distributing a PNG, and the license applies to that image, not to the SVG. If instead you are redistributing someone else's SVG, then the GFDL requires you to put the SVG itself for download.
Yeah. My real objection is that it lacks *elegance*. Oh well.
- d.
Alfio Puglisi wrote:
On Wed, 23 Mar 2005, David Gerard wrote:
Yep. Uploading a PNG is not actually providing the editable form per GFDL. When I've uploaded a PNG I've included my email for the SVG itself should anyone want the editable version.
Strictly speaking, that's not a problem whith the GFDL: you are uploading and distributing a PNG, and the license applies to that image, not to the SVG. If instead you are redistributing someone else's SVG, then the GFDL requires you to put the SVG itself for download.
Well, it does mean that if you have a GFDL SVG file, you can't put a PNG of it on Wikipedia. There do not seem to be many of those yet, but with the wide distribution of Inkscape, I expect them to start appearing rapidly.
This is easily remedied by allowing SVG upload, which is why I am asking what would be needed for it to be re-enabled.
Andrew
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Andrew Archibald schrieb:
This is easily remedied by allowing SVG upload, which is why I am asking what would be needed for it to be re-enabled.
Since SVG is "just" XML, and we "only" want static images (at the moment), can't we just filter all the evil parts out? Have a whitelist for tags and attributes, parse the SVG as XML, remove everything not on the whitelist, and save the result?
This could be expanded gradually as the need arises (clickable objects etc.).
Magnus
Magnus Manske wrote:
Andrew Archibald schrieb:
This is easily remedied by allowing SVG upload, which is why I am asking what would be needed for it to be re-enabled.
Since SVG is "just" XML, and we "only" want static images (at the moment), can't we just filter all the evil parts out? Have a whitelist for tags and attributes, parse the SVG as XML, remove everything not on the whitelist, and save the result?
This could be expanded gradually as the need arises (clickable objects etc.).
Magnus
Well, yes, one could write such a program. I did. A version is at http://en.wikipedia.org/wiki/User:Aarchiba/SVG_sanitizer
What I'm trying to do now is get someone to tell me what else needs to be done to get SVG uploads enabled.
Andrew
wikitech-l@lists.wikimedia.org