> It's trivial to deal with tainting the database: both secondary hashing and more invasive hashes deal with that problem.
Sorry, what does "more invasive hashes" mean?
> It's trivial to deal with impersonated hashes, all positives can be scanned on device in a second round with a different hash method.
The double hashing would definitely help. I doubt anybody's gotten a close collision for more than one hash at a time.
It's not inconceivable that they could do it, though. As far as I know, there are only two hash methods that get used for this, and I think both of them are based on sliding a window over a reduced version of the image and doing a DCT, so they're pretty similar. I wouldn't be surprised if somebody could fool both of them enough to at least force you to tighten up your similarity threhsholds. It would be safer to come up with something that worked on completely different principles. No idea how hard that would be.
I don't think that the second-stage backup, where you send the image off somewhere, is "privacy preserving" by any standard I'd be comfortable with. Well, OK, actually even completely foolproof client side scanning isn't privacy preserving enough for me, but I mean that's substantially worse.
I also don't think it'd be easy to find anybody to run that server. And it'd be a significant structural change from what's deployed now. It'd be much more disruptive than adding a second hash (which is isomorphic to just switching to a single composite hash). It took a long time to get the present system deployed, so that big a change doesn't seem "trivial".
> These systems have undisclosed minimums. A person sharing CSAM will be generating positive results at a significant rate. Receiving a few images with faked hashes won't set off alarms, and if a victim is suddenly receiving hundreds of images, that would already be obvious.
Minimum what? If you just say "undisclosed minimums", my mind immediately assumes you mean threshold similarity scores. But you seem to mean hit counts to trigger various actions.
Anyway, both of those are set by the service that's using the database. Those services vary in their strictness and clue level, so I'm not sure you can say anything very general about them.
> These articles over sensationalise what occurs when a positive match is found.
In the threat model of the original article, the people doing the review for false positives are most likely the same people who poisoned the database to begin with. They've corrupted it to give them hits on images they want to suppress, even though the system operators don't want to support them in suppressing those images. So that whole "reviewed by a human and discarded" step doesn't happen.
In the broader world, I suspect that the thresholds for "delete the file" tend to be very low... too low for there to be human review. The thresholds for "disable the user's account" probably aren't exactly stratospheric, either. You can have damaging consequences well short of midnight police raids.
Also, "framing" people isn't necessarily the only thing you might use it for. For example, you could try to use it to drive the cost of running the system up to unsupportable levels.