@afre you are right, but in our case, signing is optional, and relates only to a given camera (itself authenticated quite seriously by the German post authority, if I understand correctly.
Then at the time of capturing the pic, inside the camera, the owner can, optionally again, add his name or whatever signature he wants.
Nobody can then change it, short of deleting it, while image processing apps can (and, IMHO, should) maintain the signature while various processings are added.
Then I, as a customer of my favorite newspaper, can verify their nice exciting image was not invented, or copied from a similar event 2 years ago.
This, is significant to me. Far more, indeed, than protecting my own pics, dealing with copyrights etc.
I remember years ago - coming across a Canon proprietary system for forensics that signed images as written to card within the camera. The community canon magic lantern firmware supports signing of images as written to card within the camera. I notice that reuters has a similar (competing) CAI framework system. A few years ago Kodak proposed a blockchain framework for images to support image sales, ownership delegation and authenticity.
I agree that a common open standard supported by all is typically a good idea. At first glance this CAI scheme seems to be heavily supported/promoted by Adobe (?)
I cannot find any public implementation docs - but from their simplified FAQ - it is just a framework to sign the metadata block and data block of the image at every step along the creation, editing and display path. To have end-to-end authenticity it would require the camera to support, as well as the editing software, as well as the display software. I suspect that it will be quite some time before typical consumer cameras will support CAI as standard.
The problem is the editing software⊠as being opensource and therefore, open to manipulation - it opens a can-of-worms - and complicates significantly the overall implementation. At first brush - keeping track of image edits and signing them is not a significant issue as DT & RT already keep track of editing history and can save this history within the metedata. But not only would you need the CAI framework for the image within all DT & RT modules, but the editing software would also need to have an authenticity framework all the way from written sourcecode to code storage to compiled version to deployed version to running version. This is something that Adobe can control (reasonably well being a closed code shop); but is something that DT or RT as opensource projects would I think struggle to implement with limited resources. It would mean only âofficialâ versions would support CAI with complete authenticity - self compiled versions would be considered tainted.
If there was the will - all issues could be mitigated by engineering and processes & procedures. In opensource just takes (lots of) time and effort. To fully support the CAI framework; would need engineering, processes & procedures as well as infrastructure similar to what is needed for compiling and distributing signed linux kernels. Not impossible but not for the faint-of-heart.
DT & RT could get 80% of what benefit there might be from the CAI framework by just signing the RAW image on import and storing that signature within the exif block or xmp file; then signing the editing history as well as the final image data upon export and storing that signature within the exif block. You could actually create a python script using GNUPG to do this right now. You wouldnât be able to prove authenticity back to the camera - but it would allow you to prove which RAW image was used, what editing history resulted in the finished image, and that the finished image has not been modified outside of that editing history.
