IMHO, it's the comparison to a stored hash value which is the scanning part. In my scenario, the hash calculation is only done during upload and the hash is not

IMHO, it's the comparison to a stored hash value which is the scanning part. In my scenario, the hash calculation is only done during upload and the hash is not saved on device. Let's say tomorrow China tells Apple to do client-side scanning, and let's say Apple decides to comply. Scenario A (Apple already did on-device scanning): Apple flips a few bits. iOS no longer cares whether images where uploaded on not. The code change can easily be hidden assuming no reverse engineering. There's little measurable difference unless the user has a matching image in which case the user is already done for [EDIT: in retrospect, the device should be running a scan on the local images every blacklist fetch. I still think that scanning more images is much less of a difference than the other scenario, where the device has to do stuff it just did not do before] Scenario B (Hash Comparison is server-side): The code change can be hidden of course. But otherwise there are significant changes: The device needs to calculate hashes to every image upon creation which it did not before. The device needs to fetch the blacklist every X days which it did not before. The device needs to run the local scan every blacklist fetch which can be slow if many images. All these things are far more likely to be noticeable and far more likely to generate network traffic. >Pushing a perceptual hash of every photo to Apple would actually decrease your privacy as now Apple can find any known photo in your library - not just CSAM but on any topic - memes, political protests, porn, whatever. The Hash shouldn't be reversible, so the only way for Apple to do that is to have an existing dataset. Which is possible, but preferable to the no E2E situation and (IMHO) the on-device scanning situation.