[Alligaturtle]

I agree with this sentiment. Years ago, I asked around at one of the smartphone companies whether it would be possible to certify to an end user that a photo is either:

1) Authentic and only lightly edited with image manipulation software (e.g., cropped, color balanced, or text placed over top of the image) 2) Produced on a phone that has had to go through hardware hacks

Note that the guarantee in (1) wouldn't prevent someone from taking a photo of a TV screen. When I asked that original question, I had quite a few more details about how the certification might be done, how the credentials would be hosted, and how the results would be shown on a website.

Anyway, just asking this question was met with a storm of negative responses. I counted two dozen messages that were either neutral (asking for clarification) or else outright hostile before the first hesitantly positive message. My favorite hostile response was that allowing people to certify images as real would steal peoples' rights. I didn't follow the logic, but the guy who made the argument was really into it.

There were lots of comments about how using AI would be a better solution, some commenting on how Cannon already did it (and messed up gloriously), others stating they didn't have faith in hardware... it makes a fella never want to ask a question again.

In the end, I got an expert to speculate that the technology currently exists, and has existed for 5-10 years, to do this with a modern smartphone. However, unless a high-level engineer or executive argues that providing this feature will somehow be a competitive advantage, there is no appetite to provide this kind of feature.

[danShumway]

> My favorite hostile response was that allowing people to certify images as real would steal peoples' rights. I didn't follow the logic, but the guy who made the argument was really into it.

My guess is likely because it seems like this would be impossible to implement without adding DRM to the smartphone and/or locking down Open Source image editors out of the attestation process. You would need to prevent access to the software, firmware, etc... otherwise the device could be virtualized or the program recompiled to circumvent the signature.

And for obvious reasons there's going to be pushback to adding that kind of DRM to smartphones. The tech does likely exist; this sounds to me like just normal attestation? It would likely hook into something like the Play Integrity API. A lot of people already hate the Play Integrity API though.

It's not the tech that's the problem, it is as you say, that people are hesitant to do it because it would require locking down the phone's software stack in a way that is widely understood by many developers and user advocates to be anti-user and in contrast to user rights to control their own devices and load their own software and/or firmware onto their devices.

I could maybe see an argument introducing some kind of signature to a raw camera input in firmware before it ever reached the user at all -- mostly just because devs seem to have given up the fight about custom firmware on a phone in general. But if you're talking about the phone signing the image after light editing like a crop has happened, at that point you're talking about moving this signature into user-space code, and while I'm sure that problem could have been explained better to you by the devs, it's not surprising to me at all that you'd get a hostile response to that suggestion because I don't see how it would be possible to do that without locking down user-space code.

[AnthonyMouse]

> mostly just because devs seem to have given up the fight about custom firmware on a phone in general

This is more like prioritization. If you can't even install your own apps, you focus on the gorilla holding a knife to your throat.

> But if you're talking about the phone signing the image after light editing like a crop has happened, at that point you're talking about moving this signature into user-space code, and while I'm sure that problem could have been explained better to you by the devs, it's not surprising to me at all that you'd get a hostile response to that suggestion because I don't see how it would be possible to do that without locking down user-space code.

That's the part that isn't a problem. If you had an existing image with an existing signature, you could modify it and store the changes as a diff against the original. You don't need or even want to sign it again, you just keep the original and its signature intact. Compressing two images that are nearly identical against each other shouldn't even have particularly high overhead.

Doing it this way would also be more secure because you wouldn't have to trust the device doing the modifications in any way.

The problem continues to be how to create such a signature to begin with, without depriving the user of control over their own property or leaving the keys inside of devices that are in the physical possession of every attacker in the world.

[danShumway]

> That's the part that isn't a problem. If you had an existing image with an existing signature, you could modify it and store the changes as a diff against the original.

I think this glosses over things a little bit. Are you going to transmit the original and the diff to every image viewer? People are talking about doing these checks on clientside devices, not just having an attestation check somewhere else.

Ultimately the only way you can check this is to give someone the original and the signature to compare. Want to blur or censor a face? Tough. Want to crop? Tough. And the person doing that verification would want to be able to look at the photograph to tell how extensive your edits were.

Technically what you're saying is true in that you could do diffs this way, but in practice you'd have to commit to publishing the pre-edit photo. We're also suddenly no longer talking about a behind-the-scenes process that just puts a little green check on the photo or something; because edits can be anything and only the original photo would be signed; so the "verification" in your image editor would now be a software stack that shows you the original photo alongside the edits I guess?

----

> The problem continues to be how to create such a signature to begin with, without depriving the user of control over their own property or leaving the keys inside of devices that are in the physical possession of every attacker in the world.

I'm quibbling though, I think we're mostly in agreement. This is the DRM aspect that people seem to be forgetting. Commentary about attestation is not making the obvious and direct comparison that controlling device behavior is already something companies are trying to do and failing at.

[AnthonyMouse]

> Ultimately the only way you can check this is to give someone the original and the signature to compare. Want to blur or censor a face? Tough. Want to crop? Tough. And the person doing that verification would want to be able to look at the photograph to tell how extensive your edits were.

Well of course they would. Otherwise what are you even trying to attest? Otherwise someone could take an image from a camera, replace literally every pixel with whatever they want and then claim it's the same image.

[danShumway]

Agreed, but at that point, why have the edits anymore; particularly if you expect people to actually check.

Obscuring faces for privacy, cropping would no longer work. And even minor touchups like lighting would be of questionable value since you're expecting users not to look at the edited photo or at least to primarily look at the edited photo next to the original.

I suspect in practice that doing edits on top of a signed photo would be basically the same as not having editing capability at all; and even that's assuming users would compare the edited and non-edited versions at all, which is not a safe assumption in my mind given how hard it is to even get people to click into a full article past the headline.

[AnthonyMouse]

The value isn't that the users are going to do it under normal circumstances. They would see the edited photo. You'd only care about the signature if its provenance came into question.

You could also handle cropping and omissions by having the original device sign the picture as a grid of individual tiles. Then you could omit some and still prove that the others are original.

[not2b]

I could take a photo of someone else's photo with a camera that cryptographically signs the image. Then I suppose I could claim that my photo is the original (see? it is signed, with a camera that maintains a chain of trust) and the original photo is now the stolen one. To pull this off it would have to be a really high quality camera that would make an accurate copy.

Perhaps something like this is what your hostile responder was thinking of.

[tornato7]

But if both images had a timestamp in the signature, wouldn’t you be able to prove that the original was taken first?

[AnthonyMouse]

How does the device know what time it is?

What happens if the original was taken with any existing device that doesn't make signatures, or is a model that subsequently had its keys revoked?

[tornato7]

You can store the hash on a public Blockchain and the timestamp of that transaction will be verifiable.

[AnthonyMouse]

If everybody does that with everything, blockchains get infeasibly large. If not, anybody can go and register things on a blockchain that the original creator didn't and then claim they were first.

[tornato7]

You would just use any sort of aggregation scheme to include multiple hashes at once. Even concatenating 1000 image hashes and hashing that would allow you to prove later that they were all included.