Privacy concern with export-filename and sodipodi:absref

Bug #168958 reported by Worms-x on 2007-10-09
This bug affects 11 people
Affects Status Importance Assigned to Milestone

Bug Description

Inkscape 0.45.1 saves in the source of a svg file:

sodipodi:docbase="C:\complete path to the file.............."
inkscape:export-filename="C:\complete path to the file.png"

showing there the complete structure of my hard disk.

If I put a file made with Inkscape online, this is a major privacy concern,
I don't want people to see the structure of my hard disk.

Could this be changed, or at least obscured, as an option?

Thank you!

Bug Importer (bug-importer) wrote :

I thougt about that some times ago and wanted to post a similar
proposition. It is kinda freaky to share files that can reveal some infos
about the structure of a file system. As an example, I just opened in
notepad an svg downloaded from and here is what I see:

inkscape:export-filename="C:\Documents and
sodipodi:docbase="C:\Documents and Settings\mm81002\Desktop"

from here I can say that the username in that windows system is "mm81002"

I won't say this is a bug so I'd transfer that into the feature request


Originator: NO

docbase is now gone, it wasn't really necessary

export-filename remains, because it is useful. If you don't want to share
it, just don't export to bitmap the file you are going to share (or make
backup), or export to plain svg before sharing.

Bug Importer (bug-importer) wrote :

sodipodi:absref has the same problem.

Ryan Lerch (ryanlerch) on 2008-01-15
Changed in inkscape:
importance: Undecided → Medium
status: New → Confirmed

This "feature" seems to be finally gone now. Can a dev please confirm this?

sas (sas-sas) wrote :

No, this "feature" isn't gone: inkscape:export-filename and sodipodi:absref are still created. Also, although sodipodi:docbase is no longer created, it's still preserved when editing old files.

Bug 170966 suggests putting the export hints in preferences.xml, removing the need for inkscape:export-filename. The same technique could be used to eliminate sodipodi:absref.

sas (sas-sas) wrote :

Update: sodipodi:docbase is no longer preserved when editing old files (as of SVN revision 19239). No progress on inkscape:export-filename or sodipodi:absref.

As there still is no Inkscape release with a fix, I decided to work on a tiny command line tool to make it easier
to strip such information from .svg files. It's called "svgstrip". It's not stable yet, use it at your own risk.
The Git repositoy of svgstrip can be found here:;a=summary

Please contact me if you're interested in collaboration.

jazzynico (jazzynico) wrote :

Marked Bug #230543 duplicate of this one. It also a per-document setting.

Inkscape now provides a scoured SVG option (File>Save As...) which gets rid of all unnecessary attributes. See Bug #409004.

bastik (bstk) wrote :

It would be great if there was an option to get rid of that 'inkscape:export-filename' key once and for all. (Even if it is a hidden option.)

The suggestions made, don't solve the problem for my work flow:
 * make changes in inkscape
 * export and test icon appearance
 * go to first point and repeat until it's acceptable
 * save svg
 * open svg in editor and strip inkscape:export-filename tag
 * publish svg and png

I don't like to save as plain or scoured svg as the file should be useful for others.

Jan-Erik Finnberg (wheany) wrote :

I agree with bastik. I would love to share an svg file that still retains for example layer information, so that other people can edit the file more easily, but I really don't want them to know my username (which happens to be my full real name in Windows), especially if I'm sharing a file to the public internet.

As far as I know, it's "only" a matter of deleting the export-filename attribute by hand in a text editor, or by using a script, but that is something I must always remember to do. And once I forget to do that, I probably cannot remove the information ever.

If there are other such tags or attributes that may leak personally identifiable information like that, I'd like them removed as well.

Wong Cho Ching (chwong249664) wrote :

I have some ideas on solutions to this bug

A. How about making the content of inkscape:export-filename relative? Relativize the path have the following benifits:
* Fix privacy issue in some extent. However, it won't help if the export destination is too far away from the original one.
* As a bonus, it fixes file migration problem. In the current version of inkscape:
1. In the directory /home/user/Document/, create the file drawing.svg
2. Export it to /home/user/Document/drawing.svg
3. Somehow, you want to move the everything from /home/user/Document/ to /home/user/Desktop/
4. Now use the export function on inkscape. Uh oh. It still exports to /home/user/Document/
1. create an export drawing.svg in USB pendrive
2. plug the USB pendrive on another computer. Uh oh! The absolute export path no longer works.
^ That's why relativize the path can be useful.
Maybe we can set a limit of directory layers for relativization of path. So that path won't be relativized if the export file is 2, or 3 layers of directory away from the source file.

B. Encrypt inkscape:export-filename. XOR encryption should be good enough. Store the key in inkscape preference. Then store the encrypted data to inkscape:export-filename
The advantage of using this method compared with A is that it works no matter where is the export file located in
One of the problem of this idea is that it won't work if inkscape data file got deleted, or the user is launching another copy of inkscape. It is common because of the following reason:
* System upgrade
* The .svg file is stored in a portable device

C. Use both method. For absolute path, use method B. For relativized path, use method A
The issue of using this method is that this would change more code than using single method.

How do you think about it?

Since this bug is about pivacy and a relative file name is not a complete fix, I won't join the discussion on that.
I doubt you will like this direction, but frankly none of export file names, window position or sizes belong into a graphics file: that kind of Inkscape usage data is about the user and his/her preferences, not about the actual graphic, just related to it. So personally, I think this data just should be removed from Inkscape SVG altogether and go to some Inkscape cache (that does support living on a USB stick). That would solve the privacy issue.

For those interested in svgstrip, I moved it to GitHub:

drei (dreinull) wrote :

yikes, this has been around for ages and nobody seems to care. I just discovered this in one of my public projects. So now everybody with access to that file knows my username, my employer and that I'm saving files on a public cloud service. I'm not amused.

F Champigneul (frchamp) wrote :

Yes, this bug is really annoying. It's strange that nobody fixed it yet.

The sodipodi:absref tag should be removed in my humble opinion. If it's used for backward compatibility, then a better way to handle this would be to do add a specific format in the "save as" (for instance SVG Inkscape 0.48).

Thangalin (thangalin) wrote :

Here's how to fix this issue, although a better solution is needed:

1. Download Inkscape source code.
2. Edit src/ui/dialog/export.cpp
3. Insert the following lines after line 1207:

                Glib::ustring base_filename = Glib::path_get_basename(temp_string);
                Glib::ustring path = Glib::build_filename("", base_filename);

4. Change the following line (should be moved to line 1210 now) from:

                repr->setAttribute("inkscape:export-filename", filename_ext.c_str());


                repr->setAttribute("inkscape:export-filename", path.c_str());

5. Save the file.
6. Compile and install.

Now do the following:

1. Open an SVG file (e.g., drawing.svg).
2. Export it to a PNG file (e.g., drawing.png).
3. Save the SVG file.

The SVG file no longer contains the full path to "drawing.png", but should use a relative path (to the SVG file) instead.

Obviously this is a temporary fix.

A robust solution would be to introduce a checkbox option that allows "save export as relative path."

Hope it helps.

jazzynico (jazzynico) on 2016-04-11
Changed in inkscape:
status: Confirmed → Triaged
Rainer Klute (rainer-klute) wrote :

Three and a half years after the status has changed to “triaged” and still no solution in inkscape (0.92, by the way). What is blocking this issue to proceed?

Jonathan Hofinger (jhofinger) wrote :

Closing as a fix to this has been merged into master yesterday (

Please report any new issues to Gitlab. Corresponding GitLab issue:

Closed by:

Changed in inkscape:
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.