Thread by @SarahJamieLewis

Also has anyone else attempted to reverse engineer how Apple might have arrived at 1/trillion probability of false account flagging?

Some back of the napkin math, please double check...

If you assume the threshold is >10 false positives over a year to trigger an account (thrown around in the Apple docs), and each person stores ~1024 new photos per year (~3-4/day) then to get a 1/trillion figure your single-instance false positive probability has to be ~1/2000

You can get that probability if you assume the database being checked against contains ~16M unique hashes and the effective hash size is ~36bit (Neuralhash hashes appear to be 128 bit, but they are perceptual not random)

Neither of those values seems absurd given what we know.

Which would mean that the actual probability of a single false positive match for someone who takes ~3-4 photos a day over the course of a year would be ~40%.

Could be that Apple picked 1/trillion because it sounds very large and looks better in print, but it would be really nice to be able to verify that by knowing what the proposed threshold value is, and what the actual expected false positive rate is.

And yeah that is the average case...if you take a lot of photos, say you are a new parent documenting your kid taking 50 photos a day then your probability of getting >10 false positives over a year would be ~30% based on the guesstimates above

That is on the extreme end but is in no way completely outside of reality.

The only way to make that not awful would be to assume that by "1 in a trillion" Apple actually means a much, much larger number.

This math also assume that events are independent which I don't think is an actual valid assumption given that perceptual hashes are by-definition not independent (similar-but-different images will result in similar-but different hashes)

Would be great if someone could independently derive their own guesstimates for this to check my math.

Also if you assume these numbers are anywhere near accurate then you have to come the conclusion that any obfuscation of the matching count needs account-specific parametrization otherwise it quickly starts leaking distinguishing bits (e.g. matches > threshold w/out decryption)