Comment by jeroenhd
4 hours ago
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.
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.
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.