C2PA metadata handling #662
Conversation
There was a problem hiding this comment.
Thank you a bunch for the PR!
I do question how open a standard truly is if, in practice, implementers end up hardcoding yet another centralized trust list curated by Adobe, especially when considering that a explicit design goal of the C2PA spec is "Whole Workflow Applicability". To be fair, the C2PA Implementation Guide mentions DLTs and NFTs as solutions to that problem, but I don't see them being relevant in practical applications. That said, this definitely is a topic better suited for discussion elsewhere, not on a technically good PR review 😂
I also like how you refactored the main function to return an ExitCode instead of calling exit, which plays nicer with destructors.
I just have a small nitpick before we can merge this.
|
Yes, the C2PA standard rides on hype and buzzwords. The NFT part is a handwavey nonsense just like NFTs themselves. The chain of trust for applications only makes sense for Cloud/SaaS image processing, and really works only on trust. I don't mean to endorse C2PA with this PR, only provide tools for dealing with images that contain this data. |
|
Thanks again, all is clear and looks good to me! Merging this 🚀 |
| // StripChunks::None is the default value, so to keep optimizing by default, | ||
| // interpret it as stripping the C2PA metadata. | ||
| // The C2PA metadata is invalidated if the file changes, so it shouldn't be kept. | ||
| if opts.strip == StripChunks::None { |
There was a problem hiding this comment.
Should we also strip automatically if StripChunks::Strip was used? I.e. only error if caBX was explicitly kept with StripChunks::Keep.
There was a problem hiding this comment.
This point is certainly open to discussion and could be adjusted in the future based on user feedback and similar inputs. For now, I believe the logic implemented in this PR offers a good default behavior without overburdening the Strip and Keep variants with additional complexity, as users relying on them are, in my view, more likely to be sensitive to different chunk selection strategies. But I don't have a strong opinion one way or another, caBX is by design a bit of a weird chunk anyway.
There's Adobe's initiative to embed "provenance" metadata in files along with a cryptographically signed history of file changes. The metadata is invalidated if the file is changed in any way without updating the signature. Only parties trusted by Adobe are allowed to sign files.
AFAIK an open-source program can't be given a private key to sign its changes, so
oxipng's only choices are to either avoid changing the signed files at all, or strip the invalidated c2pa metadata when optimizing files.I've made
oxipngstrip the c2pa metadata by default. If explicit--keep=caBXis used, then the file will be skipped with a warning "The image contains C2PA manifest that would be invalidated by any file changes".