Skip to content

Agenda 2025-05-06 #12

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
TzviyaSiegman opened this issue Apr 25, 2025 · 6 comments
Open

Agenda 2025-05-06 #12

TzviyaSiegman opened this issue Apr 25, 2025 · 6 comments

Comments

@TzviyaSiegman
Copy link
Collaborator

TzviyaSiegman commented Apr 25, 2025

Agenda: C2PA and IPTC

Speakers: Leonard Rosenthol and Brendan Quinn

  • Responses to Authentic Web Questions
  • Overview of C2PA
  • IPTC work on C2PA
  • Discussion

Meeting information

Minutes

@TzviyaSiegman TzviyaSiegman changed the title Agenda 202-05-06 Agenda 2025-05-06 Apr 25, 2025
@lrosenthol
Copy link

Two other items that we will cover in the talk...

  • Relationship to Creative Assertion Working Group (CAWG)
  • Relationship to JPEG Trust (ISO 21617)

@TzviyaSiegman
Copy link
Collaborator Author

C2PA Questionnaire is available for preread

@tantek
Copy link
Member

tantek commented May 6, 2025

Additional suggested pre-read for workshop participants, given the primary topic of this meeting:

I have a conflict for most of the duration of this mini-workshop instance.

The time of this second instance is also the same as the first, which is exceptionally unfriendly to participants in Asia and Oceania, such as the author of the above pre-read.

If there is an intention to continue this mini-workshop series, I request rotating future event instances across times that are more friendly and accommodating across timezones in order to be more inclusive of global participants.

Lastly, here is another suggested pre-read on a fallacy I noted in the prior mini workshop^1:

Thank you for your attention to both of these suggested pre-reads.

Stay skeptical, my friends.

Tantek Çelik, Mozilla Advisory Committee Representative, Member of W3C Credible Web Community Group (https://credweb.org/)

^1 https://github.com/w3c/authentic-web-workshop/blob/main/minutes/2025-03-12AuthWeb.md

(Originally published at: https://tantek.com/2025/126/t1/)

@TzviyaSiegman
Copy link
Collaborator Author

Questions we didn't get to in today's session:

  1. How have the softbinding algorithms been security tested? Are any of them cryptographically secure?
  2. How does the certificate lifecycle impact credentials' validity
  3. What, if anything, prevents the IPTC signing process from being used by every user of email, web, or social media, to sign content they create?
  4. The browser certificate ecosystem discovered some vulnerabilities with EV certificates, in that it's possible to register companies with misleading names, which then justifies issuing misleading EV certificates. (This was partially discussed, but lots of questions about EV cert).

It would also be great to hear your response to @martinthomson's article above.

Thanks @lrosenthol and Brendan Quinn

@jyasskin
Copy link
Member

jyasskin commented May 7, 2025

@lrosenthol mentioned that it would be great to get browsers to display information from C2PA. Let's think about what that might look like:

It might be possible to let users go through the context menu to open a "metadata" view, which could show C2PA, EXIF, and any other interesting metadata. However, not many users are going to go to that trouble, so it probably doesn't really handle the use case of helping users know when content is authentic.

It would be possible to badge images with a little logo, but it would be important that users tend to draw the right conclusions from seeing that badge. If it's mostly GenAI companies putting C2PA into their images, and users really want to see an indication of content that's human-created, we might accidentally decrease the average user's understanding.

One could also imagine showing the signing entity's name when the user clicks the logo. That's where the EV experience is worrying: it's likely possible to register a company named "BBC" in London, Texas, and it would be important that the UI for content signed by this company not be confusable with the real BBC's content.

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 Integrity-Policy 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?

@martinthomson
Copy link
Member

@lrosenthol mentioned that it would be great to get browsers to display information from C2PA

I've heard this a few times and - because I think that this is not helpful - it's partly what motivated me to write that article.

It's technically possible to display badges if you have the necessary trust infrastructure (which invokes all of the problems that @jyasskin describes regarding who gets to assert what, and a whole lot more). But as he observes, you need to consider what that badge might represent. If it rounds to "this is AI generated", that's not going to improve the situation much.

There are also some very fundamental problems with the C2PA architecture that need to be addressed before even that sort of thing is feasible

The whole idea of a traceable chain of provenance is, to be frank, implausible. Perceptual hashing is not strong enough to rely on for strong assertions about identity of sources. And cryptographic hashing doesn't survive even the most superficial of edits. You are more likely to be able to do - as I think Jeffrey is implying - something about authenticating the "source" of content (the BBC, not the specific camera used by the journalist).

If you were to limit this to "NYT asserts that this image is authentic", that's a useful signal. But it is equally-well provided by HTTPS, with a little extra metadata. You go to their website and download the image, along with some assertion from them that this is "genuine" according to whatever criteria you might mutually agree upon. No signing necessary.

Signing might seem to help if the image is being distributed via other means, but that too is more readily addressed by HTTPS: include a link to the original point of distribution. Anyone who cares can talk to the WaPo or LA Times site to get the original, along with any original assertions about its provenance, authenticity, etc...

And then there is the question whether this information is really going to address the problems we care about. Ultimately, the best that any system like this can do is provide people with information. They still have to know how to use it. And want to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants