Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • I think this is really good and kudos to Apple for implementing it. The first question that popped into my mind was "what new scenarios of government X forcing Apple to do 'terrible thing' to 'individual' this enables?", but I can't think of anything. It seems that all government attack vectors this feature enables are of the type "government X forces Apple to do 'terrible thing' to 'Apple'", i.e. a government can try to force Apple into certifying a narrative, and of course Apple is going to fight tooth and nail the lack of credibility that would result from that.
  • Apple would have to be the only company around and by the time Apple “loses” in court its too late.
  • I mean, the obvious one is that they can revoke certification of a photo despite it being real.

    The harder one is they can force apple to certify a fake photo.

    the part that would be very hard but not outside the realm of plausibility, is that gov could force apple to introduce a bug in its pcc platform to link photos to the photographer in order to track and arrest inconvenient people. Apple says there are a bunch of protections against that but ultimately you are trusting apple to do it the way they say they are.

    This entire system relies on trusting apple

  • Though, on second thought, "government X could force Apple to disable feature for members of group Y" seems possible. I'm sure you can come with "Y" quite easily, heard anything about Ed Sheeran's tour?
  • Seems kind of concerning that using this at all means you send your image to Apple’s PCC machines.
  • Edit^2: On triple reread it sounds like the first pass ("Image Capture") sends the image metadata hash to be timestamped, whereas the second pass (Reference Image Development) sends the image itself but is not what actually creates the timestamp attestation. According to Apple[0][1] it sounds like the second pass (development) only happens when the reference image is actually viewed, which means that your image isn't sent if you never view the reference image?

    [0] https://support.apple.com/guide/iphone/view-reference-images...

    [1] https://www.apple.com/legal/privacy/data/en/reference-image/

    > When you take a photo in Reference mode after tapping Reference Mode, your device will include reference image information in the photo’s metadata. If you then view that photo and tap the Reference badge on your iOS device or click it on your Mac, the device will send the raw photograph, metadata about the photograph like the sensor’s signatures and the time frame in which the photo was captured, as well as the sensor’s unique hardware identifiers to Private Cloud Compute.

    Edit: On reread it seems they do in fact send the actual photographic data to PCC, which I presume has some reason over signing metadata on-device? Original mistaken post is below for transparency.

    You can always not use the reference image mode, and according to the article you send a hash of the signature of the photograph, so all they would know is you took a photograph in reference image mode at some point in time before the request.

    by wky
  • Presumably you would only do this for images you plan on sharing to social media anyways, to prove that it's not AI generated.

    PCC is quite good, about as close to private remote compute we can get without doing HME.

  • I feel like for verified photography to be useful, it really needs a depth sensor so you can tell the difference between an actual scene and a photo of a photo. Granted, you could 3d print a scene from a photo, but at least for now it should be pretty obvious to tell the difference.
  • The iPhone Pros do have a depth sensor, I don’t think it's exported but it does stay in Photos' library.
  • > Modern cameras rely on sophisticated image-processing algorithms to produce the final viewable image, so certifying that an image accurately reflects what a real camera sensor captured requires a chain of trust covering the sensor as well as the computational photography software that interpreted the capture.

    So if you jailbreak or root your phone what happens? Is this a trojan horse into making rooted phone cameras unverified? Just like how Linux machines can't watch Netflix in 4K

  • Yes.
  • It seems like the two signatures on device are processed on the camera sensor itself, and then post processing is signed by the SEP. Neither of these would be compromised even if you have a full jailbreak.
  • You'd need to jailbreak the camera sensor chip and the phone's secure element. Which isn't exactly impossible either, but it's harder. I don't think it has been done yet (but I'm sure it will be at some point).
  • This approach assumes that the smartphone in question is not under the user’s control. That should generally not be the case. When I buy a device, I have the right to install whatever I want on it and to make the camera sensors believe whatever I want. If something cannot be implemented securely under these circumstances, it’s not a good idea, and other solutions are needed. I once tested a video identification system for a company that the manufacturer claimed was absolutely secure. All it took was rooting the smartphone and bypassing the root detection. After that, you could play any pre recorded video, which would then be recognized as camera input. Under those conditions, it was easy to manipulate a video so that a company employee would consider it real enough to verify the test subject.

    It’s simply not technically possible to verify the authenticity of the camera input with 100% certainty. Pretending that it is possible only creates problems. Then someone fakes evidence, but all the normies who have no clue about technology assume that it must be real. You see this with AI detectors too they recognize random texts as generated, yet an unbelievable number of people believe them.

  • How do you plan to replace the sensor of your phone's main camera (with a device you need), and let it authenticated by the OS, and then create authenticated photographs with it?

    Apple/iOS already have part authentication pipeline on its security sensitive devices (TouchID/FaceID). How can camera sensor can't be considered one of those and needs attestation before enabling?

    From the document:

    > Apple Reference Image leverages custom-designed image sensors in iPhone 18 Pro and iPhone 18 Pro Max to ensure reliable capture of image data, and relies on Private Cloud Compute, which provides a computational environment for secure photographic processing that cannot be subverted even in the case of device compromise. (emphasis mine)

  • Very much agreed.

    I believe many of the problems we have, need social and human solutions, especially when the technical solutions are hard or impossible.

    Like here, where we can no longer trust images to depict reality and act as proof. While its admirable that people look for technical solutions, the obvious social solution is to admit that images are no longer absolute proof and will become less and less trustworthy¹.

    And, by admitting that, change our relation to these artifacts. Sure, that will change journalism, police work, legal systems, etc etc.

    But pretending that we can rely on images might allow journalists, police, judges to continue relying on them as if they're authentic, which is a far bigger problem over a longer period.

    Social solutions require effort, demand flexibility, take time and are messy. But this is what humans are and do. Not everything has a technical solution. Not every technical solution is the best option.

    ¹ we already saw this when people claimed "someone must have hacked my iphone and put it there". For decades we've seen this with images that are deliberately taken in a way to spin a story (like the illusion of a large crowd or spacious room through carefull angles or fancy lenses). And I predict we will see this with security footage, "live streams" or even bodycams with "ai enhancement". Just imagine a bodycam or a dashcam that manipulates the output to benefit the owner. "A dashcam that will prove your innocence in assumed traffic violations" or such.

  • I‘ve been wondering whether the contact tracking features introduced for Covid 19 could be used to verify that pictures of an event where taken by people who were actually around the scene. That way you‘d have some reassurance that a given picture was actually from the event. Combined with pictures from different angles from different people and some kind of verified photography should make alterations harder.
    by phkx
  • Too much potential for revealing the identities of others there.
  • I’m fairly sure that the contact tracing feature has been removed now. And it wouldn’t be needed anyway, the iPhone location services are far more useful. I imagine the geotag could be included with the verification.

    Location services is quite hard to trick. To the point people have gone to the lengths of putting iPhones inside a microwave for RF shielding and setting up fake phone tower signals inside to trick the phone in to unlocking the hearing aid feature on AirPods for unapproved countries.

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

  • To me the weakest spot of this whole endeavor is how this will create false confidence in a story just because the accompanying images pass Apple's verification.

    Like with the Watch Ultra (attacking the diving-watch market with the sheer volume-scale of selling the development to everyone buying a Watch Ultra), Apple is attacking the trusted-imaging market with the same strategy.

    Okay, fine. Will work for sure, this will disrupt the trusted-imaging market and moreover make Apple a service-provider in this industry (with the ramp-up cost paid by customers buying iPhones for entirely different purposes).

    But creating this impression and media-buzz that Apple is now verifying more than just the digital authenticity of an image may shift the public scrutiny of MANY media/online statements:

    There is a risk that random claims (and propaganda) will be given more credibility in the public eye just because they came with images that were confirmed to be "taken like this on an iPhone"

  • > images that were confirmed to be "taken like this on an iPhone"

    No, because images will be confirmed to have been taken on "this iPhone". The New York Times will be able to publish an article and to attest that the photographs shown were taken by their journalists, and then your user agent will verify that provenience.

  • The fundamental issue isn't technical. It's that people will see the "certified real" tag and just take the image for face value of whatever narrative someone wants to convey. They'll see the "Real Photo, Verified by Apple" and their brain will short circuit [0]

    I don't think we should have this, for that reason alone (but many others too).

    [0]: https://imgur.com/fVPkpuQ

  • I’m pretty sure “certified real” aren’t the words Apple will use, nor do they use it in this document. The words to describe the technology were chosen with care: semantic verification, attestation, tamper evident, etc.
  • This is so insanely complex and requires placing trust in the correctness of so many pieces, many of them closed-source. And uploading every verified "developed" image to Apple's servers. And giving up full control of the software and hardware you "own". All to achieve a goal of "verifying" photons, which is only a part of the real problem of verifying the truth of an event that was photographed.

    I hope that companies and governments don't start forcing us to use this stuff by requiring it for their services.

  • Because it’s impossible to implement this feature in open source and out in the open. It relies on a locked down image pipeline and hidden key.
  • Apple doesn't address the modified photo replay situation, where you take a picture of an already edited image.

    Photoshop / AI-gen an image -> display on a high-resolution monitor -> photograph the monitor with iPhone 18 Pro -> valid Apple Reference image.

    To get valid reference photos, you can go to the actual physical location, put the iPhone/monitor in a cardboard box to block external light, then photograph the monitor. Paint the inside of the box using Vantablack (stopping reflections) and cover the LiDAR projector with tape.

    I can't wait to see Apple Verified™ photos of UFOs flying over the Golden Gate Bridge.

  • > Paint the inside of the box using Vantablack

    But you're only allowed to do that if your name if Anish Kapoor

  • > take a picture of an already edited image

    I think the "reference image" means a photo is taking by a real iPhone 18 device at a certain time, what the content actually means is another matter.

    The "digital negative" in DNG format can be used to analyze the authenticity of the content.

    by est