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.
I can't wait to see Apple Verified™ photos of UFOs flying over the Golden Gate Bridge.
Sony's analogous solution (https://authenticity.sony.net/camera/en-us/) claims 3d depth information is built in, I'm sure Apple could do the same given at least some iPhone models have LiDAR on the back
It also doesn't prevent you from staging an image or anything that's existed since photography was invented. But that's not the problem they're trying to solve.
> Today, powerful, widely available AI tools allow users to easily generate or alter photorealistic images to a degree that was difficult to imagine just a few years ago.
Photoshop has existed for decades and so has fake images. This is a low friction way to attest "this image came from an iPhone sensor and Apple approved it". It will still take the usual image forensics to determine if the scene it depicts is legitimate.
> "But that's not the problem they're trying to solve."
It is the problem that they say they're trying to solve, though. They specifically say "where the essential role of a photograph is to prove that something actually happened".
It fails the reasonable person test to say that in the phrase "something actually happened" the "something" refers to the act of taking the photo.
This is so stupid. This makes it like, a thousand times harder to fake a photo than it would otherwise be. You pedants imagining a way to fake it doesn't change that.
> This makes it like, a thousand times harder to fake a photo than it would otherwise be.
Whether it does remains to be seen. Do you have inside knowledge about how it works? Despite their initial language about discerning real events, none of their technical explanation says anything at all about anything outside of the camera itself.
> Whether it actually meaningfully increases the difficulty of a forgery remains to be seen.
Then maybe let’s save those criticisms until this is in the hands of knowledgeable people who can actually test? I mean, I’m no fan of the direction Apple has gone under Tim Cook, but all else being equal I’m inclined to give them the benefit of the doubt that they may have thought this through over the time it took to build more than a random person speculating on HN who just read a blog post for the first time.
> (…) we see no details here about what scene information is used.
And you assume that everything in a post is the sum total of how it works?
> It increases the potential value of a forgery
By that token, should we also not be adding forgery deterrents to ID cards and bills? After all, if you can fake the preventive measures, “it increases the potential value of a forgery”.
So, in your view, photography has been fatally flawed since the late 1800’s, and mere mitigation of AI image gen are insufficient if they don’t also solve actors impersonating real people?
This has been possible since the beginning of photography and yet I can’t think of a single scenario where people have been tricked by a staged photo. Yet every day hundreds of millions of people are being fooled by AI generated photos.
> I can’t think of a single scenario where people have been tricked by a staged photo
Let me introduce you to Sir Arthur Conan Doyle and the Cottingley Fairies[0].
"Doyle was enthusiastic about the photographs, and interpreted them as clear and visible evidence of supernatural phenomena. [...] the photographs were faked, using cardboard cutouts of fairies copied from a popular children's book of the time"
Claim 7 in this patent application describes how depth sensors are used as part of an image authentication process, which would make such a workaround more difficult:
The Apple Reference Image feature is here launched on iPhone 18 Pro and iPhone 18 Pro Max that both have built-in LiDAR sensors that could be used for this process.
LiDAR wouldn't be enough here, it's trivial to block the projector and hide the dot pattern. No dot pattern = iPhone thinks the object is far away, which is what happens in landscape photos.
A better fix is to take photos with all three iPhone cameras simultaneously, ideally as a 2-3 video, and use the parallax/multiple perspectives to extract depth information.
They can also prevent photos if iPhone detects the LiDAR sensor is covered, similar to how Meta does it with their camera glasses.
I don't think it's an either or - additional data signals that need to correlate to authenticate will increase confidence. You can use multiple other signals to evaluate whether something is truly a landscape photo, and in that case not require a LiDAR capture, but if you are inside and at close range then you could assume that it should be part of scoring the authentication.
Similarly, LiDAR alone will help disqualify cases where someone is just taking a picture of e.g. a landscape target of the Golden Gate, but that it shown on a screen 1 meter away.
Hm, that's more like digitally signing an image. I'm thinking about something like e.g. encoding/encrypting depth information from multiple images to create a composite that can't be duplicated without the source images.
Right but I’d argue that realistically this feature is going to be most useful when taking photos of things reasonably close by, people especially, rather than landscape photography.
> it's trivial to block the projector and hide the dot pattern. No dot pattern = iPhone thinks the object is far away, which is what happens in landscape photos.
I've never looked at the LiDAR hardware, but where is the emitter in relation to the receiver. Why would the LiDAR not reflect off of whatever you're blocking it with and return a very short flight meaning it was very close?
> all three iPhone cameras simultaneously, ideally as a 2-3s video, and use the parallax/multiple perspectives to extract depth information.
I think optics could be used to make each camera see a different image.
A video could show shake, which could be verified against readings from the phone's accelerometer -- but you could just hold it still and claim that it was on a tripod.
> A better fix is to take photos with all three iPhone cameras simultaneously, ideally as a 2-3s video, and use the parallax/multiple perspectives to extract depth information.
I think iPhones already do this (although without taking multiple seconds of video). iOS is capable of generating pretty accurate depth data even on devices with no LiDAR unit.
Using the cameras to estimate depth information is not really a better solution than using the LiDAR sensor because the cameras are so close together that the effective range for parallax depth estimation and the effective range of the LiDAR sensor are very similar.
Is this really that big of a flaw in this implementation? I don't think it's worth the additional complexity to address it. (Encoding depth information in some way, trying to detect "flat" surfaces, whatever).
Discerning a camera taken image of an image is typically very very easy. The collors/exposure/etc will all be obviously wrong in ways to a human, even without doing any analysis.
You mean that it is sometimes very easy. But it is also sometimes impossible. You seem to be thinking only of poor quality photos of poor quality prints, but there's no basis for assuming those characteristics.
You don't even have to travel to the location, you can just spoof GPS. And of course that will only be needed until some eastern european kid gets bored one weekend and the signing keys magically appear on pastebin. Then all it will take is running a shell script.
To be fair Apple of all companies have the best shot at pulling it off. They've been perfecting their hardware security for years for other reasons and this is just another way to take advantage of that work. But yes, if someone breaks it then the trust is gone and it casts doubt on all of the photos that were ever captured using the broken system.
Also I think if you're rich enough to be able to coat the inside of a cardboard box with Vantablack, you've probably much easier ways to get misinformation out to the public than photographing a monitor in a cardboard box...
> I can't wait to see Apple Verified™ photos of UFOs flying over the Golden Gate Bridge.
While I'm on board with you about the inabsolute security of this (relative to what's typically expected of cryptographic systems), the fact that their 'verified' state requires a live certification and can be revoked means that the sensor responsible for obviously faked images will see those images and that device no longer certified.
It all relies a lot on trust in Apple, and integration with Apple, and relatively unmotivated attackers.
It's even easier than that. You just wait for someone else to figure out, some photography professional with fancy equipment and a hacker-y mindset, and you pay them to sign your photos for you.
Once a defeat device (a camera pointed at a screen) is functional, whoever has it, can simply automate a "receive API request, display image on screen, photograph it, return signed image" pipeline. A cheap internet service. I'd WAG a hundred thousand signatures per day per phone, limited by the sensor speed.
Since there's no way for anyone, Apple included, to correlate photo signatures with the device that signed them, it's also true there's no way to stop one device from signing millions in bulk. ("...an outside observer cannot determine whether any pair of reference images were taken by the same device..."; "...avoid even implicit public association between different photos taken by the same sensor...")
I think the timestamp attestation of the digital negative puts a real hamper on this, because it puts a bounded time window on the photo as part of the cryptographic chain of evidence.
So if you're the proud owner of "literally the only photo of a ridiculously unusual event in a highly public area" which is bounded to either a plausible 15-30 minute window or a sketchy March2026->Now window, people can do something like "hey, gee, did anyone else see that UFO over the golden gate bridge at 3pm?"
plus, you know, the confidence score from their secret neural network, which has an unknown scoring function.
"As part of developing the secure digital negative, PCC computes a confidence score that assesses whether the image has the physical characteristics expected of raw output from our camera sensors. Before the developed reference image is signed, PCC sends the photo GUID, sensor ID, and this confidence score to a companion service, which records them and updates the running score associated with that sensor."
I wouldn't be surprised if it's also possible to detect the differences between a photo of a real scene and a photo of a monitor or printout displaying a photo of a real scene, given they have the raw sensor output.
It doesn't need to be bulletproof to be very valuable.
However much effort is required to fake it - it's proof that the image is either legit or that much effort went in. There's TONS of cases where it's plausible for someone to have put in the effort to fake a photo with AI (nearly zero effort required) but not remotely plausible that they set up some elaborate high quality photo of a fake.
It's also much more damning if you get caught faking it. Think of the examples where police have been caught posting altered images on social media. The lame excuse that some intern didn't realize it would do more than just upscale the image won't fly if some elaborate setup was required.
We're talking about a 48MP camera here, so finding a sufficiently "high-resolution monitor" to pull this off is probably more difficult than you expect. Especially because without at least a few times as many pixels as the camera, it's likely that there will be detectable moire patterns in the image. My guess is that a physical print is more fruitful, but it's still a pretty tricky task to get high enough dynamic range and such to truly fool the sensor.
This sort of concern is presumably why Apple says "Using a neural network with hidden weights, PCC computes a confidence score for the photograph." I'm assuming that things like moire-patterns from pointing the camera at a screen would be caught by that check.
It's of course physically possible to fool the sensor, but at some point it becomes cheaper to just build a UFO and fly it over the actual Golden Gate Bridge.
so what happens if you display an extremely high res image of a 100% AI generated fake-something on an 8K display in a photo studio room and take a picture of it with the camera? it gets tagged as authentic.
An 8k monitor is typically 33 million pixels, and the sensor here is 48MP, so the resulting image is going to show at least strong moire patterns, and possibly individual pixels. Note that Apple does have a secret neural classifier on their servers looking for that kind of pattern. I also suspect that getting enough dynamic range out of a screen is tricky.
None of this is impossible, but it could make it really expensive to produce an image that passes forensic analysis.
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).
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.
You seem to be missing the point that’s being made here. Of course apple will word this very carefully. This does not matter in how people will interpret it. They will interpret it as certified real.
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.
After my brief read, one of the main reasons they’re using PCC to produce the signed JPEGs, instead of doing everything on device, is that it maintains your privacy.
If you were signing with the iPhone, an attacker could then correlate photos taken with the same device.
Apple certainly has the data that “this sensor, in this device, took this exact photo” in PCC at the time of signing, but they discard that data.
The timestamp system seems like it provides more benefit than signing the image data itself, at least in terms of difficulty to fake. As long as rolling back the stored timestamp token is prevented, I would have to find a phone that never updated its timestamp after the time I want to fake. Of course you could potentially find a phone that last connected to Apple's servers with a plausible timestamp. Even then the upper bound of when it signs the photo after reconnecting to the internet will raise eyebrows if you take too long to find the phone and fake the photo, so it effectively raises the bar to having to take the fake photo roughly simultaneously with the time the event purportedly took place anyway.
Hot damn. I've described this concept before, obviously not to this level of detail, but leaving this comment in here in case I can find my old comments. A bunch of people have poo-poo'd my proposals, but glad to see a serious actor really executing it. Probably no one at Apple ever read my posts, but it sure does feel good to see something executed. Hopefully it sticks.
Lots of criticism here but I think this is extremely promising. When this tech is extended to videos and perhaps even other forms of media, I think it has the potential of stopping all slop!
All slop? I'm sure that some "Shrimp Jesus" or "Talking Strawberry" was never considered to be authentic by anybody. There is a lot of useless AI generated content of which everybody knows it's AI generated littering the web. Having it marked as AI will not stop that.
This is really clever from Apple. The journalist use case is just the PR story. This will be really useful for identity verification and insurance apps, and has the potential to shift from "you need a smartphone to be able to live normally" to "you need an iPhone to be able to live normally".
There are already plenty of insurances that require you to submit claims through a smartphone app that tries to essentially do this by capturing sensor metadata etc. - those don't need to be nation-state resilient, just Joe the Crackhead Insurance Scammer resilient, so this works. Likewise, more and more things online require identity verification (either officially or disguised as age verification).
> People will "verify" the picture by looking at the repost of a screenshot of the verification UI, not by verifying the original themselves.
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.
I don’t understand what this brings to the table beyond what we’re currently doing.
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.
As per opening paragraph of link, AI fakes are a thing.
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.
You don’t even need an AI deepfake to edit a video.
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.
> 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.
All of this data can be spoofed if it's not somehow authenticated.
> They could also just update their app to stop accepting photos from the album.
Doesn't help at all if the spoofed data is arriving via spoofed hardware.
> That said, in the case of Apple, they're historically followers not leaders despite the public image they like to present about innovation
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.
Twitter now flashes your screen different colors while watching the camera pointed at your face when you sign up, you know, to "make sure you're a real person"
Like a lot of things in the UK, the problem isn't the harshness of the law, it's the lack of prosecution. It doesn't matter what the punishment is when criminals know that the crime is extremely unlikely to be investigated or make it to trial.
The UK allows private prosecution, if it was a real problem the insurance companies would be using it, instead of attempting to make the state pay for it.
You still need to be able to realise something is fraudulent and pursuing prosecution has a significant cost to the insurer that is likely to be a net-loss financially. Not to mention the reputational risk of the public believing you prosecuted someone wrongly.
Insurance agencies worried about fraud could just do what they did prior to smartphones: have you bring the car to a claims adjuster at your local office. I’ve brought cars to be inspected, because I got T-boned at an intersection by a careless driver before smartphones existed; it was reasonably quick and hassle-free.
Not the OP, but yes, other vendors will be able to support that as well. But a camera sensor that has
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...?
We have 99USD smartphones with 1080p+ AMOLEDs, massive 5k amp batteries and very performant SOCs (e.g. Galaxy A16) among other costly, but not vital niceties. I struggle to see how cost could be a factor here.
> I struggle to see how cost could be a factor here.
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)
How many smartphones have no camera? Zero? Bluetooth? Zero? But they could save cost by not having those. I think they are basically table stakes. If this type of thing becomes required for more and more things then no one will buy a phone that doesn't have them.
Yes, the whole insurance self-service is built on smartphones having a camera.
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)
>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.
Them becoming 70% cryptographic is enough. The people who need the feature, can get a compatible model. Nobody argued that smartphones sold for kids to game on for example should have it.
Doesn't OIS increase the size of a sensor by roughly half and thus take some significant engineering and design cost to accommodate? At least it seems that way in the phones I've taken apart and looked at.
Also, OIS is a major mechanical add on (a literal motor). 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 highend but quickly became required for one and basically free to implement for two.
>Doesn't OIS increase the size of a sensor by roughly half
No, you can apply smartphone OIS-tech on any sensor, stabilization is achieved via the lens-array, not the sensor. The size of the module slightly increases but that's not a hindering factor. Cost/Benefit of OIS on ultra-wide lenses is not there, so it's usually not applied.
>Your logic would lead to OEMs making SOCs without things like TEE and other things which started in the highend but quickly became required for one and basically free to implement for two.
TEE became a mandatory requirement of the media industry for Smartphones in ~2010, as they announced plans to restrict media-playback on a device without measures to secure the DRM-keys. Google made it mandatory shortly after, because the entire ecosystem was built on media-consumption.
It didn't come for free to the players in the industry, it became a very expensive task to develop, support and maintain it, but that's another story.
Drawing a parallel here, I fail to see who should require cryptographic authentication of a taken image from end-user devices, to the point that no consumer devices without it will be built anymore.
>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.
It will be supported in sensors for sure, but those will be premium-tier sensors, as a differentiation factor. Until today there was no premium sensor used in mass-tier devices.
Of course, again, if there is demand in the market or a regulation requiring it, it will create an incentive for the industry to follow, but I fail to see why either of this should happen in the coming years.
>To have a more serious, honest and accurate comparison than OIS, why can you not buy a single new smartphone at any price without some NPU?
I don't know why OIS is not a "serious, honest and accurate" comparison, can you elaborate?
As stated, it's a highly mature technology available for over a decade already, providing critical-mass observable end-user value, yet it didn't just naturally "trickle down" to every smartphone price-segment, simply because it comes with additional cost no matter which scale (and the Galaxy A1x tier has massive scale).
A NPU is just the evolution of a DSP, which exists in Smartphone SoC's for more than a decade now and is required for Audio and Image processing. DSP's used to run pre-calculated inference models for lens-correction, exposure, white-balance, etc., now these processes can run as models on an NPU.
---
You are trying to argue why that feature won't naturally become a commodity at basically no cost. I'm trying to answer why I don't see this happen, because I worked in this industry for more than 20 years.
The market doesn't get features as a default "easily somehow", features reach this commodity stage because of significant end-user demand (like Camera, Display, Battery), business-value (for the vendor, like Apple Pay) or industry-requirements (like TEE, Widevine example above).
I don't see this happen for this feature, because there is
1. no significant end-user value (unless the public narrative is massively skewed towards "everything is true when the image was signed"),
2. the business-value applies only for Apple's service-proposition for now (which will likely make this feature expand to the non-Pro iPhone tier), and for
3. the industry-requirement I don't see WHO would actually be able to enforce this, for WHICH actual benefit.
> I'm trying to answer why I don't see this happen, because I worked in this industry for more than 20 years.
And despite that experience, you do not see the universal value in reliable, verifiable image attestation for any user? You cannot imagine why that may be not just useful, but required, what the "end-user demand", "business-value" or "industry-requirements" could be?
This is not what I wrote and a very bad-faith statement of yours.
There is universal value in many features, yet they didn't become a commodity in all smartphone-tiers.
I don't see how and why this feature should become a default in all smartphones, which you keep insisting on without apparently comprehending the industry and market aspects I am trying to explain.
What? Those three sentences are not really compatible with each other?! Like, they are mutually exclusive and each appears to hold a different position.
How is what I wrote (that you seem to not see universal benefit) in bad-faith (honestly trying to understand what you mean) if you then add:
> I don't see how and why this feature should become a default in all smartphones [...]
So, do you see universal value or not? Cause you again said you do not and that was precisely what I wrote, that you do not seem to despite it being obvious to anyone who thinks about why phones of any price have cameras.
Should I honestly start writing a list why private as well as business users of smartphones may want, even need this? Is that really required? Consider every use case of a camera on a phone, please, before I feel the need to do that.
You fail to understand the difference between a feature having perceived "universal value" and that same feature being applied universally in all price-segments of a device. These are, and I cannot overemphasize this, two different things!
You stated that you "struggle to see how cost could be a factor here", so in good faith I was trying to give you an insight.
There is universal value in OIS, as everyone takes pictures while holding the device in his hands, yet OIS is not applied universally in all price-tiers of devices. The reason is COST.
So you wanted to shift the conversation, claiming that it's not a "serious, honest and accurate" comparison, without providing any reasons for that.
Again, I walk with you, I respond to what you're stating.
Now it ends with you starting the straw-man argument of how obviously great this feature is and asking how despite all experience I am not capable to see that.
See, it doesn't matter if _I_ see universal value in this feature or not, the topic was why I consider it unlikely to become a commodity.
You tried to move the conversation to this straw-man argument, and doing so in bad-faith. That's why our talk ends here. I give you my side of this conversation so you may read and grow from it, but this is entirely up to you.
P.S.: You also seem to misunderstand what this feature is. It's NOT picture attestation as you put it.
Picture attestation means an entity confirms the connection of a picture to something else (some "metadata"), e.g. a picture of a person to an identity (Name, ID,...) or a place. This attestation party can either be a person (self-attested) or an official entity (e.g. a government).
Nothing in this process changes with this Apple feature, because all it can do is confirm that the picture was taken by the camera as-is, but the attestation to the external metadata (WHO this is, WHAT this is, WHERE this is) still needs to be done by someone else. A party trusted enough to vouch for this.
> See, it doesn't matter if _I_ see universal value in this feature or not, the topic was why I consider it unlikely to become a commodity.
> You tried to move the conversation to this straw-man argument, and doing so in bad-faith [...]
What? The conversation started with the assumption being made that this was going to be iPhone exclusive. I stated doubt and then you (re-read to verify cause you seem to have forgotten that) moved the conversation to the only massive straw man in this interaction, the 99usd phone market.
I personally still believe that this is going to be a universal feature soon enough (wait to hear from Omnivision, etc.) and stand by that. This is my personal assessment due to the objective need for such features in the world we live in today. I may be wrong on this, we will see. But I was not the one who moved from Android OEMs to the lowest of the low-end, that was you.
I shouldn't have engaged with someone so serious that they must drag "why couldn't Android OEMs do the same" down to "99 USD Smartphone". Anyone who does such a shift, well, they must have a well founded, serious point to make.
>There is universal value in OIS, as everyone takes pictures while holding the device in his hands, yet OIS is not applied universally in all price-tiers of devices. The reason is COST.
The reason is digital stabilization is a good enough alternative to not bother, and the lens/sensor modules they use in bulk just didn't come with "analog" stabilization. And OIS is way less important than a future digitally verified photos feature could be (which could be mandated by corporations, banks, governments, insurance companies, for several uses when it becomes widespread), so they didn't bother to add it.
All kinds of cheapo smartphones still manage to have OIS, just because some Samsung models don't doesn't mean it's a universal argument for cheap phones in general.
>Nothing in this process changes with this Apple feature, because all it can do is confirm that the picture was taken by the camera as-is, but the attestation to the external metadata (WHO this is, WHAT this is, WHERE this is) still needs to be done by someone else. A party trusted enough to vouch for this.
Moot point, since the entity (e.g. gov) asking for an untampered photo (which this can do), can combine the photo with the metadata from the upload, like your gov mobile app account.
1. OIS (optical stabilization) ensures that the light photons consistently hit the same pixel, removing the blur caused by camera-shake during exposure.
2. EIS (electrical stabilization) via cropping compensates camera-shake on video(!) recording by applying the same shake to the crop-canvas within the frame.
--> EIS can fix a shaky video but not a blurry photo.
It's 2026, with cleaner high ISOs even in phone sized sensors giving the ability to raise the shutter speed as needed, we hadn't had much of an issue with blurry photos for a decade now.
Might be boring, but in 2026 "clean high ISOs" in phone-sized sensors mainly comes from image post-processing (stuff like multi-frame merging is done even when shooting "RAW"). Post-processing requires a stable (albeit noisy) image, otherwise it'll be garbage-in/garbage-out.
--> OIS actually became MORE important for Smartphones in the past years, because while post-processing produces better and better results, it massively depends on usable input data. OIS is one of the very few methods to improve the INPUT-quality for post-processing.
>"There have been several expensive cameras with no OIS, like Ricoh GR and (and v2), or ZVE10 (and v2)."
That's a apples and oranges comparison. A quick Google search tells me the size of a pixel on the Ricoh GR sensor is 4.81 µm, which is ~8 times larger than the pixel in recent smartphones (~0,6µm). It is not only physically capable to capture 8x more light, it is also much less affected by minor shaking than sensors with smaller pixel-sizes.
>*"Does anybody complain about blurry S12 photos?"
Not sure what's a "S12", but:
- On flagship phones with OIS: Not so much. Maybe in low-light scenarios, because, you know, not much light...
- On cheaper devices without OIS: Yes! Oh yes, constantly.
People assume that the picture-quality of a e.g. 2026 Galaxy A16 must be comparable or better than the picture of a 8-year old Galaxy S9. It's not, the S9 is still better in everyday shooting.
Just check user-reviews of mass-tier smartphones without OIS, like Samsung Galaxy A series...
Well, that happened because in ~2011 the entire media industry announced that they will stop media playback on devices which didn't secure the DRM-keys.
As media consumption was fundamental to the Smartphone ecosystem, Google made secure-boot and widevine mandatory.
Sure, the same could happen here, but I don't know which industry (or other body) would demand that and have sufficient justification for it.
After all, the feature doesn't really change that much for a consumer, the trust-chain is largely unchanged: If I send you a picture and tell you that's my dog, you still have to take my word for it, regardless whether Apple signed the picture or not.
> comes at a premium. Why should this premium be applied on a 99 USD Smartphone?
It's entirely software. It's R&D cost, with basically none of it in hardware (you technically just need the private key store which even very cheap devices have)
An insurance would either send #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?
So the insurance would then, instead of contracting the current service-provider for the 3rd party app, contract also with Apple and, let's say Samsung?
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?
> So the insurance would then, instead of contracting the current service-provider for the 3rd party app, contract also with Apple and, let's say Samsung?
The industry has some extensive experience in independently verifying signatures, I don't see how the manufacturers factor in here...
>So the insurance would then, instead of contracting the current service-provider for the 3rd party app, contract also with Apple and, let's say Samsung?
There would be no contract, you just upload image from your phone and they verify signature in the file
Some banks needs photos of machine readable IDs to verify user details to fight fraud. These IDs can be passports or NFC enabled EU (and compatible) ID cards.
This will allow banks to trust these cameras more on the long run, allowing higher security ID checks.
Okay, this doesn't answer the question on the vector but is another interesting example. Let's expand on that one then:
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.
Don't forget law enforcement, customs or any high(ish) stakes sector which needs to be able to trust the images they show as evidence as well.
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.
ID document verification via NFC can't by itself replace also biometrically verifying the person purporting to be the one that the document belongs to.
Without it, anyone with a stolen document can pass it. (I don't think there's a generally available database of stolen documents, so I suspect these usually remain valid until their regular date of epxiry.)
Generally, the information in our country is checked via multiple ways:
NFC + Biometric data (checked against the data inside the ID card) (+ photo of the ID in some cases), or any combination of those.
Before deepfakes were dime a dozen, I remember my bank starting a video-call with me and required me to show my ID to them via camera. This was after a multi-factor check that I passed.
Making any of these factors more trustworthy is a win in my perspective, so having a trusted sensor is always better even if you do multi-factor authentication.
Our ID cards have a private-public key pair inside them, and it allows us to sign things amongst other things. Renewing your ID card for any reason revokes the digital signature of the previous one, so scanning it via NFC probably enough to check whether it's revoked. Same with photo (since machine readable part contains serial and check digits and such).
Nowadays they do #3, demand that the customer takes pictures with a special app that claims to make the process nearly as trusted as #1 while being nearly as cheap as #2.
The idea is indeed that instead or in addition to requiring an app, the insurance company would require the app to run on a phone that supports Reference Image to make sure the image wasn't tampered with. Not right now, when the phones are new, but in a while when 50% of Americans have a sufficiently new iPhone. The rest of the people gets told to either borrow one if they want to make a claim, or go through some other alternative process designed to be so annoying that most people give up.
I think you’re on the ball, but also all KYC flows, photo proof for shipping returns (Chinese platforms were getting destroyed on this) etc. etc. It’s a very very clever solution and a very opportune time.
> This is really clever from Apple. The journalist use case is just the PR story. This will be really useful for identity verification and insurance apps, and has the potential to shift from "you need a smartphone to be able to live normally" to "you need an iPhone to be able to live normally".
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.
> 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.
So… a nation-state can't really do anything here unless they acquire alien technology. If something crazy happens (solar flare or EMP?), a fraudulent reference image can be revoked.
> 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.
> You'll still need an iPhone, the verification is linked to the specific iPhone, and the specific iPhone is linked to you.
Unless you use a friend's iPhone, or an iPhone you 'rented' for 5 minutes for $20 from someone on Craigslist or Facebook Marketplace to take a picture on and then Airdrop to you.
If they airdrop it to you that typically requires you to have an iphone or a mac and airdrop users are able to be identified and tracked so the photo could still be linked to your device. The EU forced apple to use Wi-Fi Aware though, so unless that's similarly vulnerable people in the EU might be able to avoid those issues.
What? Just send the photo using literally any other method. Am I missing something, or did everyone just waste two minutes of their lives reading this?
The reference image isn't linked to any particular iPhone or person:
We built Apple Reference Image to avoid using an explicit, public
credential for photographers, and to avoid even implicit public
association between different photos taken by the same sensor. The
final reference image is instead signed by Apple’s signing service,
after validation by PCC. That signature is backed by Apple’s
strongest technical guarantees.
Our implementation also protects the
confidentiality of the image itself, including from Apple. Merely
capturing a reference image should never expose the actual pixels to
Apple or anyone else. We achieve this through the exceptional privacy
properties of PCC — the nodes themselves are architected so that not
even Apple can access image data, just as Apple cannot see the
information processed for Apple Intelligence in PCC.
The reference image isn't linked to any particular iPhone or person
It is for Apple, to the extend that if there are backdoors and weaknesses in their PCC, they could register a device signing identity to Apple signature mapping.
I think the line of reasoning is that you have to trust Apple anyway, since they could also roll out a malicious image to your particular phone, but I still feel like PCC is much harder to verify/audit than an iPhone already is.
> it's also not possible to determine if a pair of images came from the same device.
It’s possible for Apple, as stated in the blog post (e.g. “which lets the device later produce signatures that Apple can attribute to that specific phone”).
> So… a nation-state can't really do anything here unless they acquire alien technology.
At least for the image itself, using direct projection onto the sensor (in a way similar to a retinal projector or film recorder) would be difficult to detect I imagine?
They mention something about image heuristics typical of an iPhone image, that may mean that this reference mode takes a spatial image using dual sensors that help convince the PCC that it's an image of something real. Or perhaps it uses a lidar sensor, both lidar and reference mode are only offered on the Pro models. The whole camera system is one module so it could be using all of it. Regardless, you'd need a pretty complex setup and a deep understanding of the image sensors to project something that looks real. We really don't know what is in that first lump of signed sensor data.
But at the end of the day, even if you manage to get a fake reference image, it's still on the person making the claim to show that the content of the image is real. A reference image of a document is useless, the physical document could be a forgery. A photo of people could be refuted with alibis during the timestamp window (max 15 minutes it sounds like?). A photo of property damage doesn't prove how or when it happened.
It doesn't, as it is run through an Oblivious HTTP relay run by a third party before getting to Apple's servers. So it has no IP information, and the requests use anonymous access tokens.
It is probably possible for an entity to break it, but it would require live access to both Apple and the third party (Likely Cloudflare) servers. And that is assuming there is only one third party routing OHTTP requests, otherwise you would need to monitor all of them, in real time, since the requests are transient.
> So, if compelled, Apple could theoretically tell someone if two images came from the same camera.
No they couldn't.
If you generate two SSH key pairs on your laptop, there's no way to confirm they were created on the same machine.
There's no device identifying data in a reference image, which is the point. The factory signature, the image sensor key, the Secure Enclave Processor key and all of the signing that takes place on PCC are all device-agnostic.
The reference image is processed and eventually signed by Private Cloud Compute's post-quantum signature using a hybrid MLDSA87-RSA-3072-PSS-SHA512 scheme.
So… it's not possible for Apple to know if two images came from the same iPhone.
I stand corrected. If it’s truly only the signatures and zero other identifying info, then yes you’re as secure as the underlying algorithm. I think they implied there are multiple device-originated signatures for different parts of the data, this may open some possibilities for cryptanalysis
I am not sure I follow. The private keys in the image sensor and the SEP are static, so you can see that two images are signed with the same private key. Apple 'decorrelates' this by letting PCC verify the signature and then replacing it by their own signature:
When the user initiates developing a reference image, the device uploads the secure digital negative to Private Cloud Compute. PCC recomputes the digest embedded in the frame and verifies the sensor's signature over the pixels and that digest, verifying the certificate chain back to the sensor CA. PCC also verifies the SEP signature and chains it to the BAA CA, and it verifies the signature on the device manifest and chains it to the CA that signs device manifests at the factory. It then confirms that the sensor and SEP named in those chains belong to the same device. [...] If these checks pass, PCC then submits the commitment to our signing service, which signs it with a composite post-quantum signature using a hybrid MLDSA87-RSA-3072-PSS-SHA512 scheme. The signature is embedded in the JPEG, and the reference image is returned to the device, which associates it with the main photo from the original capture.
After the secure digital negative is successfully developed, it's automatically moved to the deleted photos folder."
So in the end it all depends on how much you trust Apple's cloud and PCC nodes. If there is a weakness in their services, Apple could record both the original signatures and their signature, and could prove whether two photos were made using the same lens/device and they could even trace it back to a specific device (by looking up the original signature + signing identity given their signature).
Nation states almost certainly have the ability to extract the private keys out of an image sensor and SEP. Outside of superpowers even if you're willing to do it destructively.
Apple would be legally restricted from disclosing any government compromises, while still claiming their systems are secure and operating as intended in general.
We already know it's happening right now, and they know we know, but we can't do shit about it.
> Apple would be legally restricted from disclosing any government compromises, while still claiming their systems are secure and operating as intended in general.
I'm aware. The point is they can't give the NSA something they don't have. The photo sensor generates its own ECDSA P-256 signing key pair and never releases the private half.
Every device has a unique key pair and the private key is unavailable… there's not a way to give the NSA that would help them. The system is setup so that the image data, meta data, etc can't be accessed by anyone including Apple.
I think the chart exactly shows the weakness that some people have pointed out. Apple's PCC servers at some point in time know the signing identity for a photo and Apple's generated replacement signature. The relevant steps from your chart:
- verifies each link and its certificate chain, sensor signature over pixels, SEP signature, device manifest signature
- PCC Submits the commitment (the JPEG hash) to Apple's signing service.
So, at some point in time, Apple's servers have both the original certificate chain and the new replacement signature. If this is recorded, Apple can deanonimize photos and check whether two photos were from the same device/sensor.
Apple's system protects against most state actors, except Apple and the US, unless you fully trust that their PCC is watertight.
(Remember that Apple was part of PRISM and probably also its successor.)
I don't think law enforcement needs it, because when sending/posting a picture, people leak so much metadata anyway.
But people outside the US should certainly distrust these systems.
> The NSA has probably already forced Apple to hand the keys over to them.
Again, that's not how it works.
There's no set of keys and certificates they could give to the NSA. Every iPhone 18 Pro and Pro Max has a unique set of cryptographic keys, most of which can't be accessed by Apple.
The first thing that happens is when photo sensor is initialized at the factory, it creates its own ECDSA P-256 signing key pair; the private key is never disclosed. The public key is signed by the factory's certificate authority.
This ain't X.509 where VeriSign's key pair is sitting in a HSM at their HQ and in theory could be forced to sign a fraudulent certificate or revoke someone's valid website certificate.
They don’t need the signing keys though. Apple could roll out a separate version of sepOS to assist law enforcement that signs at they will.
Also, while the unique device ID is supposed to be burned into fuses by the SE during production, it is kinda hard to prove for anyone that is not Apple that this indeed happens in the way they state.
Personally I’m not a strong believer in such theories though. I think it’s more mundane and Apple helps law enforcement by having some weak defaults. Like how iMessage is end-to-end encrypted, but most chats are available to law enforcement because most people turn on iCloud Backups/Messages in iCloud and not ADP, resulting in chats only being encrypted at-rest in iCloud. This is only stated somewhere in a footnote in one of their security documents.
There are more weak defaults like that in various crucial apps (e.g. WhatsApp) that makes most important stuff available to law enforcement when needed.
> Nation states almost certainly have the ability to extract the private keys out of an image sensor and SEP. Outside of superpowers even if you're willing to do it destructively. They can then sign their own fraudulent images.
That's not how this works.
Let's pretend they're able to extract the sensor key and the SEP key. Then what?
An attacker won't have the ECDSA P-256 over SHA-256 signed timestamp token from the Apple Push Notification Service.
When Reference mode starts, the operating system supplies a SHA-256 digest to be embedded at a fixed location in the captured frame’s metadata. The digest is computed from the most recent secure timestamp, the device manifest, and the device's secure boot manifest.
More encryption and checking happens until the secure digital negative is sent to Private Cloud Compute:
PCC recomputes the digest embedded in the frame and verifies the sensor's signature over the pixels and that digest, verifying the certificate chain back to the sensor CA. PCC also verifies the SEP signature and chains it to the BAA CA, and it verifies the signature on the device manifest and chains it to the CA that signs device manifests at the factory. It then confirms that the sensor and SEP named in those chains belong to the same device. Only if all these checks pass does processing continue.
Only PCC can create an Apple Reference Image; an attacker having the image and sensor private keys doesn't enable them to create a reference image.
> An attacker won't have the ECDSA P-256 over SHA-256 signed timestamp token from the Apple Push Notification Service.
Sure they can, they have everything needed to prove to Apple's servers that they're a real iPhone since pulling the keys means they have the cryptographic root of trust, and Apple's servers will happily be a signature oracle for the in that case.
> When Reference mode starts, the operating system supplies a SHA-256 digest to be embedded at a fixed location in the captured frame’s metadata. The digest is computed from the most recent secure timestamp, the device manifest, and the device's secure boot manifest.
And when you know what is measured into those manifests and the keys at the root of trust you can manufacture those too.
> 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
You think that this won't be used as additional data by the various competing companies who have implemented "take a live still or video selfie of yourself with your phone and show us your ID cards" for identity verification purposes?
> 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.
Some banking apps nowadays ask you to upload a photo of your ID and then use the webcam/selfie camera to confirm that's it's really you (sometimes asking you to move your head in a particular way). But how trustworthy is that process really? Apple Reference Image could be (part of) a solution, by certifying that both images were taken by the same device around the same time.
GP does not have it all wrong. A company desiring you to prove your identity often asks for a photograph of your government ID. Now that this is easily faked, it is reasonable to expect that the company will ask for a verifiably authentic photograph of your government ID.
That the Apple Reference Image itself is not traceable to the device/user is beside the point in this use case.
Why would anyone be using images of government IDs when modern documents have NFC chips with the data, signed and with anti-cloning mechanisms on them? If they can verify an Apple Reference Image they can verify an NFC document.
> If they can verify an Apple Reference Image they can verify an NFC document
Interfacing with images is easy. Interfacing with NFC takes work. I have experienced precisely zero identity-verification workflows which NFC'd anything, and that includes my banks, which could easily ask for my debit card's NFC but don't.
ICAO doc 9303 validation is about 10 lines in Python (on top of importing the right packages) last time I did it around 2012. I doubt it has become harder since then.
Revocation checking seems like a big gap, yeah. I’m not aware of any public revocation lists (but I’m also not super familiar with the industry), so I can only assume (hope?) that there are some shadowy but highly accurate databases that KYC providers are tapping into.
The CA public key I just got off my country’s website, they were kind enough to just publish it :)
Counterpoint: all of the identity-verification flows I have experienced in the last few years used NFC to read the chip in my identity documents - from car rental apps to my bank doing KYC.
If anything, verifying NFC is easier than images. Asking the chip in my identity card to provide a cryptographically-signed "This document belongs to Jane Doe" request is a handful of lines of code. Doing the same with images? Good luck coming up with an approach which isn't fooled by a photocopy!
My credit card company’s app (in Europe) reads my ID through NFC when logging in for the first time (besides requiring ID photos).
Our national app for logging into government sites and confirming things also requires a step where the ID’s NFC is read to reach the highest trust level.
So it’s definitely becoming more and more common here.
I agree, but for this to matter, a critical amount of fraud should be based on people uploading modified photos of ID's.
If someone took a picture of a fake ID in the past, this method will bring no benefit, it will just add Apple as a paid service-provider.
It also doesn't change the trust-relationship between the two parties: If I need to prove my identity by uploading a government ID, _I_ am doing the photo attestation that this is the ID matching the data I provided, with or without an Apple Reference image.
> Now that this is easily faked, it is reasonable to expect that the company will ask for a verifiably authentic photograph of your government ID.
The image will be authentic, but an authentic image of a fake id isn't useful to them.
Also--only two iPhone models support this technology. It'll be years before the DMV or whoever could count on enough adoption before they could support it.
I think this is a good thing. Proof that an image is actually real is a valuable underpinning of society and being able to provide that is incredibly important.
No, you just didn't understand GPs point, i.e. that an image provenance/authentication system (such as Apple Reference Image) can eventually become a load-bearing and by extension anticompetitive component in a larger authentication/identity verification scheme.
> a nation-state can't really do anything here unless they acquire alien technology.
Alien technology such as NSLs or supply chain attacks against Apple?
How is stealing/extracting a private key alien technology? Or even more simple, subpoena a private key to create fake authentic compromising pictures of pesky political opponents.
The one issue I have it that it lets Apple determine if two reference images were taken by he same defice. In particular if one of the images is of an ID, or otherwise contains identifying information, that is a privacy downside, and authorities can subpoena Apple to check for and reveal this connection between multiple images.
Sadly, people will happily go with this crypto-lockdown until there's no personal computing whatsoever. Only way to fight is not to play, or hack this in some way.
> This is really clever from Apple. The journalist use case is just the PR story. This will be really useful for identity verification and insurance apps
This is definitely not an Apple thing, though the use profile is more ubiquitous. Canon had, more than twenty years ago, when they first started making DSLRs, the question of "If we want law enforcement to use these, how do we handle the inevitable questions?" and as a result built out the option to digitally sign the raw sensor data in-camera so the raw file could be pointed to in court with an attestation of image integrity.
I think the biggest downside here is we're moving toward a world in which only Apple and Google and a few other privileged manufacturers can make cameras.
Identity Verification is the realm of digital credentials. The goal isn't to make putting a driving license or passport on a desk and to verify the picture is of authentic pixels, but to move to mDL / EIDAS2 technology to have a digital representation of a driving license/passport.
This tech would just indicate that they got authentic pixels capturing a potentially fake license.
Likewise, this doesn't help as much as you'd like with most bespoke remote selfie verification systems, since this doesn't support video, doesn't protect against MITM and adds a remote processing delay that breaks any time-of-flight measurement. It shuffles the risks around.
Nobody is worry about making the jobs of age verification companies trying to violate user privacy any easier. In fact we should be moving towards new ways of circumventing these attacks on privacy.
And it also makes Apple's Private Compute to process all the pictures taken by all the iphones. Can we trust their privacy preservation against a court order?
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.
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.
Indeed, that may simply be it. You would want to verify time and date. When coming up with the thought I was looking for ways to crowd verify real world events.
The functionality included time-based rotation of the identifier that supposedly at least notably increased the effort to identify/track people over a longer time frame. I never dug into the details, but I figure that works better with short-term contacts and may break if you are in contact with many people over a longer time frame.
Also, like contact tracking, it should be opt-in, so that you explicitly could act as ‚eyewitness‘.
Seems to lead us down the slippery slope of requiring an Apple device, or a Google device (e.g., https://cybernews.com/privacy/google-qr-code-recaptcha-requi...), or the device of some other entity (that may be mostly non-aligned with democratic values) in order to participate in society.
The unfortunate result of AI slop is reduced trust, which in turn is responded to with surveillance, which ultimately leads to the loss of liberty. Is it possible to do these sorts of verifications in an open way? I kinda doubt it, since someone has to control the hardware manufacturing process.
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.
That's also why the approach is fundamentally flawed. The open-ish C2PA protocol has been "defeated" by tricking phones into signing arbitrary data already. The even-more-closed Apple version can be defeated the same way and relies on Apple to be the sole arbiter of truth.
That's the issue: Instead of trusting your neighbour or a photo journalist's integrity (and if this direct trust is missing, who else should you trust?), you trust a trillion dollar US company. Actor injection.
Am wondering why no one is talking about traceability of Photos. Ex: CSAM which Apple was fighting for a long time. I thought this feature was the answer to provide proof of who shot the picture.
I dont think this is relavent to that use case. It seems like this proposal would be an optional off by default feature. They also seem to be going to lengths to make it privacy first so the verified photos cannot be linked to a specific photographer.
According to the description in the article, "an outside observer cannot determine whether any pair of reference images were taken by the same device." and they "avoid even implicit public association between different photos taken by the same sensor"
Nothing stops you not verifying, or simply stripping the verification off.
What you are prevented from doing is adding a verification to a photo outside of the iOS image pipeline, or modifying the photo with the verification still in tact.
I skimmed the whole article and I didn’t see a single image so I’m confused. Is there some watermark of some kind or where is this metadata integrated? Because if it’s just metadata then I need to parse each photo I come across manually, and if it’s a watermark it can be faked because I won’t manually validate every single image I come across to prove the watermark isn’t fake.
presumably the metadata reader app would be integrated into the photo viewer app which would verify the digital sigs.
I have my doubts about this scheme but this is not one of them. If the point is that someone in principle could verify, that is enough for it to be useful, even if not everyone does.
Apple has to allownpost-manufacruring exchanges of camera due ton right of repair legislation. This requires them to publish pairing tools that are to be used during the repair process to update all the cryptographic vérification chains in the device.
Now the camera module is supposed to generate a key pair internationally and send the public key over the bus. This looks like it is interceptable at repair time and a man in the middle can insert a different public key that they generated externally. Is there a way to stop this?
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.
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.
It does indeed, and that is a fundamental flaw. but as has been discussed here, it is better than the alternative, which is no verification.
During the pandemic, I outlined a scheme for using blockchain technology for image provenance and authenticity tracking. The idea was that instead of any one entity assigning authenticity that it would be done in a crowdsourced manner and that the device would overlay a score whenever an image or video is shown to a user.
My assumption was that the desire of users to see such scores would force all manufacturers to implement this open protocol. But my approach suffered from chicken and egg problem, which Apple's does not.
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.
this already happened -> 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!
> 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.
> 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
My guess is Apple puts out a patch for the jailbreak and their servers stop certifying photos for old iOS versions.
Realistically the average person doesn’t have to care about verified photos. Your personal photos of your kids and friends don’t need cryptographic verification. But photos from journalists might.
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).
334 comments
[ 4.8 ms ] story [ 143 ms ] threadPhotoshop / 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.
I can't wait to see Apple Verified™ photos of UFOs flying over the Golden Gate Bridge.
> Today, powerful, widely available AI tools allow users to easily generate or alter photorealistic images to a degree that was difficult to imagine just a few years ago.
Photoshop has existed for decades and so has fake images. This is a low friction way to attest "this image came from an iPhone sensor and Apple approved it". It will still take the usual image forensics to determine if the scene it depicts is legitimate.
It is the problem that they say they're trying to solve, though. They specifically say "where the essential role of a photograph is to prove that something actually happened".
It fails the reasonable person test to say that in the phrase "something actually happened" the "something" refers to the act of taking the photo.
Whether it does remains to be seen. Do you have inside knowledge about how it works? Despite their initial language about discerning real events, none of their technical explanation says anything at all about anything outside of the camera itself.
Therefore because of your worry (which is based on remarkably little information), it's a bad technology?
Come the fuck on. That's beyond luddite bullshit.
You must be new around here. ;-)
Then maybe let’s save those criticisms until this is in the hands of knowledgeable people who can actually test? I mean, I’m no fan of the direction Apple has gone under Tim Cook, but all else being equal I’m inclined to give them the benefit of the doubt that they may have thought this through over the time it took to build more than a random person speculating on HN who just read a blog post for the first time.
> (…) we see no details here about what scene information is used.
And you assume that everything in a post is the sum total of how it works?
> It increases the potential value of a forgery
By that token, should we also not be adding forgery deterrents to ID cards and bills? After all, if you can fake the preventive measures, “it increases the potential value of a forgery”.
After all, if money is no object, you could just bribe every single apple employee involved in the project.
Let me introduce you to Sir Arthur Conan Doyle and the Cottingley Fairies[0].
"Doyle was enthusiastic about the photographs, and interpreted them as clear and visible evidence of supernatural phenomena. [...] the photographs were faked, using cardboard cutouts of fairies copied from a popular children's book of the time"
[0] https://en.wikipedia.org/wiki/Cottingley_Fairies
Which surely will be useful in ID verification on the Internet; Android devices most likely will follow with same or similar solution
https://image-ppubs.uspto.gov/dirsearch-public/print/downloa...
The Apple Reference Image feature is here launched on iPhone 18 Pro and iPhone 18 Pro Max that both have built-in LiDAR sensors that could be used for this process.
A better fix is to take photos with all three iPhone cameras simultaneously, ideally as a 2-3 video, and use the parallax/multiple perspectives to extract depth information.
They can also prevent photos if iPhone detects the LiDAR sensor is covered, similar to how Meta does it with their camera glasses.
Similarly, LiDAR alone will help disqualify cases where someone is just taking a picture of e.g. a landscape target of the Golden Gate, but that it shown on a screen 1 meter away.
I've never looked at the LiDAR hardware, but where is the emitter in relation to the receiver. Why would the LiDAR not reflect off of whatever you're blocking it with and return a very short flight meaning it was very close?
I think optics could be used to make each camera see a different image.
A video could show shake, which could be verified against readings from the phone's accelerometer -- but you could just hold it still and claim that it was on a tripod.
I think iPhones already do this (although without taking multiple seconds of video). iOS is capable of generating pretty accurate depth data even on devices with no LiDAR unit.
seems pretty easy to make it sufficiently difficult to trick the system
Discerning a camera taken image of an image is typically very very easy. The collors/exposure/etc will all be obviously wrong in ways to a human, even without doing any analysis.
https://www.elcomsoft.com/news/428.html
https://blog.elcomsoft.com/2011/04/nikon-image-authenticatio...
You don't even have to travel to the location, you can just spoof GPS. And of course that will only be needed until some eastern european kid gets bored one weekend and the signing keys magically appear on pastebin. Then all it will take is running a shell script.
It's funny to see Apple fall into this same trap.
But you're only allowed to do that if your name if Anish Kapoor
There’s no such thing as a Golden Gate Bridge.
Prove it.
I think the idea is to control the easy mass production of AI gen picture and not 100% coverage.
That’s a tradeoff I can live with.
You will find pre made kits to do that exact thing in a few weeks/months on alibaba and similar
While I'm on board with you about the inabsolute security of this (relative to what's typically expected of cryptographic systems), the fact that their 'verified' state requires a live certification and can be revoked means that the sensor responsible for obviously faked images will see those images and that device no longer certified.
It all relies a lot on trust in Apple, and integration with Apple, and relatively unmotivated attackers.
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.
Once a defeat device (a camera pointed at a screen) is functional, whoever has it, can simply automate a "receive API request, display image on screen, photograph it, return signed image" pipeline. A cheap internet service. I'd WAG a hundred thousand signatures per day per phone, limited by the sensor speed.
Since there's no way for anyone, Apple included, to correlate photo signatures with the device that signed them, it's also true there's no way to stop one device from signing millions in bulk. ("...an outside observer cannot determine whether any pair of reference images were taken by the same device..."; "...avoid even implicit public association between different photos taken by the same sensor...")
So if you're the proud owner of "literally the only photo of a ridiculously unusual event in a highly public area" which is bounded to either a plausible 15-30 minute window or a sketchy March2026->Now window, people can do something like "hey, gee, did anyone else see that UFO over the golden gate bridge at 3pm?"
plus, you know, the confidence score from their secret neural network, which has an unknown scoring function.
I wouldn't be surprised if it's also possible to detect the differences between a photo of a real scene and a photo of a monitor or printout displaying a photo of a real scene, given they have the raw sensor output.
Not sure if they're doing anything like that.
However much effort is required to fake it - it's proof that the image is either legit or that much effort went in. There's TONS of cases where it's plausible for someone to have put in the effort to fake a photo with AI (nearly zero effort required) but not remotely plausible that they set up some elaborate high quality photo of a fake.
It's also much more damning if you get caught faking it. Think of the examples where police have been caught posting altered images on social media. The lame excuse that some intern didn't realize it would do more than just upscale the image won't fly if some elaborate setup was required.
This sort of concern is presumably why Apple says "Using a neural network with hidden weights, PCC computes a confidence score for the photograph." I'm assuming that things like moire-patterns from pointing the camera at a screen would be caught by that check.
It's of course physically possible to fool the sensor, but at some point it becomes cheaper to just build a UFO and fly it over the actual Golden Gate Bridge.
Scrapped in 3..2..1..
But Apple likely would reject such photo because of inappropriate depth map / LiDAR data.
None of this is impossible, but it could make it really expensive to produce an image that passes forensic analysis.
I don't think we should have this, for that reason alone (but many others too).
[0]: https://imgur.com/fVPkpuQ
PCC is quite good, about as close to private remote compute we can get without doing HME.
After my brief read, one of the main reasons they’re using PCC to produce the signed JPEGs, instead of doing everything on device, is that it maintains your privacy.
If you were signing with the iPhone, an attacker could then correlate photos taken with the same device.
Apple certainly has the data that “this sensor, in this device, took this exact photo” in PCC at the time of signing, but they discard that data.
There are already plenty of insurances that require you to submit claims through a smartphone app that tries to essentially do this by capturing sensor metadata etc. - those don't need to be nation-state resilient, just Joe the Crackhead Insurance Scammer resilient, so this works. Likewise, more and more things online require identity verification (either officially or disguised as age verification).
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.
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.
All of this data can be spoofed if it's not somehow authenticated.
> They could also just update their app to stop accepting photos from the album.
Doesn't help at all if the spoofed data is arriving via spoofed hardware.
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.
The UK allows private prosecution, if it was a real problem the insurance companies would be using it, instead of attempting to make the state pay for it.
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)
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)
Them becoming 70% cryptographic is enough. The people who need the feature, can get a compatible model. Nobody argued that smartphones sold for kids to game on for example should have it.
Also, OIS is a major mechanical add on (a literal motor). 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 highend but quickly became required for one and basically free to implement for two.
No, you can apply smartphone OIS-tech on any sensor, stabilization is achieved via the lens-array, not the sensor. The size of the module slightly increases but that's not a hindering factor. Cost/Benefit of OIS on ultra-wide lenses is not there, so it's usually not applied.
>Your logic would lead to OEMs making SOCs without things like TEE and other things which started in the highend but quickly became required for one and basically free to implement for two.
TEE became a mandatory requirement of the media industry for Smartphones in ~2010, as they announced plans to restrict media-playback on a device without measures to secure the DRM-keys. Google made it mandatory shortly after, because the entire ecosystem was built on media-consumption.
It didn't come for free to the players in the industry, it became a very expensive task to develop, support and maintain it, but that's another story.
Drawing a parallel here, I fail to see who should require cryptographic authentication of a taken image from end-user devices, to the point that no consumer devices without it will be built anymore.
>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.
It will be supported in sensors for sure, but those will be premium-tier sensors, as a differentiation factor. Until today there was no premium sensor used in mass-tier devices.
Of course, again, if there is demand in the market or a regulation requiring it, it will create an incentive for the industry to follow, but I fail to see why either of this should happen in the coming years.
>To have a more serious, honest and accurate comparison than OIS, why can you not buy a single new smartphone at any price without some NPU?
I don't know why OIS is not a "serious, honest and accurate" comparison, can you elaborate?
As stated, it's a highly mature technology available for over a decade already, providing critical-mass observable end-user value, yet it didn't just naturally "trickle down" to every smartphone price-segment, simply because it comes with additional cost no matter which scale (and the Galaxy A1x tier has massive scale).
A NPU is just the evolution of a DSP, which exists in Smartphone SoC's for more than a decade now and is required for Audio and Image processing. DSP's used to run pre-calculated inference models for lens-correction, exposure, white-balance, etc., now these processes can run as models on an NPU.
---
You are trying to argue why that feature won't naturally become a commodity at basically no cost. I'm trying to answer why I don't see this happen, because I worked in this industry for more than 20 years.
The market doesn't get features as a default "easily somehow", features reach this commodity stage because of significant end-user demand (like Camera, Display, Battery), business-value (for the vendor, like Apple Pay) or industry-requirements (like TEE, Widevine example above).
I don't see this happen for this feature, because there is
1. no significant end-user value (unless the public narrative is massively skewed towards "everything is true when the image was signed"),
2. the business-value applies only for Apple's service-proposition for now (which will likely make this feature expand to the non-Pro iPhone tier), and for
3. the industry-requirement I don't see WHO would actually be able to enforce this, for WHICH actual benefit.
And despite that experience, you do not see the universal value in reliable, verifiable image attestation for any user? You cannot imagine why that may be not just useful, but required, what the "end-user demand", "business-value" or "industry-requirements" could be?
There is universal value in many features, yet they didn't become a commodity in all smartphone-tiers.
I don't see how and why this feature should become a default in all smartphones, which you keep insisting on without apparently comprehending the industry and market aspects I am trying to explain.
Peace.
How is what I wrote (that you seem to not see universal benefit) in bad-faith (honestly trying to understand what you mean) if you then add:
> I don't see how and why this feature should become a default in all smartphones [...]
So, do you see universal value or not? Cause you again said you do not and that was precisely what I wrote, that you do not seem to despite it being obvious to anyone who thinks about why phones of any price have cameras.
Should I honestly start writing a list why private as well as business users of smartphones may want, even need this? Is that really required? Consider every use case of a camera on a phone, please, before I feel the need to do that.
You stated that you "struggle to see how cost could be a factor here", so in good faith I was trying to give you an insight.
There is universal value in OIS, as everyone takes pictures while holding the device in his hands, yet OIS is not applied universally in all price-tiers of devices. The reason is COST.
So you wanted to shift the conversation, claiming that it's not a "serious, honest and accurate" comparison, without providing any reasons for that.
Again, I walk with you, I respond to what you're stating.
Now it ends with you starting the straw-man argument of how obviously great this feature is and asking how despite all experience I am not capable to see that.
See, it doesn't matter if _I_ see universal value in this feature or not, the topic was why I consider it unlikely to become a commodity.
You tried to move the conversation to this straw-man argument, and doing so in bad-faith. That's why our talk ends here. I give you my side of this conversation so you may read and grow from it, but this is entirely up to you.
P.S.: You also seem to misunderstand what this feature is. It's NOT picture attestation as you put it.
Picture attestation means an entity confirms the connection of a picture to something else (some "metadata"), e.g. a picture of a person to an identity (Name, ID,...) or a place. This attestation party can either be a person (self-attested) or an official entity (e.g. a government).
Nothing in this process changes with this Apple feature, because all it can do is confirm that the picture was taken by the camera as-is, but the attestation to the external metadata (WHO this is, WHAT this is, WHERE this is) still needs to be done by someone else. A party trusted enough to vouch for this.
But let's end this here. Have a good day.
> You tried to move the conversation to this straw-man argument, and doing so in bad-faith [...]
What? The conversation started with the assumption being made that this was going to be iPhone exclusive. I stated doubt and then you (re-read to verify cause you seem to have forgotten that) moved the conversation to the only massive straw man in this interaction, the 99usd phone market.
I personally still believe that this is going to be a universal feature soon enough (wait to hear from Omnivision, etc.) and stand by that. This is my personal assessment due to the objective need for such features in the world we live in today. I may be wrong on this, we will see. But I was not the one who moved from Android OEMs to the lowest of the low-end, that was you.
I shouldn't have engaged with someone so serious that they must drag "why couldn't Android OEMs do the same" down to "99 USD Smartphone". Anyone who does such a shift, well, they must have a well founded, serious point to make.
The reason is digital stabilization is a good enough alternative to not bother, and the lens/sensor modules they use in bulk just didn't come with "analog" stabilization. And OIS is way less important than a future digitally verified photos feature could be (which could be mandated by corporations, banks, governments, insurance companies, for several uses when it becomes widespread), so they didn't bother to add it.
All kinds of cheapo smartphones still manage to have OIS, just because some Samsung models don't doesn't mean it's a universal argument for cheap phones in general.
>Nothing in this process changes with this Apple feature, because all it can do is confirm that the picture was taken by the camera as-is, but the attestation to the external metadata (WHO this is, WHAT this is, WHERE this is) still needs to be done by someone else. A party trusted enough to vouch for this.
Moot point, since the entity (e.g. gov) asking for an untampered photo (which this can do), can combine the photo with the metadata from the upload, like your gov mobile app account.
There's lens stabilization and there is also sensor stabilization. Both are things.
Because it's just not that important, phones and cameras have also used digital stabilization via cropping since forever.
1. OIS (optical stabilization) ensures that the light photons consistently hit the same pixel, removing the blur caused by camera-shake during exposure.
2. EIS (electrical stabilization) via cropping compensates camera-shake on video(!) recording by applying the same shake to the crop-canvas within the frame.
--> EIS can fix a shaky video but not a blurry photo.
It's video where people care about these days.
--> OIS actually became MORE important for Smartphones in the past years, because while post-processing produces better and better results, it massively depends on usable input data. OIS is one of the very few methods to improve the INPUT-quality for post-processing.
>"There have been several expensive cameras with no OIS, like Ricoh GR and (and v2), or ZVE10 (and v2)."
That's a apples and oranges comparison. A quick Google search tells me the size of a pixel on the Ricoh GR sensor is 4.81 µm, which is ~8 times larger than the pixel in recent smartphones (~0,6µm). It is not only physically capable to capture 8x more light, it is also much less affected by minor shaking than sensors with smaller pixel-sizes.
>*"Does anybody complain about blurry S12 photos?"
Not sure what's a "S12", but:
- On flagship phones with OIS: Not so much. Maybe in low-light scenarios, because, you know, not much light...
- On cheaper devices without OIS: Yes! Oh yes, constantly.
People assume that the picture-quality of a e.g. 2026 Galaxy A16 must be comparable or better than the picture of a 8-year old Galaxy S9. It's not, the S9 is still better in everyday shooting.
Just check user-reviews of mass-tier smartphones without OIS, like Samsung Galaxy A series...
Sure, the same could happen here, but I don't know which industry (or other body) would demand that and have sufficient justification for it.
After all, the feature doesn't really change that much for a consumer, the trust-chain is largely unchanged: If I send you a picture and tell you that's my dog, you still have to take my word for it, regardless whether Apple signed the picture or not.
You wanna buy it now or not? /s
It's entirely software. It's R&D cost, with basically none of it in hardware (you technically just need the private key store which even very cheap devices have)
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.
An insurance would either send #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...
There would be no contract, you just upload image from your phone and they verify signature in the file
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.
Without it, anyone with a stolen document can pass it. (I don't think there's a generally available database of stolen documents, so I suspect these usually remain valid until their regular date of epxiry.)
Before deepfakes were dime a dozen, I remember my bank starting a video-call with me and required me to show my ID to them via camera. This was after a multi-factor check that I passed.
Making any of these factors more trustworthy is a win in my perspective, so having a trusted sensor is always better even if you do multi-factor authentication.
Our ID cards have a private-public key pair inside them, and it allows us to sign things amongst other things. Renewing your ID card for any reason revokes the digital signature of the previous one, so scanning it via NFC probably enough to check whether it's revoked. Same with photo (since machine readable part contains serial and check digits and such).
The idea is indeed that instead or in addition to requiring an app, the insurance company would require the app to run on a phone that supports Reference Image to make sure the image wasn't tampered with. Not right now, when the phones are new, but in a while when 50% of Americans have a sufficiently new iPhone. The rest of the people gets told to either borrow one if they want to make a claim, or go through some other alternative process designed to be so annoying that most people give up.
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.
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.
> And while "a nation state actor can spoof this" is a problem for the journalism use case
This is incorrect:
So… a nation-state can't really do anything here unless they acquire alien technology. If something crazy happens (solar flare or EMP?), a fraudulent reference image can be revoked.> 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:
Yup, you don’t even need nukes: https://en.wikipedia.org/wiki/Explosively_pumped_flux_compre...
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.
Unless you use a friend's iPhone, or an iPhone you 'rented' for 5 minutes for $20 from someone on Craigslist or Facebook Marketplace to take a picture on and then Airdrop to you.
Or you could just email/WhatsApp/... it.
Perhaps do not be so literal: Airdrop, SMS/MMS/RCS, WhatsApp, Signal, etc:
* https://github.com/localsend/localsend
It is for Apple, to the extend that if there are backdoors and weaknesses in their PCC, they could register a device signing identity to Apple signature mapping.
I think the line of reasoning is that you have to trust Apple anyway, since they could also roll out a malicious image to your particular phone, but I still feel like PCC is much harder to verify/audit than an iPhone already is.
It’s possible for Apple, as stated in the blog post (e.g. “which lets the device later produce signatures that Apple can attribute to that specific phone”).
At least for the image itself, using direct projection onto the sensor (in a way similar to a retinal projector or film recorder) would be difficult to detect I imagine?
But at the end of the day, even if you manage to get a fake reference image, it's still on the person making the claim to show that the content of the image is real. A reference image of a document is useless, the physical document could be a forgery. A photo of people could be refuted with alibis during the timestamp window (max 15 minutes it sounds like?). A photo of property damage doesn't prove how or when it happened.
Apple knows the iphone the reference image was upload from, so, yes, there is.
It is probably possible for an entity to break it, but it would require live access to both Apple and the third party (Likely Cloudflare) servers. And that is assuming there is only one third party routing OHTTP requests, otherwise you would need to monitor all of them, in real time, since the requests are transient.
> The final reference image is instead signed by Apple’s signing service, after validation by PCC.
So, if compelled, Apple could theoretically tell someone if two images came from the same camera.
[1] https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation
it’s one step removed from identity.
fwiw i think this is an unambiguous improvement over current post-sensor attestations, it’s just good to explore the edges
No they couldn't.
If you generate two SSH key pairs on your laptop, there's no way to confirm they were created on the same machine.
There's no device identifying data in a reference image, which is the point. The factory signature, the image sensor key, the Secure Enclave Processor key and all of the signing that takes place on PCC are all device-agnostic.
The reference image is processed and eventually signed by Private Cloud Compute's post-quantum signature using a hybrid MLDSA87-RSA-3072-PSS-SHA512 scheme.
So… it's not possible for Apple to know if two images came from the same iPhone.
When the user initiates developing a reference image, the device uploads the secure digital negative to Private Cloud Compute. PCC recomputes the digest embedded in the frame and verifies the sensor's signature over the pixels and that digest, verifying the certificate chain back to the sensor CA. PCC also verifies the SEP signature and chains it to the BAA CA, and it verifies the signature on the device manifest and chains it to the CA that signs device manifests at the factory. It then confirms that the sensor and SEP named in those chains belong to the same device. [...] If these checks pass, PCC then submits the commitment to our signing service, which signs it with a composite post-quantum signature using a hybrid MLDSA87-RSA-3072-PSS-SHA512 scheme. The signature is embedded in the JPEG, and the reference image is returned to the device, which associates it with the main photo from the original capture.
After the secure digital negative is successfully developed, it's automatically moved to the deleted photos folder."
So in the end it all depends on how much you trust Apple's cloud and PCC nodes. If there is a weakness in their services, Apple could record both the original signatures and their signature, and could prove whether two photos were made using the same lens/device and they could even trace it back to a specific device (by looking up the original signature + signing identity given their signature).
They can then sign their own fraudulent images.
We already know it's happening right now, and they know we know, but we can't do shit about it.
I'm aware. The point is they can't give the NSA something they don't have. The photo sensor generates its own ECDSA P-256 signing key pair and never releases the private half.
Every device has a unique key pair and the private key is unavailable… there's not a way to give the NSA that would help them. The system is setup so that the image data, meta data, etc can't be accessed by anyone including Apple.
- verifies each link and its certificate chain, sensor signature over pixels, SEP signature, device manifest signature
- PCC Submits the commitment (the JPEG hash) to Apple's signing service.
So, at some point in time, Apple's servers have both the original certificate chain and the new replacement signature. If this is recorded, Apple can deanonimize photos and check whether two photos were from the same device/sensor.
Apple's system protects against most state actors, except Apple and the US, unless you fully trust that their PCC is watertight.
(Remember that Apple was part of PRISM and probably also its successor.)
I don't think law enforcement needs it, because when sending/posting a picture, people leak so much metadata anyway.
But people outside the US should certainly distrust these systems.
Again, that's not how it works.
There's no set of keys and certificates they could give to the NSA. Every iPhone 18 Pro and Pro Max has a unique set of cryptographic keys, most of which can't be accessed by Apple.
The first thing that happens is when photo sensor is initialized at the factory, it creates its own ECDSA P-256 signing key pair; the private key is never disclosed. The public key is signed by the factory's certificate authority.
This ain't X.509 where VeriSign's key pair is sitting in a HSM at their HQ and in theory could be forced to sign a fraudulent certificate or revoke someone's valid website certificate.
Also, while the unique device ID is supposed to be burned into fuses by the SE during production, it is kinda hard to prove for anyone that is not Apple that this indeed happens in the way they state.
Personally I’m not a strong believer in such theories though. I think it’s more mundane and Apple helps law enforcement by having some weak defaults. Like how iMessage is end-to-end encrypted, but most chats are available to law enforcement because most people turn on iCloud Backups/Messages in iCloud and not ADP, resulting in chats only being encrypted at-rest in iCloud. This is only stated somewhere in a footnote in one of their security documents.
There are more weak defaults like that in various crucial apps (e.g. WhatsApp) that makes most important stuff available to law enforcement when needed.
That's not how this works.
Let's pretend they're able to extract the sensor key and the SEP key. Then what?
An attacker won't have the ECDSA P-256 over SHA-256 signed timestamp token from the Apple Push Notification Service.
When Reference mode starts, the operating system supplies a SHA-256 digest to be embedded at a fixed location in the captured frame’s metadata. The digest is computed from the most recent secure timestamp, the device manifest, and the device's secure boot manifest.
More encryption and checking happens until the secure digital negative is sent to Private Cloud Compute:
PCC recomputes the digest embedded in the frame and verifies the sensor's signature over the pixels and that digest, verifying the certificate chain back to the sensor CA. PCC also verifies the SEP signature and chains it to the BAA CA, and it verifies the signature on the device manifest and chains it to the CA that signs device manifests at the factory. It then confirms that the sensor and SEP named in those chains belong to the same device. Only if all these checks pass does processing continue.
Only PCC can create an Apple Reference Image; an attacker having the image and sensor private keys doesn't enable them to create a reference image.
Sure they can, they have everything needed to prove to Apple's servers that they're a real iPhone since pulling the keys means they have the cryptographic root of trust, and Apple's servers will happily be a signature oracle for the in that case.
> When Reference mode starts, the operating system supplies a SHA-256 digest to be embedded at a fixed location in the captured frame’s metadata. The digest is computed from the most recent secure timestamp, the device manifest, and the device's secure boot manifest.
And when you know what is measured into those manifests and the keys at the root of trust you can manufacture those too.
[1]: "How pixels become an Apple Reference Image" - https://news.ycombinator.com/item?id=49735284
You think that this won't be used as additional data by the various competing companies who have implemented "take a live still or video selfie of yourself with your phone and show us your ID cards" for identity verification purposes?
> 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.
Some banking apps nowadays ask you to upload a photo of your ID and then use the webcam/selfie camera to confirm that's it's really you (sometimes asking you to move your head in a particular way). But how trustworthy is that process really? Apple Reference Image could be (part of) a solution, by certifying that both images were taken by the same device around the same time.
This is explicitly not possible, as the post you were replying to pointed out.
> 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.
How would they do that ? There is only one signed key of the device
> Apple Reference Image is not an id system
GP does not have it all wrong. A company desiring you to prove your identity often asks for a photograph of your government ID. Now that this is easily faked, it is reasonable to expect that the company will ask for a verifiably authentic photograph of your government ID.
That the Apple Reference Image itself is not traceable to the device/user is beside the point in this use case.
Interfacing with images is easy. Interfacing with NFC takes work. I have experienced precisely zero identity-verification workflows which NFC'd anything, and that includes my banks, which could easily ask for my debit card's NFC but don't.
I think processing that information is mandatory now, but probably was optional/largely unimplemented in 2012. But maybe I'm off by five years or so?
The CA public key I just got off my country’s website, they were kind enough to just publish it :)
If anything, verifying NFC is easier than images. Asking the chip in my identity card to provide a cryptographically-signed "This document belongs to Jane Doe" request is a handful of lines of code. Doing the same with images? Good luck coming up with an approach which isn't fooled by a photocopy!
Our national app for logging into government sites and confirming things also requires a step where the ID’s NFC is read to reach the highest trust level.
So it’s definitely becoming more and more common here.
If someone took a picture of a fake ID in the past, this method will bring no benefit, it will just add Apple as a paid service-provider.
It also doesn't change the trust-relationship between the two parties: If I need to prove my identity by uploading a government ID, _I_ am doing the photo attestation that this is the ID matching the data I provided, with or without an Apple Reference image.
The image will be authentic, but an authentic image of a fake id isn't useful to them.
Also--only two iPhone models support this technology. It'll be years before the DMV or whoever could count on enough adoption before they could support it.
> a nation-state can't really do anything here unless they acquire alien technology.
Alien technology such as NSLs or supply chain attacks against Apple?
This is definitely not an Apple thing, though the use profile is more ubiquitous. Canon had, more than twenty years ago, when they first started making DSLRs, the question of "If we want law enforcement to use these, how do we handle the inevitable questions?" and as a result built out the option to digitally sign the raw sensor data in-camera so the raw file could be pointed to in court with an attestation of image integrity.
This tech would just indicate that they got authentic pixels capturing a potentially fake license.
Likewise, this doesn't help as much as you'd like with most bespoke remote selfie verification systems, since this doesn't support video, doesn't protect against MITM and adds a remote processing delay that breaks any time-of-flight measurement. It shuffles the risks around.
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.
The unfortunate result of AI slop is reduced trust, which in turn is responded to with surveillance, which ultimately leads to the loss of liberty. Is it possible to do these sorts of verifications in an open way? I kinda doubt it, since someone has to control the hardware manufacturing process.
I hope that companies and governments don't start forcing us to use this stuff by requiring it for their services.
Whatever that means in detail...
What you are prevented from doing is adding a verification to a photo outside of the iOS image pipeline, or modifying the photo with the verification still in tact.
I have my doubts about this scheme but this is not one of them. If the point is that someone in principle could verify, that is enough for it to be useful, even if not everyone does.
Now the camera module is supposed to generate a key pair internationally and send the public key over the bus. This looks like it is interceptable at repair time and a man in the middle can insert a different public key that they generated externally. Is there a way to stop this?
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
It does indeed, and that is a fundamental flaw. but as has been discussed here, it is better than the alternative, which is no verification.
During the pandemic, I outlined a scheme for using blockchain technology for image provenance and authenticity tracking. The idea was that instead of any one entity assigning authenticity that it would be done in a crowdsourced manner and that the device would overlay a score whenever an image or video is shown to a user.
My assumption was that the desire of users to see such scores would force all manufacturers to implement this open protocol. But my approach suffered from chicken and egg problem, which Apple's does not.
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.
If there is too much of a gap between the upper and lower bounds then the image becomes suspicious.
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.
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.
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
Realistically the average person doesn’t have to care about verified photos. Your personal photos of your kids and friends don’t need cryptographic verification. But photos from journalists might.
Hardware wins.