mczachurski
@mczachurski@socialhub.activitypub.rocks
- Comment on FEP-5837: Content Credentials for Media Attachments 2 days ago:
For me, a key benefit of C2PA is that recipients can independently inspect and validate the provenance of the actual asset. They can check signatures and content bindings, examine the recorded editing history, and inspect ingredients or thumbnails where these are included. This does not eliminate the need to assess the signer’s trustworthiness, but it means we do not have to rely solely on the publishing server’s interpretation.
When only a server-generated summary remains, that capability is lost. We receive a value such as
Trusted, but cannot independently examine the evidence behind it or explore the provenance history that was present in the original. I understand that the proposal also allows signed derivatives. My concern is specifically about implementations that distribute neither a verifiable derivative nor an accessible signed original.There is also an author-choice aspect here. A photographer may deliberately export an image with Content Credentials because they want to share its provenance. Where their editing software provides disclosure controls, they may already have made choices about which information to include. I would like platforms to respect that intention and offer preservation as an explicit option, with a clear warning about any personal metadata that will also be retained.
Privacy protection is important, and export controls may not cover every piece of embedded metadata. However, I think the author should be able to make an informed choice to publish the signed original, rather than having its verifiable provenance automatically removed during processing.
I also agree with the concern about withdrawing consent: preserving an original does not guarantee that federated copies can later be deleted. That limitation should be clearly explained before publication.
- Comment on FEP-5837: Content Credentials for Media Attachments 3 days ago:
Thank you for working on this proposal. I have a concern about relying on server-reported validation summaries when the distributed image no longer contains its original C2PA manifest.
If a server re-encodes an upload, removes the manifest, and does not sign the derivative, recipients must trust the publisher’s
contentCredentialssummary. They cannot independently verify that report against the distributed file.For example, a malicious server could distribute AI-generated images while claiming that they were camera captures with
Trustedcredentials. A recipient relying solely on those fields would have no cryptographic evidence with which to challenge the claim. It could end up displaying misleading provenance information based entirely on the publishing server’s assertions.I appreciate that the proposal explicitly identifies the summary as a publisher’s claim. My concern is that, without an independently verifiable asset, trust in the publishing server becomes the sole basis for accepting that claim.
I suspect many smaller instances will be unable or unwilling to take on the cost and operational responsibility of maintaining trusted signing credentials. The optional signed-derivative approach may therefore see limited adoption.
Could preserving and exposing the original signed asset be considered a first-class alternative? This would retain the existing signature without requiring the publishing server to operate its own signing infrastructure. Recipients could independently validate the original using their clients, browser extensions, or external C2PA verification tools.
This would not make every provenance claim inherently truthful, but it would allow recipients to check the signature, assess the signer, and verify the manifest’s binding to the actual file, rather than relying solely on a server-reported result.
In this model, additional ActivityPub properties would not be necessary for cryptographic verification, since the evidence remains available in the original file.
Preserving the original would require explicit author consent, since the file may contain sensitive metadata, including location information. An optimized derivative could still be provided for display, with a clear distinction between that derivative and the signed original.