Cryptography also has answers for some of this sort of thing. For example, you could use STARKs (Succinct Transparent Arguments of Knowledge) to create a proof that there exists a raw image I, and a signature S_I of I corresponding to the public key K (public input), and that H_O (public input) is a hash of an image O, and that O is the output of providing a specified transformation (cropping, JPEG compression) to I.
Then you give me O, I already know K (you tell me which manufacturer key to use, and I decide if I trust it), and the STARK proof. I validate the proof (including the public inputs K and H_O, which I recalculate from O myself), and if it validates I know that you have access to a signed image I that O is derived from in a well-defined way. You never have to disclose I to me. And with the advent of zkVMs, it isn't even necessarily that hard to do as long as you can tolerate the overhead of running the compression / cropping algorithm on a zkVM instead of real hardware, and don't mind the proof size (which is probably in the tens of megabytes at least).
Not if you do it, only if the chip also gives you a signed JPEG. Cropping and other simple transformations aren't an issue, though, since you could just specify them in unsigned metadata, and people would be able to inspect what they're doing. Either way, just having a signed image from the sensor ought to be adequate for any case where the authenticity is more important than anesthetics. You share both the processed version and the original, as proof that there's no misleading alteration.
> You share both the processed version and the original, as proof that there's no misleading alteration
so you cannot share the original if you intend to black out something from the original that you don't want revealed (e.g., a face or name or something).
The way you specced out how a signed jpeg works means the raw data _must_ remain visible. There's gonna be unintended consequences from such a system.
And it aint even that trustworthy - the signing key could potentially be stolen or coerced out, and fakes made. It's not a rock-solid proof - my benchmark for proof needs to be on par with blockchains'.
> The way you specced out how a signed jpeg works means the raw data _must_ remain visible. There's gonna be unintended consequences from such a system.
You can obviously extend this if you want to add bells and whistles like cropping or whatever. Like signing every NxN sub-block separately, or more fancy stuff if you really care. It should be obvious I'm not going to design in every feature you could possibly dream of in an HN comment...
And regardless, like I said: this whole thing is intended to be opportunistic. You use it when you can. When you can't, well, you explain why, or you don't. Ultimately it's always up to the beholder to decide whether to believe you, with or without proof.
> And it aint even that trustworthy - the signing key could potentially be stolen or coerced out, and fakes made.
I already addressed this: once you determine a particular camera model's signature ain't trustworthy, you publish it for the rest of the world to know.
> It's not a rock-solid proof - my benchmark for proof needs to be on par with blockchains'.
It's rock-solid enough for enough people. I can't guarantee I'll personally satisfy you, but you're going to be sorely disappointed when you realize what benchmarks courts currently use for assessing evidence tampering...
It also occurs to me that the camera chips -- or even separately-sold chips -- could be augmented to perform transformations (like black-out) on already-signed images. You could even make this work with arbitrary transformations - just sign the new image along with a description (e.g., bytecode) of the sequence of transformations applied to it so far. This would let you post-process authentic images while maintaining authenticity.
