5 ms·

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

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.

not2b 3y ago
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 3y ago
  But if both images had a timestamp in the signature, wouldn’t you be able to prove that the original was taken first?
  - AnthonyMouse 3y ago
    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 3y ago
      You can store the hash on a public Blockchain and the timestamp of that transaction will be verifiable.
      - AnthonyMouse 3y ago
        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 3y ago
        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.
        AnthonyMouse 3y ago
        That just moves the problem from where to store the blockchain to where to store the concatenated hashes. If this is some cloud provider, what are you getting from a blockchain? Just have the cloud provider do the certification. If they betray you or go out of business you've lost your hashes anyway. If it's stored on the endpoint device, you can't prove it anymore if the device gets lost or damaged. In theory people could back them up, but we all know perfectly well that ordinary people are not going to do that unless it's automated. So then you're back to storing them in a distributed system, i.e. making them a necessary part of the blockchain. And then it gets too big.
danShumway 3y ago
> 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 3y ago
  > 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.

not2b 3y ago

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 3y ago
But if both images had a timestamp in the signature, wouldn’t you be able to prove that the original was taken first?
- AnthonyMouse 3y ago
  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 3y ago
    You can store the hash on a public Blockchain and the timestamp of that transaction will be verifiable.
    - AnthonyMouse 3y ago
      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 3y ago
        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.
        AnthonyMouse 3y ago
        That just moves the problem from where to store the blockchain to where to store the concatenated hashes. If this is some cloud provider, what are you getting from a blockchain? Just have the cloud provider do the certification. If they betray you or go out of business you've lost your hashes anyway. If it's stored on the endpoint device, you can't prove it anymore if the device gets lost or damaged. In theory people could back them up, but we all know perfectly well that ordinary people are not going to do that unless it's automated. So then you're back to storing them in a distributed system, i.e. making them a necessary part of the blockchain. And then it gets too big.

danShumway 3y ago

> 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 3y ago
> 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.