First look at C2PA

Via Nina Schick’s most recent YouTube, I learned about something called C2PA. Per their website’s description:

The Coalition for Content Provenance and Authenticity (C2PA) addresses the prevalence of misleading information online through the development of technical standards for certifying the source and history (or provenance) of media content. C2PA is a Joint Development Foundation project, formed through an alliance between Adobe, Arm, Intel, Microsoft and Truepic.

So it appears to be one of these industry conglomerate groups aimed at creating a standard that can be used across the board. There are many groups like this, with varying degrees of effectiveness. In this case, it appears the bulk of the work is in capturing and cryptographically signing certain metadata related (hopefully) to the provenance of (some) digital artifacts.

As Wikipedia details it further:

Part of the stored metadata can be, for example, the name of the hardware and software used for storage, such as a camera, smartphone, camera app, or editing program. Further contents can include the location and time of a recording, a list of performed editing steps as well as information about authors and publishers of a file… In addition, a digital fingerprint (hash code) of the file’s payload (photo, text…) is stored. For visual payloads, there is an option to store a reduced representation of the content (thumbnail).

The idea then seems to be that the C2PA-compliant provenance data can then somehow “travel” with a given artifact as it appears across the web.

There are a few structural details of how the data is organized I also want to capture here, especially as they might easily be transferred to AI attribution efforts as well. Briefly:

The basic element of C2PA data structures are so-called “Assertions”.^[13] Assertions contain statements about the file content, e.g. about processing steps that have been performed. The hash value of the file’s payload is also stored in an assertion. […]

A list of links to all assertions is stored in a data structure called “Claim”.^[14] This is also where the software stores the hash values calculated for all assertions. To protect the claim and the hashes stored in the claim from tampering, the storing system generates a digital signature for the claim. This signature contains an encrypted hash value for the content of the claim. […]

The signature of the claim, the claim itself, and the entire assertion store are part of a higher-level structure called “Manifest.” […]

If the respective file format allows for, the metadata is stored directly in the file. If this is not possible, as with plain text files for example, the data is stored in a sidecar file.

There’s a whole lot of hashing going on here! But this general structure of the Assertion > Claim > Manifest is interesting.

As someone who has worked a lot in the disinformation space though, I can see how this whole thing is full of holes. And since it’s not widely supported (and unfortunately end users don’t seem to care all that much about metadata trails while they are doomscrolling on the toilet), it’s unlikely to make a huge impact apart from being “a good idea.”

Is it even a good idea though, I’m left wondering after reading this part on the Wikipedia page:

The cryptographic integrity of a C2PA-compliant file does not provide evidence that it contains an authentic representation of reality. Instead of the scene captured by the lens, a C2PA-compliant camera or camera app could store and cryptographically sign a freely invented, e.g., AI-generated, image. Similarly, any C2PA-compliant system can freely invent or arbitrarily falsify any metadata that is to be stored and then properly sign that data. The result would be a file that fully complies with the technical specifications of the standard. A C2PA-compliant check would show that the hashes stored in the signatures match the contents of the file and therefore declare the file valid in terms of the C2PA standard.

Statements as to whether a stored content adequately reflects reality are not possible within the scope of the C2PA standard.

So the metadata/signature are to some degree falsifiable, and there’s no guarantee that any of a file’s contents actually reflect reality. That sounds… not that good?

At the same time, I freely admit these are difficult & complex problems to solve with any degree of certainty. And any steps taken are better than no steps taken. Unless, that is, those steps bring us false confidence about things that aren’t true once we scratch the surface.

That said, again, there are some elements here which seem compatible to questions of generative AI provenance and attribution. But in casual initial scans, I don’t really see it explicitly covered in the specification. Given the dates of early 2022, I guess that is not a tremendous surprise, since generative AI didn’t really explode until the second half of last year.

In any event, I will continue poking at this and spend some time more carefully going through the spec & reporting on any potentially related elements for AI attribution.