The reason human verification is necessary is that the government is relying on something called the "private search" doctrine to conduct the search without a warrant. This doctrine allows them to repeat a search already conducted by a private party (i.e., Google) without getting a warrant. Since Google didn't actually look at the file, the government is not able to look at the file without a warrant, as that search exceeds the scope of the initial search Google performed.

I doubt sha1 hashes are used for this. Those image hashes should match files regardless of orientation, cropping, resizing, re-compression, color correction etc. The collision could be far more frequent with these hashes.

The hash should ideally match even if you use photoshop to cut the one person out of the picture and put that person into a different photo. I'm not sure if that is possible, but that is what we want.

> Out of curiosity, what is false positive rate of a hash match?

No way to know without knowledge of the 'proprietary hashing technology'. Theoretically though, a hash can have infinitely many inputs that produce the same output.

Mismatching hash values from the same hashing algorithm can prove mismatching inputs, but matching hash values don't ensure matching inputs.

> I wonder if (or why) human verification is actually necessary here

It's not about frequency, it's about criticality of getting it right. If you are going to make a negatively life-altering report on someone, you'd better make sure the accusation is legitimate.

I'd say the focus on hashing is a bit of a red herring.

Most anyone would agree that the hash matching should probably form probable cause for a warrant, allowing a judge to sign off on the police searching (i.e., viewing) the image. So, if it's a collision, the cops get a warrant and open up your linux ISO or cat meme, and it's all good. Probably the ideal case is that they get a warrant to search the specific image, and are only able to obtain a warrant to search your home and effects, etc. if the image does appear to be CSAM.

At issue here is the fact that no such warrant was obtained.

I think it'll prove far more likely that the government creates incentives to lead Google/other providers to fully do the search on their behalf.

The entire appeal seems to hinge on the fact that Google didn't actually view the image before passing it to NCMEC. Had Google policy been that all perceptual hash hits were reviewed by employees first, this would've likely been a one page denial.

If the hash algorithm were CRC8, then obviously it should not be probable cause for anything. If it were SHA-3, then it's basically proof beyond reasonable doubt of what the file is. It seems reasonable to question how collisions behave.

I don't agree that it would be proof beyond reasonable doubt, especially because neither google nor law enforcement can produce the original image that got tagged.

By original do you mean the one in the database or the one on the device?

If the device spit out the same SHA3, then either it had the exact same image, or the SHA3 was planted somehow. The idea that it's actually a different file is not a reasonable doubt. It's too unlikely.

By the original, I mean the image that was used to produce the initial hash, which Google (rightly) claimed to be CSAM. Without some proof that an illicit image that has the same hash exists, I wouldn't accept a claim based on hash alone.

Oh definitely you need someone to examine the image that was put in the database to show it's CSAM, if the legal argument depends on that. But that's an entirely different question from whether the image on the device is that image.

> Most anyone would agree that the hash matching should probably form probable cause for a warrant

I disagree with this. Yes, if we were talking MD5, SHA, or some similar true hash algo, then the probability of a natural collision is small enough that I agree in principle.

But if the hash algo is of some other kind then I do not know enough about it to assert that it can justify probable cause. Anyone who agrees without knowing more about it is a fool.

That's fair. I came away from reading the opinion that this was not a perceptual hash, but I don't think it is explicitly stated anywhere. I would have similar misgivings if indeed it is a perceptual hash.

For non-broken cryptographic hashes (e.g., SHA-256), the false-positive rate is negligible. Indeed, cryptographic hashes were designed so that even nation-state adversaries do not have the resources to generate two inputs that hash to the same value.

See also:

https://en.wikipedia.org/wiki/Collision_resistance

https://en.wikipedia.org/wiki/Preimage_attack

These are not the kinds of hashes used for CSAM detection, though, because that would only work for the exact pixel-by-pixel copy - any resizing, compression etc would drastically change the hash.

Instead, systems like these use perceptual hashing, in which similar inputs produce similar hashes, so that one can test for likeness. Those have much higher collision rates, and are also much easier to deliberately generate collisions for.

Naively, 1/(2^{hash_size_in_bits}). Which is about 1 in 4 billion odds for a 32 bit hash, and gets astronomically low at higher bit counts.

Of course, that's assuming a perfect, evenly distributed hash algorithm. And that's just the odds that any given pair of images has the same hash, not the odds that a hash conflict exists somewhere on the internet.

You need to know the input space as well as the output space (hash size).

If you have a 32bit hash but your input is only 16bit, you'll never have a collision (and you'll be wasting a ton of space on your hashes!).

Image files can get into the megabytes though, so unless the output hash is large the potential for collisions is probably not all that low.

You do not need to know the input space.

Normal hash functions have pseudo-random outputs and they can collide even when the input space is much smaller than the output space.

In fact, I'll go run ten million values, encoded into 24 bits each, through a 40 bit hash and count the collisions. My hash of choice will be a truncated sha256.

... I got 49 collisions.