>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.
>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, with or without OIS. There have been several expensive cameras with no OIS, like Ricoh GR and (and v2), or ZVE10 (and v2).
It's video where people care about these days. Does anybody complain about blurry S12 photos?
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...
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 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).
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
People will go "no, I nerd out and tinker more than ever" where by "nerd out and tinker", and what they mean is "I prompt the AI, and it does the tinkering for me".
I say the question isn't if you use AI to build you something, but if you nerd out and tinker yourself.
For some tinkerers, the tinkering is writing the code. That's you.
For other tinkerers, the tinkering is accomplishing an objective or building a thing. That's maybe Matthias Wandel.
I used to be like you (when I was a pro coder), and now I'm more like Matthias (I have a homestead and a small business). You're welcome to write the code and enjoy yourself that way. I want to enjoy the thing I've built, with the help of AI. You can say I didn't build it, I don't really care--my ego isn't wrapped up in it.
>For other tinkerers, the tinkering is accomplishing an objective or building a thing
Those are not tinkerers then, as there's no tinkering involved. Or there might be in other parts (e.g. with electronics to hook up and house the code AI wrote for you, if it's something that will run on a Raspberry Pi), but not in the coding part.
The question implies: "do you still enjoy nerding out and tinkering by writing code yourself, now that AI can write it". Else asking if you're demotivated from doing it "because of AI" wouldn't make sense.
So I would say that "I like making stuff by having AI write the code" is still an admission of not nerding out and tinkering (regarding code) anymore.
> Those are not tinkerers, as there's no tinkering involved.
This seems closed minded view of tinkering. There are plenty of ways to tinker aside from just writing code. It could be in driving traffic to a website, selling a product, combining datasets, automating a task, etc.
I personally love economics and have used AI to tinker with combing multiple datasets to create new ways of viewing economic growth at the metro level across variables.
But what if I use AI to write live demos where you can write machine code, debug it visually in your browser, punch data on virtual punch cards? What if I used AI to generate videos about this, generate the artwork, backgrounds, narration, intro music, etc. I guess I am just a meta-tinkerer :-)
> Same how you're not a musician just because you had Suno create something.
In this analogy, the person calling themselves a musician would have to be falsely calling themselves a programmer after using AI to code something. The word used here was "tinker" which can be any number of things. One can "tinker" with business ideas, investment theses, hardware designs, economic models, gameplay concepts, baking recipes, brewing formulas, and more.
AI is just another tool to nerd out and tinker with. The question was "Is anyone else losing their motivation to nerd out and tinker".
If you're using AI (to wit: another tool) to nerd out and tinker, then you're obviously not losing that motivation.
So my genuine answer to the original question is: No, I nerd out and tinker more than ever.
Right now, I am using AI as a tool to do stuff I otherwise wouldn't do, like reverse engineer a Whoop band for use with Apple Health sans a Whoop subscription.
It is the YAML spec's fault. The implementations get away with it because the spec is not strict enough, plus all the magic it uses it bad (like the types being guessed implicitly in some case, or NO treated as boolean).
They sell to dozens of major companies, plus sell their own retail.
An added 0.4% revenue for selling the most expensive part (the display) of the new flagshit product, for the most popular high end phone line in the world, sounds about right.
>I’m more and more convinced that all of AI engineering is Neijuan (内卷, meaning curl inwards). In China it describes a system that demands ever more effort and competition without improving output. The way in which it sometimes shows up in the West is the 996 nonsense. The English term for Neijuan is “Involution” from the book Agricultural Involution. Agricultural involution describes the intensification of farming that raises productivity per square meter while leaving productivity per head unchanged.
Isn't the term "diminishing returns" already covering that?
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.
reply