Hacker News new | ask | show | jobs
by danShumway 991 days 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.

1 comments

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

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

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

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.

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.

I'm still skeptical that this would end up working well in practice, but I do want to say:

> You could also handle cropping and omissions by having the original device sign the picture as a grid of individual tiles.

is a pretty good idea, I like that quite a lot. Not saying it means I'm on board with signatures overall (I mean, we're still in agreement that this would require locking down devices to at least some degree) but I do think that's an elegant solution for the cropping/censoring part of it.