I agree. The issue of data given away by metadata is kind of important and should definitely be taken care of.

Actually I might even say that keeping metadata *by default* when re-exporting an image may be slightly irresponsible because people may be leaking important information without even realizing it.

I am not setting it a blocker for now, but at least I put this on 2.10 so that it stays on sight.

Quoting from Bug 789731 - "GIMP adds a considerable amount of metadata in the form of XMP values that are not supported by ViewNX2 - which barfs on the "after" versions, declaring them to be "unrecognized file type."

Software that barfs on encountering GIMP/unknown metadata would be another reason to have the user option to not embed any XMP metadata in an exported image. This would be less important from a "responsibility" point of view. But it would be a nice side-benefit of having the option to not export metadata, if the user's only other option is to delete the metadata by hand after every export to avoid triggering a crash in some other software.

digiKam has crashed in the past when encountering unknown metadata in XCF files:
http://digikam.1695700.n4.nabble.com/Bug-224697-New-Crash-with-gimp-xcf-files-with-metadata-td1734487.html

I don't know about today's digiKam, because a couple months ago I recompiled the relevant "image-format reading" KDE software to not try to read XCF files, to avoid repeated crashes when digiKam encounters 2.9 (and some 2.8) XCF files. It would be a lot of work to "undo" these changes to check to see whether the metadata was the/a reason why digiKam 5.8 crashed upon encountering these XCF files.

Let's put in the blocker list.

I completely agree that we need some configurability for metadata export,
privacy (not technical issues of other apps) is my main concern.

Elle, is there anything technically wrong with the metadata, or do other
apps just not properly deal with it?

(In reply to Michael Natterer from comment #4)
> Elle, is there anything technically wrong with the metadata, or do other
> apps just not properly deal with it?

I think it's more a matter of software A not recognizing software B's particular metadata field, sometimes from using different versions of exiv2. Tomorrow I'll check some KDE bug reports, and also run some GIMP-exported metadata past exiftool, to see if exiftool reports any problems.

(In reply to Elle Stone from comment #5)
> (In reply to Michael Natterer from comment #4)
> > Elle, is there anything technically wrong with the metadata, or do other
> > apps just not properly deal with it?
> 
> I think it's more a matter of software A not recognizing software B's
> particular metadata field, sometimes from using different versions of exiv2.
> Tomorrow I'll check some KDE bug reports, and also run some GIMP-exported
> metadata past exiftool, to see if exiftool reports any problems.

As far as I can tell, in the past when digiKam has crashed after trying to read various files, where embedded metadata was the problem, the problem seems to usually be a case where digiKam didn't correctly handle a crash that actually happened in exiv2.

As far as I can tell from checking two sample source image files, there's nothing technically wrong with the metadata that GIMP writes to the various metadata fields. For a camera-generated jpeg opened using GIMP, and a camera raw file opened from GIMP using RawTherapee:

* I opened both files with GIMP and then exported them to disk without adding any new metadata, and checked the metadata using exiftool. The jpeg metadata files were a match and the output from the raw file probably was a match, but I didn't do a line-by-line check.

* I used GIMP's metadata writer to add additional metadata. I filled in all the available metadata fields, using random entries to fill in dicom/GPS/other fields for which I had no actual metadata to try to add, and exported the image as a jpeg, png, and tiff. Exiftool had no trouble reading the metadata GIMP embedded in the exported files, even when the source image was a camera-generated jpeg or raw with lots of camera-saved data, plus some digiKam-created data, plus all the metadata added using GIMP's new "edit metadata".

* I opened the jpeg with all the added metadata, using RawTherapee, darktable, geeqie, and showfoto, and there weren't any problems. None of these other image editors showed *all* of the added metadata, but they all showed some of it.

How I see the improvements:

(1) By default, the various formats embedding metadata should not have the features checked by default ("Save Exif|XMP|IPTC data" -> if not mistaken, if we have all 3 unchecked, there will be no metadata leak, am I wrong? Or are there other data we need to care of?).

(2) We should have the options in the preferences to override this default (some people may want to have all metadata always exported), possibly with a nice warning message "Careful, this can be sensitive personal data, blabla".
This could be a new tab "Image Export", just next to "Image Import".

(3) I would suggest to add a few metadata editing there for the few ones which makes sense as "could be the same for whatever I produce", in particular stuff like Author stuff, maybe also Copyright metadata, company, etc.
Anything entered here would be used as metadata unless you specifically overrided it in the metadata editor.

(4) Maybe move the "Comment" field from "Default Image" tab to "Image Export" tab in Preferences. As I understand, this is a metadata which is possibly applied to any exported image, not just the new images (which is what "Default Image" is more about).

And to remove the blocker, I believe that point (1) at least should be dealt before 2.10. That removes at least the security issue of leaking data by mistake.

Implementing (2) as well would be nice too though, so that people heavily relying on metadata don't complain that they have one more click to do to export with metadata. But I don't see this as a blocker.

(In reply to Jehan from comment #7)
> How I see the improvements:
> 
> (1) By default, the various formats embedding metadata should not have the
> features checked by default ("Save Exif|XMP|IPTC data" -> if not mistaken,
> if we have all 3 unchecked, there will be no metadata leak, am I wrong? Or
> are there other data we need to care of?).

Making a quick check, opening a tiff containing about a million bits of metadata embedded from the camera, digiKam, and GIMP, and then re-exporting it under a new name with all the boxes unchecked, exiftool reports only one bit of embedded metadata, that being the "Image Description", which I had previously written using GIMP's "Comment" field in the export dialog (while exporting the image previously as a jpeg).

Checking more carefully, duh, I didn't notice the rather large "Comment" field in GIMP's *tiff* export dialog, though in fact I wrote the comment while exporting the image as a jpeg.

Checking even more carefully, there are three metadata fields filled with what could be considered a "comment":

1. "Description", into which I had written "Description field in GIMP metadata writer" using "Image/Metadata/metadata writer".
2. "User Comment", into which the information in GIMP's "Comment" box is written. I had typed in "Here's a test comment written in the GIMP jpeg export dialog"
3. "Image Description", which also contains the information written into GIMP's "Comment box":  "Here's a test comment written in the GIMP jpeg export dialog"

So "2" and "3" are two separate metadata fields, to which GIMP is asking exiv2 to write the same information. 

Why is "Description" handled differently than "Image Description/User Comment"?  See:

* http://dev.exiv2.org/issues/985
* http://www.metadataworkinggroup.com/pdf/mwg_guidance.pdf, Section 5.2.
* https://ninedegreesbelow.com/photography/dam-software-metadata.html#caption - for fields digiKam did write to, and maybe still writes to, when filling in "comment/description" fields.

I don't have any suggestions regarding what "should" get written where by GIMP, except that it would be nice if "digiKam/RawTherapee/PhotoFlow/darktable/geeqie/other free-libre softwares" would all agree with each other. Maybe a topic for the next libre-graphics meeting?

Oh, wait, all three fields will hold the default comment from Preferences, unless/until a new comment is written into the Description box using the metadata editor. This field is for XMP metadata. It might be preferable to keep all three "comment/description" fields in synch with one another, depending on who's advice/precedent you follow (I don't know what "[File] Comment" is):

exiftool -s -G red.jpg (empty Description tag in metadata editor):
[File]          Comment                         : default comment for all images
[EXIF]          ImageDescription                : default comment for all images
[EXIF]          UserComment                     : default comment for all images

exiftool -s -G red.jpg (after writing the Description tag and re-exporting)
[File]          Comment                         : default comment for all images
[EXIF]          ImageDescription                : default comment for all images
[EXIF]          UserComment                     : default comment for all images
[XMP]           Description                     : Description written into the Description box of the Description panel using the metadata editor.


Separate question: Should GIMP even be providing such emphasis (in the default New Image dialog and also in the export dialogs) on making it easy to write a Comment (aka Image Description), into exported images' metadata? Could this simply be removed from the UI and left to the metadata writer? Maybe for 3.0, if this is part of 2.X API?


Also, should the option to export or not export the metadata be hidden in an "Advanced" box that has to be clicked to make sure the boxes are, or aren't, checked? Personally I'd like the "Advanced" boxes to vanish from all the export dialogs, there's nothing advanced about what's hidden behind the "+" signs.


Hmm, a comment in a new image, taken from default comment in Preferences, doesn't show in the metadata viewer or editor, until the image is exported and then reopened.

So now at least, the plug-in don't export metadata by default. Hopefully I didn't miss any format which has metadata handling (well there was PSD, but it doesn't look like there is any dialog giving choice, and anyway, this is a work format, same as XCF, so having the metadata there is less of a problem).

commit 096debb0fdb1bc41ca7b2f57f391285cf965539e
Author: Jehan <jehan@girinstud.io>
Date:   Thu Jan 11 00:39:22 2018 +0100

    Bug 790552 - do not save metadata by default.
    
    This is a privacy concern. Whereas importing metadata is usually a good
    idea, exporting it should be a conscious action. A lot of private data
    can be leaked through metadata and many people don't realize it (which
    also usually means they don't need it). On the other hand, the people
    who realize it are the ones who would explicitly edit the metadata and
    check what they want to be exported or not.
    
    This is only a first step. Some people may want to always export the
    metadata and for these people, there should be abilities to change the
    default.

 plug-ins/common/file-png.c     |  6 +++---
 plug-ins/file-jpeg/jpeg-save.c |  6 +++---
 plug-ins/file-tiff/file-tiff.c | 11 +++--------
 plug-ins/file-webp/file-webp.c |  6 +++---
 4 files changed, 12 insertions(+), 17 deletions(-)

Mitch: could you review the branch wip/bug790552-metadata-preferences please? I implemented setting metadata preferences.
Can I push this to master?

commit 6149bbe85bb3a1525a72a47b1923e44acdd07dd0
commit 68b12a380a2624d37e7d1e5ef5674536a77dc5a8
commit b2e86c40ebe68c3ee85b0d6b808247bb90e5d957
commit afd808633fc4c991e21209e9d58b885cca7e316f

The main issue raised (privacy concern) is now fixed.

There are now preferences for metadata handling, and the default is to not export anything. These settings are now visible by the plug-ins, and all (hopefully? I did PNG, JPEG, TIFF and WebP; apart from PSD which has no dialog at all, I didn't see other formats exporting these metadata) relevant file plug-ins have been updated to use these as defaults (these defaults can still be overrided by per-plugin saved settings, previous run settings, and finally through the dialogs when run interactively, of course).

commit c49b8463bd199bff084dd7136f96f99ab8bb842d
Author: Jehan <jehan@girinstud.io>
Date:   Thu Jan 11 01:53:35 2018 +0100

    app: adding metadata handling as "Export Policies" in preferences.
    
    These preferences are currently not used anywhere. This is the next
    step.

 app/config/gimpcoreconfig.c      | 42 ++++++++++++++++++++++++++++++++++++++++++
 app/config/gimpcoreconfig.h      |  3 +++
 app/config/gimprc-blurbs.h       |  9 +++++++++
 app/dialogs/preferences-dialog.c | 20 +++++++++++++++++++-
 4 files changed, 73 insertions(+), 1 deletion(-)

commit 4c4fa84f854787839398b06f355fe5364e76b73b
Author: Jehan <jehan@girinstud.io>
Date:   Thu Jan 11 05:14:07 2018 +0100

    app, libgimp, libgimpbase: new gimp_export_(exif|xmp|iptc)() functions.
    
    These allows plug-ins to know the preferences regarding metadata.

 app/plug-in/gimppluginmanager-call.c |  6 +++---
 libgimp/gimp.c                       | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 libgimp/gimp.h                       |  3 +++
 libgimpbase/gimpprotocol.c           | 12 ++++++------
 libgimpbase/gimpprotocol.h           |  6 +++---
 5 files changed, 72 insertions(+), 12 deletions(-)

commit 3061268e25785f858d6679b37685818af9d91f4f
Author: Jehan <jehan@girinstud.io>
Date:   Thu Jan 11 05:17:59 2018 +0100

    libgimp: gimp_image_metadata_save_prepare() uses metadata preferences.
    
    gimp_image_metadata_save_prepare() now back to suggesting metadata
    flags, but this time with reasonnable base. It indeed uses the presence
    of particular metadata, but also whether the preferences asks for this
    metadata to be exported by default or not.

 libgimp/gimpimagemetadata.c | 29 ++++++++++++++++++-----------
 1 file changed, 18 insertions(+), 11 deletions(-)

commit 82f6baf2bbbd760f4bf33f997288f4f3a9fa7ce5
Author: Jehan <jehan@girinstud.io>
Date:   Thu Jan 11 05:21:32 2018 +0100

    plug-ins: file export should follow preferences regarding metadata.
    
    Various plug-ins exporting metadata should now follow preferences, which
    would override any default. Of course these preferences can still be
    overriden by saved settings (global parasite), previous run settings,
    and finally through the GUI when interactive.

 plug-ins/common/file-png.c          | 36 +++++++++++++++++++++---------------
 plug-ins/file-jpeg/jpeg-save.c      | 17 +++++++++++------
 plug-ins/file-jpeg/jpeg-save.h      |  1 +
 plug-ins/file-jpeg/jpeg.c           |  9 ++++++---
 plug-ins/file-tiff/file-tiff.c      |  5 +++++
 plug-ins/file-webp/file-webp-save.c | 26 +++++++++++---------------
 plug-ins/file-webp/file-webp-save.h | 16 +++++++++-------
 plug-ins/file-webp/file-webp.c      | 22 ++++++++++++++++++----
 8 files changed, 82 insertions(+), 50 deletions(-)

Created bug 792441 for further tweaking, and improvements of metadata preferences, default fields (comments…) and whatnot.

At least the main issue (the privacy one) has now been taken care of.

Well... even though I raised the privacy issue, I think I would prefer
if we exported everything by default and leave the disabling to the
people with extra paranoia...

I can already see the flood of bugs "GIMP destroyed my metadata"...

For the record, as discussed on IRC: I find it more responsible to not export them and leave the people heavily relying on them to check the "always export" checkboxes.

It is more of a question of the people who don't want their private info to leak in metadata probably don't even know that exists so they will just give out their info (without even realizing how). On the other hand, people who *want* metadata, well… they know it exists. So they are likely to search the feature and check that the exported JPEG has metadata in it.

Also about the flood of bugs, I can as well imagine the flood of "GIMP is leaking private data" bugs, especially in current all-about-privacy-security atmosphere.

This will just be different people.

But I see what you mean too and I can't say I have the ultimate answer. I let you decide on this one, I guess.

Do we actively hunt for meta-data in the image, or just not export the relevant well-known parasites?

What would happen if e.g. some filter created copies of the meta-data and stored them under different names? Wouldn't we give the users a false sense of security then?

This is not necessarily an argument for or against any setting, more for the way it'll be advertised.

(In reply to Michael Schumacher from comment #17)
> Do we actively hunt for meta-data in the image, or just not export the
> relevant well-known parasites?

We don't "hunt for metadata" or anything. We just don't export them in our plug-ins. I'm not even sure what you mean since the image does not exist before export so there is nothing to hunt for.
And there are no "well-known parasites" anymore (but for one, see below). Metadata is now a core feature of GIMP and saved as their own object within the GimpImage structure.

Also the "Comment" which you can set in preferences is still exported. Cf. bug 792441 which has been created for such refinement (and will likely happen after 2.10). This is the only remaining "hacky" metadata (which is indeed still implemented as parasite, it would seem, unlike the rest).

And we have new API functions so that any third-party plug-ins can know the settings and act according to user preferences.
If they don't do so, that's not GIMP. Ask the third-party developers to respect your preferences.
 
> What would happen if e.g. some filter created copies of the meta-data and
> stored them under different names?

Do you have examples of what you mean?
This looks as either a bug, a feature or a side channel attack depending on what you mean. ;-)

> Wouldn't we give the users a false sense of security then?
> This is not necessarily an argument for or against any setting, more for the
> way it'll be advertised.

In the end, GIMP is not a metadata management software. To this day at least, GIMP is really lacking on many points and I would not advise on using GIMP to have a strict control of your metadata. Many software still do this better.
Actually if you are an activist or do any activity which requires you to be careful with any image you send (or simply you want to keep strict control of what data you give away), I would urge you to get proper tools for metadata handling. GIMP would be a good tool in your workflow, but it cannot be the main metadata tool. Not today at least.

The metadata features we are getting for 2.10 won't be perfect and our metadata editor has many bugs, but that is a first step, I guess. If we have to wait for perfection before shipping a feature because we don't want to "give a false sense of XXX", then we never ship anything.