Browser API for C2PA

[chrisn]

In #12 (comment) @jyasskin said:

The idea came up of providing a browser API to parse C2PA data. That's probably not useful: the server can provide a JS library to do the same thing, and it can write whatever it wants to the page's UI. However, I could imagine extending the w3c/webappsec-subresource-integrity#133 and https://github.com/WICG/signature-based-sri proposals to look at embedded signatures. Then images on, say, the BBC's site, which weren't signed by the BBC's key, could fail to load instead of showing unauthorized content. @chrisn, would that be attractive?

[chrisn]

Thank you for sharing those proposals, I'll take a look.

The idea came up of providing a browser API to parse C2PA data. That's probably not useful: the server can provide a JS library to do the same thing, and it can write whatever it wants to the page's UI.

This is the approach being taken today, e.g., on LinkedIn (example post from IPTC). The main motivation for browser support is to avoid spoofing by the page by elevating the surfacing of provenance information to browser UI.

Note, though, that in the LinkedIn example, the image as seen by the browser doesn't carry a C2PA signature - the original image did on upload, but this wasn't preserved by the site on resizing for display. Leonard will know more, but I believe that C2PA is working on solutions for this.

Then images on, say, the BBC's site, which weren't signed by the BBC's key, could fail to load instead of showing unauthorized content. @chrisn, would that be attractive?

Yes, or the browser could surface that there's a mismatch between the content and signature rather than failing to load.

[jyasskin]

To carry a signature across edits like resizing, you need C2PA's soft bindings (@lrosenthol in case I've misunderstood). But IIUC, the soft bindings aren't cryptographic-strength: an attacker is expected to be able to produce a completely different image that soft-binds to a signed original. That means that browsers can't automatically trust a soft-bound signature. Instead, LinkedIn could re-sign the results of its edits, and the browser could show the user (somehow) that the image served by LinkedIn was also signed by LinkedIn.

Then, if the image turns out to be false, fact-checkers (#18) might be able to use the soft-binding to allocate blame to the right entities. But that fact-checking process has to be a human one, rather than automated in a browser. (Although maybe browser UI has a place in connecting the humans to each other.)

[chrisn]

Instead, LinkedIn could re-sign the results of its edits, and the browser could show the user (somehow) that the image served by LinkedIn was also signed by LinkedIn.

This is the solution I'd hope to see, rather than relying on soft bindings, I only mentioned that as an aside really.

[lrosenthol]

To carry a signature across edits like resizing, you need C2PA's soft bindings (@lrosenthol in case I've misunderstood).

That is one approach - certainly. The other approach is that the thumbnails themselves are also signed, with provenance expressing what took place (e.g., resizing and probably transcoding). This is what a number of sites that have added C2PA support are doing. And you don't necessary need to embed the Content Credential if you want to save space for your thumbnails - by leveraging the IANA standardized http link header for this purpose.