4 ms·

That's a lot of words to say "we re-invented C2PA but made worse by getting our servers involved somehow". Like with C2PA, the entire thing hinges on nobody be

That's a lot of words to say "we re-invented C2PA but made worse by getting our servers involved somehow". Like with C2PA, the entire thing hinges on nobody being able to dump keys or trick the TPM into signing arbitrary image data. The timestamping server is a nice idea (though I don't see why they can't just use a normal timestamping server, I guess to keep control over the protocol) but it doesn't solve the fundamental problem that defeated C2PA.

Gigachad 17d ago
It looks like the reason for the custom timestamp setup is to assert and upper and lower bound on time. A normal timestamp server can asset it saw the image at a certain time but not that the image wasn’t created much earlier. This setup, the image processing pipeline can immediately attach the last seen timestamp to the photo as a lower bound, and then connect to the network to get the upper bound time. If there is too much of a gap between the upper and lower bounds then the image becomes suspicious.
- jeroenhd 17d ago
  The lower bound is specified by the device, you don't need support from the timestamping server for that. Determining if this timestamp is or isn't suspicious can be done at verification time. The timestamping feature itself makes sense from a verification perspective (though the privacy implications are questionable, of course), but I don't think it necessitates an Apple-specific setup. This approach does have one benefit, which is that Apple gets all the (meta)data to determine if something is or isn't "real", rather than letting the verifier decide beforehand. I can only imagine the outrage if Google or Microsoft added a "upload all of your photos to us and we will mark them are real or fake" protocol, even with all of the verified compute gaff.
  - dagaci 17d ago
    this already happened -> https://news.ycombinator.com/item?id=49421158 https://news.ycombinator.com/item?id=49421158 -> My passing comment mentioning Apple Reference Image in the same thread was moderated down into oblivion for some reason!
willy_k 17d ago
Doing that on modern iOS is unlikely. They’ve really locked it down in the past half decade.
avianlyric 16d ago
> Like with C2PA, the entire thing hinges on nobody being able to dump keys or trick the TPM into signing arbitrary image data. Is the whole point here that Apple have baked the TPM and keys directly into the sensor. So extracting the keys or injecting arbitrary data, will likely involve the destructive delidding of the image sensor itself. That’s a significantly higher bar you need to jump, than any approach where the sensor and TPM are separate modules with no cryptographic capabilities in the sensor itself. From the article > The creation of a secure digital negative begins with a secure boot of the camera sensor into a specialized reference capture mode. The mode instructs the sensor to cryptographically sign pixel data immediately after capture, and prevents the sensor firmware from modifying the data.

Gigachad 17d ago

It looks like the reason for the custom timestamp setup is to assert and upper and lower bound on time. A normal timestamp server can asset it saw the image at a certain time but not that the image wasn’t created much earlier. This setup, the image processing pipeline can immediately attach the last seen timestamp to the photo as a lower bound, and then connect to the network to get the upper bound time. If there is too much of a gap between the upper and lower bounds then the image becomes suspicious.

jeroenhd 17d ago
The lower bound is specified by the device, you don't need support from the timestamping server for that. Determining if this timestamp is or isn't suspicious can be done at verification time. The timestamping feature itself makes sense from a verification perspective (though the privacy implications are questionable, of course), but I don't think it necessitates an Apple-specific setup. This approach does have one benefit, which is that Apple gets all the (meta)data to determine if something is or isn't "real", rather than letting the verifier decide beforehand. I can only imagine the outrage if Google or Microsoft added a "upload all of your photos to us and we will mark them are real or fake" protocol, even with all of the verified compute gaff.
- dagaci 17d ago
  this already happened -> https://news.ycombinator.com/item?id=49421158 https://news.ycombinator.com/item?id=49421158 -> My passing comment mentioning Apple Reference Image in the same thread was moderated down into oblivion for some reason!

willy_k 17d ago

Doing that on modern iOS is unlikely. They’ve really locked it down in the past half decade.

avianlyric 16d ago

> Like with C2PA, the entire thing hinges on nobody being able to dump keys or trick the TPM into signing arbitrary image data. Is the whole point here that Apple have baked the TPM and keys directly into the sensor. So extracting the keys or injecting arbitrary data, will likely involve the destructive delidding of the image sensor itself. That’s a significantly higher bar you need to jump, than any approach where the sensor and TPM are separate modules with no cryptographic capabilities in the sensor itself. From the article > The creation of a secure digital negative begins with a secure boot of the camera sensor into a specialized reference capture mode. The mode instructs the sensor to cryptographically sign pixel data immediately after capture, and prevents the sensor firmware from modifying the data.