3 ms·

> 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 t

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

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.

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