And it should, unfortunately it’s not. Maybe right to repair and other laws will, hopefully, change that but for now, it’s bundling, part pairing and locks all the way down.

they are not welcome to implement it on my device

I wish, sadly that’s not how using non open source or open hardware devices work. You are running their software on their hardware with their limitations. It’s not a PC or SBC.

Edit: if we were to stick to the card game analogy, it’d be more like playing the card game in a hotel, in a room that you rented, rather than at home.

I agree on permission.

Yet I’ll still try to clarify the technical aspect because I find that genuinely interesting and actually positive. The point of homomorphic encryption is that they are NOT looking at your data. They are not encrypting data to decrypt them. An analogy would be that :

• we are a dozen of friends around a table,
• we each have 5 cards hidden from others,
• we photocopy 1 card in secret
• we shred the copied card, remove half of it, put it in a cup and write a random long number on that cup
• we place that cup in a covered bowl
• one of us randomly picked gets to pick a cup, count how many red shards are in it, write it back in the cup and writes adds the number to the total written on the bowl, we repeat that process until all cups are written on only once
• once that’s done we each pick back our up without showing it to the others

Thanks to that process we know both something about our card (the number of red shards) and all other cards (total number of red shards on the bowl) without having actually revealed what our card is. We have done so without sharing our data (the uncut original card) and it’s not possible to know its content, even if somebody were to take all cups.

So… that’s roughly how homomorphic encryption works. It’s honestly fascinating and important IMHO, the same way that cryptography and its foundation, e.g. one way functions or computational complexity more broadly, are basically the basis for privacy online today.

You don’t have to agree with how Apple implemented but I’d argue understanding how it works and when it can be used is important.

Let me know if it makes sense, it’s the first time I tried to make an analogy for it.

PS: if someone working on HE has a better analogy or spot incorrect parts, please do share.

I don’t want Apple exflitrating my photos.

Well they don’t. I don’t want to justify the opt-in by default but, again (cf my reply history) here they are precisely trying NOT to send anything usable to their own server. They are sending data that can’t be used by anything else but your phone. That’s the entire point of homomorphic encryption, even the server they are sent to do NOT see it as the original data. They can only do some kind of computations to it and they can’t “revert” back to the original.

Dunno either, funnily enough skimming through https://eprint.iacr.org/2012/144 I noticed authors are from KUL https://www.esat.kuleuven.be/

Why do I say “funnily enough” is because, just like with e.g. IMEC for chips, some of the foundation of modern technology, comes from the tiny and usually disregarded country of Belgium.

Well to be fair, and even though I did spend a bit of time to write about the broader AI hype BS cycle https://fabien.benetou.fr/Analysis/AgainstPoorArtificialIntelligencePractices LLMs are in itself not “bad”. It’s an interesting idea to rely on our ability to produce and use languages to describe a lot of useful things around us. So using statistics on it to try to match is actually pretty smart. Now… there are so many things that went badly for the last few years I won’t even start (cf link) but the concept per se, makes sense to rely on it sometimes.

not going to be the overhyped LLM doing the analysis

Here indeed I don’t think so but other vision models, e.g. https://github.com/vikhyat/moondream are relying on LLM to generate the resulting description.

Yep, reading their blog post to read a bit better. I don’t like that it’s enabled by default, especially despite iCloud off (which should be a signal to say the user does NOT want data leaving their device) but considering what others are doing, this seems like the best trade off.

Looks like they did “Brakerski-Fan-Vercauteren (BFV) HE scheme, which supports homomorphic operations that are well suited for computation (such as dot products or cosine similarity) on embedding vectors that are common to ML workflows” namely they use a scheme that is both secure and efficient specifically for the kind of compute they do here. https://machinelearning.apple.com/research/homomorphic-encryption

extract information

I don’t think so, at least assuming the scheme isn’t actually broken… but then arguably that would also have far reaching consequence for encryption more broadly, depending on what scheme the implementation would be relying on.

The whole point is precisely that one can compute without “leaks”.

Edit: they are relying on Brakerski-Fan-Vercauteren (BFV) HE scheme, cf https://machinelearning.apple.com/research/homomorphic-encryption

I don’t know how much compute cost this adds to an already expensive computation.

At that scale and because they do pay for servers I bet they did the math and are constantly optimizing the process as they own the entire stack. They might have somebody who worked on the M4 architecture give them hint on how to do so. Just speculating here but arguably they are in a good position to make this quite efficient, even though in fine if it’s actually worth the ecological costs is arguable.

So homomorphic encryption means the server can compute on the data without actually knowing what’s in it. It’s counter-intuitive but better not think about it as encryption/decryption/encryption precisely because the data is NOT decrypted on the server. It’s sent there, computed on, then a result is sent back.

“does this even if you’ve already opted out of uploading your photos to iCloud.” damn that’s a bit much!

Edit; in this thread, people who miss the point of homomorphic encryption to dunk (sadly often rightfully so) on Apple.