Also I'm surprised the 3rd-party doctrine doesn't apply. There's the "private search doctrine" mentioned but generally you don't have an expectation of privacy for things you share with Google
Also I'm surprised the 3rd-party doctrine doesn't apply. There's the "private search doctrine" mentioned but generally you don't have an expectation of privacy for things you share with Google
"More simply, a hash value is a string of characters obtained by processing the contents of a given computer file and assigning a sequence of numbers and letters that correspond to the file’s contents."
From 2018 in United States v. Reddick.
Like I said in a sib. comment, this FOIA lawsuit goes into questions of hashing pretty well: https://caselaw.findlaw.com/court/us-2nd-circuit/2185910.htm...
This FOIA litigation by ACLU v ICE goes into this topic quite a lot: https://caselaw.findlaw.com/court/us-2nd-circuit/2185910.htm...
Either way I think the judge's wording makes sense.
Once the hashing algorithm was assigned, individual values are computed or calculated.
I don't think the judge's wording is all that bad but the word "assigned" is making it sound like Google exercised some agency when really all it did was apply a pre-chosen algorithm.
The hash is kind of metadata recorded by Google, I feel like Google using it to keep child porn off their systems should be reasonable. Same ballpark as limiting my storage to 1GB based on file sizes. Sharing metadata without a warrant is a different question though.
If the FPR is comparable to asking a human "are these the same image?", then it would seem to be equivalent to a visual search. I wonder if (or why) human verification is actually necessary here.
See also:
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.
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.
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.
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 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.
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.
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.
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.
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.
Does two different labs DNA analysis are exactly equal?