… just delete it all before posting (in a copy of course).
I use the package exiv2
from which: exiv2 rm your-image-file
Per the man page, exiv2 supports a range of image formats (as metadata containers) and, for a given image format, a range of different metadata types. I’ve really only used it for JPEG, for which it works well for me (not just for deleting, but also for viewing, and for changing / fixing).
eog is pretty good if you click “Show Details”. GIMP can also do it (view or edit). In either of those cases if you wanted GUI rather than command line.
Can I guarantee that any of those three options covers all metadata? Nope. Not without viewing and understanding the source code, which I have not done.
There is always the risk that a tool comes upon an image format / image metadata format that it doesn’t understand - and it would become important as to how the tool then handles that.
In the context of this topic, my only interest is in deleting all metadata. I am comfortable that exiv2 rm does the job i.e. works as advertised.
I’ve said it before but I’ll say it again … Thunderbird and Firefox should offer this functionality out-of-the-box i.e. by default strip out all metadata on transfer but of course you get to configure if you want the default the other way and you get to configure whether you want the choice to override that each time (a check box on a dialog box, I guess).
Guys, thank you. I am going to use these tools. The only thing I have to add to this conversation is that I want to share my pictures. I accept some risk of bad actors in order to express my humanity. Come what may.
It is probably worth mentioning two consequences of, and complications with, deleting all metadata from a JPEG file.
You will lose the thumbnail. Whether that is a problem at all depends on whether the receiving software uses the thumbnail, and in what way, and whether it is capable of regenerating the thumbnail if it needs the thumbnail. (If the software relies on the thumbnail and has to regenerate the thumbnail then the software may operate more slowly, particularly on first run.)
You will lose the orientation tag. That means that if the original photo was taken with the image capturing device (phone or digital camera) rotated out of the normal orientation, the image will display incorrectly (will display rotated). Not all software is even capable of interpreting the orientation tag anyway. To address that, after returning from holiday and uploading all the photos, I do a bulk reset of the orientation tag with
mogrify -auto-orient *.jpg
That way the photos display in the correct orientation regardless of whether the displaying software supports the orientation tag and regardless of whether the orientation tag is subsequently stripped (by exiv2 or anything else).
In an ideal world exiv2 would be capable of doing a selective strip (maybe it is!), so as to leave just these two items (if the user so desires). Note though that the thumbnail is usually implemented by nesting a JPEG file inside the JPEG file and hence it is not safe simply to ignore the thumbnail if not stripping it. That said, the nested JPEG thumbnail usually has almost no metadata, if any at all.
Some metadata cannot be deleted, such as file creation date. In which case, you may wish to modify it to Unix epoch to prevent revealing sensitive information.
To be clear, the intention in the OP was to discuss metadata that is represented inside the contents of the file for image formats - and the privacy and security risk that therefore arises if you transfer that (entire) file outside your network e.g. email it, upload it to a web site, or even just put it on removable media and give it to somebody. (The same issues arise with other container formats, such as audio and video.)
Otherwise you make a valid point. For some threat models, you also have to be concerned with filesystem metadata. I don’t think it would be usual for filesystem metadata to leak when emailing or uploading to a web site (but stand to be corrected) but if using removable media then that could be an issue (and your proposed mitigation would be one approach). The file name can of course leak if the client software uses that in e.g. a MIME header (for email or web site upload).
Digressing slightly: I was reading the other day about someone anonymous who was potentially identified and part of the identification process involved noticing that all the files had (different?) even timestamps (because %$#*@^ older Windows filesystems only have 2s precision).
