You have it all wrong.
Apple Reference Image is not an id system; it's primarily a way to attest that the pixels recorded by the camera sensor have not been altered in any way; the pixels, metadata and timestamp are all cryptographically signed.
There's no way to link a reference image to a person; it's also not possible to determine if a pair of images came from the same device.
> And while "a nation state actor can spoof this" is a problem for the journalism use case
This is incorrect:
When the image sensor is first initialized in the factory, it creates a
cryptographic signing identity, sharing only the public key with the
factory. The SEP similarly creates a separately-attested signing
identity. These identities are bound together into the device manifest,
allowing us to later check whether a particular sensor and SEP are from
the same device.
The final signature on a reference image is a composite post-quantum
signature combining RSA-3072 and ML-DSA-87. To our knowledge, Apple
Reference Image is the only image provenance system that provides
quantum-secure defenses.
> Also, the journalism use case suffers from the same fundamental issue all of these use cases suffer from: People will "verify" the picture by looking at the repost of a screenshot of the verification UI, not by verifying the original themselves.
I would imagine there will be a way to confirm an Apple Reference Image on the web. Pretty soon, 3rd parties will be able to verify the image themselves:
Reference images can be viewed in the Photos app alongside the main
image, like a digital negative, to visually compare the two assets and
determine if any edits were made. APIs are available in iOS, iPadOS, and
macOS 27 for third-party apps to enable viewing of these reference images.I think you have a point. I would only note that just because it is not explicitly designed as one, does not mean it will not be effectively utilized in that manner.
An insurance would either assign #1 an insurance agent or mechanic to initially assess the damage (trusted) or #2 ask the customer to send pictures (untrusted).
Tendency is #2 for cost-saving of the insurance, and 3rd party apps are used to execute this.
Now the idea is that the insurance company discontinues the App and the (untrusted) customer must have an iPhone 18 Pro to make an insurance claim?
Or is the insurance agent / mechanic an untrusted entity who will now be required to have an iPhone 18 Pro?
What is the fraud vector here, and how can the insurance service provider continue cost-saving on damage-assessment by offloading to the customer, if the customer is required to own a specific device?
In a couple of years it will be almost any iPhone instead of 18 Pro. And if it catches on, other phone vendors will provide a similar service.
And then stop the 3rd party app which is vendor-agnostic and works on all devices?
I'd say that's unlikely.
IF that's an industry this Apple-feature will disrupt, it seems it will barely have an impact on the process of insurance companies themselves, but will actually disrupt the service-provider industry FOR insurances:
The insurance won't be able to stop their existing 3rd party cost-saving, as it provides the largest device-coverage for offloading to the customer.
Instead, either the insurance or the 3rd party service-provider will have to pay Apple in addition to make use of this feature, with the hopes that the provided data will reduce fraud.
Which brings me back to my actual question: What is the fraud-vector here?
The industry has some extensive experience in independently verifying signatures, I don't see how the manufacturers factor in here. And for app features, just ask banks how integrating biometrics, payment services, etc. goes. Tends to be preferred, once Apple and Google Pay became fully available here in Austria, banks dropped their own NFC payment solutions in rapid succession.
This will allow banks to trust these cameras more on the long run, allowing higher security ID checks.
Banks are offloading the trusted process of ID verification to an untrusted entity (end-user, merchant,...) and compensate for the loss of security by using a trusted service-provider (now Apple AND an iPhone 18 Pro).
This is already happening today in two scenarios:
1. lower-risk scenarios (remotely) with trusted 3rd party service-providers and very low Hardware-requirements ("use this app on your phone to take a picture/video") and
2. higher-risk scenarios (on-site) with trusted 3rd party service-providers ("use THIS expensive device to take a picture/video of the customer/citizen")
Apple now potentially disrupts the service-provider industry of #2 (higher-risk scenarios) by
#a grabbing a part of this hardware/service market that MAY allow the end-user to be in control of the device and
#b replacing the on-site hardware/service with an iPhone "in a box".
They can't disrupt #1 because their cost-saving can't mandate the end-user to buy a 1000+ USD device just for THEM to provide the contracted service. (They can add convenience if you have it, but they can't reject their service if you don't)
Which means they disrupt mainly #2: The industry providing trusted imaging solutions for higher-risk scenarios.
--> So it's the Watch Ultra game all over again.
On Watch Ultra they disrupted the diving-watch market by the sheer scale of selling their development to everyone buying a Watch Ultra, driving down the cost so much that they can undercut every diving-watch company on the market.
Now they use the sheer scale of iPhone 18 Pro sales to enter the trusted-imaging market-segment, undercutting every player there and take that market.
Back in the day Canon and Nikon tried this with embedded private keys on their cameras, and with Sandisk's WORM SD cards. Then, somebody extracted the keys and it was game over.
While my iPhone 17 can't match a full frame mirrorless camera, it can take pretty impressive photos, so they are already more than adequate in detail and clarity department. So making these images trusted is a huge win for them.
Insurance companies can have a native app and require the device’s camera. Companies already have tools to combat a liveliness check. Even if you’re using a modified app that pulls from the photo album instead of the camera? A video recording with the appropriate liveness verification easily avoids that mess.
It's been possible to do a live video deepfake for a long time now, but as with all new tech, law and society are taking their sweet time to understand the risks; IMO this is the other side of the same coin as some infamous tech comments on consumer products: https://news.ycombinator.com/item?id=9224 and https://en.wikiquote.org/wiki/Rob_Malda
NVIDIA suggested AI fakes controlled with face tracking input as a compression technique just for reducing video call bandwidth requirements (to ~117 bytes per frame). They did that six years ago: https://www.dpreview.com/news/5756257699/nvidia-research-dev...
As we're now in an AI race, even NVIDIA's specific technique has flaws which all the current tools can detect, there's never any guarantee of this continuing to be the case.
That said, in the case of Apple, they're historically followers not leaders despite the public image they like to present about innovation, and I'd expect this method to be flawed from day one even if we weren't reading a corporate blog post written in a self-congratulatory tone I find almost as off-putting as when AI write.
AI deepfake or edit video doesn’t pass liveliness checks without all the c2pa or reference image song and pony show.
Insurance companies can monitor the light reflections from the flash that they control or monitor the accelerometer and compare the accelerometer values with the video that they receive.
They could also just update their app to stop accepting photos from the album.
While its true Apple usually isn't the first in a product category--not the first mp3 player, not the first smartphone, not the first tablet) but once they get there, they're quite innovative.
When the iPhone 5s was released in 2013, it was the first smartphone with a 64-bit processor, which caught Qualcomm off guard. Even when Qualcomm released a 64-bit processor the following year, it kinda didn’t matter because Android was still 32-bit.
Why do you believe Android manufacturers and SOC makers like Qualcomm won’t be able to offer a similar solution?
1. a public/private key exchanged during device-production (production-cost),
2. the capability to reboot in a cryptographic mode (R&D / component cost) and
3. a cloud-service which then processes the raw data to create a JPG (operational cost)
comes at a premium. Why should this premium be applied on a 99 USD Smartphone?
Which is my whole puzzle on this vector: If the big benefit is for insurance/ID-verification, which apply cost-saving by offloading their process to the untrusted customer, how much they can offload this by requiring their customer to own a 1000+ USD smartphone to provide THEIR service...?
The most I can imagine is insurances offloading their work to OTHER companies, NOT trusting them and therefore requiring them to own a 1000+ USD Smartphone. But even then, why not use a third party app that also runs on a 3y old iPhone and a 99 USD Android device...?
Okay. In good faith, I'll go with you:
If COST is not a factor, why does the Galaxy A16 still have no OIS (Optical Image Stabilization)?
Unlike this trusted-imaging service, OIS would be a feature for increased user-experience which is highly-matured and exists in Smartphones since 2013.
The answer is COST: A camera-module with OIS is a more-expensive component than a module without it.
And that's ONLY the component-cost: A OIS-camera doesn't come with increased cost in device-production (it's just another component to place and assemble), no increased cost in R&D (the tech is very mature, all the SW is there) and no running costs (there are no cloud-services required to operate OIS)
Also, OIS is a major mechanical add on (a literal motor) and even 1500usd smartphones lack it on some of their sensors, mainly because while it can have an advantage on an ultrawide, that tends to be more limited. Incidentally, most 99usd phones have one (actually usable) sensor which thus tends to have a larger width to compensate. I hope, in good faith, you see the difference, to something like ARI.
AMOLED, etc. are also a bit more expensive then OIS, but we get those into a sub 100usd BOM easily somehow. More so for 5g, certain features just become expected/required.
Your logic would lead to OEMs making SOCs without things like TEE and other things which started in the high-end but quickly became required and essentially free to implement.
Not saying it is free now, but that the upcoming gen of chips from Sony, Samsung, etc. will have it build in for such a minimal BOM impact, this will be an expected, common place feature across all prices.
To have a more serious, honest and accurate comparison than OIS, why do most new smartphone at 99usd include some form of an NPU? Or the trusted modules for biometrics, etc.?
But the assumption that smartphone cameras, including those used in 99USD smartphones, will become 100% cryptographic cameras in a few years is highly unlikely, considering that those cameras didn't even gain OIS in the last 13 years despite the feature being highly matured and widely available.
Changing the topic to other features won't change that.
You seem to lack the understanding how this industry works, and assume that every development naturally just trickles down and becomes a commodity. This is not the case.
This cryptographic feature will definitely become available from camera sensor suppliers, first of all likely from Sony. But it will be a feature of premium sensors and will remain a differentiation factor.
Sony will not support cryptography to its sensors without additional cost. Device-vendors integrating those sensors then have additional cost in R&D, production AND operations. All this will not be waived and put in a 99USD device.
For the other assumption, that "If this type of thing becomes required", I fail to see how this should happen for a mass-market consumer: This feature doesn't authenticate the content of an image, it just authenticates the RAW data of the image sensor. It won't (and shouldn't!) make the user more trusted towards another entity (like Apple mentions themselves in the link)
The timestamping server is the hard part, especially with the verified compute component. It's just not something I see Samsung doing.
I expect Google to show up with a blog post titled "extending C2PA with timestamps for industry-leading authenticity confirmation" any time.
I don't follow. It's my user agent that's verifying the image, and my device will tell me that it's not verified.
True.
> raises the bar but could be bypassed with enough effort.
Anyone can spoof this.
Apple cannot stop spam iMessages. They can't stop someone from rendering their privileged UI inside a browser viewport. People copy and paste remote script executions from convincing captchas.
This whole provenance thing is a red herring. You agree with me, but there's truly not a single application for this that won't be exploited.